Skip to content

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

kentcdodds
Copy link

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:

Screenshot of a tweet by @connor4312 stating, “I would use this in VS Code 👍 Our current UI for prompt completions:” followed by an image of a dark-themed UI dropdown titled “temperature (1/2)” with a text input labeled “Temperature setting” and options including “Insert as text”, “Run as Command”, and temperature values: 0, 0.5, 0.7, and 1.0. The option “0” is highlighted.

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):

Dropdown UI from the MCP Inspector Resource Templates tool. The section is labeled “entry” with a subheading “A single entry.” The user is selecting an id from a searchable dropdown input. The list includes values in descending order: 71, 61, 51, 41, 31, 21, 19, down to 1, which is currently selected and indicated with a checkmark.

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

  • 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

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

Additional context

Closes #585

@connor4312
Copy link
Contributor

connor4312 commented May 28, 2025

You'll want to update the spec in schema/draft/schema.ts and then npm r generate:json to update the JSON schema

@kentcdodds
Copy link
Author

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants