exceptions
Custom exceptions for MCPServer.
MCPServerError
Bases: Exception
Base error for MCPServer.
Source code in src/mcp/server/mcpserver/exceptions.py
4 5 | |
ResourceError
Bases: MCPServerError
A resource failure you anticipated.
Raise this from a resource or resource template handler for a failure you saw
coming: the client receives a -32603 protocol error carrying your message
(ResourceNotFoundError below is the -32602 variant), and the server logs it
at INFO without a traceback. Any other exception is treated as a crash: the
client gets a generic message naming only the URI, and the server logs the
traceback at ERROR.
The SDK raises it too, and UnexpectedResourceError subclasses it, so
except ResourceError around MCPServer.read_resource() catches every read
failure, crash or not.
Source code in src/mcp/server/mcpserver/exceptions.py
8 9 10 11 12 13 14 15 16 17 18 19 20 21 | |
ResourceNotFoundError
Bases: ResourceError
Resource does not exist.
Raise this from a resource handler to signal that the requested instance does not exist.
Clients receive -32602 (invalid params) per
SEP-2164.
Source code in src/mcp/server/mcpserver/exceptions.py
24 25 26 27 28 29 30 | |
UnexpectedResourceError
Bases: ResourceError
A resource read failed with something other than ResourceError or MCPError.
The SDK raises this itself, around a crash in a resource or resource template
handler. You never raise it. __cause__ is the original exception, which the
server logs with its traceback. The message names only the URI, so the
original text is withheld from the client.
Source code in src/mcp/server/mcpserver/exceptions.py
33 34 35 36 37 38 39 40 | |
ToolError
Bases: MCPServerError
A tool failure you anticipated.
Raise this from a tool (or a resolver) for a failure you saw coming: the
call returns is_error=True with your message in content for the model to
read, and the server logs it at INFO without a traceback. Any other exception
is treated as a crash: the model sees only Error executing tool <name>, and
the server logs the traceback at ERROR. A ResourceError that escapes the tool
(say from ctx.read_resource()) counts as anticipated too.
The SDK raises it too, for an unknown tool name and for arguments that fail
the input schema, and UnexpectedToolError subclasses it, so except ToolError
around MCPServer.call_tool() catches every tool failure, crash or not.
Source code in src/mcp/server/mcpserver/exceptions.py
43 44 45 46 47 48 49 50 51 52 53 54 55 56 | |
UnexpectedToolError
Bases: ToolError
A tool call failed with something other than ToolError or MCPError.
The SDK raises this itself, around a crash in the tool (or a resolver) or a
return value that fails output conversion. You never raise it. The message is
only Error executing tool <name>, so nothing from the original reaches the
client. __cause__ is the original exception, which the server logs with its
traceback before returning the is_error=True result. Catch it around
MCPServer.call_tool() to tell a crash from a deliberate ToolError.
Source code in src/mcp/server/mcpserver/exceptions.py
59 60 61 62 63 64 65 66 67 68 | |
InvalidSignature
Bases: Exception
Invalid signature for use with MCPServer.
Source code in src/mcp/server/mcpserver/exceptions.py
71 72 | |