check_citations

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

The annotation readOnlyHint=true is already present, and the description adds substantial beyond-annotation context: it runs fully offline, sends nothing, cannot determine real vs. fake references, and notes that a missing reference is usually a slip rather than dishonesty. This paints a complete behavioral picture and explains the tool's intent and limitations.

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 longer than average but every sentence earns its place: it front-loads the core function, then lists specific check types, supported styles, offline behavior, limitations, and even advice on handling findings. No fluff or repetition, just dense, useful 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?

Given the tool's complexity and the absence of an output schema, the description does well by stating that it returns 'the line of every problem' and explaining the conceptual approach (self-contradiction detection). It lacks an exact return structure, but that is not fully required, and the description covers language, year handling, and offline behavior sufficiently for an agent to gauge whether this tool fits.

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?

The input schema already provides 100% coverage for all three parameters, including defaults and descriptions for each. The tool description does not add any new parameter-level semantics, so it rests at the baseline of 3; it neither clarifies nor conflicts with 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 begins with a specific verb and resource: 'Compares a document against its own reference list and reports where the two disagree.' It enumerates concrete checks (malformed DOI, impossible year, duplicates) and explicitly distinguishes itself from sibling tools like check_originality or check_paraphrase by focusing on internal consistency rather than external similarity.

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 description clearly states supported languages and citation styles, and explicitly identifies a key limitation: it cannot verify whether references are real papers, only whether the document contradicts itself. It does not name specific alternative tools, but the 'nothing is sent anywhere' and offline nature help the agent decide when this (vs. a look-up tool) is appropriate.

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