You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
completion/complete
endpoint optional when this capability is not presentDescribe 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.
The text was updated successfully, but these errors were encountered: