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

With no annotations, the description carries the full burden. It discloses that it mutates state (adds a line, changes the default) and is deprecated, but omits permissions, reversibility, side effects of changing a default route, and any response information.

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?

It is a single short sentence with the deprecation status front-loaded, so it is not bloated. However, the brevity comes at the cost of clarity rather than from efficient packing of information.

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?

A mutation tool with no annotations, no output schema, and 0% parameter documentation needs the description to do much more. The deprecation notice is the one genuinely useful addition, but the rest of the context an agent needs to invoke this safely is missing.

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?

Schema description coverage is 0% for three parameters, so the description should compensate. It only addresses inboundAgentId by deferring to 'lines.update', leaving workspaceId and route (an enum of sip-test/phone-gateway) entirely unexplained.

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 states a verb+resource pair (add/attach a line and make it the default for a route) but is cryptic: 'Deprecated alias: add (if needed) and make default the line for this route' is compressed to the point that the agent must decode it. It vaguely distinguishes itself from siblings via 'inboundAgentId as in lines.update' but never clearly names what it aliases.

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?

'Deprecated alias' hints the agent should prefer something else, yet the description never says what to use instead or under what conditions this tool should still be called. No when-to-use/when-not guidance is provided beyond the deprecation label.

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