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

With no annotations provided, the description carries full behavioral disclosure. It reveals that verification is deterministic, that the engine 'eliminates what is not the answer; it does not generate it', and that each verdict has a precise meaning. It also explains that SYSTEM_ERROR indicates verifier failure (not claim falsehood) and that INCOMPLETE means no verifier applied, plus the sealed receipt mechanism for re-checking.

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 dense and information-rich, front-loaded with the core purpose and every sentence contributes value. However, it is a single rambling paragraph of about 200 words with many nested parentheticals and em-dashes, which reduces readability and could be improved with bullets or short paragraphs.

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 (two forms, nested objects, enum, domain coverage, and verdict semantics), the description is remarkably complete. It covers all major facets: input shapes, domain scope (~60 secular domains), verdict interpretation, and re-verification path. Without an output schema, it still describes the return values in sufficient detail.

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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema: it explains the relationship between mode/params (MATH form) and steps/spec (DOMAIN form), gives a real spec example for physics, and details the return envelope (verdict, trail, receipt). This significantly clarifies how to structure inputs correctly.

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 'Verify a claim deterministically' and explicitly lists the verdict outputs (HOLDS / BROKEN / INCOMPLETE / SYSTEM_ERROR) and the two usage forms (MATH and ANY DOMAIN). It distinguishes itself from siblings by naming find_verifier for domain lookup and seal_fetch for re-verification, making its unique role clear.

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 by separating MATH (mode, params) from ANY DOMAIN (steps with domain-specific spec) and provides a concrete physics example. It also tells the agent to use find_verifier to locate the appropriate domain and includes a critical usage caveat: never relay SYSTEM_ERROR as a refutation. This clearly frames appropriate invocation.

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