-
Notifications
You must be signed in to change notification settings - Fork 762
add displayValue support to completions #589
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
You'll want to update the spec in schema/draft/schema.ts and then |
Done. Thanks! |
@@ -812,7 +812,7 @@ export interface Tool { | |||
}; | |||
|
|||
/** | |||
* An optional JSON Schema object defining the structure of the tool's output returned in | |||
* An optional JSON Schema object defining the structure of the tool's output returned in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably changed due to my editor. I can revert if it matters.
@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 |
This adds (non-breaking) support for
displayName
in the completions server response which clients can use to display something different for a value than the value itself.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
/displayValue
objects 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