Loading ToolBench
MCP server to search and inspect Substreams packages — browse the registry and introspect .spkg module graphs, protobuf types, and DAG dependencies
This server has three tools with reasonable naming (verb-noun convention: search_, inspect_, module_) and parameter schemas are present in the TypeScript source. However, there are critical gaps in descriptions and schema completeness. The Python implementation (server.py) is incomplete and appears abandoned (package.json shows TypeScript as the main entry point). The TypeScript code is truncated mid-function, making it impossible to verify the full implementation. Tool descriptions exist but lack depth on when to use each tool vs. alternatives. Parameter descriptions are present but minimal. Output schemas are undocumented, LLMs cannot plan downstream calls without knowing what fields are returned. Error handling is not visible in the truncated source. The server uses STDIO transport, which is a hard cap at 50, but definition quality issues push this lower.
Load and introspect a .spkg package from a URL, returning its module definitions, DAG dependencies, protobuf types, and execution metadata.
Generate a Mermaid flowchart of a package's module dependency graph (DAG), showing inputs, outputs, and execution order.
Search the substreams.dev package registry for blockchain data stream packages. Multi-word queries filter results to match all words.
Output schemas undocumented. LLMs cannot infer what fields are returned from search_substreams, inspect_package, or module_graph. Without response documentation, agents cannot plan chained calls or extract required data.
Parameter descriptions are minimal and lack actionable constraints. 'spkg_url' says 'Direct URL to a .spkg binary file' but does not specify format, valid domain patterns, or error cases if the URL is invalid or unreachable. LLMs will guess and may pass malformed URLs.
search_substreams 'sort' parameter has enum constraint but description does not list allowed values inline.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Tool descriptions do not explain WHEN to use each tool vs. alternatives. Users cannot infer the distinction between search_substreams (find packages) and inspect_package (load details of a known package) without trial and error.
inspect_package returns complex protobuf types and DAG structures. Without a documented output schema, LLMs cannot navigate the nested response or extract module names, dependencies, or type definitions. This forces manual parsing and hallucination risk.
Source code is truncated mid-function (src/index.ts ends at line 'c'). The full implementation of tool handlers, error handling, and output generation is not visible. Scoring is based on incomplete evidence.
No error handling visible. If a search returns zero results, an invalid URL is passed, or the substreams.dev API is down, the tool does not guide the LLM on recovery. Per Python code, there is a fallback message for unavailable results, but TypeScript implementation is cut off.