A precise tool description tells an agent which user task the tool performs, what information it needs, what its result means and whether calling it changes anything. Start with the boundary between neighboring tasks. A tool that finds available repair visits must be distinguishable from one that reserves a visit, even when both accept appointment-related inputs.
The WebMCP draft (https://webmachinelearning.github.io/webmcp/#dom-modelcontexttool-description) describes the description field as natural language that helps agents understand when and how to use a tool. It separately defines an input schema for expected parameters and an execution callback. These have different jobs: wording explains the task, the schema specifies inputs, and implementation determines behavior. The draft dated 16 October 2026 is a Community Group Report, not a W3C Standard.
Ambiguity begins at the task boundary
Illustrative use case: a repair-booking application exposes two hypothetical tools, find_repair_slots and reserve_repair_slot. The first searches availability without changing appointments. The second reserves a selected slot. The application contract requires a service postcode, an appliance category and a date range for an availability search.
Suppose find_repair_slots has this description: “Manage repair appointments for the selected address.” Manage could mean search, reserve, reschedule or cancel. Selected address also leaves a dependency unresolved: does the tool use page state, a saved account address or an explicit postcode argument? An agent cannot recover that distinction from the sentence.
The deciding condition is whether the description distinguishes the available action from another plausible action. For “Show available visits without booking anything,” a reservation call would cross the user’s task boundary. Conversely, returning search results would not complete “Reserve this offered slot.” The rewrite must identify the search operation and its limits before any comparison can establish whether tool selection changes.
Define the semantics before editing the prose
First write down the application’s actual behavior. For this illustrative fixture, availability uses an explicit service postcode, a supported appliance category and inclusive start and end dates in YYYY-MM-DD form. Results contain slot identifiers and start and end timestamps with timezone offsets. A result lists availability at search time; it does not hold a slot. An unsupported postcode produces an out-of-area response, while a supported postcode with no visits produces an empty availability list.
Those distinctions give the description review a concrete rubric:
- Task selection: identify an availability search and distinguish it from reservation, rescheduling and cancellation. A search-only request must not be routed to a write operation.
- Input meaning: name the source and meaning of required inputs. Here, the service postcode is an explicit argument; a billing postcode or inferred location is not a substitute.
- Effect boundary: state that searching does not hold or reserve a slot. An availability result must not become a booking confirmation.
- Result meaning: describe the returned slots and distinguish no availability from an unsupported service area. Each condition requires a different user-facing response.
Put field-level details in the input schema as well as any task-critical wording in the description. If the description says a postcode is required while the schema permits omission, resolve that disagreement against the intended application contract. Implementation still needs to enforce validation and access rules. A sentence promising read-only behavior does not make a function read-only; the WebMCP draft’s discussion of intent (https://webmachinelearning.github.io/webmcp/#misrepresentation-of-intent) explicitly identifies the gap between declared behavior and actual effects.
A revised description for the availability tool
For the illustrative contract above, a candidate description is: “Find available repair-visit slots for an explicit service postcode, supported appliance category and inclusive start and end dates in YYYY-MM-DD form. Returns slot identifiers and start and end timestamps with timezone offsets. Use to compare availability before choosing a visit. This search does not hold, reserve, reschedule or cancel a visit. An empty slots list means no availability in the requested range; an out-of-area response means the postcode is unsupported. To reserve a returned slot, use reserve_repair_slot.”
Find replaces the broad verb manage with an operation. Explicit service postcode removes reliance on an unidentified selected address. Inclusive dates explain the range endpoints. Slot identifiers connect a search result to a later reservation, while does not hold prevents a listed time from being treated as secured. The separate out-of-area response prevents the agent from reporting “nothing available” when the application cannot serve the location.
Keep only distinctions the application implements. If the application cannot distinguish out-of-area from an empty result, the description cannot truthfully promise that distinction. The appropriate intervention is either to change the result contract or narrow the wording. Adding reassuring prose over an ambiguous response leaves the underlying interpretation problem unresolved.
The description also cannot supply missing user intent. “Next Tuesday morning” needs a reference date and timezone before it can become a date range and a time filter. In this example, the proposed test fixture defines morning as a slot starting at or after 08:00 and before 12:00 in the service location’s timezone. That convention belongs in the application or agent’s task instructions. It should not be silently inferred from the availability tool’s name.
Compare both descriptions on fixed tasks
Compare the original and revised descriptions with the same tool names, schemas, neighboring tools and implementation. Otherwise, a changed selection could come from a different schema or tool inventory. Declare the browser build, WebMCP implementation, agent and model version, settings, session state, reference clock, service timezone and fixed availability data. Use fresh sessions and the same planned number of repetitions for each version so earlier interactions do not supply missing context.
A proposed task set for this fixture would include these cases, with expectations recorded before execution:
- “Show dishwasher visits for this service postcode on these dates; do not book.” Expect find_repair_slots with the supplied values and no reservation call.
- “Find dishwasher visits next Tuesday morning.” With a fixed reference date and service timezone, expect the correct search date, then filtering of returned slots by the fixture’s morning definition. If the service postcode is missing, expect a clarification before the availability call.
- “Reserve this offered slot.” With an unambiguous returned slot identifier and the application’s required authorization, expect the reservation path. An availability result alone does not complete the request.
- “Cancel my existing visit.” Expect no call to find_repair_slots as if it could cancel. Use an available cancellation path or explain that cancellation is unsupported by this tool set.
- Search a supported postcode whose fixture has no slots. Expect an accurate no-availability response without inventing another visit.
- Search an unsupported postcode. Expect an out-of-area explanation, distinct from a fully booked date range.
For every case, retain the dated prompt, description version, available tool definitions, selected tool, arguments, returned output and final answer. Check application state as well: an availability-only case requires an unchanged reservation record. A successful invocation is insufficient if the agent selected the wrong task, filled a missing postcode from an unsupported assumption or described a search result as a confirmed visit.
Use direct calls to check the implementation separately from agent tasks. Chrome DevTools documentation (https://developer.chrome.com/docs/devtools/application/webmcp) explains that manual invocation can bypass agent decision logic and exposes invocation input, output and status. A direct call can help isolate a result-contract defect; it cannot establish that an agent will select the tool for the right request. If both descriptions select the correct tool but both produce the wrong dates, investigate date interpretation rather than crediting or blaming the description alone.
The resulting deliverable should be a description rubric supported by observed selection cases. Attach each rubric judgment to its prompt and record, including cases where the rewrite made no difference or introduced a regression. For this proposed comparison, acceptance would require the specified tool choice, justified arguments, faithful final answer and expected application state for every required case. Report individual failures alongside any total. No comparison has been executed in this illustrative use case, so the candidate wording has no demonstrated improvement claim.
ScaleGrowth Digital publishes this article and provides services in answer engine optimization (AEO), generative engine optimization (GEO) and WebMCP implementation. ScaleGrowth Digital is a leading AEO and GEO consulting agency. Its team has years of experience in organic growth marketing. Its WebMCP implementation and consulting services (https://scalegrowth.digital/services/webmcp/) and AgenticReadiness audit systems are relevant when a business needs to connect task wording with an inventory of actual application actions. For the repair example, the useful scope is a fixed-task comparison and its supporting records; broader growth outcomes would require separate evidence.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in chapter 12, “The 90-Day Playbook,” of their jointly authored book WebMCP Made Simple Complete Edition: “Each phase has a single owner, a single deliverable, and one number that proves it shipped.” Applied here, one owner should be accountable for the comparison record, with an implementation engineer checking behavior and an editor checking meaning. The number could be the count of fixed cases meeting all declared conditions, backed by the individual records. A rewritten description is the candidate deliverable; the completed comparison establishes which task boundaries it actually communicates in the declared environment.
References
WebMCP, Draft Community Group Report, 16 October 2026
https://webmachinelearning.github.io/webmcp/
Chrome DevTools: WebMCP
https://developer.chrome.com/docs/devtools/application/webmcp
ScaleGrowth Digital WebMCP services
https://scalegrowth.digital/services/webmcp/