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

Annotations already cover read-only, non-destructive, closed-world reads, so the description doesn't need to establish safety. It adds the useful detail about what kind of content comes back, but doesn't cover error behavior when the binding_id is unknown or whether the full extraction config could include secrets/credentials. Adequate with annotations but not rich.

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?

A single front-loaded sentence with zero waste, leading with the verb and adding just enough scope detail. Every clause earns its place.

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?

No output schema, low parameter documentation, and no annotations covering return shape beyond safety. For a config-fetch tool an agent needs to know the binding_id format and roughly the response structure. The description lists config areas but leaves the identifier semantics and failure modes unaddressed.

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?

There is one parameter, binding_id, and schema coverage is 0%: the schema gives no description at all. The description only implies the identifier selects a data feed, but doesn't say whether it's a UUID, name, or slug. It finds some meaning but doesn't compensate for the coverage gap.

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?

We asks for a specific verb (Fetch) and resource (one data feed's full configuration), and it enumerates the content returned (source, target, schedule, extract parameters). It's clear it retrieves a single binding, implicitly distinct from list_bindings although it doesn't name that sibling explicitly.

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?

Implied usage: fetching a single feed's configuration by id. There's no explicit when-to-use versus list_bindings, and no prerequisites or exclusions stated. A reasonable agent can infer the single-vs-list distinction, but the description doesn't route explicitly.

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