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

With no annotations, the description carries the full burden, and it does provide meaningful behavioral detail: matching is against requirement text, not title; it intentionally returns nothing rather than strained matches. This is substantive non-obvious behavior. However, it stops short of describing permissions, output shape, or other operational traits.

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 fairly tight and front-loads the main idea. The 'The join.' fragment and the somewhat aphoristic warning about title matches add flavor but not much structural value; still, most sentences earn their 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?

There is no output schema and no annotations, yet the description only says a successful response is JSON and that the tool may return nothing. It does not describe the actual result shape, ordering, pagination, or how limit and min_hits shape the response, leaving a real gap for an agent trying to use the result.

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 75%, so the schema already explains capability, min_hits, and framework. The description adds context that capability means 'funded capability' and that matching targets the control's requirement text, but it adds no detail about limit, min_hits behavior, or framework restriction beyond what the schema provides.

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 identifies a specific relation—controls that a funded capability actually touches—and clarifies the core matching mechanism (requirement text, not title). It is not a tautology and conveys enough to distinguish the tool from generic crosswalk/search siblings, though the phrase 'The join' is somewhat cryptic.

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?

The description implies when to use it: when you have a capability and need the controls whose text genuinely concerns it. It does not state explicit when-not-to-use conditions or mention alternative sibling tools, so the guidance is mostly implicit rather than directive.

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