InitializeResult returns Prompts and Resources in Capabilities, even when no Prompts or Resources are added to the MCP Server

[netroy]

Is your feature request related to a problem? Please describe.
When one creates a new mcp.Server, there are no Prompts, Resources, or Tools defined on it. At this point if a client connects to this server, the capabilities property on the initialize response should not return any capabilities where the featureSet is empty, because this makes the client think that there might be these features available.

Describe the solution you'd like
InitializeResult.Capabilities should only include capabilities that have a non-empty featureset.

Additional context
I can send a PR to address this. I just wanted to check if this makes sense to you folks.

Changing these lines to the following code "fixed" this issue for me.

	capabilities := &serverCapabilities{
		Logging: &loggingCapabilities{},
	}
	if len(ss.server.prompts.features) > 0 {
		capabilities.Prompts = &promptCapabilities{ListChanged: true}
	}
	if len(ss.server.resources.features) > 0 {
		capabilities.Resources = &resourceCapabilities{ListChanged: true}
	}
	if len(ss.server.tools.features) > 0 {
		capabilities.Tools = &toolCapabilities{ListChanged: true}
	}
	return &InitializeResult{
		// TODO(rfindley): alter behavior when falling back to an older version:
		// reject unsupported features.
		ProtocolVersion: version,
		Capabilities:    capabilities,
		Instructions:    ss.server.opts.Instructions,
		ServerInfo: &implementation{
			Name:    ss.server.name,
			Version: ss.server.version,
		},
	}, nil

[jba]

What if the server adds tools or other features after the client connects?
It looks like the typescript API requires you to signal that you might have tools by calling server.setToolRequestHandlers. We could do something like that.

What are the consequences of saying you support a feature when you don't?

[jba]

If this matters, I would say: let's add Server.WillAddTools(). Then at the time Server.Run is called, you must have either added a tool, or called WillAddTools to set the capability.

[jba]

We could also add HasTools, etc. to ServerOptions. Less clutter that way.

[martinemde]

Here's a few extra considerations related to this:

• A server should be able to declare that it doesn't support prompts, resources, and/or tools.
• A server should be able to inform the client that it will not send list changed notifications even if it does support one of the capabilities.

My expectation would be that ServerOptions support some form of hasPrompts: false for each type.

Here's the log from Claude desktop talking to a go-sdk MCP server I implemented that has 1 tool. Note that the client seems to re-request prompts, resources, and tools regularly (ids are increasing, so this is within the same session)

2025-07-03T00:36:59.563Z [say] [info] Message from server: {"jsonrpc":"2.0","id":0,"result":{"capabilities":{"completions":{},"logging":{},"prompts":{"listChanged":true},"resources":{"listChanged":true},"tools":{"listChanged":true}},"protocolVersion":"2024-11-05","serverInfo":{"name":"studio-mcp","version":"dev"}}} { metadata: undefined }
2025-07-03T00:36:59.564Z [say] [info] Message from client: {"method":"notifications/initialized","jsonrpc":"2.0"} { metadata: undefined }
2025-07-03T00:36:59.568Z [say] [info] Message from client: {"method":"tools/list","params":{},"jsonrpc":"2.0","id":1} { metadata: undefined }
2025-07-03T00:36:59.568Z [say] [info] Message from client: {"method":"tools/list","params":{},"jsonrpc":"2.0","id":2} { metadata: undefined }
2025-07-03T00:36:59.568Z [say] [info] Message from client: {"method":"resources/list","params":{},"jsonrpc":"2.0","id":3} { metadata: undefined }
2025-07-03T00:36:59.568Z [say] [info] Message from server: {"jsonrpc":"2.0","id":1,"result":{"tools":[{"description":"Run the shell command `say -v siri {{speech}}`","inputSchema":{"type":"object","required":["speech"],"properties":{"speech":{"type":"string","description":"a very concise message to say out loud to the user"}}},"name":"say"}]}} { metadata: undefined }
2025-07-03T00:36:59.569Z [say] [info] Message from server: {"jsonrpc":"2.0","id":2,"result":{"tools":[{"description":"Run the shell command `say -v siri {{speech}}`","inputSchema":{"type":"object","required":["speech"],"properties":{"speech":{"type":"string","description":"a very concise message to say out loud to the user"}}},"name":"say"}]}} { metadata: undefined }
2025-07-03T00:36:59.569Z [say] [info] Message from server: {"jsonrpc":"2.0","id":3,"result":{"resources":[]}} { metadata: undefined }
2025-07-03T00:36:59.574Z [say] [info] Message from client: {"method":"prompts/list","params":{},"jsonrpc":"2.0","id":4} { metadata: undefined }
2025-07-03T00:36:59.575Z [say] [info] Message from server: {"jsonrpc":"2.0","id":4,"result":{"prompts":[]}} { metadata: undefined }
2025-07-03T00:37:26.183Z [say] [info] Message from client: {"method":"tools/call","params":{"name":"say","arguments":{"speech":"Testing after reboot - is this working now?"}},"jsonrpc":"2.0","id":5} { metadata: undefined }
[Studio MCP] Tool called with args: map[speech:Testing after reboot - is this working now?]
[Studio MCP] Built command: say -v siri Testing after reboot - is this working now?
[Studio MCP] Executing command: say -v siri Testing after reboot - is this working now?
[Studio MCP] Command completed successfully with exit code 0
[Studio MCP] Final output length: 0 chars
2025-07-03T00:37:29.483Z [say] [info] Message from server: {"jsonrpc":"2.0","id":5,"result":{"content":[{"type":"text"}]}} { metadata: undefined }
2025-07-03T00:47:00.241Z [say] [info] Message from client: {"method":"resources/list","params":{},"jsonrpc":"2.0","id":6} { metadata: undefined }
2025-07-03T00:47:00.243Z [say] [info] Message from server: {"jsonrpc":"2.0","id":6,"result":{"resources":[]}} { metadata: undefined }
2025-07-03T00:47:00.246Z [say] [info] Message from client: {"method":"prompts/list","params":{},"jsonrpc":"2.0","id":7} { metadata: undefined }
2025-07-03T00:47:00.246Z [say] [info] Message from server: {"jsonrpc":"2.0","id":7,"result":{"prompts":[]}} { metadata: undefined }
2025-07-03T00:57:00.238Z [say] [info] Message from client: {"method":"resources/list","params":{},"jsonrpc":"2.0","id":8} { metadata: undefined }
2025-07-03T00:57:00.241Z [say] [info] Message from server: {"jsonrpc":"2.0","id":8,"result":{"resources":[]}} { metadata: undefined }
2025-07-03T00:57:00.242Z [say] [info] Message from client: {"method":"prompts/list","params":{},"jsonrpc":"2.0","id":9} { metadata: undefined }
2025-07-03T00:57:00.243Z [say] [info] Message from server: {"jsonrpc":"2.0","id":9,"result":{"prompts":[]}} { metadata: undefined }

[jba]

Thanks, @martinemde, for that data. It's clear we need to fix this, and in the right way: flexible, convenient, and future-proof.

The most flexible and future-proof way would be to export all capabilities symbols and let the user provide them on ServerOptions. For example, we could export the one for resources:

type ResourceCapabilities struct {
   ListChanged bool
   Subscribe bool
}

type ServerOptions struct {
    ...
    ResourceCapabilities *ResourceCapabilities
}

The logic would be:

1. If ServerOptions.ResourceCapabilities is non-nil, use it as written.
2. Otherwise, if the server has a resource at the time Server.Run is called, then it has the capability for resources, as well as list-changed and subscribe (when we support it).
3. Otherwise, the server doesn't support resources.

My main concern is with step 1. We support list-changed notifications out of the box; why let the user disable them, especially inadvertently via the default value of the ResourceCapabilities struct? Ditto for subscriptions, when we support them.

So I think a better design is an exported ResourceCapabilities that does not match the protocol implementation. Currently it would be an empty struct. If there were a reason for further configuration, like explicitly turning off list-changed notifications, we could add fields:

type ResourceCapabilities struct {
    DisableListChanged bool
    DisableSubscribe bool
}

The above logic still applies with this revised struct. Most of the time users won't have to do anything, because they will pre-register resources if they have any.

/cc @findleyr @samthanawalla

[jba]

Although that is the ultimate goal, I think today we can get by with just steps 2 and 3. That is, we will change the server to advertise only capabilities for which it has registered features.

[findleyr]

I agree that we should do 2 and 3, and see if step 1 is ever needed.

I'm not convinced that if we do step 1, we should invert the sense of the capabilities...

[jba]

#93 should fix this. Reopen if there's still a problem.