Is your feature request related to a problem? Please describe.
While implementing MCP server support in mcpdotnet, we noticed that unlike other capabilities (resources, tools, prompts, logging, etc.), completion support is implicitly mandatory for all servers. This leads to inefficient implementations where servers must handle completion requests even when they don't provide any meaningful completion functionality, returning empty results. The reason for this isn't immediately clear from the specification documentation.
Describe the solution you'd like
We propose:
- Adding an optional "completion" capability flag to ServerCapabilities
- Making the completion/complete endpoint optional when this capability is not present
- Adding explicit documentation about completion handling requirements
- If completion must remain mandatory, documenting the rationale in the specification
Describe alternatives you've considered
Current workaround is to implement empty completion results (this is what we will be doing in mcpdotnet as a fallback if no completion handler is registered), but this creates unnecessary rpc traffic and processing overhead for servers that don't need completion functionality.
Additional context
This change would align completion handling with other MCP capabilities' optional nature. While this would technically be a breaking change, existing servers already supporting completion wouldn't be affected, and clients could easily adapt by checking the capability flag before making completion requests. This could also be a performance gain for clients when dealing with servers that don't provide this capability.
If completion support must remain mandatory for all servers, it would be valuable to document the architectural reasoning behind this decision in the specification.
Is your feature request related to a problem? Please describe.
While implementing MCP server support in mcpdotnet, we noticed that unlike other capabilities (resources, tools, prompts, logging, etc.), completion support is implicitly mandatory for all servers. This leads to inefficient implementations where servers must handle completion requests even when they don't provide any meaningful completion functionality, returning empty results. The reason for this isn't immediately clear from the specification documentation.
Describe the solution you'd like
We propose:
Describe alternatives you've considered
Current workaround is to implement empty completion results (this is what we will be doing in mcpdotnet as a fallback if no completion handler is registered), but this creates unnecessary rpc traffic and processing overhead for servers that don't need completion functionality.
Additional context
This change would align completion handling with other MCP capabilities' optional nature. While this would technically be a breaking change, existing servers already supporting completion wouldn't be affected, and clients could easily adapt by checking the capability flag before making completion requests. This could also be a performance gain for clients when dealing with servers that don't provide this capability.
If completion support must remain mandatory for all servers, it would be valuable to document the architectural reasoning behind this decision in the specification.