Errors

The MCP server surfaces the same coded errors as the REST API. A failure inside a tool produces the same code, message, and HTTP status on both. Arguments that don't match a tool's input schema are refused before the tool runs, with a plain-text error.

Tool errors

A tool failure comes back as an MCP CallToolResult with isError: true and a JSON error payload:

{
  "error": {
    "code": "API_KEY_NOT_AUTHORIZED_FOR_LIBRARY",
    "message": "Not authorized for this library.",
    "status": 404
  }
}

• code: the stable, machine-readable failure mode. Dispatch on this.
• message: a human-readable string safe to show to end users.
• status: the HTTP status the same error returns over REST, so clients can reuse REST-oriented error handling.

Invalid arguments

Arguments that don't match a tool's input schema (a required argument missing or empty, or a list or string over its limit) are refused before the tool runs, and nothing changes. The result has isError: true and one plain-text block, with no code or status:

MCP error -32602: Input validation error: Invalid arguments for tool delete_assets: Maximum of 100 assets can be deleted at once. at ids

Each failing argument adds one <message> at <argument> line.

Resource errors

A failed resource read surfaces as a JSON-RPC error whose message carries the same text as the equivalent tool error. The JSON-RPC error envelope carries the message only; for machine-readable code and status, use the equivalent tool, whose error payload always includes both.

Error-code reference

The codes, their messages, and the HTTP status each maps to are the same across transports. The full table lives in the REST reference:

The codes you'll most often see from MCP tools: