Skip to main content
Glama

Compare saved citation observations

compare_evidence_snapshots
Read-onlyIdempotent

Compare two supplied evidence snapshots bound to the same input. No fetch, payment or content storage. Unreadable sources and changed/unknown processing profiles are not classified as quote removal. Maximum 196608 bytes; no authenticity or truth inference.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
afterYesSaved inputHash plus a bounded version-1 evidence body. Other client-result fields are ignored; no payment/authenticity claim is inferred.
inputYes
beforeYesSaved inputHash plus a bounded version-1 evidence body. Other client-result fields are ignored; no payment/authenticity claim is inferred.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / input / properties / requireAllSources
      Added value: +{
      +  "description": "Preserve the exact billing policy from the original request, including omission.",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds valuable context beyond that: it specifies that no fetch, payment, or content storage occurs, which goes beyond the read-only hint. It also discloses the size limit (196608 bytes) and states that no authenticity or truth inference is made, which are behavioral traits not in annotations. It doesn't contradict annotations, so a high score is justified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (two sentences) and front-loaded with core purpose and constraints. Every sentence adds value: it specifies the action, the resource, key behavioral exclusions, and important caveats. No wasted words, and the information is structured logically.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a comparison tool with a rich input schema and detailed constraints (matching input hashes, size limits), the description is largely complete. It covers the main context: it's offline, no side effects, handling of unreadable sources, and what is not inferred. The schema already documents the nested structure and limits (e.g., max items, byte limits) in the input schema, so the description doesn't need to repeat those. The absence of an output schema is a minor gap, but the description's key behavioral notes are sufficient for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 67%, with most parameters having descriptions in the schema (e.g., 'inputHash' and 'evidence' have descriptions). The description adds minimal additional parameter meaning beyond what the schema provides, mainly reinforcing that both inputHashes must match the canonical input hash. The baseline for high coverage is 3, and since the description does not significantly enhance parameter understanding beyond the schema, a 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('compare'), a clear resource ('two supplied evidence snapshots'), and a key constraint ('bound to the same input'). It clearly differentiates from siblings by emphasizing 'no fetch, payment or content storage', which distinguishes it from tools like prepare_evidence_request or validate_evidence_request that likely involve fetching or validation. The title is also informative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'No fetch, payment or content storage', which tells the agent when not to use it (for actions that require fetching or storing). It also clarifies that 'Unreadable sources and changed/unknown processing profiles are not classified as quote removal', which prevents misinterpretation of results. It doesn't name an alternative tool directly, but the exclusion of fetch/payment/storage is clear enough to guide selection among siblings.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources