Skip to main content
Glama

Fair Offer check (free)

check_fair_offer
Read-only

Free: check any x402 offer's Fair Offer block from outside, without paying. Each of the seven Fair Offer rules comes back verified, declared, contradicted or not claimed. Pass accept_proof (e.g. "sample=attested; price<=listing") to learn whether the offer meets a buyer's requirements.

Input Schema

NameRequiredDescriptionDefault
urlYesPublic https URL of the paid endpoint
accept_proofNoOptional Accept-Proof value

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds genuinely new context: no payment is required and each rule returns one of four discrete verdicts. It stops short of describing auth/rate-limit behavior or what a response envelope looks like.

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

Conciseness4/5

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

Three sentences, front-loaded with the 'Free' differentiator and the core action; the verdict vocabulary follows naturally. Minor cost: the accept_proof sentence carries a slightly dense embedded example.

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?

No output schema exists, so the description takes on return-value disclosure and does explain the four verdict states per rule. Adequate for a 2-parameter read-only tool, though the overall response shape beyond the per-rule verdicts is not described.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description meaningfully upgrades the notably vague schema text for accept_proof ('Optional Accept-Proof value') by supplying a concrete syntax example ('sample=attested; price<=listing') and stating what the parameter answers.

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?

States a concrete verb+resource ('check any x402 offer's Fair Offer block') plus scope qualifiers ('from outside, without paying'), which cleanly separates it from siblings like lint_listing or signed_sample that operate on listings or samples rather than an external offer.

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

Usage Guidelines3/5

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

It gives one concrete usage cue — pass accept_proof to check an offer against buyer requirements — but never states when to prefer this tool over lint_listing or the other validation-adjacent siblings, leaving comparison to inference.

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.