Shared HTTP client, error types, blockchain constants, and schemas for Crypto APIs MCP servers
This is a shared library package, not a standalone MCP server. It exports reusable schemas, constants, and utilities (blockchains, networks, HTTP client, error handling) for other MCP servers to import. The repository contains only ONE tool definition visible in the source: 'system_info' in src/tools/system-info/index.ts. The tool has a basic schema (action enum + optional context string) and a description, but the description is extremely verbose (1200+ chars), poorly structured, and reads like API documentation rather than LLM-optimized guidance. The schema is minimal, only 2 input fields with no output schema documented. The tool is marked as READ_ONLY risk but has no tool annotations (readOnlyHint) in the code. Parameter descriptions exist but are terse. No error handling patterns visible. The package.json shows this is a TypeScript library (type: module, exports dist/index.d.ts) with Zod for validation, but no explicit MCP server registration or startup code is present in the provided source. The library appears designed to be imported by other MCP servers (e.g., mcp-signer, other CryptoAPIs tools), not to run as a standalone server.
CryptoAPIs reference documentation — no API call, no credits consumed. Actions: • blockchains — Supported blockchains, networks, products per chain, denominations, fiat currencies • errors — Complete error code table (HTTP status, error code, message) • credits — Credit charging structure, cost multipliers per blockchain, monitoring & operations taxes (xPub, synced addresses, blockchain events), pay-as-you-go • callbacks — Webhook mechanics: URL requirements, retry strategy (5 retries, exponential backoff), HMAC security, idempotency • limits — Throughput soft/hard limits per plan, 2.1x penalty multiplier, rate limiting behavior
No output schema documented. The tool description lists actions (blockchains, errors, credits, callbacks, limits) but does not specify what structure is returned for each. LLMs cannot plan downstream use without knowing return fields.
Description is 1200+ characters (far exceeds 1024 char guideline). It reads like API reference documentation (bullet points of features) rather than LLM-friendly guidance. No WHEN/WHY explanation, just a feature list. LLMs need 'Use this tool to retrieve CryptoAPIs reference information without consuming credits' before the feature list.
Parameter 'action' enum lacks descriptions. Each enum value (blockchains, errors, credits, callbacks, limits) should have a 1-2 sentence explanation of what data it retrieves. Currently only listed in the tool description as bullet points.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 41 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 29 | - | v1 |
No tool annotations despite marked READ_ONLY risk. The schema should declare 'readOnlyHint: true' to signal to MCP clients that this tool does not modify state. Currently inferred from description only.
Repository structure suggests this is a library package, not a standalone MCP server. No main server entry point, no MCP protocol handler visible, no explicit tool server initialization. Cannot verify if tool is actually registered with an MCP server at runtime.
Parameter 'context' description is vague: 'Optional context for the request - echoed back in response'. Does not explain WHAT context means (e.g. blockchain name, reference identifier, error code table section?) or WHY the LLM would use it.
No error handling or recovery guidance. If the tool fails or returns unexpected data, the description does not tell the LLM what to do next or what errors are possible.