Aligns Resources and Resource Templates with the pattern used by Tools and Prompts, and introduces auto-routing.

[Pavel-Guseynov]

Aligns Resources and Resource Templates with the pattern used by Tools and Prompts, and introduces auto-routing.

• Introduce MCP::Primitive to encapsulate common logic for all MCP primitives.
• Refactor MCP::Tool and MCP::Prompt to inherit from MCP::Primitive, reducing code duplication.
• Enable class-based definitions for MCP::Resource and MCP::ResourceTemplate by inheriting from MCP::Primitive.
• Update MCP::Server to support auto-registration of class-based resources and templates.

Motivation and Context

Using Tools in this SDK was straightforward, but when I tried adding Resources, it was confusing. The interface is totally different, the documentation is sparse, and there are barely any examples.
Unlike Tools, the lack of support for encapsulating resources into dedicated classes, combined with the need for manual registration, made it difficult to organize code efficiently.

I checked the issues and found I'm not the only one with this problem (see #98).

How Has This Been Tested?

• Ran unit tests to ensure no regressions in the existing code.
• Added unit tests covering the new class-based implementation.
• Validated the changes by using the new code in an actual project.

Breaking Changes

No. Backward compatibility is fully preserved.

Types of changes

• 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

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

Additional context

While researching the MCP documentation, I noticed a reference to -32002 for "Resource not found" errors. I initially began refactoring JsonRpcHandler to centralize exception handling to support this. However, I suspect the documentation might be outdated and that the standard JSON-RPC error -32602 (Invalid params) is actually the correct implementation.
Since I am not completely sure which code is correct, I reverted the error handling refactor to keep this PR focused. Could you confirm if -32602 is the standard? I can submit a separate PR if a broader change to error codes is required.

[koic]

Thank you for this PR and for the detailed write-up. The problem you identified is real, and this PR was a helpful reference during the design discussion for issue #98.

I'm closing this one in favor of #447, which implements the same feature: class-based definitions for MCP::Resource and MCP::ResourceTemplate, aligned with the MCP::Tool and MCP::Prompt DSL, plus automatic routing in the default resources/read handler. It also resolves the error code question left open here by returning -32602 with the URI in the error data, following SEP-2164.

The MCP::Primitive refactoring from this PR was not carried over, since it is an internal deduplication rather than part of the scope of issue #98, and the branch had drifted too far from the current main to rebase cleanly.

Thanks again for your contribution!