MCP server for streaming live blockchain data from Indexing Co pipelines
The server registers 14 tools with explicit schemas and descriptions in src/mcp/tools.ts using Zod validation. Naming follows verb_noun conventions (subscribe, unsubscribe, get_*, list_*, create_, delete_, query, chart, describe_*, clear_). Descriptions are present for all tools and most parameters. However, several tools lack comprehensive parameter descriptions, output schemas are not explicitly documented, and error handling, while present, lacks recovery guidance in most cases. The server uses STDIO transport, which caps protocol readiness at 50. Definition quality averages around 62 across tools, good fundamentals but gaps in completeness and LLM-optimization.
Backfill historical data for a pipeline.
Run a SQL query and render the results as an ASCII chart. Types: sparkline, line, bar, histogram, table.
Delete stored events (all or by channel).
Create or update a pipeline. Adapter types: POSTGRES (with connectionUri, table, uniqueKeys), HTTP (for webhooks — do NOT use "webhook"), WEBSOCKET, DIRECT (stream to MCP via connectionUri channel name).
Delete a pipeline.
Auto-discover data shape: sample keys, types, and value examples from stored events.
Output schemas not documented. Tools like get_subscriptions, get_events, describe_data, list_pipelines, get_pipeline, and get_status return structured data but do not document their response schemas. LLMs cannot predict field names or types for downstream planning.
Parameter descriptions are minimal or absent in several tools. The 'options' parameter in chart has a description but its nested properties (title, width, height, bins) lack field-level docs. The 'delivery' object in create_pipeline has inline descriptions but lacks type clarity for nested fields.
Error messages are generic. Tools return error() responses with basic messages, but do not guide LLM recovery. Example: subscribe() returns 'No DIRECT pipeline found for channel' with hints, which is good. But query() and chart() return generic 'Query error' and 'Chart error' without actionable guidance on what went wrong.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 58 | - | v1 |
Get recent raw events. Returns JSON payloads as-is.
Get a pipeline by name.
WebSocket state, channels, event counts, and uptime.
List active channels, connection status, and event counts.
List all pipelines. For DIRECT streaming pipelines, the delivery.table field is the channel name to use with subscribe.
Run a read-only SQL query against stored events. Use json_extract(data, '$.key') to query event fields.
Subscribe to a pipeline's DIRECT channel. The channel name must match the `table` field of a pipeline with DIRECT adapter. Use list_pipelines to find valid channel names.
Stop receiving events for a channel.
Destructive tools (clear_events, delete_pipeline) lack confirmation or dry-run patterns. An LLM could accidentally delete all events or a pipeline without user confirmation. No CONFIRMATION_REQUEST pattern is implemented.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are not present in tool registration. While the Risk field in the schema metadata indicates READ_ONLY, WRITE, and DESTRUCTIVE, these are not passed to the MCP SDK as tool annotations.
Missing pagination metadata. get_events accepts limit and offset but does not return a total_count or has_more flag. LLMs cannot determine if more results exist without calling again.