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

With no annotations, the description carries the full burden and does disclose real consequences: 'approve' triggers scoring, 'reject' scores nothing, the result is total-only, and the caller's own points move with score quality — a non-obvious incentive effect worth stating. Gaps remain: nothing about whether a submission can be re-vetted, whether vetting locks the submission, or what permissions the api_key confers.

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 clause, and the rest is a compact checklist plus decision semantics; the parenthetical about point gain/loss is load-bearing. The single long sentence packs several claims together, making it denser than ideal, but no sentence is wasted.

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?

For a four-required-parameter scoring decision with no annotations and no output schema, the description covers the purpose, the review criteria, and the consequence of each decision. What is missing is the lifecycle around the call — whether notes are required to justify a rejection, what an approve returns, and whether the action is reversible.

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 25% (api_key documented), so the description should compensate more than it does. It adds genuine meaning to the decision enum by explaining the downstream effect of 'approve' versus 'reject', but says nothing about submission_id format/provenance or what belongs in the required 'notes' field — which is arguably where a reviewer's findings should be recorded.

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 ('Vet a teammate's HLA answer') and then spells out the actual vetting checklist (name checking against release files, re-reading messy text, cutoff completeness, INVALID never assigned). This is far more than a restatement of the name and lets an agent distinguish it from hla_submit, hla_get_report, and planets_vet without opening a schema.

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 phrase 'before it scores' clearly places the tool in the workflow — after a teammate submits, prior to scoring. It also explains what each decision does downstream. It does not name alternative tools (e.g., review_submission, decline_submission) or state when vetting should be skipped, which keeps it short of a 5.

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