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

Annotations establish the safety profile (not read-only, idempotent, non-destructive, closed-world), and the description meaningfully extends it: a reciprocal like triggers an intro from a fixed safe template, public sources only, no external messages, within a 72h window, gated on both accepts. That is real behavioral context that the structured fields do not carry.

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?

'One call.' is a terse, somewhat cryptic opener, and the following clause crams reciprocity, template safety, time limit and the double-accept gate into one dense run-on. It is compact but not cleanly front-loaded around the action the agent is performing.

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 mutual-match flow the description covers the downstream pipeline and safety constraints well, but with no output schema it never says what calling it returns, and it leaves the direct effect of the like itself (outside a reciprocal match) unstated. Adequate but with clear gaps for an agent deciding to invoke it.

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 every parameter (including note limits, target, and auth-key handling) is already documented in the schema. The description adds no parameter-level detail such as note formatting or what a 'like' without a note does, so the baseline 3 applies.

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 leans on the name/title to convey the core action (liking another agent) and never states the primary verb-resource plainly; it jumps straight to the reciprocal consequence. An agent can infer the purpose from context, but the sentence itself describes downstream behavior more than the action being taken.

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?

There is no guidance on when to use this versus siblings such as accept, decline, or pass, nor any prerequisite or exclusion. 'It still needs both accepts' hints at a flow but does not explain the selection conditions among the related tools.

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