Skip to main content
Glama

x402 Crypto Market Structure

api_info

Read-onlyIdempotent

REST API access for autonomous agents — pricing, quick start, and migration guide.

Call this when: building a trading bot, deploying an autonomous agent, hitting
the MCP rate limit, or running 24/7 without a human in the loop. The MCP tier
(what you're using now) is free via Smithery, rate-limited to 60 calls/minute
per IP, and good for testing. The REST API is for production: pay per call in
USDC; paid endpoints are rate-limited to 60 calls/minute and 200 calls/hour
per wallet. No API key required.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds context that it is a guide/informational tool, explains the free vs paid tiers, rate limits (60/min per IP, 200/hour per wallet), and that no API key is required. This enriches the behavioral picture beyond the annotations without contradiction.

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?

Two paragraphs, first sentence states purpose. Additional sentences provide concrete use cases and tier comparisons. Each sentence earns its place, though it could be slightly tightened without losing value.

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

Completeness5/5

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

For a zero-parameter informational tool with an output schema, the description fully covers when to use it, why, pricing details, rate limits, and migration path. No significant gaps given the low complexity and existing structured metadata.

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?

The tool has zero parameters, so schema coverage is 100%. Baseline for 0-param tools is 4; the description adds contextual value by explaining what the info covers (pricing, quick start, migration), even though parameter-level semantics are not applicable.

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 clearly states the tool provides 'REST API access for autonomous agents — pricing, quick start, and migration guide.' It goes beyond a generic verb+resource by listing specific contents and explicit use cases (building a trading bot, hitting the MCP rate limit). This distinguishes it from sibling market-data tools.

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?

Explicit 'Call this when' section lists concrete scenarios (building trading bot, deploying autonomous agent, hitting rate limit, running 24/7). It also contrasts the MCP tier (free/testing) with the REST API (production/paid), giving clear guidance on when this informational tool is relevant.

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.

TDQS

A4/5.0
Disambiguation3/5

The five market_* tools overlap in purpose—all provide market analysis for tokens—but each has a distinct focus (macro regime, full diligence, light coverage, orderflow, snapshot). The overlap is manageable, but an agent could hesitate between market_snapshot and market_orderflow since both include orderflow data. address_risk and api_info are clearly distinct.

Naming Consistency2/5

Naming conventions are inconsistent: address_risk, api_info, market_orderflow, and market_snapshot are noun_noun compounds, while market_analyze is noun_verb, and market_full/market_light are noun_adjective. There's no consistent verb_noun or pattern, making it harder to infer tool behavior from names alone.

Tool Count5/5

Seven tools is well-scoped for a market analysis server. Each tool covers a reasonable slice of functionality without excessive redundancy, and the count fits the typical 3-15 tool sweet spot.

Completeness4/5

The tool set covers the major aspects of market structure analysis: macro regime, snapshot, orderflow, full due diligence, lightweight coverage for any token, wallet risk, and API info. Minor gaps exist—such as no dedicated historical data tool or token-level risk beyond what market_full provides—but agents can work around them.

Resources