Repository navigation
Internationalization considerations #153
Description
Currently, the description property for tools accepts a single string. Because the success of an agent invoking the correct tool often depends on semantic matching with this natural-language description, the specific language used is a critical factor. If the user operates the agent in a language different from the tool's descriptions, it may lead to suboptimal tool selection. The success also depends on the language model powering the agent. However, neither the user's language nor the underlying model is exposed to developers. It would be great if you could provide developer guidance and/or coordinate this early on with the i18n WG.
Activity
DavidMulder0 commentedon Mar 23, 2026
I’ve been thinking about this: on the one hand, LLMs reason and perform agentic tasks best in English (or at least "world languages" like English or Chinese), so it likely makes sense that
nameanddescriptionshould not be localized. At the same time, small models do struggle with mixing languages, creating a risk of unintended language switching (Although, we've had success by simply repeating the "you should answer in X" instruction at the end of each reasoning section, so probably not a major issue)Anyway, I think that leaves from my POV two potential improvements:
I would want to see in the spec clear 'rules' on what will be shown to the user, and what will be shown to the LLM, for example
namewill not be shown to the usertitlewill be shown to the user (see Codify MCP tool name requirements and add title #152)descriptionwill not be shown to the userinputSchemashould carry strings that would be shown to the user if a tool call is visualized (alternatively, the website could control the visualization of tool calls, though that feels like a major undertaking).While the website knows the target language for localizing user-facing strings (via
navigator.languages), WebMCP should maybe expose the "preferred language of the model." While there is a slight fingerprinting risk, for the vast majority of models (and thus users), this will likely be English, Chinese and perhaps one day Arabic or Spanish.It is worth considering though whether the minor fingerprinting risk is worth the minor improvement compared to websites 'guessing' the language to use based on
navigator.languages, e.g. "if chinese, use chinese tools, otherwise use english tools", would right now be "perfectly good enough".Add note to title that it should be localized to the user's language w…
xfq commentedon May 13, 2026
(The following are some of my unsorted initial reactions, not formal recommendations from the i18n WG.)
You should probably not solve it by exposing “the model’s preferred language” to websites. That is an implementation detail, likely fingerprinting surface, and not stable. Model language, user language, page language, and browser language are different concepts.
If
nameis an application internal identifier, it should probably be a stable ASCII identifier, not localized, and not shown to users.If
titleis the human-facing label, it should consider the page/site/app/user UI locale, not justnavigator.language.For
inputSchema, human-facing labels/descriptions for parameters and enum choices need to be localized.It is reasonable developer guidance to say that an English fallback is useful today because many tool-use models are strongest with English metadata. But making English normative would be bad design and wrong for a web standard. WebMCP also targets assistive technologies, not just LLMs.
If
titleor other strings can appear in browser/native UI, the spec need some kind ofdirhandling.