Skip to main content
Glama

fresh402_openapi_contract_diff

Detect bounded directional compatibility evidence in a public JSON OpenAPI3.0/3.1 contract: paths/methods, required fields, supported scalar type/enum/null domains, and effective authentication alternatives/scopes. Request acceptance and response guarantees have opposite compatibility directions. Complex schema composition, custom dialects, ambiguous visibility and unexpanded references remain review/unknown; no general satisfiability or compatibility proof. Use for API contract review; Smart Diff is for general documents. First register the contract URL with free fresh402_register, without selectors or ignore rules, then reuse watch_id. compare_to accepts previous (default) or baseline; an available same-watch previous_hash overrides it. Limits include 256000 decoded document bytes, 100 paths and 500 operations. No YAML, external reference fetching, API-operation execution, LLM or complete compatibility guarantee. $0.020 USDC per call on Base mainnet (eip155:8453); requires an x402-capable MCP payment client and funded native-USDC payer, otherwise returns a payment challenge. Alternatively use prepaid credits through REST or this MCP tool: X-Fresh402-API-Key in HTTP, with params._meta["fresh402/prepaid"] containing idempotency_key, tariff_version and max_credits. When root mpp_payments.enabled is true, native MPP EVM charge is another option at the same USDC price: use an authorized Base EIP-712 signer and official mppx client, org.paymentauth/credential metadata and a persisted private recovery token. MPP receipt: org.paymentauth/receipt; see docs/MPP.md. Never combine MPP, prepaid and x402. Discover packages at /v2/prepaid/plans; see docs/AGENT_PREPAID.md for browserless wallet enrollment, bounded early credits and recovery. Optional Circle Gateway x402 is available only when root circle_gateway.enabled is true. Use the GatewayWalletBatched quote, a funded Base Gateway EOA and a persisted private recovery token. Pending batches return 409; replay the original proof/input/token after 60 seconds. Results require Gateway confirmed/completed evidence; never mix providers. No Circle prepaid funding. See docs/CIRCLE_GATEWAY.md. Optional free evaluation: inspect GET /v3/agent-trial for the CAPTCHA-free machine trial (unfunded EOA ownership signing required). Web tools may also use the separate human trial at /v2/trial. Only enabled, eligible allowances authorize free execution; shared capacity can return 429 earlier. Send X-Fresh402-Trial-Key and a distinct persisted Idempotency-Key per logical REST or MCP call. Reuse the same tool/input/key for retained recovery. Never mix trial and payment/prepaid credentials. Exhaustion never authorizes a charge; ordinary requests without trial credentials retain the paid challenge.

Input Schema

NameRequiredDescriptionDefault
watch_idYesRequired existing watch ID: 'w_' plus 32 lowercase hexadecimal characters. Obtain it with free fresh402_register or POST /v1/register using the public JSON OpenAPI 3.0/3.1 URL and no selector or ignore rules. Reuses the saved URL; do not pass url here. YAML, non-OpenAPI documents and scoped/filtered watches are unsupported. Illustrative IDs must be replaced.
compare_toNoOptional mode: 'previous' (default) compares with the latest saved OpenAPI Contract Diff snapshot; 'baseline' uses its fixed saved baseline. Before contract history exists, the current registered watch state seeds the initial baseline. previous_hash overrides the mode. 'hash' appears only in results, not as an accepted input mode.previous
previous_hashNoOptional 64-character hexadecimal reference hash, case-insensitive. Prefer a hash returned by OpenAPI Contract Diff for this same watch, matching a retained contract snapshot or fixed baseline. The current registered core hash is also accepted as a fallback: without a matching contract snapshot, the fixed baseline (or registered state if no baseline exists) is used. Overrides compare_to; unavailable hashes return 404. Omit to use the selected mode.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / description
      Added value: +"Compare a registered, unfiltered public JSON OpenAPI 3.0/3.1 contract; watch_id is required, compare_to defaults to previous, and optional previous_hash overrides it. Bounded structural analysis, not a complete compatibility proof; no YAML, external reference fetching or execution of described API operations. Unknown fields are rejected."
    • addedInput schema / properties / compare_to / description
      Added value: +"Optional mode: 'previous' (default) compares with the latest saved OpenAPI Contract Diff snapshot; 'baseline' uses its fixed saved baseline. Before contract history exists, the current registered watch state seeds the initial baseline. previous_hash overrides the mode. 'hash' appears only in results, not as an accepted input mode."
    • addedInput schema / properties / previous_hash / description
      Added value: +"Optional 64-character hexadecimal reference hash, case-insensitive. Prefer a hash returned by OpenAPI Contract Diff for this same watch, matching a retained contract snapshot or fixed baseline. The current registered core hash is also accepted as a fallback: without a matching contract snapshot, the fixed baseline (or registered state if no baseline exists) is used. Overrides compare_to; unavailable hashes return 404. Omit to use the selected mode."
    • addedInput schema / properties / watch_id / description
      Added value: +"Required existing watch ID: 'w_' plus 32 lowercase hexadecimal characters. Obtain it with free fresh402_register or POST /v1/register using the public JSON OpenAPI 3.0/3.1 URL and no selector or ignore rules. Reuses the saved URL; do not pass url here. YAML, non-OpenAPI documents and scoped/filtered watches are unsupported. Illustrative IDs must be replaced."
  2. Added

TDQS

A3.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and discloses substantial behavioral detail: bounded analysis limits (256000 decoded bytes, 100 paths, 500 operations), unsupported inputs (YAML, external reference fetching, API-operation execution), error behavior (404 for unavailable hashes, 409 pending batches, 429 capacity), and payment/auth requirements. It also clearly states the tool does not provide a general satisfiability or compatibility proof. The payment details are excessive but they do transparently disclose invocation requirements.

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

Conciseness2/5

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

The description is far too long for the tool: after a clear purpose statement, it devolves into extensive payment, prepaid, MPP, Circle Gateway, trial, and cross-reference material. Much of this is irrelevant to selecting or invoking fresh402_openapi_contract_diff and drowns the core usage guidance. The purpose is front-loaded, but overall the text is bloated and repetitive.

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

Completeness3/5

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

It covers prerequisites, limits, unsupported cases, auth/payment options, and some error modes, which is substantial for a complex tool. However, there is no output schema and the description does not explain the shape or fields of the returned compatibility evidence, so an agent still lacks guidance on interpreting results. Payment coverage is disproportionately detailed while result semantics remain vague.

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 100%, so watch_id, compare_to, and previous_hash are already fully documented in the schema. The description adds a concise restatement that compare_to accepts previous or baseline and that previous_hash overrides it, but this does not go meaningfully beyond the schema. Baseline 3 is appropriate when structured fields do the heavy lifting.

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

Purpose4/5

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

The opening sentence names a specific operation (compatibility evidence detection) on a specific resource (public JSON OpenAPI 3.0/3.1 contracts) and enumerates the compared aspects: paths/methods, required fields, scalar domains, and auth alternatives/scopes. It also distinguishes itself from fresh402_smart_diff explicitly. The purpose is clear, though the jargon-heavy phrasing and surrounding payment text make it less immediately legible than a direct verb such as 'compare'.

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

Usage Guidelines4/5

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

It states 'Use for API contract review' and contrasts that with fresh402_smart_diff for general documents. It also gives the prerequisite workflow: register the contract URL first with fresh402_register, then reuse watch_id. It does not explain when to use this versus fresh402_contract_watch or fresh402_check, but the primary usage context and one alternative are clear.

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