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

Annotations declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, yet the description leads with 'Read' and never reconciles that mismatch — it does not say what the call consumes, whether the approval is invalidated, or what 'destructive' refers to. The sentence 'Creating or updating contacts can trigger the customer's CRM workflows' gestures at downstream mutation risk, but it describes consequences of the approved CRM write, not the behavior of this tool itself. With annotations this strong, an agent is left guessing whether invoking this is safe or commits something.

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 sentences, front-loaded with the resource and its scope, followed by the consent constraint and the CRM-side effect. Nothing is redundant or padded. The last sentence is somewhat tangential to the tool's own behavior, which keeps it just short of a 5.

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?

An output schema exists, so return values need not be explained, and the consent boundary is covered. But for a tool with five required parameters, a nested arguments object, and session-scoped fields like expected_catalog_version and read_skills, the description gives no guidance on how to assemble a valid call or what happens when the approval has expired — a stated concern of the title itself.

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 only 50%: only read_skills, publication_proposal_id and expected_catalog_version carry schema text, and the description repeats none of them. Critically, the actual selector for the record — the nested arguments.review_id — is documented nowhere in either the schema or the description, and the protocol parameters work_id and request_key are equally unexplained. The description adds no parameter meaning at all beyond the title's mention of what the approval contains.

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?

States a specific verb and resource — 'Read a saved human approval' — and scopes the content of that approval (exact lead records, CRM destination, field mapping, expiry). That is enough to distinguish it from generic CRM siblings such as genads_crm_connections or genads_crm_request, but it never names genads_crm_reviews, its closest sibling (a listing of reviews), so the singular-vs-list distinction has to be inferred.

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 supplies a useful negative constraint ('Human approval is made in GenAds; chat cannot mint approval or reveal lead answers'), which tells the agent not to treat this call as a way to obtain or fabricate consent. However, there is no positive trigger ('use this before delivering leads to a CRM destination') and no pointer to genads_crm_reviews or genads_crm_request as alternatives when the agent only has a partial reference. Usage is implied rather than stated.

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