Internationalization considerations

[christianliebel]

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.

[DavidMulder0]

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 name and description should 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:

1. 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

   • name will not be shown to the user
   • title will be shown to the user (see Codify MCP tool name requirements and add title #152)
   • description will not be shown to the user
   • Perhaps inputSchema should 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).

2. 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".

[xfq]

(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 name is an application internal identifier, it should probably be a stable ASCII identifier, not localized, and not shown to users.

If title is the human-facing label, it should consider the page/site/app/user UI locale, not just navigator.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 title or other strings can appear in browser/native UI, the spec need some kind of dir handling.