summarize_contract

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

With no annotations, the description carries the full burden. It discloses an important behavioral trait: the tool switches between Claude-based generation and an extractive fallback depending on ANTHROPIC_API_KEY. However, it does not mention whether the operation is read-only, what happens with an invalid doc_id, or latency/cost implications.

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 concise and front-loaded: the first sentence states purpose, the second exposes fallback behavior, and the Args section cleanly documents the parameter. Every sentence adds value, though the fallback details could be slightly tightened.

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 a single parameter, an output schema, and no annotations, the description is mostly complete. It covers purpose, behavior, parameter semantics, and the prerequisite relationship to load_contract. It leaves out explicit error handling and output structure, but the output schema covers the latter.

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 provides only 'Doc Id' with no description (0% coverage). The description compensates fully by explaining that doc_id is the value 'returned by load_contract', giving the agent critical provenance and prerequisite information beyond 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 states a specific verb ('Summarize'), a resource ('a loaded contract'), and a concrete output ('plain English' summary plus 'top things a reviewer should double check'). This clearly distinguishes it from siblings like load_contract, extract_clauses, and flag_risks.

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 establishes a clear prerequisite: the contract must already be loaded, and doc_id must be the one returned by load_contract. This gives an agent a clear when-to-use context, though it does not explicitly name alternatives or exclusions.

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