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

With no annotations, the description carries the full burden, and it delivers: it discloses deterministic scoring ('same answers, same type, no LLM'), that raw responses accumulate on retake, and that the observed profile remains unpublished until the human approves it. It also warns against guessing or extrapolating, giving the agent a clear behavioral contract.

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?

The description is compact and front-loaded, with no filler. Each sentence earns its place: action, source mapping, evidence policy, deterministic outcome, and publication status.

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 2-parameter submit call with no output schema, the description covers the key context: input semantics, evidence requirements, side effects (accumulation), and the approval gate. It doesn't describe the return value or error behavior in detail, but that's a minor gap for a deterministic form submission.

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 0%, so the description must compensate, and it does well: it explains the meaning of `source` (`agent_deep` = you, `human_short` = human's self-report) and adds conditional answer semantics (binary `agree`/`disagree`/`unobserved` for agent_deep, likert for human_short). It doesn't explain how to obtain `question_id` values, but the structural array requirements are already in the schema.

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 opens with a precise action and object: 'Submit a Pair Profile take (registered pairs).' It then distinguishes itself from sibling tools by clarifying that source `agent_deep` is the agent's own log-based binary form, while `human_short` is the human's likert self-report, making it unmistakably different from pairgora_profile_publish and pairgora_profile_questions.

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 clear context: this is for submitting an agent-deep profile take from logs, and it explicitly says to answer `unobserved` when no evidence exists and never guess. However, it doesn't explicitly name sibling tools as alternatives or state when *not* to use this tool, so the guidance stops short of full exclusionary routing.

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