slop-mcp
# slop-mcp
**Install many MCPs without killing your context.**
slop-mcp is an MCP orchestrator that lets you connect dozens of MCP servers while exposing only 8 meta-tools to your agent. No more context window bloat from loading hundreds of tool definitions upfront.
```
Without slop-mcp: 50 MCPs × 20 tools = 1000 tool definitions in context
With slop-mcp: 50 MCPs × 20 tools = 8 tool definitions in context
```
## Documentation
- **[Quick Start Guide](https://dev.standardbeagle.com/slop-mcp/docs/getting-started/quick-start)** - Get running in 5 minutes
- **[Full Documentation](https://dev.standardbeagle.com/slop-mcp/)** - Complete guides and reference
- **[KDL Configuration](https://dev.standardbeagle.com/slop-mcp/docs/reference/kdl-config)** - Configuration reference
- **[CLI Reference](https://dev.standardbeagle.com/slop-mcp/docs/reference/cli)** - Command-line options
## Event Monitoring
slop-mcp integrates with [Claude Code's Monitor tool](https://docs.claude.ai/en/docs/claude-code/cli-usage#monitor) to stream events from any source — git hooks, build tools, CI pipelines, file watchers, or MCP servers.

```bash
# Start watching for events (runs until killed)
slop-mcp monitor &
# Send events from anywhere — shell scripts, git hooks, CI, cron
slop-mcp message "commit a1b2c3f: fix auth token refresh"
slop-mcp message "build failed: src/auth.ts(42): TypeError"
slop-mcp message "tests: 43 passed in 1.2s"
slop-mcp message "deploy v0.14.0 → staging (healthy)"
# Or poll MCPs with a SLOP script
slop-mcp monitor watch-deploy.slop
```
Use with Claude Code:
```javascript
Monitor({
command: "slop-mcp monitor",
description: "build events",
persistent: true
})
```
See the [Monitoring Guide](https://dev.standardbeagle.com/slop-mcp/docs/concepts/monitoring) for git hook templates, build wrappers, and SLOP polling scripts.
## Caveman Your MCPs
Third-party MCPs are written for everybody. They ship 400-token marketing-prose descriptions, deprecation caveats, twelve optional parameters you'll never set, and SDK history nobody asked for. Multiply across a dozen MCPs and that's your whole context budget — burned before the first user turn.
slop-mcp lets you **rewrite any MCP's metadata** to match what your project actually needs:
```
Before: generate_image → 420-token description, 14 params, 6 enums
After: generate_image → 30-token description, "use defaults" hints
Custom: thumbnail → 12-token description, 1 param (prompt)
```
Three progression levels:
1. **Caveman the descriptions** — replace verbose vendor prose with terse agent-friendly text. Original tool unchanged, agent sees only your version.
2. **Document hardcoded values** — for params your project never varies, the override description says "always pass X" instead of explaining the full enum.
3. **Wrap with a custom SLOP tool** — define a brand-new tool with a minimal schema (e.g. just `prompt`) that calls the underlying MCP with all the boilerplate baked in.
Customizations live at user, project, or local scope and can be exported as portable JSON packs and committed to git — your team gets the same compressed interface on clone.
See the [Customization Guide](https://dev.standardbeagle.com/slop-mcp/docs/concepts/customization) for the full image-MCP walkthrough and the `customize_tools` reference.
## The Problem
As described in Anthropic's article [Code Execution with MCP](https://www.anthropic.com/engineering/code-execution-with-mcp), current MCP implementations face two critical challenges:
1. **Context Window Overload**: When agents connect to many tools, loading all tool definitions upfront consumes excessive tokens. With thousands of connected tools, agents must process hundreds of thousands of tokens before even reading user requests.
2. **Intermediate Result Duplication**: Tool outputs repeatedly flow through the model's context. Transferring large documents between services forces the same data through the model between operations, potentially doubling token consumption.
The article proposes code execution within MCP as a solution—letting agents discover tools progressively and process data within the execution environment rather than shuttling everything through context.
## How slop-mcp Addresses These Issues
slop-mcp takes a different but complementary approach: instead of code execution, it provides an **orchestration layer** that aggregates multiple MCP servers while maintaining context efficiency.
### Progressive Tool Discovery
Rather than loading all tool definitions upfront, slop-mcp exposes just 8 meta-tools:
| Tool | Purpose |
|------|---------|
| `search_tools` | Find tools across all connected MCPs by name or description |
| `execute_tool` | Execute a specific tool on a specific MCP |
| `get_metadata` | Get full metadata (tools, prompts, resources) for connected MCPs |
| `run_slop` | Execute SLOP scripts with access to all MCPs |
| `manage_mcps` | Register/unregister MCPs at runtime |
| `auth_mcp` | Handle OAuth authentication for MCPs that require it |
| `slop_reference` | Search SLOP built-in functions by name or category |
| `slop_help` | Get full details for a specific SLOP function |
This means an agent connecting to slop-mcp sees **8 tool definitions** regardless of how many MCPs are connected or how many tools they expose. The agent discovers tools on-demand via `search_tools` and executes them via `execute_tool`.
### Lazy Connection & Async Startup
MCP servers connect asynchronously in the background:
```
Server starts → Immediately ready to serve
↓ (background)
MCP #1 connecting...
MCP #2 connecting...
MCP #N connecting...
```
The server doesn't block waiting for all MCPs to connect. Tools become available progressively as their MCPs come online.
### In-Environment Script Execution
The `run_slop` tool allows executing structured scripts that can:
- Call multiple tools across different MCPs
- Process intermediate results without sending them back through the model
- Chain operations efficiently
This keeps large intermediate data within the execution environment, addressing the token duplication problem.
### Efficient Tool Index
Tools are indexed locally when MCPs connect:
- Fuzzy search by name or description
- Filter by MCP name
- No network calls during search
- Thread-safe concurrent access
## Architecture
```
┌─────────────────────────────────────────────────────┐
│ slop-mcp Server │
│ ┌───────────────────────────────────────────────┐ │
│ │ 8 Meta-Tools (constant context cost) │ │
│ │ • search_tools • execute_tool │ │
│ │ • get_metadata • run_slop │ │
│ │ • manage_mcps • auth_mcp │ │
│ │ • slop_reference • slop_help │ │
│ └───────────────────────────────────────────────┘ │
│ │ │
│ ┌────────────────┼────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Registry │ │ Tool Index │ │ Auth │ │
│ │ (async) │ │ (local) │ │ (OAuth) │ │
│ └─────┬──────┘ └────────────┘ └────────────┘ │
└────────┼────────────────────────────────────────────┘
│
┌────┼────┬─────────────┐
▼ ▼ ▼ ▼
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│MCP #1│ │MCP #2│ │MCP #3│ │MCP #N│
│stdio │ │ SSE │ │ HTTP │ │ ... │
└──────┘ └──────┘ └──────┘ └──────┘
```
## Configuration
slop-mcp uses KDL configuration with three-tier scoping:
| Scope | File | Purpose |
|-------|------|---------|
| User | `~/.config/slop-mcp/config.kdl` | Cross-project defaults |
| Project | `.slop-mcp.kdl` | Git-tracked project config |
| Local | `.slop-mcp.local.kdl` | Git-ignored secrets |
Example configuration:
```kdl
mcp "filesystem" {
command "npx" "-y" "@anthropic/mcp-filesystem"
args "/path/to/allowed/dir"
}
mcp "github" {
transport "sse"
url "https://mcp.github.com/sse"
// OAuth handled automatically via auth_mcp tool
}
```
Import existing configurations:
```kdl
import "claude-desktop" // Import from Claude Desktop config
import "claude-code" // Import from Claude Code settings
```
## Quick Start
### npm
```bash
npx @standardbeagle/slop-mcp
```
### PyPI
```bash
uvx slop-mcp
```
Or install globally:
```bash
# npm
npm install -g @standardbeagle/slop-mcp
# pip
pip install slop-mcp
```
### From Source
```bash
go install github.com/standardbeagle/slop-mcp/cmd/slop-mcp@latest
```
## Usage
### As an MCP Server (stdio)
```bash
slop-mcp serve
```
### With HTTP/SSE Transport
```bash
slop-mcp serve --port 8080
```
### Claude Desktop Configuration
Add to your Claude Desktop config:
```json
{
"mcpServers": {
"slop": {
"command": "slop-mcp",
"args": ["serve"]
}
}
}
```
## Comparison with Code Execution Approach
| Aspect | Code Execution (Article) | slop-mcp |
|--------|-------------------------|----------|
| Tool Discovery | Filesystem exploration | `search_tools` with fuzzy matching |
| Context Cost | Minimal (code interpreter) | Constant (8 meta-tools) |
| Data Processing | In-sandbox code | SLOP scripts via `run_slop` |
| Infrastructure | Secure sandbox required | Standard MCP servers |
| Flexibility | Full code execution | Structured tool orchestration |
Both approaches solve the same core problems. Code execution offers maximum flexibility but requires sandboxing infrastructure. slop-mcp provides a simpler deployment model while still achieving significant context efficiency gains.
## Related Projects
- [standardbeagle-tools](https://github.com/standardbeagle/standardbeagle-tools) - Claude Code plugin for slop-mcp integration
## License
MIT
TDQS
Scored across 10 tools
Several tools have overlapping capabilities: slop_help and slop_reference both provide SLOP function details, get_metadata and search_tools both help discover MCP tools, and execute_tool and run_slop can both invoke MCP tools. The descriptions do clarify the intended context, but an agent has to read carefully to avoid picking the wrong one.
Most tools follow an action-first snake_case pattern like execute_tool, manage_mcps, and search_tools. However, slop_help, slop_reference, and agnt_watch break that pattern with domain-first or object-first naming, and abbreviations like agnt and mcps add inconsistency. The names are still readable, but the convention is not uniform.
Ten tools is a reasonable size for a server covering SLOP execution, MCP management, authentication, tool discovery, and customization. It is not bloated, though slop_help and slop_reference could plausibly be merged, and agnt_watch feels somewhat tangential. Overall the count is appropriate with only minor redundancy.
The set covers the core workflows: registering and managing MCPs, authenticating, discovering and executing tools, running SLOP scripts, and customizing tool definitions. There are no major dead ends, and even persistence is available through run_slop. Minor gaps exist, such as no explicit update endpoint for MCP configs and no cancellation mechanism for long-running scripts, but agents can generally work around them.