I’ve spent most of my career thinking about how language shapes the way people move through products. As agents have begun navigating products in place of people, language shapes their experience, too. But the language for agents isn’t intentionally designed — at least not in the way product content usually is. It’s written as infrastructure rather than an interface. But it is an interface. It’s just that the user interacting with it isn’t a human.
In this new interaction model, the human is at the edges of the experience — setting a task in motion, evaluating a result — rather than in the middle of it. Agents are consuming the content and doing the work.
The parallel for this interaction model that keeps coming back to me is accessibility. Assistive technologies interpret structure and language literally. They can’t rely on visual context or spatial relationships. And, crucially, we can’t design for each piece of assistive tech individually. (Can you imagine trying to optimize for a single screen reader at a time?) Instead, we have to design according to standards that ensure the experience works with any well-built assistive technology, because we can’t control or anticipate what users show up with.
Agents work the same way. We can’t design for one specific agent in one specific context. We have to design for any agent that picks up the tool.
I started pulling on this thread by testing Webflow’s MCP (Model Context Protocol, for those who don’t know) server, which lets agents connect to and interact with Webflow. A few patterns stood out immediately.
First, the vocabulary in the tool schemas didn’t match the product UI or the language a user would actually bring to a prompt. An agent working from a plain-language request had to bridge that vocabulary gap on its own. Sometimes it did, sometimes it didn’t, apparently at random.
The tool descriptions listed what actions were available but didn’t explain when to use one tool over another, what prerequisites existed, what vocabulary users might use to request an action available in a certain tool, or what tools might be chained together sequentially. In every test session, given the same prompt, the agent took a completely different path. The path it took appeared to be determined by the order in which tools surfaced during the agent’s search. (I kept waiting for agents to arrive at a consistent approach. They did not.) Clear descrptions and sequencing would give agents a predictable and performant path to follow rather than selecting whatever tool happened to load first.
Error messages told agents what had gone wrong but not what to do about it. Research on agent tool-calling has found that most agents can’t self-correct after an error if the message doesn’t include context-specific guidance. The same way one precise word can be the bridge to user comprehension, one precise sentence can be the difference between an agent recovering from an error and an agent continuing to fail the same way, confidently, forever.
Adding more content isn’t the answer. Research on MCP tool descriptions found that adding detail without improving clarity actually regressed agent performance in roughly one in six casees. The content has to be better.
The MCP needs a terminology system — the same word for the same concept everywhere an agent (or human) might encounter it. If a user says “publish my site,” the publishing tool the agent encounters should be called publish_site (rather than deploy_site or other variations).
The sequencing problem is information architecture in a technical writing trenchcoat. For agents to effectively navigate them, tool descriptions need to work like wayfinding — they need to tell agents what the tool does, yes, but also what agents need to use it and what tool comes next. Tool descriptions are how we provide agents with the happy path.
The error messages need what all good error messages need — what happened, why, and what to do next, in plain language. Agents aren’t exempt from that structure just because they aren’t human. If anything, they might need it more, because they can’t recover based on their own experience the way a human user (albeit a confused and/or frustrated one) can.
This pattern usually runs the other direction. Content designers bemoan having to retrofit language to solve problems that product constraints created. With MCPs, the content layer has a direct, measurable effect on agent success, performance, and error recovery, which means getting it right is a prerequisite instead of something that can be shoehorned in after the interface is fully baked.
The vocabulary being established in MCPs now will shape how agents understand and communicate about these products for a long time. Patterns are forming, conventions are calcifying, and the people who think most carefully about language are almost entirely absent from the conversation. If the conversation is happening at all.