Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish this as a safe, read-only, non-destructive check. The description adds useful behavioral context that annotations do not: it is fast, performs no solve, and returns whether the request fits plus the closest supported alternative. Return format details are high-level but sufficient given the simple tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded: it first says what to pass, then what is returned, then when to call it. Every sentence contributes and there is no repetition or waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must explain the return value; it does so at a high level by stating it returns feasibility and the closest supported alternative. For a one-parameter, read-only capability check, this is adequate, though it could specify the exact return shape slightly more.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully documents the single description parameter, so the baseline is 3. The description adds value by instructing the agent to use plain language and providing a concrete example with depots, pickups/deliveries, and vans, which clarifies the expected granularity beyond the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: check whether a routing request fits this server. It clearly distinguishes the tool from siblings by stating it returns feasibility and a closest alternative, with no solve, so an agent can tell it apart from optimize_routes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear usage trigger: 'Call it first when unsure the tool fits.' That directly addresses the decision point for an agent. It does not explicitly name the alternative tools or state when not to use it, which keeps it short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.