refactor(exceptions): MinimaxRequestError is a subclass of MinimaxAPIError, conflating two error categories

[TumCucTom]

Summary

In minimax_mcp/exceptions.py:

class MinimaxAPIError(Exception):
    """Base exception for Minimax API errors."""
    pass

class MinimaxRequestError(MinimaxAPIError):
    """Request related errors."""
    pass

MinimaxRequestError is a subclass of MinimaxAPIError, but the two represent different error categories:

• MinimaxAPIError — problems talking to the remote API (auth, network, 5xx, etc.). Worth retrying.
• MinimaxRequestError — client-side problems (missing required field, bad combination, etc.). Never worth retrying.

Because of the inheritance, every except MinimaxAPIError block in minimax_mcp/server.py also catches MinimaxRequestError. This makes it impossible for callers to handle "transient" vs "permanent" failures differently — and it complicates retry logic, metrics, and error budgets.

Impact

• All tool functions return the same generic error message format for both transient and permanent failures, even though clients might want to retry one and not the other.
• The PR test: expand coverage to server.py and __main__.py (#72) #87 test suite had to be written around the inheritance — e.g. with pytest.raises(MinimaxRequestError) works, but a hypothetical try/except MinimaxAPIError: retry() would also catch MinimaxRequestError, which is the wrong behavior.

Suggested fix

Two options, in order of preference:

1. Make them siblings under MinimaxError (rename the current base to MinimaxError or add a new neutral base). Both MinimaxAPIError and MinimaxRequestError should be siblings, not parent/child.
2. At minimum, update existing except MinimaxAPIError as e: blocks to except (MinimaxAPIError, MinimaxRequestError) as e: (or except MinimaxError as e: after the refactor) and document the categories in each tool's docstring.

Option 1 is cleaner and a one-file change.

Discovered via

Issue filed as a follow-up to PR #87 (test coverage). Tests pass either way, but the inheritance makes the error-handling story confusing for new contributors.

🤖 Generated with Claude Code

[hogeheer499-commits]

I can prepare this refactor, but there are two observable compatibility choices that seem worth confirming first:

1. If MinimaxRequestError becomes a sibling of MinimaxAPIError, the existing except MinimaxAPIError blocks in server.py will stop converting request/validation failures into TextContent errors. Should those handlers catch a new shared MinimaxError base so current MCP tool behavior is preserved, or should client-side request errors intentionally propagate?
2. client.py currently wraps requests.exceptions.RequestException (including network/timeout/5xx paths) in MinimaxRequestError. If the goal is transient-versus-permanent classification, should transport failures become MinimaxAPIError (with MinimaxAuthError remaining underneath it), while local validation/request-shape failures become MinimaxRequestError?

Once the intended public hierarchy and server behavior are confirmed, I can keep the patch small and add pure-Python inheritance/catch-path regression tests.