Repository navigation
Add title property to ModelContextTool #133
Description
This spec says name "is used by agents to reference the tool when making tool calls.". In the current MCP spec name is "intended for programmatic or logical use, but used as a display name in past specs". The problem is that name is something you use in code (e.g. in a 'toolactivated' event handler), but at the same time it should be shown to the user. The way the MCP spec nowadays handles this is that they added a second property called title:
name: string
Intended for programmatic or logical use, but used as a display name in past specs or fallback (if title isn’t present).
title?: string
Intended for UI and end-user contexts — optimized to be human-readable and easily understood, even by those unfamiliar with domain-specific terminology.
If not provided, the name should be used for display (except for Tool, where annotations.title should be given precedence over using name, if present).
And to quote the MCP spec a bit more to justify the general need to show tool names to users
For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations.
Applications SHOULD:
- Provide UI that makes clear which tools are being exposed to the AI model
- Insert clear visual indicators when tools are invoked
- Present confirmation prompts to the user for operations, to ensure a human is in the loop
Also: Are diacritics and spaces allowed in name? I vaguely recall that many MCP clients don't allow that, but neither the MCP spec nor the WebMCP spec seems to put any limit on it.
Lastly: The above was a real hurdle I hit when trying to link up some code to WebMCP: Description should probably be localized based on the locale of the page, but then you either localize name as well (gets weird in code) or you don't and you have english mixed into the text shown to the user.
Activity
kenchris commentedon Mar 9, 2026
We probably need to state that title doesn't have to be included in the definition shared with the LLM itself. Another option would be to have it be part of annotations: or similar. I expect that we might want to expand this to include icons to show in UI, just like Gemini shows the Spotify logo when interacting with Spotify. (Potentially, favicons can cover most of these use-cases, unless we want different icons per tool etc)
[My own prototype implementation of WebMCP actually adds both title and icon support, so I myself needed this]
DavidMulder0 commentedon Mar 9, 2026
titleseem from my POV to be a required property (as tools need to be shown to the user, and those need to be localized).iconsare a nice to have IMHO. Personally for something that should always be filled out for all tools it feels 'wrong' to 'hide' it in the 'annotations'.domfarolino commentedon Mar 9, 2026
I agree title is more important than icon, but neither are required per the MCP spec, right?
DavidMulder0 commentedon Mar 10, 2026
titlewas only added to the 2025-06-18 version of the MCP specification, sotitlein MCP had to be optional to be backwards compatible with previous versions. For WebMCP there is no such limitation, sotitlecan be required from v1. Note how the quote in the opening post describesnameas "used as a display name in past specs". Withouttitleyou either have no display name (obviously bad for a HITL flow) or you require webpages to localize the toolnamewhich is bound to cause issues (unsupported characters ending up in tool names is the one I walked up against, etc.)Timeline:
name,description, andinputSchemaannotationsoutputSchemaandtitleexecutionkhushalsagar commentedon Mar 31, 2026
Is the use-case for
titlecoming from an agent presenting the set of available tools to the user? So they can choose which tool to invoke.I expected
titlecan be generated by models based on the tool name, description and schema. A model generated string is necessary at runtime anyway, to explain to the user why a tool should be invoked for their query and what parameters are being passed to it.DavidMulder0 commentedon Mar 31, 2026
@khushalsagar
titleis very much not primarily for LLMs, it's about things like:Showing a list of tools in a management interface so that the user can disallow tools up front
Crucially this could (and should IMHO) be available before engaging with the LLM. Maybe one day this won't be needed anymore, but right now I think all of us (assuming all of us are developers) have seen agents going off the rails.
User consent retrieval
Crucially this should NOT be generated by the LLM, as an injection attack could then direct the LLM to give a fabricated name.
Showing the user what's going on whilst waiting for a tool to execute
Obviously any specific browser vendor might decide to do all of these or none of these, but the important thing is for the browser to have some label that's consistent across users and trustworthy. This is particularly important if a browser would for example implement the WebMCP specification using only smaller local LLMs (running LLMs is expensive 😅). I already had Gemini in Google Sheets (whilst testing) break a report of mine by making the wrong edit out of my viewport. To be fair, I was partially to blame, as I gave Gemini an impossible task (I thought there was information in the report that wasn't there), but Gemini did go a bit haywire. Definitely one of the places Google Sheets could improve, but even there they already provide some UI to control tool access: