Directory
Wolfram|Alpha
Computational intelligence engine — answer factual queries, perform math, science, and data computations via the Wolfram|Alpha API.
Routability
can the router discover, pick, and call it?81/100Blinted 7/6/2026, 12:54:15 PM
Param schemas
65% · w25
Descriptions
60% · w20
Live probe
100% · w15
Planner test
100% · w30
Affordances
80% · w10
15 checks
- schema · 3 endpoints are planner-eligible
- schema · param-schema coverage 0/3 endpoints (0%)
- schema · typed params 1/1
- schema · required flags present
- description · 1/3 endpoint descriptions carry real intent
- description · capability tags: math-compute, knowledge-facts
- description · 3 example queries
- probe · https://wolframalpha.x402.paysponge.com/v1/result → HTTP 402 (x402 challenge — healthy)
- probe · https://wolframalpha.x402.paysponge.com/v2/query → HTTP 402 (x402 challenge — healthy)
- planner · "What is the derivative of x^3 + 2x?" → picked + constructed (GET)
- planner · "How many calories are in a medium apple?" → picked + constructed (GET)
- planner · "What is the population of Tokyo?" → picked + constructed (GET)
- affordances · no user-identity params (n/a)
- affordances · no escape-hatch tool — every uncovered filter needs a new endpoint (whack-a-mole)
- affordances · signing hygiene: build-don't-execute language (or no signables)
Suggested fixes
- Add param schemas to the 3 schema-less endpoints (or retire them) — schema-less POSTs are dead weight in the menu.
- Rewrite 2 endpoint description(s) to say what a USER would ask for ("crypto spot price by symbol — price of ETH, BTC…"), not what the URL is. Weak: v1/simple, v2/query
- Consider ONE guarded general-query tool exposing the backend's native query language (see snapshot-free graphql_query) so long-tail intents need no new endpoints.
Fix it with Claude Code
Paste this into Claude Code inside the MCP’s repo — it carries the failing checks, the fix list, and the conventions the router grades against.
You are upgrading the MCP service "Wolfram|Alpha" so an AI router can reliably discover, choose, and call its tools. Yeetful's Reason Router just graded it 81/100 (B). I'll point you at the service's codebase; audit it against the findings below and implement the fixes.
## Failing checks
schema (65%):
- param-schema coverage 0/3 endpoints (0%)
description (60%):
- 1/3 endpoint descriptions carry real intent
affordances (80%):
- no escape-hatch tool — every uncovered filter needs a new endpoint (whack-a-mole)
## Fixes, in priority order
1. Add param schemas to the 3 schema-less endpoints (or retire them) — schema-less POSTs are dead weight in the menu.
2. Rewrite 2 endpoint description(s) to say what a USER would ask for ("crypto spot price by symbol — price of ETH, BTC…"), not what the URL is. Weak: v1/simple, v2/query
3. Consider ONE guarded general-query tool exposing the backend's native query language (see snapshot-free graphql_query) so long-tail intents need no new endpoints.
## The conventions to build to (what the router needs)
- **Param schemas on every tool/endpoint**: name, type, required-vs-optional, and a description per param. A router refuses to construct calls it cannot validate — schema-less endpoints are invisible.
- **Descriptions that carry user intent**: write what a USER would ask ('crypto spot price by symbol — price of ETH, BTC…'), never what the URL is. Include 2–3 example queries.
- **One guarded escape hatch instead of endless params**: if the backend has a native query language (GraphQL/SQL), expose ONE read-only general-query tool with strict guardrails (single read-only operation, allowlisted root fields, depth + page-size caps, response truncation) and a compact schema card in the tool description (root fields + useful filters + one example). Long-tail intents then need no new endpoints.
- **Declare user-identity params**: any param that should be the CALLER's own address (their votes, follows, balances, orders) must say so in its description ('the user's own wallet address') so routers can inject identity server-side instead of guessing.
- **Server-side joins for the headline intent**: if answering the #1 user question takes two chained calls (e.g. resolve follows → filter proposals), add one param that does the join server-side.
- **Build, don't execute**: anything signable returns an UNSIGNED payload (typed data / tx template) for the user's own wallet. Never hold keys, never sign, never submit on the user's behalf.
- **Free tiers still need rate limiting**: no payment gate means no natural throttle.
Start by reading the tool/endpoint definitions and their input schemas, then apply the fixes smallest-first. After each change, restate which failing check it clears.
Audit before you build: if a fix describes a capability the service ALREADY provides (e.g. an escape hatch or identity param that exists but the grader missed), do NOT duplicate it — say so, skip it, and note it back as a likely router-side scoring gap on Yeetful rather than an MCP deficiency. Only change what this service actually controls.x402 endpoints
3- GET/v1/result$0.01wolframalpha.x402.paysponge.com
at volume≈ $14.40/day @ 1 call/min·≈ $864/day @ 1 call/sec
GET /v1/result
- GET/v1/simple$0.01wolframalpha.x402.paysponge.com
at volume≈ $14.40/day @ 1 call/min·≈ $864/day @ 1 call/sec
GET /v1/simple
- GET/v2/query$0.02wolframalpha.x402.paysponge.com
at volume≈ $28.80/day @ 1 call/min·≈ $1,728/day @ 1 call/sec
GET /v2/query