inspector icon indicating copy to clipboard operation
inspector copied to clipboard

Set completion support to false by default

Open fredericbarthelet opened this issue 6 months ago • 2 comments

Change completion support default to false and use server capabilities value to assert support for completion. Fixes #436

Motivation and Context

Current implementation always tries a first completion request on resource template or prompt usage, even if the server does not advertise support for completions. The silent error fallback currently implemented then switch back the support to false for further calls.

How Has This Been Tested?

Yes, with a server with completion, and with one without

Breaking Changes

None

Types of changes

  • [x] 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

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

Additional context

I noticed server built using the Typescript SDK were not advertising completions support - even when they do support it - unless manually specified in the server construct arguments. I opened a PR to fix that as well to ensure completions capabilities advertising and use is more coherent. Same thing for Python SDK.

  • https://github.com/modelcontextprotocol/typescript-sdk/pull/546
  • https://github.com/modelcontextprotocol/python-sdk/pull/865

fredericbarthelet avatar May 26 '25 00:05 fredericbarthelet

Thanks for this fix. If I'm understanding the typescript SDK issue correctly, it seems like typescript servers are most likely not reporting completion correctly in their capabilities? Would it make sense to wait to merge this once that fix is out so we can test with the expected state using latest sdk versus a potentially buggy one?

olaservo avatar May 27 '25 04:05 olaservo

Yep, agreed, let's wait for a new TS SDK version to be published first with this fix. I'll have a quick look on other language SDK as well in the meantime.

fredericbarthelet avatar May 27 '25 07:05 fredericbarthelet

@olaservo both TS and Python fixes have been merged. Should we move forward with this PR?

fredericbarthelet avatar Jul 07 '25 09:07 fredericbarthelet

Thanks @fredericbarthelet ! I was about to merge this, but I'm thinking we might wait until the Python SDK update is actually released, so that we can point people to update their server from the latest SDK version. We should be good on TypeScript since that was added a while back. What do you think?

olaservo avatar Jul 07 '25 12:07 olaservo

You're right @olaservo - better to wait for the next Python SDK release :)

fredericbarthelet avatar Jul 07 '25 12:07 fredericbarthelet

Should be good to go now :) OK @olaservo ?

fredericbarthelet avatar Jul 11 '25 21:07 fredericbarthelet