modelcontextprotocol/go-sdk
Watch
1
0
Fork
You've already forked go-sdk
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
go-sdk/docs/rough_edges.md
Robert Findley 3430e2242e
 mcp: add Capabilities fields to ServerOptions and ClientOptions (#713) 
This allows users to configure default capabilities, disable defaults,
or suppress listChanged notifications by setting ListChanged: false.

Key changes:
- Add ServerOptions.Capabilities and ClientOptions.Capabilities fields.
- Merge user-provided capabilities with dynamically-added ones (tools,
  prompts, resources, sampling, elicitation).
- Check ListChanged before sending list-changed notifications.
- Deprecate HasPrompts, HasResources, HasTools on ServerOptions.
- Remove unreleased ElicitationModes field from ClientOptions.
- Add clone methods to capability structs using shallowClone helper.
- Add synctest-based tests for notification behavior (go1.25).
- Add TestClientCapabilitiesOverWire and TestServerCapabilitiesOverWire
- Document the new Capabilities API in docs/

Updates #706
2025-12-11 20:17:46 -05:00

2.1 KiB
Raw Permalink Blame History

Rough edges: API decisions to reconsider for v2

This file collects a list of API oversights or rough edges that we've uncovered post v1.0.0, along with their current workarounds. These issues can't be addressed without breaking backward compatibility, but we'll revisit them for v2.

  • EventStore.Open is unnecessary. This was an artifact of an earlier version of the SDK where event persistence and delivery were combined.

    Workaround: Open may be implemented as a no-op.

  • Event need not have been exported: it's an implementation detail of the SSE and streamable transports. Also the 'Name' field is a misnomer: it should be 'event'.

  • Enforcing valid tool names: with SEP-986 landing after the SDK was at v1, we missed an opportunity to panic on invalid tool names. Instead, we have to simply produce an error log. In v2, we should panic.

  • Inconsistent naming.

    • ResourceUpdatedNotificationsParams should probably have just been ResourceUpdatedParams, as we don't include the word 'notification' in other notification param types.
    • Similarly, ProgressNotificationParams should probably have been ProgressParams.

  • AudioContent.MarshalJSON should have had a pointer receiver, to be consistent with other content types.

  • ClientCapabilities.Roots should have been a distinguished struct pointer (see #607).

    Workaround: use ClientCapabilities.RootsV2, which aligns with the semantics of other capability fields.

  • Default capabilities should have been empty. Instead, servers default to advertising logging, and clients default to advertising roots with listChanged: true. This is confusing because a nil Capabilities field does not mean "no capabilities".

    Workaround: to advertise no capabilities, set ServerOptions.Capabilities or ClientOptions.Capabilities to an empty &ServerCapabilities{} or &ClientCapabilities{} respectively.