Skip to main content
Glama
PaulieB14

Substreams Search MCP Server

by PaulieB14
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

Substreams Search MCP Server

npm version

MCP server that lets AI agents search, inspect, and analyze Substreams packages — from registry discovery to sink deployment. Supports dual transport — stdio for local clients and SSE/HTTP for remote agents (OpenClaw, custom frameworks).

Tools

search_substreams

Search the substreams.dev package registry.

Parameter

Type

Default

Description

query

string (required)

—

Search term, e.g. "solana dex" or "uniswap"

sort

string

"most_downloaded"

most_downloaded, alphabetical, most_used, last_uploaded

network

string

—

Filter by chain: ethereum, solana, arbitrum-one, etc.

Returns package name, URL, creator, network, version, published date, and download count.

inspect_package

Inspect a Substreams package (.spkg) to see its full module graph, protobuf types, and metadata.

Parameter

Type

Description

url

string (required)

Direct URL to a .spkg file

Returns:

  • Package metadata (name, version, documentation, network)

  • All modules with their kind (map/store/blockIndex), output types, and update policies

  • Full DAG: each module's dependsOn and dependedBy relationships

  • Input chain for each module (source blocks, other maps, stores with get/deltas mode, params)

  • List of all protobuf output types and proto files

  • Mermaid diagram of the module graph

list_package_modules

Lightweight alternative to inspect_package — just the module names, types, and inputs/outputs.

Parameter

Type

Description

url

string (required)

Direct URL to a .spkg file

get_sink_config

Analyze a package's sink configuration and generate ready-to-run CLI commands.

Parameter

Type

Description

url

string (required)

Direct URL to a .spkg file

Returns one of three results:

  • sink_configured — Package has an embedded sink config. Extracts the SQL schema (for SQL sinks), identifies the sink module and type, and generates install, setup, and run commands with the correct network endpoint.

  • no_sink_config_but_compatible_modules_found — No embedded config, but modules output sink-compatible types (e.g. DatabaseChanges). Identifies them and suggests how to wire up sinking.

  • no_sink_support — No sink-compatible modules. Lists all module output types so you know what custom consumer you'd need.

Related MCP server: @lpm-registry/mcp-server

Workflow

search_substreams("uniswap", network: "polygon")
  → find package, get spkg.io URL

inspect_package("https://spkg.io/creator/package-v1.0.0.spkg")
  → see module DAG, output types, what it produces

get_sink_config("https://spkg.io/creator/package-v1.0.0.spkg")
  → get SQL schema + CLI commands to deploy

Quick Start (npx)

No installation needed:

Claude Desktop / Cursor / Claude Code (stdio)

Add to your MCP config (claude_desktop_config.json, ~/.cursor/mcp.json, or ~/.claude/mcp.json):

{
  "mcpServers": {
    "substreams-search": {
      "command": "npx",
      "args": ["substreams-search-mcp"]
    }
  }
}

OpenClaw / Remote Agents (SSE)

Start the server with the HTTP transport:

# Dual transport — stdio + SSE on port 3849
npx substreams-search-mcp --http

# SSE only (for remote/server deployments)
npx substreams-search-mcp --http-only

# Custom port
MCP_HTTP_PORT=4000 npx substreams-search-mcp --http

Then point your agent at the SSE endpoint:

{
  "mcpServers": {
    "substreams-search": {
      "url": "http://localhost:3849/sse"
    }
  }
}

Transport Modes

Invocation

Transports

Use case

npx substreams-search-mcp

stdio

Claude Desktop, Cursor, Claude Code

npx substreams-search-mcp --http

stdio + SSE :3849

Dual — local + remote agents

npx substreams-search-mcp --http-only

SSE :3849

OpenClaw, remote deployments

A /health endpoint is available at http://localhost:3849/health when HTTP transport is active.

How it works

  • Search: The substreams.dev registry has no public API. This server scrapes the package listing pages, paginates through all results, deduplicates, and returns structured JSON. Multi-word queries search for the first word server-side and filter the rest client-side.

  • Inspect: Uses @substreams/core to fetch and parse .spkg files (protobuf-encoded Substreams packages), extracting module definitions, DAG relationships, and proto type information.

  • Sink config: Reads the embedded sinkConfig (a google.protobuf.Any field) from the package, decodes it based on the type URL, and maps networks to Substreams endpoints for correct CLI commands.

Available Tools

1 tool
search_substreamsA
Read-only

Search the substreams.dev package registry for blockchain data stream packages. Multi-word queries filter results to match all words.

ParametersJSON Schema
NameRequiredDescriptionDefault
sortNoSort ordermost_downloaded
queryYesSearch term, e.g. 'solana dex' or 'uniswap'
networkNoFilter by blockchain network, e.g. 'ethereum', 'solana', 'arbitrum-one'

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds value beyond the readOnlyHint annotation by specifying that multi-word queries match all words (AND logic), which is a behavioral trait not documented elsewhere. It is consistent with annotations and provides useful context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main purpose, no extraneous information. Every sentence is valuable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with complete schema description and readOnlyHint annotation, the description adequately covers the tool's purpose and behavior. No output schema exists, but the description does not need to explain return values as per instructions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters are fully described in the schema (100% coverage), so the description does not need to add much. It mentions multi-word query behavior, which marginally enhances the query parameter meaning, but overall the schema carries the burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool searches the substreams.dev package registry for blockchain data stream packages, and specifies multi-word query behavior. It uses a specific verb and resource, making the purpose unmistakable even without sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for searching packages but does not provide explicit guidance on when to use this tool versus alternatives (none exist) or any prerequisites. The context is clear enough for an agent to infer appropriate use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0
Disambiguation5/5

Only one tool exists, so there is no possibility of confusion between tools.

Naming Consistency5/5

The single tool name follows a clear verb_noun pattern (search_substreams), consistent with common conventions.

Tool Count4/5

The server is purpose-built for searching, so a single search tool is appropriate and not excessive, though it is minimal.

Completeness3/5

The tool covers basic search functionality but lacks advanced features like filtering by package attributes or retrieving package details, which could be expected for a registry search server.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/PaulieB14/substreams-search-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server