fix: Raise resource not found error

[vincent0426]

Introduce resource not found error handling following the MCP specification.

This change ensures that when a resource is not found, the server returns error code -32002 (RESOURCE_NOT_FOUND) as specified in the Resources Error Handling.

Concern: There is currently no explicit error handling for FastMCP exceptions in the low-level server. I'm not sure if we want to wrap fastmcp exceptions under McpError to raise the correct error code which avoid changing the low-level server code, otherwise, sdk might need to create a new exception type to handle non-connection error?

Motivation and Context

Closes https://github.com/modelcontextprotocol/python-sdk/issues/1579

Previously, when a resource was not found, the server returned error code 0 (generic error) instead of the spec-compliant -32002 (RESOURCE_NOT_FOUND).

Root Cause:

• FastMCP raises ValueError when a resource is not found
• low-level server's exception handler was not properly recognizing these exceptions
• Exceptions without an error attribute were converted to ErrorData(code=0, ...)

https://github.com/modelcontextprotocol/python-sdk/blob/3390e49c01e297d3cc8a4917c886d1009f279e45/src/mcp/server/lowlevel/server.py#L705-L708

Solution:

• Added ResourceError exception class with an error attribute containing ErrorData with the appropriate error code
• Updated ResourceManager to raise ResourceError with RESOURCE_NOT_FOUND code for unknown resources

How Has This Been Tested?

• unit test
• Reproduced and verified the fix for the original issue

data: {"jsonrpc":"2.0","id":7,"error":{"code":-32002,"message":"Unknown resource: https://example.com/does-not-exist"}} 

Breaking Changes

Types of changes

• [X] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] Documentation update

Checklist

• [X] I have read the MCP Documentation
• [X] My code follows the repository's style guidelines
• [X] New and existing tests pass locally
• [X] I have added appropriate error handling
• [X] I have added or updated documentation as needed

Additional context

[maxisbey]

Related: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1545

Due to ongoing discussions around exactly what errors to use here we should wait on that before merging any fixes for this.

[fennb]

Related: modelcontextprotocol/modelcontextprotocol#1545

Due to ongoing discussions around exactly what errors to use here we should wait on that before merging any fixes for this.

FWIW, the protocol spec discussion acknowledges that -32002 is wrong (typo) and -32602 is actually "correct" (or at least, what was intended). The official (reference) typescript SDK also returns -32602. Given this is the official python SDK and code 0 is clearly wrong, my proposal would be to bring the python SDK inline with the (reference) typescript SDK, regardless of the "bug" in the spec.

At least that way, clients developing against the reference server implementations will be 100% consistent (and, ultimately, correct, if not for the spec documentation issue)?