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

Annotations declare destructiveHint=true and openWorldHint=true, so the agent needs to know what the response actually does irreversibly. The description only clarifies the FIT branch ('creates internal opportunities requiring existing review') and omits what NOT_FIT, NEEDS_CLARIFICATION, or OWNER_CONFIRMATION_REQUIRED do, or whether the response is final/reversible. It also implies a narrower effect ('no external outreach', 'consent-only') than the destructive/open-world annotations suggest.

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?

Three fragments, no wasted filler, and the safety constraint is front-loaded. But the terseness shades into under-specification rather than concise clarity, and the most useful fact (what FIT does) is buried last.

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 destructive, non-idempotent, open-world mutation with no output schema needs more than three clipped sentences: what happens on each outcome, whether the underlying request changes state, and whether the call can be retried. Almost none of that is present.

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%, so the description must carry parameter meaning and it does not. Neither request_id nor the four enum outcomes are explained beyond the single hint about FIT; an agent cannot tell what distinguishes NEEDS_CLARIFICATION from OWNER_CONFIRMATION_REQUIRED.

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 phrase 'Consent-only FX network discovery/handshake' is jargon-laden and never states the concrete verb+resource relationship, i.e. that this tool answers an existing network request with a decision. It never distinguishes itself from siblings such as initiate_network_request, get_network_request, or request_opportunity_match, and 'respond_to_network_request' alone conveys more than the text does.

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?

'No identity, contact, terms, documents or external outreach' lists prohibited actions but never states when to call this versus get_network_request (read) or initiate_network_request (create). There is no trigger condition, no prerequisite, and no guidance on choosing among the four outcome values.

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