MCP Tool Dropdown UX Improvements

[hawkticehurst]

Cataloging a list of various UX improvements to VS Code's MCP Tool Dropdown / Confirmation Card that we should discuss / implement for the April 2025 milestone.

Companion issue: #245721

Add first-time server run confirmation card

EDIT: Decided to cut this proposal/idea. See discussion below.

Currently there's a warning attached to every single tool call along the lines of:

> This tool is from 'filesystem' (MCP Server). Note that MCP servers or malicious conversation content may attempt to misuse 'Code - Insiders' through tools. Please carefully review any requested actions.

I think we can offload a lot of this language to a single confirmation card that is shown when a new MCP server is used for the first time in any given chat session.

• Goal: Allow us to simplify the language used in individual tool confirmation cards
• Goal: Surface server level controls right in chat
  • Allow server to run for the current chat session (default) –– Least trust
  • Allow server to run in the current workspace –– Medium trust
  • Allow server to always run –– Most trust

Add more information to tool dropdown closed state

Currently, the closed state of a tool dropdown only shows the name of the tool that will be run and buttons to continue or cancel the tool run. I propose that we also add the server name and simplified text warning/prompting folks to review what the tool will do before proceeding.

• Goal: Improve the ability to quickly parse which server a tool comes from
  • I know we started with a design along these lines and then moved server information inside the dropdown, but after lots of feedback I now think it's more important to surface this information at the top level
• Goal: Co-locate the text warning/prompting tool review next to the buttons where action is taken
  • Currently, this kind of information is hidden within the dropdown and is easy to miss

Design note: "Run {tool_name}" uses the foreground color token, while server name and warning text uses descriptionForeground.

Human readable tool names

@digitarald pointed out that the MCP spec now includes the ability to include a human readable tool name. It seems like most (all?) MCP servers have not started to use this yet, but as they do we should be prepared to gracefully "upgrade" to use this name instead of the "raw" tool name.

Wrap long content in see more/see less UI and add input label

Currently, tool descriptions are rendered inside tool dropdowns without any alterations. This is fine for short descriptions but they can get quite long, so we should wrap long content in a See more / See less collapsible UI.

• Goal: Ensure that all the information inside a tool dropdown remains visible / easy to parse

Additionally, we do not label tool input and think we should.

• Goal: Improve clarity of what the JSON/text snippets inside tool dropdown represent

See more/see less closed:

See more/see less expanded:

Add more information to post-tool-run dropdown

Currently, post-tool-run dropdown just include an unlabeled JSON/text snippet of the tool run output. I propose we add the following:

• Tool description
• Tool input
• Add label to tool output

Note that all of these can be wrapped in the collapsible See more / See less UI mentioned above if needed. Additionally, add a green check mark to the far right of the tool run dropdown title section.

• Goal: Make it easier to go back and review/audit a tool run by adding all the relevant information someone might want/need
• Goal: Add further visual indication that the tool run was successful while maintaining the ability to have a dropdown chevron

Overall tool dropdown UI polish

While a lot of UI changes/polish have already been demonstrated in the screenshots above, two more updates that haven't been noted yet are:

• Wrap post-tool-run content in rounded rectangle/card UI
  • Goal: Add a consistent visual indicator to tool usage in chat views
  • Goal: Ensure that checkmark icons are easy to parse / associate with a given tool run
• Adjust hover / click area to take full width of dropdown header
  • Goal: Make it easier to identify / open tool dropdowns

[hawkticehurst]

cc @digitarald @connor4312 @roblourens @jrieken

[Sayvai]

I've created a new UX improvement issue 🧐

• Feature Request: Add MCP Server Name to MCP Tool Selection Options in Copilot Chat Prompt Input #246298

[isidorn]

Overall I really like the direction here.
My only concern is the "Carefully review the proposed actions" bit - and other affordances with the "careful" word. I worry that the experience already has a lot of text, and I wonder if we should cut this (and show it on hover?)

[hawkticehurst]

My only concern is the "Carefully review the proposed actions" bit - and other affordances with the "careful" word. I worry that the experience already has a lot of text, and I wonder if we should cut this (and show it on hover?)

Ahh right! Thank you for calling this out @isidorn! I totally forgot to include a note saying that I'm actually not a big fan of the current copy and would explicitly love some feedback on this. Perhaps cc @ntrogh

With that said, I'm actually not totally against the idea of cutting this text and moving it to a hover (button hover??). I can see an argument that you'll see that server first-run card a fair few times, so that could carry nearly all of the weight for this UX pattern. @kkbrooks would also like your input on this.

[roblourens]

Looks really nice! I'm just not sure when exactly the "server run confirmation" shows- at this point, the server has been started, we have to do this before sending the request. So then it's just a two-step confirmation each time a tool from that server is used? Having the "always allow" option implies that if I just click "Continue", then I would see that server confirmation next time as well?

[hawkticehurst]

I'm just not sure when exactly the "server run confirmation" shows- at this point, the server has been started, we have to do this before sending the request.

My thinking was that this would be shown right before the first tool call from any server that hasn't yet been run in the current chat session.

But to your wider implied point, this is definitely one of the weird oddities of this UI that could be worth discussing more. The card implies that the server hasn't started yet (even though it has). I tried my very best to be precise with the language in the card –– I don't actually say anything about the server already running or not, just that it/it's tools are about to be used for the first time (in this session).

So then it's just a two-step confirmation each time a tool from that server is used?

No, by default this would only be shown one time per chat session per server. You can kind of think of it as granting permission for the server to be used during that session. Individual tool calls from that server will still be prompted, however.

Having the "always allow" option implies that if I just click "Continue", then I would see that server confirmation next time as well?

Yes, the default would be to re-show this confirmation dialog for each new chat session.

My thinking was that "always allow" would mean you would never see that confirmation card ever again. Unless you manually go into the settings and revoke that permission, that server will be allowed to be run across all chat sessions and workspaces.

But again, individual tool calls from that server will still be prompted (unless you grant permission for specific individual tools to run without manual confirmation).

[kkbrooks]

@hawkticehurst I'd recommend checking the string in Writer to see what it comes up with based on the Microsoft style guides. I think @ntrogh is already out on holiday so let's see how far that can get us while he's away. He can give his expert opinion when he returns 😄

My thinking was that "always allow" would mean you would never see that confirmation card ever again. Unless you manually go into the settings and revoke that permission, that server will be allowed to be run across all chat sessions and workspaces.

I think Always Allow would be good. Might be worth looking at the Microsoft sign in flow because they have a similar concept. I think they have something like "don't show again" (that never actually works).

[hawkticehurst]

I'd recommend checking the string in Writer to see what it comes up with based on the Microsoft style guides.

After some iteration, how do folks feel about "Review tool details in the dropdown before continuing."?

I specifically like that there's now a clear indication that you are supposed to review the contents inside the dropdown. I had gotten feedback during some design crits last week that expanding the dropdown to find tool details would be easy to miss without some more explicit direction.

[digitarald]

Add first-time server run confirmation card

To focus the conversation this could be removed it from this UX discussion. I'd think I enable a server when I install it or once I click the checkbox in the tool picker; not having it in every new session in the chat. Worst case that it further worsens the approval-blindness.

filesystem (MCP Server)

Do we show (Extension) in other UIs in VS Code? If there's a way to go through the source of that tool, either server or extension, it doesn't need a label. Maybe an icon?

"Review tool details …"

This seems noise, when imagine getting this UI 15 times per session. Maybe it can be limited to the first tool call during a session?

[connor4312]

Overall nice 👍

Worst case that it further worsens the approval-blindness.

Yea, I don't think the "first-time server run confirmation card" adds anything useful. The server is already running at that point, and we'll already ask to confirm before using any of its tools, add another approval step doesn't do anythng.

Review tool details in the dropdown before continuing

Imo no need to call this out explicitly, twisties are already ubiquitous in VS Code UI, i don't think we need to teach users that they can be used in this surface.

Wonder if we can streamline for the common case of 1-off approvals, and show an "Approve [Once]" button inline and show the two "Continue+" and "Cancel" buttons only once expanded

[roblourens]

Do you have the tool confirmation collapsed by default? Could we just have it expanded by default (or maybe not even collapsible, you just see part of the description with 'see more', and the input editor, capped at ~5 lines and scrolling).

Is the argument for that just that it would be noisy?

I was just thinking about this today because I was using some MCP tools that I'm not familiar with, and we have this nice keyboard shortcut to run the tool, but I didn't think that I could really make an informed decision without grabbing my mouse to click and seeing the input anyway.

[digitarald]

i don't think we need to teach users that they can be used in this surface.

I've seen many MCP demos and very few users ever open the tools even though it would help to explain what's happening behind the scenes.

+1 on keyboard shortcuts to expand and confirm.

Wonder if we can streamline for the common case of 1-off approvals, and show an "Approve [Once]" button inline and show the two "Continue+" and "Cancel" buttons only once expanded

I think it has to be clear that this step is waiting on user interaction, which a small play button might not convey as well. I'd also want the "allow always" buttons to be more visible by default (I pick them based on the tool, not the input).

Adding to the line of thought: Remove cancel button. The user could as well just reply in the chat input. Maybe we can also introduce a more visible "stop" UI closer to where the streaming is happening.

[hawkticehurst]

To focus the conversation this could be removed it from this UX discussion.

Yea, I don't think the "first-time server run confirmation card" adds anything useful.

Yeah @digitarald and I chatted offline today and I can get behind removing the server first run card!

For posterity, the initial motivation for this first-time server card was the belief that we should be showing a warning more prominently (vs hiding it away), since the potential risk to your machine is very high when using an MCP server.

I had tried to move the current warning outside of the tool dropdown, but it made the card feel really clunky/information dense, so I ultimately landed on the idea of a new separate card that would show up right before any tool calls are made.

But after the chat with Harald, we decided prioritizing a UX that keeps people in a smooth flow state is more important here. So I'll update the OG post and will update some of the designs to reflect this.

If there's a way to go through the source of that tool, either server or extension, it doesn't need a label. Maybe an icon?

@digitarald could you explain this a bit more? What does "go through the source of that tool" mean?

Regardless, I can reach out to our icon designer David and see if we can come up with some ideas for this! Just to reconfirm, the only two types of tools that will run via this UI are from MCP servers and extensions correct?

This seems noise, when imagine getting this UI 15 times per session. Maybe it can be limited to the first tool call during a session?

Yeah that's fair feedback. It'll ultimately just become something that folks ignore pretty quickly and just take up visual space, so I'm happy to look into ways that we can remove it.

With that said, I'm not sure I like the idea of showing this message on the first tool call, just because this message is so co-located with the tool itself. I worry that it would make it look like the first tool to be run is "extra risky" while the others are not.

i don't think we need to teach users that they can be used in this surface.

Echoing @digitarald's point, I unfortunately do think it's something that a lot of people will miss. The concern that this dropdown is not discoverable enough, was a pretty consistent bit of feedback I got while gathering feedback on this work.

Wonder if we can streamline for the common case of 1-off approvals, and show an "Approve [Once]" button inline and show the two "Continue+" and "Cancel" buttons only once expanded

I really love the UI mock you proposed @connor4312! I spent several design iterations exploring something very similar, but your proposal is even cleaner than where I got with it! Sadly, I ultimately agree with @digitarald though, I worry it would be too easy to miss that there's an action that the user needs to take here.

Is the argument for that just that it would be noisy?

@roblourens yep pretty much. But honestly, at this point I'm willing to give an already expanded tool card a shot. It would solve several of the problems mentioned above regarding discoverability.

Adding to the line of thought: Remove cancel button. The user could as well just reply in the chat input. Maybe we can also introduce a more visible "stop" UI closer to where the streaming is happening.

I actually quite like this 🧐

We could replace cancel with "Always allow" and then I do actually have some ideas for moving the stop UI to a more discoverable place. Changing the current UI has been something I've been meaning to file an issue about.

[roblourens]

Adding to the line of thought: Remove cancel button. The user could as well just reply in the chat input.

I'm unsure about this, I'm thinking that a big blue button is demanding an interaction, and we should give users an "out". If I can't dismiss the thing, like if I want to stop the interaction and not send another message, then I might feel unsettled.

But honestly, at this point I'm willing to give an already expanded tool card a shot. It would solve several of the problems mentioned above regarding discoverability.

For my personal use, I'm feeling like I often can't make a good decision without seeing the details. But Cursor hides them too

How am I supposed to confirm this without clicking? The details are very important... way too vibe coding for me. But maybe other people just want to do stuff quickly and sort it out later.

[hawkticehurst]

I'm unsure about this, I'm thinking that a big blue button is demanding an interaction, and we should give users an "out". If I can't dismiss the thing, like if I want to stop the interaction and not send another message, then I might feel unsettled.

Lol after having the weekend to think about this I came to the exact same conclusion. We definitely should always leave an option/affordance to dismiss one of these cards (or any place where we ask for the input of a human for that matter).

At this point I'm willing to give an already expanded tool card a shot.

Here's what it might look like to have a tool run card that is expanded by default / has no dropdown. I still propose that post-run UI includes the dropdown however.

I'm honestly liking this direction:

• It solves the problem of discoverability
• It kind of solves the keyboard shortcut problem (no need to have keybindings to expand and then run)
  • There's still the issue of the "See more" sections, but at least it's better than not seeing any information at all
• The "See more" UI ensures that the card always has a "default" size
  • Note: The "default" size would vary a bit depending on whether the Input JSON/text snippet needs to be collapsed too
• It's honestly not as noisy as I thought it would be –– but would love to get other opinions on this

Some other tweaks:

• Included a third button for "Always Allow"
  • Note that the split button would still include "Allow for this Session" and "Allow for this Workspace"
• In previous mocks I show the Output JSON/text snippet show 3 lines of text in a collapsed view, now it's just one line of text

[connor4312]

Sadly, I ultimately agree with @digitarald though, I worry it would be too easy to miss that there's an action that the user needs to take here.

I wonder if we could also use some gentle motion animation to hint to the user that it's waiting for them.

It's honestly not as noisy as I thought it would be –– but would love to get other opinions on this

I wonder what you're thinking of showing when there is substantial input to the tool. What you have shown is not too noisy but with more input I think it could noisy to the point where I would not want it expanded by default

[hawkticehurst]

I wonder what you're thinking of showing when there is substantial input to the tool.

My thinking is that the Input section will get the same "See more" treatment.

The result is that by default you will only see one line of text for the description and input.

I can send a new mock that demos a long input.

[hawkticehurst]

I can send a new mock that demos a long input.

[roblourens]

I like this expanded design. For the input editor, I think I'd rather have it capped to some max # of lines, and scrollable, than click to expand. Because there will still be cases with very long inputs.

[hawkticehurst]

Oh great call out. I'm mostly on board with this idea, but the one call out I'll make is that this would result in a scrolling container inside a scrolling container which I generally try to avoid due to the scroll trapping that can happen.

But with the length of output responses I've seen from tools, I think the trade off is probably worth it here.