[Server] Added possibility to set custom ServerCapabilities.

[ineersa]

Added setServerCapabilities method to builder to allow setting of custom ServerCapabilities.
Implemented application tests as proof of concept.

Motivation and Context

Resolves #66
It allows setting of custom server capabilities, for example if we will be implementing logging capability.

How Has This Been Tested?

Added unit test, implemented application tests

Breaking Changes

Non breaking

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

I couldn't test initialize response via Inspector tests, so as discussed in slack tried to implement Application tests as proof of concept.

CONS of Inspector tests:

• running as global npx package, no version pin
• requires npm+npx to run and all infrastructure, one more dependency
• they are quite slow
• supports not everything Supported methods include: tools/list, tools/call, resources/list, resources/read, resources/templates/list, prompts/list, prompts/get, logging/setLevel, Inspector doesn't provide access to initialize response, so we can't test server capabilities for example.
• coding agents can't run tests with npx inside, I guess some weird issues with envs and sandboxes.

CONS of application tests:

• need to implement client logic to test things, for example if we add logging capability current application test won't catch error, but Inspector will throw Failed to connect to MCP server: MCP error -32601: No handler found for method "logging/setLevel".

If we will add some client logic to ApplicationTestCase like initialization, logger setting etc. it will work same as Inspector but without overheads of npm. All test in \Mcp\Tests\Application\ManualStdioExampleTest runs in 200ms for example, and are quite easy to implement.

[chr-hertel]

I don't see the value in additional functional tests tbh, but would rather focus on unit tests + high level inspector-based tests.

Can we decouple that discussion please from the actual feature about custom server capabilities. what is your use case of defining that explicitly? is the built-in logic wrong or not sophisticated enough?

[ineersa]

Sure I will move tests to a separate PR.

As for custom ServerCapabilities, issue was created on a slightly different version of code, now it handled better.

For example:

• we return that we have completions always, even if we don't have them
• i was thinking about adding logging at that point in time and logging capability was a first step for that
• tool/prompts/resources updates, I don't think those can be send now at all, since there is no event loop but capabilities are present

If you prefer managing capabilities internally we can close issue/PR.

EDIT: removed tests, squashed

[CodeWithKyrian]

+1 on adding a custom way to control ServerCapabilities.

I think it makes perfect sense as users should be able to toggle off things like list change notifications if they don’t need them, or as @ineersa mentioned, disable completion or logging altogether.

Also, looking ahead: once we support user-defined handlers, they’ll definitely need a way to manage their own capabilities too and enable only what’s relevant.

[chr-hertel]

Needs a rebase, but than a good start.

I wonder if going forward more explicit methods like disableLogging could be a thing.

[ineersa]

Needs a rebase, but than a good start.

I wonder if going forward more explicit methods like disableLogging could be a thing.

Rebased, it makes sense yeah.
Some capabilities like tools/resources/prompts can be automatically determined and some like logging can be enabled/disabled.

[chr-hertel]

i guess we could get rid off the two additional ifs (here and in the setter) by just going with:

Suggested change

	return $this->serverCapabilities;
	return $this->serverCapabilities ?? new ServerCapabilities(
	tools: [] !== $this->tools,
	toolsListChanged: $this->eventDispatcher instanceof EventDispatcherInterface,
	resources: [] !== $this->resources || [] !== $this->resourceTemplates,
	resourcesSubscribe: false,
	resourcesListChanged: $this->eventDispatcher instanceof EventDispatcherInterface,
	prompts: [] !== $this->prompts,
	promptsListChanged: $this->eventDispatcher instanceof EventDispatcherInterface,
	logging: false,
	completions: true,
	);

or am I wrong?

[ineersa]

Reason to have if here is that some tests was using get without set, so I didn't want to break it.

I removed new ServerCapabilities from setter, and had to add guard in \Mcp\Server\Builder::build.

It doesn't feel right either way.

Maybe we could create new ServerCapabilities inside \Mcp\Server\Builder::registerCapabilities which would feel better?

If you want to keep it in Registry I modified code accordingly.

[chr-hertel]

Also needs to be a signed commit, please

[chr-hertel]

Thank you @ineersa!