go-zero icon indicating copy to clipboard operation
go-zero copied to clipboard
verified publisher icon zeromicro

Consider offical MCP sdk as it is now v1

Open joeblew999 opened this issue 2 months ago • 4 comments

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.

joeblew999 avatar Oct 02 '25 02:10 joeblew999

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.

kevwan avatar Oct 02 '25 07:10 kevwan

Glad it is helpful . And Thankyou for considering my proposal

joeblew999 avatar Oct 04 '25 02:10 joeblew999

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/[email protected]
  • 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?

kevwan avatar Oct 05 '25 08:10 kevwan

Because the official sdk is using go 1.23, we need to postpone the integration later when we upgrade go version to 1.23 in go-zero.

kevwan avatar Nov 01 '25 05:11 kevwan