Skip to main content
Glama
Sign In
AgentWorld MCP Server

AgentWorld MCP Server

by shawnhvac
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

check_x402_endpoint

Checks an x402 endpoint's 402 response before payment or deployment: verifies facilitator reachability, Payment-Required header survival, signable terms, price vs settlement cost, description length.

Instructions

[FREE] Check one x402 endpoint before you try to pay it, or check your own before you ship.

Calls the URL once with no payment and grades the 402 a buyer receives: whether a facilitator is named where clients read it and whether that facilitator answers, whether the Payment-Required header exists and survives a default 4KB proxy buffer, whether the terms are complete enough to sign, and whether the price clears the measured on-chain cost of settling it, and whether the resource description is short enough to survive Coinbase CDP's /verify (a ~500-char cap past which first-settle through their

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "check_x402_endpoint"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYes
methodNoGET

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden, and it does disclose important traits: the tool is free, calls the URL exactly once, and sends no payment. What it omits is equally important — it never states whether the outbound call is strictly read-only, whether it retries, or what happens to endpoints that hang. The sentence also cuts off mid-thought, leaving the Coinbase CDP cap explanation incomplete.

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

Conciseness3/5

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

The lead is well front-loaded with a bracketed [FREE] marker and a one-line purpose, and the body is dense with substance rather than filler. But the second sentence is a run-on chaining four 'whether' clauses, and it terminates mid-word, so the structure degrades exactly where the value is highest.

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?

There is no output schema and no annotations, so the description must describe both behavior and returns. It explains the graded dimensions well but never says what the grading output looks like — pass/fail, score, or a list of findings — which is the single most useful thing for an agent deciding how to act on the result.

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

Parameters2/5

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

Schema description coverage is 0% for both parameters, so the description must compensate and it largely does not. The url parameter is only obliquely implied by 'Calls the URL once', and the method parameter is never mentioned at all, leaving an agent to discover the GET default straight from the JSON schema.

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?

States a specific verb and resource: it calls an x402 endpoint's URL once and grades the returned 402 challenge. That is far more concrete than a tautology. However, it never distinguishes itself from close siblings such as check_payment_readiness, preflight_check, safe_preflight_check, or marketplace_check_endpoint, so an agent cannot route between them from this text alone.

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?

Gives clear timing context: use it before attempting payment on someone else's endpoint, or against your own endpoint before shipping. That is a usable when-to-use signal. It stops short of naming alternatives or stating when not to use it, so it falls below a 5.

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

Deploy Server

Other Tools