
Mcp Chaining
- 464 installs
- 3.9k repo stars
- Updated January 26, 2026
- parcadei/continuous-claude-v3
mcp-chaining is a Claude Code skill that documents a research-to-implement pipeline chaining 5 MCP tools with graceful degradation for developers building multi-server agent workflows.
About
mcp-chaining is a continuous-claude-v3 skill describing an end-to-end research-to-implement MCP pipeline. It chains 5 MCP tools across servers—including nia documentation search—with graceful degradation when a server or credential is unavailable. The skill covers tool naming conventions, environment variable debugging, and when to compose multi-tool calls versus single-server usage. Developers reach for mcp-chaining when designing agent pipelines that hand context between MCP servers or debugging chained MCP failures in Bash-backed workflows.
- Enables continuous Claude sessions that persist context across multiple agent instances
- Supports MCP server chaining for complex multi-step agent workflows
- Reduces token usage and context-window pressure by distributing work
- Provides handoff protocol between independent Claude Code sessions
Mcp Chaining by the numbers
- 464 all-time installs (skills.sh)
- +2 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #1,862 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/parcadei/continuous-claude-v3 --skill mcp-chainingAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 464 |
|---|---|
| repo stars | ★ 3.9k |
| Last updated | January 26, 2026 |
| Repository | parcadei/continuous-claude-v3 ↗ |
How do you chain multiple MCP tools in one pipeline?
Let one Claude instance hand off context and tasks to another Claude instance through chained MCP servers.
Who is it for?
Agent developers wiring multi-MCP research-to-implement pipelines who need degradation patterns and server naming conventions.
Skip if: Developers only needing a single MCP server or production monitoring of live agent fleets rather than pipeline design.
When should I use this skill?
Building multi-tool MCP pipelines, debugging MCP environment variables, or learning MCP server tool naming conventions.
What you get
Documented multi-step MCP pipeline with server tool IDs, fallback behavior, and environment configuration notes.
- chained mcp workflow
- degradation fallback plan
- tool id reference table
By the numbers
- Chains 5 MCP tools in the documented pipeline
Files
MCP Chaining Pipeline
A research-to-implement pipeline that chains 5 MCP tools for end-to-end workflows.
When to Use
- Building multi-tool MCP pipelines
- Understanding how to chain MCP calls with graceful degradation
- Debugging MCP environment variable issues
- Learning the tool naming conventions for different MCP servers
What We Built
A pipeline that chains these tools:
| Step | Server | Tool ID | Purpose |
|---|---|---|---|
| 1 | nia | nia__search | Search library documentation |
| 2 | ast-grep | ast-grep__find_code | Find AST code patterns |
| 3 | morph | morph__warpgrep_codebase_search | Fast codebase search |
| 4 | qlty | qlty__qlty_check | Code quality validation |
| 5 | git | git__git_status | Git operations |
Key Files
scripts/research_implement_pipeline.py- Main pipeline implementationscripts/test_research_pipeline.py- Test harness with isolated sandboxworkspace/pipeline-test/sample_code.py- Test sample code
Usage Examples
# Dry-run pipeline (preview plan without changes)
uv run python -m runtime.harness scripts/research_implement_pipeline.py \
--topic "async error handling python" \
--target-dir "./workspace/pipeline-test" \
--dry-run --verbose
# Run tests
uv run python -m runtime.harness scripts/test_research_pipeline.py --test all
# View the pipeline script
cat scripts/research_implement_pipeline.pyCritical Fix: Environment Variables
The MCP SDK's get_default_environment() only includes basic vars (PATH, HOME, etc.), NOT os.environ. We fixed src/runtime/mcp_client.py to pass full environment:
# In _connect_stdio method:
full_env = {**os.environ, **(resolved_env or {})}This ensures API keys from ~/.claude/.env reach subprocesses.
Graceful Degradation Pattern
Each tool is optional. If unavailable (disabled, no API key, etc.), the pipeline continues:
async def check_tool_available(tool_id: str) -> bool:
"""Check if an MCP tool is available."""
server_name = tool_id.split("__")[0]
server_config = manager._config.get_server(server_name)
if not server_config or server_config.disabled:
return False
return True
# In step function:
if not await check_tool_available("nia__search"):
return StepResult(status=StepStatus.SKIPPED, message="Nia not available")Tool Name Reference
nia (Documentation Search)
nia__search - Universal documentation search
nia__nia_research - Research with sources
nia__nia_grep - Grep-style doc search
nia__nia_explore - Explore package structureast-grep (Structural Code Search)
ast-grep__find_code - Find code by AST pattern
ast-grep__find_code_by_rule - Find by YAML rule
ast-grep__scan_code - Scan with multiple patternsmorph (Fast Text Search + Edit)
morph__warpgrep_codebase_search - 20x faster grep
morph__edit_file - Smart file editingqlty (Code Quality)
qlty__qlty_check - Run quality checks
qlty__qlty_fmt - Auto-format code
qlty__qlty_metrics - Get code metrics
qlty__smells - Detect code smellsgit (Version Control)
git__git_status - Get repo status
git__git_diff - Show differences
git__git_log - View commit history
git__git_add - Stage filesPipeline Architecture
+----------------+
| CLI Args |
| (topic, dir) |
+-------+--------+
|
+-------v--------+
| PipelineContext|
| (shared state) |
+-------+--------+
|
+-------+-------+-------+-------+-------+
| | | | | |
+---v---+---v---+---v---+---v---+---v---+
| nia |ast-grp| morph | qlty | git |
|search |pattern|search |check |status |
+---+---+---+---+---+---+---+---+---+---+
| | | | |
+-------v-------v-------v-------+
|
+-------v--------+
| StepResult[] |
| (aggregated) |
+----------------+Error Handling
The pipeline captures errors without failing the entire run:
try:
result = await call_mcp_tool("nia__search", {"query": topic})
return StepResult(status=StepStatus.SUCCESS, data=result)
except Exception as e:
ctx.errors.append(f"nia: {e}")
return StepResult(status=StepStatus.FAILED, error=str(e))Creating Your Own Pipeline
1. Copy the pattern from scripts/research_implement_pipeline.py 2. Define your steps as async functions 3. Use check_tool_available() for graceful degradation 4. Chain results through PipelineContext 5. Aggregate with print_summary()
Related skills
How it compares
Pick mcp-chaining for multi-MCP pipeline design with fallbacks; use single-server MCP docs when only one integration is needed.
FAQ
How many MCP tools does mcp-chaining cover?
mcp-chaining documents a pipeline chaining 5 MCP tools end to end, including documentation search via nia__search, with graceful degradation when individual servers or credentials are unavailable.
What problems does mcp-chaining help debug?
mcp-chaining helps debug MCP environment variable misconfiguration, cross-server tool naming mismatches, and pipeline failures when chaining multiple MCP calls in research-to-implement workflows.