Proposal: export method name constants

[ChrisJBurns]

Currently there are a many constants that are private in mcp/protocol.go. Is there any objection to making them public? This would avoid having to rewrite the constants in every app that uses the sdk

const (
	methodCallTool                  = "tools/call"
	notificationCancelled           = "notifications/cancelled"
	methodComplete                  = "completion/complete"
	methodCreateMessage             = "sampling/createMessage"
	methodElicit                    = "elicitation/create"
	methodGetPrompt                 = "prompts/get"
	methodInitialize                = "initialize"
	notificationInitialized         = "notifications/initialized"
	methodListPrompts               = "prompts/list"
	methodListResourceTemplates     = "resources/templates/list"
	methodListResources             = "resources/list"
	methodListRoots                 = "roots/list"
	methodListTools                 = "tools/list"
	notificationLoggingMessage      = "notifications/message"
	methodPing                      = "ping"
	notificationProgress            = "notifications/progress"
	notificationPromptListChanged   = "notifications/prompts/list_changed"
	methodReadResource              = "resources/read"
	notificationResourceListChanged = "notifications/resources/list_changed"
	notificationResourceUpdated     = "notifications/resources/updated"
	notificationRootsListChanged    = "notifications/roots/list_changed"
	methodSetLevel                  = "logging/setLevel"
	methodSubscribe                 = "resources/subscribe"
	notificationToolListChanged     = "notifications/tools/list_changed"
	methodUnsubscribe               = "resources/unsubscribe"
)

[findleyr]

Thanks for filing.

The reason we didn't do this was to avoid polluting the mcp namespace (any more than it already is--it's a large package!).

At some point, we wished we'd moved some specific types to a separate package, but that ship sailed. Maybe if we do this, it should be in a new package (mcpspec?).

With all that said, I don't feel strongly either way about this. If people want it, I think we can do it. But we'll probably wait a bit as v1.0.0 just came out.

Probably we should discuss this at the next proposal meeting. We just had a meeting today, and a ~monthly cadence makes sense, so that means we'll probably hold this proposal until early November, which will also allow more time for feedback.

[jba]

What's an example of where you'd need to refer to those values?

[ChrisJBurns]

@jba We have several places within the ToolHive codebase that tends to have the "tools/call" string. We could have our own constant but I thought I'd ask if it was possible to put into the SDK given they are already there but privatised.

[jba]

I think you should have your own constant for that one string.

FYI, the way we think about things, "already there but privatised" is much closer to "not there at all" than it is to "exported." :)
We try to keep the API as small as possible.

[ChrisJBurns]

@jba No problems, I thought I'd raise it just in case! Happy to close this