verify_claimInspect a stored claim for recorded conflicts and contradictions. Use it to review existing evidence, but note it does not perform independent scholarly verification.
Inspect a persisted claim for recorded conflicts; this is not independent scholarly verification and never upgrades derived evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| claim_id | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It clearly signals that this is an inspection operation, not verification, and explicitly states it never upgrades derived evidence. It does not mention permissions or error behavior, but the core non-effect is transparently stated.
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 a single, tight sentence with no wasted words. The core action is front-loaded, and the important limitations are placed in the second clause, making the tool's behavior immediately clear.
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 simple tool with one parameter and no output schema, the description explains the purpose and the key limitation clearly. It does not describe the return format or what happens when no conflicts exist, but the essential information for selecting and invoking the tool is present.
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 schema has 0% description coverage, so the description must compensate. The single parameter 'claim_id' is self-explanatory and the description's reference to 'a persisted claim' implies what it identifies, but the description never explicitly links claim_id to the inspected claim or explains its format beyond the schema constraints.
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 uses a specific verb and resource: 'Inspect a persisted claim for recorded conflicts.' It also explicitly distinguishes itself from scholarly verification, so the agent can tell it apart from tools like reconstruct_research or extract_paper_claims.
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 what the tool does not do ('not independent scholarly verification' and 'never upgrades derived evidence'), giving an explicit exclusion. It does not name a specific alternative tool, but the negative guidance is sufficient to prevent misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.