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

Annotations declare readOnlyHint=false and idempotentHint=false, implying this call persists or mutates state and may produce different results on repeat. The description says only 'evaluate', which reads as a passive analysis and gives no hint that a scored entry is written, that repeating a call is non-idempotent, or that the desk_key is the sole credential. It adds almost no behavioral context beyond the annotations.

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 no filler or repetition; the purpose is the first thing the reader encounters. Slightly generic 'Use this to' opener keeps it just short of ideal, but sizing is appropriate.

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 needn't be explained, and the schema fully covers parameters. What is missing for a non-read-only, non-idempotent tool is any statement of side effects, credential requirements, or where it fits relative to the eight sibling tools, leaving notable gaps.

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%, so the schema already documents all seven parameters including cadence_days, previous_declined, and sender. The description's mention of cadence and spam signals loosely gestures at cadence_days/previous_declined, but adds no format, default, or interaction detail beyond the schema's baseline.

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 verb ('evaluate') and resource ('inbound recruiter pitch or outreach message') and even enumerates the scoring dimensions (relevance, specificity, cadence, spam signals). It is clearly distinguishable from a generic 'process' tool, but it never contrasts itself with siblings like intake_message or get_scoreboard, so differentiation is left to inference.

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 opening 'Use this to evaluate...' signals intended usage, which is better than nothing. However, there is no when-to-use vs when-not-to-use guidance, no mention of prerequisites (a valid, unrecoverable desk_key), and no routing to or away from the adjacent tools such as intake_message or set_criteria.

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