Read a deal

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

Annotations only supply readOnlyHint and openWorldHint, so the description adds real value by disclosing the shape of the result (the four possible verdicts) and one hard limitation (it cannot confirm a champion). It does not say how much of the input is required vs. optional or how confident/enriched the read is when params are sparse, which keeps it below a 5.

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?

Two sentences, front-loaded with the usage trigger before the output description and the sibling redirect. It is dense with enumerations but each clause carries information; the only slight drag is the run-on list of verdicts embedded mid-sentence.

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 carries the job of explaining what comes back, and it does so by listing the components and the four possible calls. With 16 mostly optional parameters and light annotations, a note on how thin inputs degrade the read would make it fully complete, but nothing essential 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 100% and the schema already explains inference expectations for vertical, targetRole, and productDescription. The description adds no parameter-level guidance beyond what the schema provides, so the baseline 3 applies.

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 names a specific action (produce one read on buyer readiness), enumerates the outputs (fit score, ICP match of the people involved, risk flags, fit check) and states the terminal verdict set. It also explicitly differentiates itself from get_icp_fit_score, so an agent can route without opening schemas.

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 concrete trigger ('after a first conversation'), an explicit boundary ('It doesn't confirm a champion; that takes asking the person'), and names the alternative for the narrow case ('For a quick fit score only, use get_icp_fit_score'). When-to-use, when-not, and alternative are all present.

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