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

Annotations already declare readOnly/idempotent/closed-world, so safety is covered; the description goes further by disclosing the no-match behavior (response gains coverage_note and tracked_count, framed as a coverage limit rather than a hiring finding) and the 'information, not financial advice' caveat. These are genuine behavioral disclosures, though the long data_contract sentence is closer to output documentation than behavior.

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?

Purpose is front-loaded in the first sentence and the paragraphs follow a sensible order: purpose, return shape, call examples, edge case, compliance, bulk routing. It is on the long side — the field-by-field enumeration and the data_contract sentence add bulk — but with no output schema those fields are load-bearing rather than padding.

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?

With no output schema, the description carries the full return contract (as_of, per-company fields, derived deltas, coverage_note/tracked_count fallback, data_contract), and the annotations cover safety. An agent has everything needed to call it correctly and interpret the response, including the explicit truncation of scope versus CSV exports.

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 coverage is 100% and documents the case-insensitive company filter, so the baseline is 3. The description adds real meaning beyond the schema by showing that an omitted company ({}) returns every tracked employer, which the schema does not state since the parameter is optional with no default explained.

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 first sentence states a specific resource (hiring velocity across tracked Bitcoin/crypto-infrastructure employers) and its source of truth (live ATS boards), a topic none of the siblings cover. An agent can tell this is the headcount-velocity tool without comparing schemas against get_etf_flows, get_network_signal or get_sovereign_reserves.

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 an explicit usage boundary ('one question, one answer') and routes away bulk, history, backfill and scheduled-pull workloads to the CSV/datapackage at coinbucha.com/data. It also states the two calling modes up front ('{"company": "coinbase"} for one employer, or {} for every employer tracked'), so the agent knows both when and when-not to call it.

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