Specific ToolNotFoundError for easier handling than ToolError in multi-tenant environments

[DevonFulcher]

Description

We are running a remote MCP server and we are seeing errors like:

mcp.server.fastmcp.exceptions.ToolError: Unknown tool: <unknown-tool-name>

I'm unsure why our users are trying to call our remote MCP server with the name of a tool that we don't manage. Regardless, we would like to handle these errors separately from a generic ToolError. For instance:

• ToolNotFoundError: user error that shouldn't alert us.
• ToolError: an error that could indicate an actual issue with our system that we should alert on and fix.

References

I couldn't find any issues related to this.

[RudrenduPaul]

I'd like to implement this.

My plan: add ToolNotFoundError(ToolError) to src/mcp/server/fastmcp/exceptions.py and raise it in the tool-dispatch path instead of a bare ToolError when the requested tool name isn't found. This allows callers to distinguish between "tool not found" and other tool errors.

Small, self-contained change with a test. Would maintainers like a PR for this?

[RudrenduPaul]

Hi — I'd like to implement this. Making ToolNotFoundError a subclass of McpError (or a specific base exception) would let callers catch tool-not-found specifically without having to inspect error messages.

My plan:

1. Add ToolNotFoundError(McpError) to exceptions.py
2. Raise it in the tool dispatch path where tool_name not in tools
3. Add a test that catches ToolNotFoundError specifically

Will keep the change minimal. Let me know if there's a preferred exception hierarchy or if you'd like it to carry additional fields (e.g. the tool name that was requested).

[maxisbey]

What does adding a separate exception type get you here? Are you somehow catching it explicitly?