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

Annotations only cover openWorldHint=false and destructiveHint=false, so the description carries most of the burden and does well: "It changes no record" clarifies the stage-not-write semantics, and it discloses dedup/skip behavior with reasons. It omits operational traits such as batch size limits (schema allows 2000 rows), permission requirements, or whether proposals expire.

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?

Four sentences, front-loaded with the staging model before the parameter guidance, with zero filler about the product's philosophy. Slightly dense — the outcome enumeration and the instruction sentences could be trimmed — but every sentence carries information.

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?

Output schema exists, so not explaining return values is fine, and the description does tell the agent to report outcome counts. However, for a 7-parameter tool with a nested rows object and a required `companyId` that is never explained, plus an undocumented CSV-style import path (`fileContent`/`mapping`/`fileName`), the agent lacks enough to pick the right invocation mode.

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 only 14%, so the description must compensate; it does explain `rows` fields (personName required, optional firm/title/email/linkedin_url/phone/notes/role_tags), `source` format with concrete examples, and `agent_name`. But the required `companyId` (the TARGET) and the file-import path parameters (`mapping`, `fileName`, `fileContent`) are completely undocumented, leaving a large compensating gap.

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 ("Stages a list of people as proposals") and then enumerates the three distinct outcomes: new person → add proposal, existing pipeline person → gap-filling proposal, already-proposed/duplicate → skipped with reason. This clearly separates it from siblings like fundraising_stage_network_person and fundraising_upsert_network_from_import by emphasizing staging-for-decision rather than writing records.

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?

Gives concrete usage conditions: "Stage only what the member asked for, and for an event only the people going" and "Report the counts from the outcomes, never as added records." That is real when/how guidance, but it never names the follow-up alternative (e.g. fundraising_decide_proposal) or states when a direct create/upsert path is preferable, so it stops short of full alternative routing.

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