Skip to main content
Glama
Sign In
AgentWorld MCP Server

AgentWorld MCP Server

by shawnhvac
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_x402_market_heatmap

Find x402 endpoints still live and payable now, with price, network, payTo, readiness score, and buyer workarounds. Check before budgeting research on directories where many listings are dead.

Instructions

[FREE] Find x402 endpoints you can actually pay right now.

Every endpoint listed in the public x402 directories was called once, unpaid, and read the way a buying agent reads a 402. Returns the ones still live behind a paywall with price, network, payTo, a 0-100 buyer-readiness score, and buyer_notes: the concrete workaround each defect implies, such as carrying your own facilitator when the seller names none, or treating a 502 as their oversized header rather than your client.

Use it before spending a research budget on a directory: most listed endpoints are no longer live, and payable_now

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_x402_market_heatmap"
  }
}

Input Schema

NameRequiredDescriptionDefault
min_scoreNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description does real work: it discloses the methodology (every directory endpoint called once, unpaid, read as a 402), that results are filtered to still-payable endpoints, the returned fields including buyer_notes workarounds, and that it is free. Latency, rate limits and failure modes of the call itself are not covered, but the behavioral picture is unusually complete.

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 key claim is front-loaded and the middle section is informative, but the text terminates mid-sentence ('and payable_now '), leaving a dangling fragment and an incomplete argument. Some of the prose ('read the way a buying agent reads a 402') is atmospheric rather than functional.

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 filtered-listing tool with no output schema, the description enumerates the return payload (price, network, payTo, score, buyer_notes) and warns that most directory entries are stale, which is exactly what an agent needs before calling. The truncated ending and the unmentioned min_score default are the remaining gaps.

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?

There is one parameter, min_score, with 0% schema coverage. The description never names it, but it does establish that the readiness score is on a 0-100 scale, which lets an agent infer the filter's units and range. That is helpful but not a full explanation of default behavior or filtering semantics.

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: 'Find x402 endpoints you can actually pay right now', and explains that the results are verified-live paywalled endpoints with price, network, payTo and a readiness score. This is distinguishable from siblings like check_x402_endpoint or marketplace_check_endpoint, though it never names them explicitly.

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 a clear context for use: 'Use it before spending a research budget on a directory' because most listed endpoints are dead. It lacks an explicit boundary against similar siblings (e.g. single-endpoint checks) and the closing sentence is cut off, so the exclusion guidance is incomplete.

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