Consider restricting maximum input lengths

[johannhof]

We have generally made the observation that shortening any web-exposed text consumed by an agent reduces an attacker's ability to run prompt injection attacks (or, phrased differently, dramatically shrinks the total universe of injections available to an attacker). This doesn't fully solve for prompt injection but complements other means of defense such as classifiers or supervisor / critic models.

Anecdotally, there is also a cutoff at which long elaborate prompts tend to confuse models more than help them from a quality perspective, and the added instruction set of many available tools could contribute to a bloated model context.

I'm not sure if there's any published research on this yet, at least I haven't read any, and this is based on practical red teaming experience. Nonetheless, we should consider this at the design phase for WebMCP, since it would be very hard to implement such a restriction retroactively (and if research would disprove my experience, extending the maximum length is trivial).

Can we find some conservative maximum character length for all developer-provided inputs such as tool name, description, property names / descriptions, etc.?

cc @victorhuangwq @khushalsagar

[bwalderman]

This makes sense given the state of LLMs today, but the maximum viable length could increase in the future as models become more powerful and may vary a lot between different models even now. For example, a local SLM generally won't be able to handle as long/complex tool descriptions as a higher-tier LLM can. So, I'm not sure enforcing a single universal limit for names and descriptions in the web platform API is a good idea.

We could consider letting browser implementations set a quota for tool context and provide an API to get the quota. The Prompt API does something similar: https://webmachinelearning.github.io/prompt-api/#dom-languagemodel-inputquota

[victorhuangwq]

Providing some kind of reasonable limit or quota for fields that really shouldn’t be long feels like the right direction. As you said, it raises the bar for antagonistic use cases, as they’d have to get a lot more creative with a much smaller token budget. Brandon’s quota idea also seems like the more future‑proof option for a spec.

Tool names and property names are easy to cap. Descriptions are where it requires some consideration, since “reasonable” can be dependent on implementation / subjectivity. But it’s worth calling out that most of the prompt‑injection examples I have seen through MCP metadata happen in the description field. That’s probably because descriptions are often not scrutinized as closely by people using them (assuming most people just glance at their list of names of their mcp tools once in a while).

Anecdotally, there is also a cutoff at which long elaborate prompts tend to confuse models more than help them from a quality perspective, and the added instruction set of many available tools could contribute to a bloated model context.

I think this is in line with recent trending conversations about progressive disclosure (e.g. claude skills), so as to not lead to context bloat.

[xfq]

(Adding i18n-tracker label, since it might be related to https://w3c.github.io/bp-i18n-specdev/#char_truncation )

[JasonColapietro]

Production evidence from Suede Agent Studio's deployed WebMCP storefront, originally reported in #266: when a tool description exceeds a published per-field character budget, the overrun is silently truncated. For a commerce tool, the omitted text can include price or review-policy caveats, leaving a buying agent with an incomplete description at decision time.

That makes the effective input length a product and safety constraint, not just a prompt-size optimization. Whatever limit or quota model is chosen, authors need to be able to detect an overrun before material terms disappear silently.