Consider offical MCP sdk as it is now v1

[joeblew999]

https://github.com/modelcontextprotocol/go-sdk/releases/tag/v1.0.0

I am not at expert but it’s supported officially by golang team so a steady dependency.

[kevwan]

Sure, I was planned to use the official sdk. Glad to see the v1 is out. I'll migrate to it. Thanks for your information.

[joeblew999]

Glad it is helpful . And Thankyou for considering my proposal

[kevwan]

I've started working on migrating to the official MCP Go SDK v1.0.0. Here's my approach:

Migration Strategy

1. Dependencies Added ✅

• github.com/modelcontextprotocol/go-sdk@v1.0.0
• github.com/google/jsonschema-go (for schema generation)
• github.com/yosida95/uritemplate/v3 (for resource templates)

2. Integration Approach

The go-zero MCP implementation has a unique architecture that wraps MCP server functionality within go-zero's rest.Server for HTTP/SSE transport. To maintain backward compatibility while adopting the official SDK, I'm planning a hybrid approach:

Option A: Wrap Official SDK (Recommended)

• Keep the existing McpConf and rest.Server integration for HTTP/SSE transport
• Use the official SDK's mcp.Server internally for protocol handling
• Create adapter types that bridge between go-zero's API and the official SDK
• Maintain the existing public API surface for go-zero users

Option B: Full Replacement

• Replace custom implementation entirely with official SDK
• Would require significant breaking changes to the public API
• Less desirable for maintaining backward compatibility

3. Key Challenges

1. Transport Layer: The official SDK uses its own transport abstraction (mcp.Transport). Go-zero's implementation is tightly integrated with rest.Server for SSE. Need to create a custom transport adapter.

2. Type Mapping: Many custom types (Tool, Prompt, Resource, Content types) need to map to official SDK types.

3. Configuration: Current McpConf structure needs to coexist with official SDK's ServerOptions.

4. Handler Signatures: Current handlers use func(ctx context.Context, params map[string]any) (any, error), while SDK uses more structured approaches with schema generation.

4. Next Steps

1. Create adapter types and transport bridge
2. Refactor internal implementation to use official SDK
3. Maintain public API compatibility
4. Update tests
5. Update documentation

This will be a phased migration to ensure stability and backward compatibility. I'll update this issue as progress is made.

cc @kevwan - Does this approach align with your vision for the integration? Any preferences on how to balance compatibility vs adopting SDK conventions?