Pay-per-call AI infrastructure for autonomous agents: DeFi market data, LLM inference, speech-to-text, text-to-speech, and trading research. x402 v2 pricing published before every call and settled in USDC on Base via the Coinbase CDP facilitator. No API key, no account, no subscription.
Scored across 5 tools
Each tool maps to a clearly different capability (trading signals, LLM inference, market data, speech-to-text, text-to-speech), so selection is mostly unambiguous. The only mild overlap is between alpha and markets, which both sit in the crypto/trading domain but operate on different data and outputs.
All names are single-token, lowercase, and stable (alpha, infer, markets, stt, tts), with no camelCase/snake_case mixing. However, the convention is inconsistent in kind — some are verbs (infer), some nouns (markets, alpha), and some acronyms (stt, tts) — so it's readable but not a predictable verb_noun pattern.
Five tools is a well-scoped, lightweight set with no redundancy, each covering a distinct function. It is slightly thin for a server branding itself as a multi-capability platform, but nothing feels bloated.
The server is a grab-bag of unrelated capabilities (trading, LLM, speech) with no single coherent domain, making lifecycle completeness hard to judge. Individually each tool looks self-contained, but there are no obvious cross-tool workflows or companion operations (e.g. no history, config, or management tools) tying them together.
Institutional-grade trading signals with position sizing (Kelly Criterion), chain rotation detection, and multi-timeframe analysis. Returns an actionable trade plan.
| Name | Required | Description | Default |
|---|---|---|---|
| portfolio_size_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full behavioral burden. It discloses only that an 'actionable trade plan' is returned; it says nothing about auth requirements, data freshness, rate limits, or what happens when portfolio_size_usd is omitted (it is optional).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with capability and ending on the concrete deliverable. No filler or repetition, though the enumerations could be trimmed without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations, so the description should carry more: it conveys the general deliverable but not the shape of the trade plan or how the single parameter affects the result. Adequate for orientation, incomplete for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single parameter, so the description must compensate. 'Position sizing (Kelly Criterion)' implies portfolio_size_usd drives sizing, which is meaningful, but units, whether it is required in practice, and acceptable ranges remain unstated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete resource (trading signals/trade plan) and enumerates the analytical methods (Kelly Criterion sizing, chain rotation, multi-timeframe analysis), so an agent can tell what it produces. It does not, however, differentiate from siblings such as 'markets', and the opaque name 'alpha' carries no meaning on its own.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no named alternative among siblings (infer, markets, stt, tts). The phrase 'institutional-grade' implies sophistication but gives the agent no condition for selecting this tool over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
LLM inference with auto-formatting and streaming. Accepts messages array, returns AI-generated text. Supports JSON/code auto-detection.
| Name | Required | Description | Default |
|---|---|---|---|
| stream | No | ||
| messages | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses streaming and JSON/code auto-detection, which is real value, but says nothing about which model runs, token/length limits, authentication, error behavior, or how streamed output is delivered — significant gaps for an inference call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short front-loaded sentences with no filler, and the core capability leads. There is mild redundancy between 'LLM inference' and 'returns AI-generated text', which keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% parameter coverage, the description leaves an agent without model selection, output format, streaming delivery semantics, or failure modes. For a generative tool whose results are opaque to the caller, noticeably more disclosure is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions the 'messages array' and implies the stream flag via 'streaming', but never explains the message roles (user/assistant/system), content format, or how stream=true changes the response shape — roughly half the parameter surface remains undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('LLM inference') and adds the differentiators that matter versus siblings stt/tts: text generation with auto-formatting and streaming. It never names a sibling explicitly, so it falls short of a 5, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over alpha/markets/stt/tts, no prerequisites, and no mention of exclusions or fallbacks. The agent must infer usage entirely from the tool name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Real-time DeFi TVL leaders and DEX trending pairs. Supports meme coin category, watchlist filtering, and delta sync since timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| set | No | ||
| since | No | ||
| category | No | ||
| watchlist | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It signals 'real-time' and 'delta sync since timestamp' (an incremental-fetch trait), which is genuinely useful, but says nothing about rate limits, auth requirements, caching, or what happens when 'since' is omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with zero padding; the core resource is front-loaded before the optional-capability list. Efficient, though the capability list reads as a feature dump rather than prioritized guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and 0% schema coverage on four parameters, the description should do more. It partially compensates by naming the return content (TVL leaders, trending pairs) and three of four params, but leaves `set` opaque and gives no guidance on defaults or incremental-sync behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially does: 'meme coin category' maps to the enum parameter, 'watchlist filtering' to watchlist, and 'delta sync since timestamp' to since. The `set` parameter is left entirely unexplained, and none of the parameters get format or default details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete resource and scope: real-time DeFi TVL leaders and DEX trending pairs, with the meme/watchlist/delta-sync capabilities enumerated. No sibling differentiation is needed since the listed siblings (alpha, infer, stt, tts) are unrelated, but the description also omits an explicit verb framing the operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no statement of when this tool should be chosen over anything else. The mention of 'supports meme coin category, watchlist filtering, and delta sync' hints at optional modes but does not tell an agent which mode to pick or when.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Speech-to-text with crypto keyword detection (bullish/bearish/dump/pump/etc.) and timestamped speaker segments. Returns transcript with keyword timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| audio_base64 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the return content (transcript with keyword timestamps) but says nothing about accepted audio formats, size/duration limits, or auth requirements for a tool whose sole input is a base64 payload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the core function front-loaded and the keyword/segment capabilities following. No filler, though it is arguably under-specified rather than merely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description is the only source of information. It partially covers returns but leaves the single required input parameter and operational constraints (audio format, limits) unexplained, which is inadequate for a working call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter (audio_base64) with 0% schema description coverage, and the description adds no information about it. The encoding expectation, supported audio formats, and any size constraints are left entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific transformation ('speech-to-text') and goes beyond the name by naming distinguishing features: crypto keyword detection (bullish/bearish/dump/pump) and timestamped speaker segments. It is clearly distinguishable from the likely siblings (markets/alpha/infer), though it never explicitly contrasts with the 'tts' sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance and no alternatives named, despite 'tts' being an obvious counterpart tool in the sibling list. An agent must infer that stt is for audio input and tts for audio output solely from the acronyms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Text-to-speech with emotion casting (happy/serious/urgent) and pronunciation memory. Returns audio/mpeg.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| emotion | No | ||
| pronounce | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return format (audio/mpeg), but says nothing about auth needs, rate limits, text-length caps, cost, or whether pronunciation memory persists across calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the core capability and features, with the return type placed last. No filler, though the parenthetical enum repeats schema data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter tool with a nested object, zero schema description coverage, and no annotations or output schema, the description is thin: the undocumented 'pronounce' structure and missing behavioral constraints leave real gaps an agent cannot fill from elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are three parameters. The description restates the emotion enum already present in the schema and only obliquely gestures at the nested 'pronounce' object via the phrase 'pronunciation memory', giving no indication of its structure or expected keys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific capability (text-to-speech) plus two distinguishing features (emotion casting, pronunciation memory) and the output MIME type, which implicitly separates it from the sibling stt tool. It never names the alternative, but the verb+resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no mention of the stt sibling or any condition for choosing this tool, and no prerequisites (e.g., text length limits) are stated. The enum list hints at how to drive emotion but not when to select the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
alphainfermarketsstttts
Add one secure layer between your agents and this server.