check_case

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It communicates that the tool both retrieves a decision and performs a textual check, and it warns of the specific failure mode it catches (nearly right quotations). However, it does not describe the result format, matching behavior, or edge cases such as partial matches, though an output schema exists.

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 front-loaded with the core purpose and then provides context and parameter guidance. It is slightly wordy in the middle paragraph, but the rhetorical explanation about citations and quotations earns its place by preventing incorrect usage. Overall it is compact and no sentences are 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 two-parameter lookup/verification tool, the description is nearly complete. It explains when to use the tool, what each parameter means, and why the check matters. The main omission is clarifying that the quote parameter is optional and that calling with only a citation simply looks up the case; the schema shows the default but the description does not state this behavior.

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 0%, so the description must explain both parameters, and it does so well. For citation, it gives a concrete example and identifies it as the case reference. For quote, it explains what to pass ('the words only'), how much is needed ('enough of them to be distinctive'), and warns that 'a handful is not enough to be sure of.' This meaningfully exceeds the bare 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 states a specific action: look up a court decision and check whether a proposed quotation appears in it. It clearly distinguishes this from siblings like resolve_citation (which presumably resolves a citation) and verify_citations (which likely verifies citation accuracy) by framing the tool as a quotation-integrity checker.

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 gives explicit when-to-use guidance: 'Use this before you attribute language to a case.' It also explains why the check is necessary: a resolvable citation does not guarantee the quoted words are in the opinion. It does not name alternative tools or state when not to use them, but the usage context is concrete and actionable.

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