feat: Add support for Completions Metadata#589
feat: Add support for Completions Metadata#589kentcdodds wants to merge 1 commit intomodelcontextprotocol:mainfrom
Conversation
|
You'll want to update the spec in schema/draft/schema.ts and then |
|
Done. Thanks! |
|
@SamMorrowDrums also requested this |
|
Yep, for things like GitHub issue numbers, commit shas and pull request numbers, it would be great to give some more user friendly context. |
|
Could make sense to change this to |
kentcdodds
left a comment
There was a problem hiding this comment.
Gonna switch to title
|
I'd still love to get this in front of people. |
|
I've opened a proper SEP: #1440 |
ee2282a to
bec38f0
Compare
|
@kentcdodds is this still the right implementation or should we close this PR? |
|
This PR represents the latest of the proposal to the best of my ability :) |
|
@kentcdodds do you mind resolving the schema conflicts in this PR? |
|
Done 👍 Thanks! |
- Introduced the CompletionValue interface to standardize completion value structure with title, value, and optional description - Updated CompleteResult interface to reference CompletionValue for its values property - Enhanced completion documentation to reflect new structure with description field - Adjusted JSON schema to define CompletionValue and replace inline definitions with references
This adds (non-breaking) support for
titleanddescriptionin the completions server response which clients can use to display something different for a value than the value itself.SEP: #1440
Motivation and Context
@connor4312 demonstrates the need for this in a real world setting today:
The user experience could be much better if they could provide display values.
Here's another example from a Journaling server I run (screenshot from MCP Inspector):
This is the best they can do. Users have to just know what ID they want. Would be better if I could display the journal entry title and the date in parentheses.
With this setup, the user would naturally type the title rather than the ID and the server could filter based on the title (or any other field) instead of just the ID.
How Has This Been Tested?
No, but it's a common pattern in many libraries with UX experiences like this.
Breaking Changes
I'm not a huge fan of having two ways to do this, but for simple use cases, it's much better to just use an array of strings so there's a good argument to support both an array of
value/displayValueobjects as well as an array of strings. If we do go this direction, then there is no breaking change here.Types of changes
Checklist
Additional context
Closes #585