⛓️ Context-Pipe

The Universal Standard for Context Engineering.

context-pipe is a high-performance orchestration layer directly inspired by Unix terminal piping — the same philosophy that made cmd1 | cmd2 | cmd3 the most durable composition primitive in computing. Just as the terminal chains processes through stdin/stdout byte streams, Context-Pipe chains AI tool calls through context streams: each node does one thing, passes its output to the next, and the LLM only sees the final, refined signal.

This is not a metaphor — it is a literal extension. Context-Pipe supports both MCP piping (chaining MCP tool calls through the orchestrator) and terminal piping (any binary, shell command, or script that reads stdin and writes stdout is a valid node). The two modes compose freely in a single pipe definition. And through the mcp-pipe CLI, it extends the terminal itself: the mcp-pipe tool subcommand makes any MCP server — context-mode, serena, GitHub, Firecrawl, or any server registered in pipes.json — directly pipeable from the shell, loading on demand, with no wrapper scripts and no IDE required:

cat error.log | mcp-pipe tool semantic-sift sift_logs | rg "CRITICAL"
curl -s https://example.com | mcp-pipe tool firecrawl scrape | mcp-pipe run semantic-refinery

Today, mcp-pipe run <pipe> already gives the terminal first-class access to any named pipe defined in pipes.json, composing terminal binaries through the same orchestrator used by the IDE.

🚀 The Vision

The AI agent has a fundamental infrastructure problem: every tool call returns raw, unfiltered output directly into the context window. Logs arrive with timestamps. Search results arrive with boilerplate. Agent A's 40KB analysis gets passed verbatim to Agent B. The context window fills. Signal drowns in noise. The LLM degrades.

context-pipe solves this at the infrastructure layer — before the LLM sees anything.

In the Studio of Two philosophy, we build Systems, not Patches. A patch would be a custom filter per tool. A system is a universal protocol: any tool that reads stdin and writes stdout becomes a node. Any sequence of nodes becomes a pipe. Any pipe is named, versioned, audited, and reusable across every project and every agent framework.

The result is a context supply chain: data enters raw, passes through a sequence of refineries (normalize → filter → compress → distil), and arrives at the LLM as dense, high-signal content. Every byte saved is accounted for in the Context Balance Sheet. Every pipe run is traceable. Every A2A handoff is protected.

This is not a wrapper around semantic-sift. It is the orchestration layer that makes any refinery composable, observable, and production-grade. A node can be a binary, a shell command, a Python script, or a full MCP tool (Figma, GitHub, context-mode, or any server registered in pipes.json). If it reads stdin and writes stdout, it belongs in the pipe.

Example — crawl the web, research it, save it, and ship it:

trigger: tool:web_search | tool:web_fetch

[URL]
    → firecrawl/scrape             # MCP node: fetch live page as clean text     ~18,400 tokens
    → markitdown                   # binary node: convert to structured Markdown     ~16,200 tokens
    → rg 'security|vulnerability'  # shell node: surface only relevant sections      ~3,100 tokens
    → prettier --parser markdown   # shell node: normalize formatting                ~3,050 tokens
    → semantic-sift-cli doc        # binary node: distil to high-signal summary        ~420 tokens
          ↳ tee → research.md      # T-pipe: save raw distilled copy to disk
    → security-auditor             # script node: project-specific logic               ~380 tokens
    → github/create_issue          # MCP node: open a tracked issue with findings

Context Balance Sheet (illustrative)
  in:  18,400 tokens  →  out: 380 tokens  —  97.9% saved  ·  1.2s total

Every node is a real subprocess. The T-pipe saves a raw copy at any point without interrupting the chain. The LLM receives only what matters — and every byte in, byte out, and millisecond of latency is recorded in the Context Balance Sheet automatically.

🛠️ Core Components

1. The Context-Pipe Protocol (CPP)

A language-agnostic standard with one rule: a node reads stdin, transforms content, and writes to stdout. Any binary, shell command, Python script, or MCP tool that honours this contract is a valid node. The protocol is defined in doc/CONTEXT_PIPE_PROTOCOL.md and is deliberately simple — no SDKs, no registration, no framework coupling.

2. The Orchestration Spine (orchestrator.py)

The execution engine that chains nodes into pipes. Runs each node as a real OS subprocess with shell=False enforced (no injection surface). Features: per-node timeout guard (PIPE_NODE_TIMEOUT_MS), T-Pipe stream splitting (save raw input to disk before a node processes it), and full trace accounting (input/output size + latency per node).

3. The Universal Switchboard (pipes.json + mappings)

Data-driven routing that resolves the optimal pipe automatically based on three trigger types: tool name (tool:regex), payload size (size:>N), and default fallback. Pipe definitions live in pipes.json (project-level) and optionally ~/.mcp-pipe.json (global, merged with local precedence). No code changes required to add, modify, or re-route pipes.

4. The MCP Surface (server.py + mcp-pipe CLI)

Eight MCP tools expose every capability to AI assistants directly: pipe_run, pipe_run_dynamic, pipe_read_file, pipe_analyze_file, pipe_list_shadow_tools, pipe_agent_handoff, get_pipe_stats, and pipe_onboard. The mcp-pipe CLI mirrors the same surface for terminal-first workflows — no IDE required. Shadow Tool Discovery (pipe_list_shadow_tools) gives the agent a live capability manifest combining configured pipes and curated PATH tools (jq, rg, markitdown, pandoc…).

5. Subconscious Interceptors (pipe_hook.py + onboarding.py)

IDE hooks that apply pipes transparently after every tool call — without the agent needing to invoke pipe_run explicitly. Supported: Cursor (postToolUse), VS Code/GitHub (hooks), Claude Code/Qwen/Codex (PostToolUse), Windsurf and Cline (pre-read security gateway), OpenClaw (native plugin), and pi.dev (native TypeScript extension). For OpenCode, the AGENTS.md SOP mandate is the active strategy (see Known Limitations). pipe_onboard injects all hooks, slash commands (/pipe-run, /pipe-dynamic, /pipe-handoff, /pipe-stats), and the full agent SOP in one command.

6. The A2A Bridge (a2a.py)

pipe_agent_handoff() distils Agent A's output before it enters Agent B's context window. Framework-agnostic — no monkey-patching. Works in CrewAI task callbacks, Google ADK transfer hooks, LangGraph edge functions, or any custom handoff point. Available as both a Python function and an MCP tool. Returns the original output unchanged on any error, so the agent chain is never interrupted.

7. The Native Rust Core (crates/cpipe)

cpipe is the high-performance Rust heart of the Context-Pipe ecosystem. It ports the full orchestration engine — config merging, placeholder resolution, stream routing, and the self-aware bypass guard — to a pre-compiled native binary with <2ms startup latency (500× faster than the Python runtime). It coexists with the Python server: MCP tools stay in Python (FastMCP), while the Rust binary is available as a Tauri sidecar, a standalone CLI (cpipe run, cpipe list, cpipe serve), or a Cargo library for direct embedding in Rust applications. See crates/cpipe/README.md for the full API.

8. The TypeScript/JavaScript Client (packages/cpipe-js)

@context-pipe/client is the browser-safe, sandboxed client-side port of the engine. It simulates Unix pipes entirely in memory, supports standard nodes (grep, replace), allows custom PWA node registration (RAG database lookups, CORS proxies), and fully integrates with AbortSignal for cancellation. See packages/cpipe-js/README.md for the full API and examples.

✨ What Makes This Different

🧠 The Architecture: Semantic Enums (Solving Schema Bloat)

In standard MCP setups, exposing multiple capabilities (PDF parsing, log searching, HTML cleaning) means exposing multiple tools. This causes Schema Bloat: the LLM's system prompt fills with thousands of tokens of complex tool instructions. For Small Language Models (SLMs), this pushes out chat history, overwhelms the context window, and leads to hallucinations.

context-pipe solves this through Semantic Enums. Instead of teaching the AI how to use complex command-line utilities, you expose a single tool: pipe_run(input, pipe_name). The pipe_name parameter is simply an Enum of your predefined pipelines (e.g., ["parse-and-clean-pdf", "extract-critical-errors"]).

This perfectly separates Intent from Execution:

• The LLM provides the Intent: "I need the clean text of this PDF, so I'll call the parse-and-clean-pdf pipe."
• pipes.json provides the Execution: [pandoc -> jq -> semantic-sift]

By using brief, concise pipe names, you achieve extreme prompt compression. The AI gets a menu of high-level "buttons to push" rather than reading an instruction manual for every utility on the host machine. Better yet, if you upgrade your backend tooling (e.g., swapping pandoc for markitdown), you never have to update the LLM's prompt. The AI still calls the same pipe; the engine behind it just gets faster.

🔧 Three Independent Axes of Change

A CPP pipeline separates concerns across three layers that evolve on completely independent cycles:

Improving a node's quality does not change the topology. Restructuring the routing does not touch any node. Upgrading an MCP server improves every pipe that uses it automatically — with no pipeline changes.

For MCP nodes specifically, this dissolves the traditional dependency model entirely. Every MCP server speaks the same protocol: JSON-RPC, tools/call, text response. The pipe does not depend on what implements the service — it depends on what speaks the protocol. The entire MCP ecosystem is therefore the pipe's capability layer. Every current and future MCP server is already a valid drop-in replacement for any node that serves the same semantic purpose.

In a script, you depend on what you import. In a pipe, you depend on what speaks the protocol.

This separation also means routing is compilation-free. In a traditional script, safeguards and recovery logic are embedded in code — changing how a workflow recovers requires changing, testing, and redeploying the script. In CPP, routing lives in pipes.json. A branch, a reroute, or a node swap is a configuration edit. The feedback loop between "what if I reroute this" and "let me observe what happens" collapses to near zero.

📚 Documentation

Detailed documentation is available in the doc/ directory.

• doc/INDEX.md: The navigational roadmap for the documentation ecosystem.
• doc/USE_CASES.md: Real-world, high-impact scenarios demonstrating how to chain Bash, Script Nodes, and Semantic-Sift.
• doc/OPERATOR_GUIDE.md: Definitive guide for setup, terminal mastery, and pipes.json configuration.
• doc/ARCHITECTURE.md: Technical specifications of the orchestration spine and switchboard.
• doc/CONTEXT_PIPE_PROTOCOL.md: The language-agnostic standard for tool interoperability.
• doc/INTEGRATION_ENCYCLOPEDIA.md: Master Compatibility Matrix for Cursor, VS Code, Gemini/Antigravity, and Claude.

🤝 A2A (Agent-to-Agent) Handoff

When chaining agents, use pipe_agent_handoff to distil Agent A's output before it enters Agent B's context window. Works with any framework — no monkey-patching required.

from context_pipe.a2a import pipe_agent_handoff

# In a CrewAI task callback, ADK transfer hook, or any custom handoff point:
agent_b_input = pipe_agent_handoff(
    agent_a_output,
    pipe_name="semantic-refinery",   # optional; auto-routes if omitted
    from_agent="researcher",
    to_agent="writer",
)

Also available as an MCP tool — ask your AI assistant: "Run pipe_agent_handoff() to distil this agent output before passing it on."

Function signature:

def pipe_agent_handoff(
    output: str,
    pipe_name: str | None = None,   # explicit pipe; auto-routes if omitted
    from_agent: str | None = None,  # producing agent label (telemetry + routing)
    to_agent: str | None = None,    # consuming agent label (telemetry only)
    config_path: str = "pipes.json",
) -> str: ...

Always returns the original output unchanged on any error — the agent chain is never interrupted.

🔗 Advanced Node Types

Context-Pipe supports more than just simple binaries. You can chain standard OS tools and expert mandates.

1. Bash Nodes (Sandboxed)

Execute arbitrary shell commands as part of your pipe. By design, all commands are executed natively with shell=False to prevent injection vulnerabilities.

{ "cmd": "grep", "args": ["ERROR"] }

2. Script Nodes

Executes a project-specific script (Python/Shell) or a local instruction set. Resolved from .gemini/scripts/ (default).

{ "type": "script", "cmd": "security-auditor" }

3. T-Pipe Nodes (Stream Splitting)

Save a raw copy of the stream to disk before a node distils it — without interrupting the chain. Useful for debugging pipe quality and auditing what was sifted out.

{
  "cmd": "semantic-sift-cli",
  "args": ["logs"],
  "tee": {
    "sink": "file",
    "path": "logs/{tool_name}_{iso_date}.log",
    "mode": "append"
  }
}

path supports {iso_date} (YYYY-MM-DD) and {tool_name} tokens. A tee failure never interrupts the main chain.

4. MCP Nodes

Call any MCP tool as a pipe node. No wrapper scripts — the orchestrator spawns the MCP server, calls the tool, and passes the result downstream via stdout.

{
  "type": "mcp",
  "server": "figma",
  "tool": "get_file",
  "input_key": "file_id"
}

Server definitions live in a servers block in pipes.json or ~/.mcp-pipe.json. See doc/MCP_NODE_SPEC.md for the full spec.

5. Validator Nodes (Phase 11)

A validator runs a subprocess and routes on its exit code instead of flowing linearly. Use this to build self-healing pipelines that try to fix problems automatically before failing.

{
  "name": "self-healing-lint",
  "nodes": [
    {
      "cmd": "eslint",
      "args": ["--format", "compact", "src/"],
      "type": "validator",
      "id": "lint-check",
      "branches": {
        "0": "done",
        "1": "auto-fix",
        "default": "auto-fix"
      }
    }
  ],
  "branch_sequences": {
    "auto-fix": [
      { "cmd": "eslint", "args": ["--fix", "src/"] },
      { "cmd": "semantic-sift-cli", "args": ["logs"] }
    ],
    "done": [
      { "cmd": "semantic-sift-cli", "args": ["logs"] }
    ]
  }
}

• Exit 0 → linting passed, jumps to done (distil the clean report).
• Exit 1 → linting failed, jumps to auto-fix (run --fix, then distil).
• "default" catches any other exit code (e.g. 2 for ESLint config errors).
• The validator's stdout is forwarded as input to the target sequence.

6. Condition Keys (Phase 11)

Any node can be conditionally skipped without modifying the pipe definition:

{
  "cmd": "neural-summariser",
  "condition": "size:>8000"
}

The node only runs if the current input exceeds 8 000 bytes. Supported predicates:

Unknown predicates fail-open (warn + run the node) to avoid silently blocking pipelines.

🔗 The Ecosystem (Studio of Two)

Context-Pipe is a foundational member of the Studio of Two infrastructure. It is designed to work in high-fidelity harmony with:

• Semantic-Sift: The intelligent refinery for agentic context. Sift is the flagship distillation engine for Context-Pipe, providing the mathematical and neural sifting nodes used in our standard templates.
• std-context-lab: The official integration laboratory and test gauntlet. This repository serves as our isolated battle-testing ground where cross-repository capabilities, MCP server combinations, and terminal hook interactions are simulated and verified.
  • Isolated Scenarios: Runs isolated test cases mimicking real-world AI behaviors to reproduce and verify fixes without polluting core runtimes.
  • Empirical Evidence: Every resolved bug or feature is accompanied by a tracked execution log (EVIDENCE.md), serving as empirical proof of success.
  • Platform Parity Gate: Audits Python/Rust CLI parity and shell behaviors across Windows (PowerShell/CMD) and UNIX terminals before release.

🧩 Tool Synergies & Boundaries

Four tools often appear together in a Studio of Two stack. They are complementary, not overlapping — each owns a distinct layer.

When to use which

Use context-pipe when you need to orchestrate: chain tools, apply pipes automatically on tool call, route by trigger, save T-pipe snapshots, account for ROI, or bridge agent handoffs.

Use semantic-sift when you need to compress: a large document, a log file, a search result, or any payload where noise-to-signal ratio is high. Runs standalone via CLI or MCP — and as a node inside context-pipe pipes.

Use context-mode when you need to retrieve: you have already ingested content this session and want fast BM25 search over it. Works standalone as an MCP server in any IDE. Pair it with semantic-sift on both sides — upstream to compress content before indexing (smaller index, faster search), and downstream to distil retrieved chunks before they hit the context window.

Use Serena when you need to navigate code: find a symbol, trace references, inspect types, or perform a refactor. Works standalone as an MCP server. Its structured, precise output is far better than a raw file read as input to any downstream tool — including a sifting pipe.

Complementary setup — reducing token usage

Each tool independently reduces token pressure. Together, the savings compound:

• Serena returns only the symbol you asked for — not the entire file.
• semantic-sift compresses content before it enters context-mode (smaller index, faster search) and after retrieval (noise-free chunks into the context window).
• context-mode returns only the relevant indexed chunks — not the entire ingested corpus.
• context-pipe ensures this sequence fires automatically and is accounted for — no manual wiring per task.

The result: the agent works with a fraction of the raw token volume, every session, without changing how it thinks or what tools it calls.

Synergy example

[user query]
    → serena/find_symbol           # MCP node: precise code symbol — not a raw file dump
    → context-mode/search          # MCP node: retrieve related session context
    → semantic-sift-cli semantic   # binary node: compress both into a dense summary
    → security-auditor             # script node: project-specific logic

All four tools in one pipe. Each doing exactly one job.

⚙️ Environment Variables

⚖️ Licensing

context-pipe is licensed under the Apache License 2.0. It is an "Open Source, Closed Contribution" project maintained by the Studio of Two to ensure architectural integrity.

Building High-Fidelity Infrastructure for the Intelligence Age.

🚀 Quickstart (60 seconds)

# 1. Install
pip install mcp-context-pipe "semantic-sift[neural]"

# 2. Onboard (auto-creates pipes.json + hooks for your IDE)
context-pipe-onboard   # or: ask your AI "Run pipe_onboard()"

# 3. Verify the full stack
echo "noisy log [14:22:05.123] DEBUG: heartbeat ok" | context-pipe run standard-distill
# → distilled, noise-free output with audit header

Full setup guide (Sovereign Dual-Repo Pattern, venv layout, IDE config): doc/OPERATOR_GUIDE.md

🏗️ Getting Started

1. Installation

Option A: Quick Install (PyPI)

Because MCP servers require an explicit Python executable path in your IDE config, you must create a virtual environment first:

ℹ️ What you get: This installs the Context-Pipe orchestration layer and Semantic-Sift's core Python server. The sift-core Rust binary (for near-instant heuristic sifting) is included in the PyPI wheel — no Rust toolchain required. The [neural] extra adds PyTorch (~1.5 GB) for large-payload semantic compression.

uv venv
# Windows: .\.venv\Scripts\activate
# macOS/Linux: source .venv/bin/activate
uv pip install mcp-context-pipe "semantic-sift[neural,multi-modal]"

Option B: Sovereign Pattern (Recommended for Studio of Two) Clone both repos side-by-side. The context-pipe venv acts as the master environment holding both packages. See Section 0 of the Operator's Guide for the full sequence.

# 1. Clone both repos
git clone https://github.com/luismichio/context-pipe.git
git clone https://github.com/luismichio/semantic-sift.git

# 2. Master venv in context-pipe - holds both packages
cd context-pipe
python3.12 -m venv venv
# Windows:
.\venv\Scripts\activate
# macOS/Linux:
# source venv/bin/activate
uv pip install -e .
uv pip install -e ../semantic-sift  # semantic-sift-cli lands in context-pipe/venv/Scripts/ (Win) or venv/bin/ (Mac/Linux)

# 3. ML runtime venv in semantic-sift (Python 3.12 for torch/CUDA compatibility)
cd ../semantic-sift
python3.12 -m venv venv312
# Windows:
.\venv312\Scripts\activate
# macOS/Linux:
# source venv312/bin/activate
uv pip install -e .[neural]         # torch, transformers, llmlingua

Note: The package name on PyPI is mcp-context-pipe but the installed module is context_pipe. The semantic-sift-cli binary is registered only in the venv where semantic-sift is pip-installed (step 2 above). Both pipes.json files must reference that absolute path.

2. Connect the MCP

CRITICAL: For exact configuration paths for Cursor, Gemini, Antigravity, OpenCode, VS Code, and Claude, reference the Master Configuration Matrix.

3. Connect a Refinery

Context-Pipe is the "Switchboard," but it needs a "Refinery" to distill data. Semantic-Sift is the flagship intelligence engine for this ecosystem. It uses heuristic sieves and neural models (BERT/ONNX) to incinerate noise (timestamps, boilerplate) while preserving 95% of the signal.

Note: In the Sovereign Pattern, semantic-sift is cross-installed into context-pipe/venv (step 2 above). Context-Pipe will also auto-discover a separately installed semantic-sift-cli across all known locations (system PATH, pipx, sibling venv directories) via pipe_onboard or pipe_verify.

4. Verify the Installation

After installing both packages, ask your AI assistant to verify the full stack:

"Run pipe_verify() to confirm the installation."

This will report the health of every component and automatically link semantic-sift-cli into pipes.json if it was found in a separate environment.

5. Configure your first Pipe

Edit pipes.json (see pipes.json.example) to define your high-fidelity context streams.

6. Auto-Onboard

Once connected, ask your AI Assistant to configure your workspace:

"Run pipe_onboard(environment='Cursor') to configure this project."

pipe_onboard auto-detects your IDE if environment is omitted — it inspects environment variables and parent-process names to fingerprint 12+ platforms (Cursor, Gemini, Antigravity, OpenCode, VS Code, Windsurf, Claude, Cline, etc.). Pass environment explicitly only when auto-detection is ambiguous.

🐍 Programmatic Usage

Python

Context-Pipe exposes a single pipe() function for direct integration into Python scripts, notebooks, and agent frameworks (LangChain, CrewAI, etc.) — no MCP server or CLI required.

from context_pipe import pipe

# Auto-route based on pipes.json mappings
clean = pipe(raw_logs, tool_name="bash")

# Specify a pipe explicitly
distilled = pipe(document_text, pipe_name="semantic-refinery")

# Minimal usage — returns input unchanged if no pipe resolves
result = pipe(text)

Function signature:

def pipe(
    text: str,
    pipe_name: str | None = None,
    tool_name: str = "",
    config_path: str = "pipes.json",
    vars: dict | None = None,
) -> str: ...

The function always returns the original text unchanged on any error (subprocess failure, missing config, etc.), so it is safe to use as a drop-in filter.

JavaScript/TypeScript

For client-side runtimes (browsers, PWAs, extensions), install the sandboxed package:

npm install @context-pipe/client

Initialize the PipelineEngine and run your configurations:

import { PipelineEngine } from '@context-pipe/client';

const engine = new PipelineEngine({ failFast: true });

// Run a named pipe configuration
const output = await engine.runPipe(pipeConfig, rawLogs);

See the client README for details on registering custom database or fetch nodes and handling cancellations.

Rust Library (cpipe)

For Rust or Tauri applications, embed the native core directly:

use cpipe::config::load_pipes_config;
use cpipe::orchestrator::run_pipe;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    let config = load_pipes_config();
    let pipe = config.pipes.iter().find(|p| p.name == "standard-distill")
        .ok_or("Pipe not found")?;

    let (output, _telemetry) = run_pipe(
        pipe,
        "raw context text here",
        Some("my-tool"), None, &config.servers,
    ).await;

    println!("{output}");
    Ok(())
}

Add to your Cargo.toml:

[dependencies]
cpipe = { git = "https://github.com/luismichio/context-pipe", path = "crates/cpipe" }

Pre-built binaries for Windows, macOS (Intel & Apple Silicon), and Linux are available on the GitHub Releases page, or download via:

python scripts/fetch_cpipe.py

💻 Terminal Usage (mcp-pipe CLI)

Context-Pipe ships a first-class terminal runner — mcp-pipe — so you can use every capability without an IDE or MCP server.

# Run a named pipe on stdin
cat app.log | mcp-pipe run standard-distill

# Run a named pipe on a file directly
mcp-pipe run semantic-refinery --file spec.md

# Run an ad-hoc node array (shell synergy requires --allow-shell)
echo "noisy output" | mcp-pipe run-dynamic '[{"cmd":"semantic-sift-cli","args":["logs"]}]'

# List all configured pipes + curated PATH tools (Shadow MCP discovery)
mcp-pipe list

# Print the Context Balance Sheet (ROI across all sessions)
mcp-pipe stats

# Start the MCP server manually (stdio transport)
mcp-pipe serve

# Install/remove the cpipe shell alias
mcp-pipe aliases install
mcp-pipe aliases remove

The mcp-pipe entry point is registered automatically when you pip install mcp-context-pipe. Use cpipe as a shorthand after running mcp-pipe aliases install.

Shadow MCP Registry

Every MCP server you add to an IDE registers its tools globally — they all appear in the agent's tool list whether the agent needs them or not. At scale this causes MCP tool bloat: hundreds of tools in the prompt, wasted tokens on every inference call, and a higher chance the agent picks the wrong one.

context-pipe takes a different approach. Instead of registering every context-processing tool as a first-class MCP tool, it exposes a single discovery tool — pipe_list_shadow_tools — that returns a live capability manifest on demand. The tools stay hidden ("shadow") until the agent asks for them. One MCP tool does the work of many.

What the manifest includes:

1. pipes.json pipes — every named pipe configured in your project.
2. Curated PATH tools — probes 7 well-known CLI tools (jq, yq, markitdown, pandoc, rg, fd, bat) and surfaces any found on PATH.

Known limitation: shadow tools are not callable as independent MCP tools — the agent must route them through pipe_run or pipe_run_dynamic. This is by design (it keeps the MCP surface minimal), but it means the agent cannot call jq or markitdown directly without constructing a dynamic pipe node.

Terminal access via mcp-pipe: the same manifest is available without an IDE or MCP server — mcp-pipe list prints every pipe and curated PATH tool to stdout. Pipe any content through a shadow tool directly from the terminal:

# Discover what's available
mcp-pipe list

# Run a shadow tool via a dynamic pipe — no pipes.json entry needed
echo "# My Doc" | mcp-pipe run-dynamic '[{"cmd":"markitdown"},{"cmd":"semantic-sift-cli","args":["doc"]}]'

⚠️ Known Limitations

OpenCode — MCP Tool Output Interception

The "subconscious interceptor" feature (pipe_hook.py) works transparently for Cursor, VS Code, Gemini CLI, Antigravity CLI, and Claude Desktop by injecting hook handlers that fire after every tool call.

OpenCode is the exception. The tool.execute.after hook is declared in the OpenCode plugin Hooks interface but is never triggered by the OpenCode runtime (confirmed via source audit of session/processor.ts, session/llm.ts, tool/registry.ts, agent.ts). The plugin's output mutation code is silently a no-op.

Current workaround: The AGENTS.md SOP mandate (pipe_read_file for all file reads) is the active interception strategy for OpenCode until transparent hook injection is supported upstream.

• Upstream issue: sst/opencode#21149
• Plugin issue: sst/opencode#25918
• Tracked in our backlog: Phase 4.5 — see doc/backlog.md