Why Tool Routing and Intent Lock Matter in MCP Server Design

Model Context Protocol (MCP) enables a language model to call tools on external systems through a standard interface. In practice, it's not the protocol itself but the server-side tool design that is decisive: tool names, parameter schemas, and error messages directly shape the model's behavior.

When testing a multi-domain MCP server, a typical problem is encountered: while a user searches in one domain, the model calls a tool from another domain due to name or parameter similarity. This is called intent drift. For example, a user's request to search for an intercity bus might be routed to a vehicle allocation tool because the parameter set is similar. This stems less from the model's error and more from the ambiguity of the interface design.

What is intent lock? It's the practice of maintaining the session's active domain on the server side and checking for a match with this domain on every tool call. When a user is in the bus domain, a call to the car rental tool is rejected, and a clear error is returned to the model: domain mismatch, call the domain switching tool first. Thus, changing intent becomes an explicit step rather than an implicit one.

The second line of defense is the schema. Adding a mandatory domain field to every request and response object ensures the model re-declares the context it is operating in on every call. When the declaration conflicts with the session state, the server stops the operation. This moves validation to the server instead of relying on a client-side rule.

The third point is naming discipline. Using domain-prefixed names like bus_search, flight_search, car_rental_search instead of generic names like search, find, query increases the distance between similar tools. Descriptions should be equally clear; stating what a tool does not do is as valuable as stating what it does.

Date and time fields are a separate source of error. A tool that accepts free-text dates leads the model to produce localized formats. Enforcing ISO-8601 and explicitly requesting the time zone simplifies both validation and error messages. Similarly, in numerical fields, declaring units (number of people, number of nights, currency) reduces ambiguity.

On the security side, OTP or similar verification flows are a correct approach for tools that initiate transactions. However, verification must be binding at the transaction level, not the tool level: reservation, payment, or cancellation calls should not be accepted without a verified session ID. Granting authorization based on text generated by the model is a security vulnerability independent of the protocol.

Error messages are the model's learning surface. Instead of a generic 400 response, returning structured errors that state which field is missing and its expected format significantly increases the likelihood of the model making the correct call on its next attempt. Likewise, rate limits and retry policies should be documented; the model can only understand the need to wait from the error text.

A short checklist for secure tool routing: domain-based tool naming, session-level intent lock, mandatory domain information in the schema, server-side validation, an explicit domain switching tool, ISO-8601 date format, transaction-level authorization control, structured error messages, and documentation for limits and retries.

The common thread among these points is to make incorrect behavior impossible on the server side, rather than hoping the model behaves correctly. When designing an MCP server, the question to ask is: what is the most plausible incorrect call the model could make, and at which layer does the system stop it?