This server acts as an MCP orchestrator, exposing 8 meta-tools to manage and interact with multiple MCP servers without overwhelming the context window.
Search tools (search_tools): Fuzzy search across all connected MCP servers by name or description, with pagination to discover tools on demand.
Execute tools (execute_tool): Run any tool on any connected MCP by specifying MCP name, tool name, and parameters.
Get metadata (get_metadata): Retrieve compact or verbose metadata about connected MCPs and their tools/resources/prompts, optionally writing output to a file.
Run SLOP scripts (run_slop): Execute scripts that chain multiple tool calls across MCPs, process data with built-in functions, and persist state, keeping large data out of the model's context.
Manage MCP connections (manage_mcps): Dynamically register, unregister, reconnect, list, check status/health of MCP servers at runtime with configurable transports and persistence scopes.
Handle authentication (auth_mcp): Perform OAuth flows for MCPs that require authentication, including login, logout, status checks.
Customize tools (customize_tools): Override tool descriptions, document parameters, define custom wrapper tools, and export/import customization packs across user/project/local scopes.
SLOP reference and help (slop_reference, slop_help): Browse and search built-in SLOP functions by name, category, or description.
Monitor events (agnt_watch): Build shell commands to stream daemon events (errors, interactions, process events) with filtering, for use with monitoring tools.
Serve as an MCP: Run the server itself via stdio or HTTP/SSE transports to be added to platforms like Claude Desktop.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@slop-mcp Search for any tool that can generate images using AI"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 contextQuick Start Guide - Get running in 5 minutes
Full Documentation - Complete guides and reference
KDL Configuration - Configuration reference
CLI Reference - Command-line options
Related MCP server: mcpcute
slop-mcp integrates with Claude Code's Monitor tool to stream events from any source — git hooks, build tools, CI pipelines, file watchers, or MCP servers.
# 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.slopUse with Claude Code:
Monitor({
command: "slop-mcp monitor",
description: "build events",
persistent: true
})See the Monitoring Guide for git hook templates, build wrappers, and SLOP polling scripts.
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:
Caveman the descriptions — replace verbose vendor prose with terse agent-friendly text. Original tool unchanged, agent sees only your version.
Document hardcoded values — for params your project never varies, the override description says "always pass X" instead of explaining the full enum.
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 for the full image-MCP walkthrough and the customize_tools reference.
As described in Anthropic's article Code Execution with MCP, current MCP implementations face two critical challenges:
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.
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.
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.
Rather than loading all tool definitions upfront, slop-mcp exposes just 8 meta-tools:
Tool | Purpose |
| Find tools across all connected MCPs by name or description |
| Execute a specific tool on a specific MCP |
| Get full metadata (tools, prompts, resources) for connected MCPs |
| Execute SLOP scripts with access to all MCPs |
| Register/unregister MCPs at runtime |
| Handle OAuth authentication for MCPs that require it |
| Search SLOP built-in functions by name or category |
| 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.
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.
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.
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
┌─────────────────────────────────────────────────────┐
│ 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 │ │ ... │
└──────┘ └──────┘ └──────┘ └──────┘slop-mcp uses KDL configuration with three-tier scoping:
Scope | File | Purpose |
User |
| Cross-project defaults |
Project |
| Git-tracked project config |
Local |
| Git-ignored secrets |
Example configuration:
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:
import "claude-desktop" // Import from Claude Desktop config
import "claude-code" // Import from Claude Code settingsnpx @standardbeagle/slop-mcpuvx slop-mcpOr install globally:
# npm
npm install -g @standardbeagle/slop-mcp
# pip
pip install slop-mcpgo install github.com/standardbeagle/slop-mcp/cmd/slop-mcp@latestslop-mcp serveslop-mcp serve --port 8080Add to your Claude Desktop config:
{
"mcpServers": {
"slop": {
"command": "slop-mcp",
"args": ["serve"]
}
}
}Aspect | Code Execution (Article) | slop-mcp |
Tool Discovery | Filesystem exploration |
|
Context Cost | Minimal (code interpreter) | Constant (8 meta-tools) |
Data Processing | In-sandbox code | SLOP scripts via |
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.
standardbeagle-tools - Claude Code plugin for slop-mcp integration
MIT
Build shell command streaming agnt daemon events via agnt monitor. Returns command for Claude Code Monitor tool or any shell runner. Filters: target (errors/interactions/process/all), proxy_id, process_id, severity, format.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Format: compact (default) or json | |
| target | No | Event filter: errors, interactions, process, or all (default: all) | |
| proxy_id | No | Limit to one agnt proxy | |
| severity | No | Minimum severity: info, warning, or error | |
| process_id | No | Limit to one process (required when target=process) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool builds a command rather than executing it, and that it returns a command string. However, it omits important behavioral details: whether it requires the agnt daemon to be running, whether the command blocks or streams indefinitely, potential side effects, and error conditions. The description does not contradict any annotations (there are none), but it is insufficient for a tool that constructs a potentially long-running streaming command.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and then listing filters. Every word earns its place; there is no fluff or repetition. It is concise and well-structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, no annotations, and 5 optional parameters, the description should provide a complete mental model. It explains the purpose, return value (a command), and filters. However, it lacks details about how the command is to be used (e.g., whether it must be executed immediately), any prerequisites like daemon availability, and the format of the returned command. This leaves gaps that an agent might need to infer, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already described (format, target, proxy_id, severity, process_id). The description simply lists these filters without adding new meaning beyond the schema. It does summarize the filter list, but the schema already provides equivalent information, so this is baseline level for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a shell command that streams events from the agnt daemon, specifying the verb 'Build' and the resource (shell command). It lists all filter parameters and distinguishes itself from siblings like execute_tool by noting it returns a command rather than executing it. This makes its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context (used for streaming agnt daemon events via `agnt monitor`) and mentions it returns a command for the Claude Code Monitor tool or any shell runner, implying when it might be used. However, it does not explicitly compare to alternatives or state when not to use it, such as if a user wants direct execution or to interact with a different daemon. The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OAuth for MCP servers. Actions: login (start flow), logout (drop token), status (check), list (all authenticated). Returns text.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | MCP name (required for login/logout/status) | |
| action | Yes | Action: login, logout, status, or list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'Returns text' and lists actions, omitting side effects (e.g., token storage, destructive nature of logout), prerequisites, or stateful behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences) and front-loaded with purpose. However, it may be too terse, missing critical details that could aid an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with multiple actions and no output schema or annotations, the description lacks completeness. It does not cover error handling, OAuth flow details, or output structure beyond 'text', leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats schema info (actions list, name requirement) without adding new semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's domain ('OAuth for MCP servers') and lists specific actions (login, logout, status, list) with brief explanations. It distinguishes from sibling tools which cover other areas like tool execution or metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage for authentication tasks but provides no explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Override tool descriptions, define custom tools. Actions: set_override, remove_override, list_overrides, define_custom, remove_custom, list_custom, export, import.
| Name | Required | Description | Default |
|---|---|---|---|
| mcp | No | MCP name (set_override, remove_override, list_overrides, export) | |
| body | No | SLOP script body (define_custom) | |
| data | No | Import pack as JSON string | |
| keys | No | Glob patterns selecting keys to export | |
| name | No | Custom tool name matching ^[a-z][a-z0-9_]{0,63}$ (define_custom, remove_custom) | |
| tool | No | Tool name in MCP (set_override, remove_override) | |
| scope | No | Scope: user, project, local. Default: user for set/define, all for remove. | |
| action | Yes | Action. Per-action args listed in slop-mcp docs. | |
| params | No | Per-param description overrides keyed by property name (set_override) | |
| overwrite | No | Overwrite existing keys on import (default false) | |
| stale_only | No | Only entries whose SourceHash differs from upstream (list_overrides, list_custom) | |
| description | No | Override description text (set_override, define_custom) | |
| inputSchema | No | JSON Schema draft-07 subset for tool arguments (define_custom) | |
| include_custom | No | Include custom tools in export (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only lists action names and parameter cues, without explaining side effects, permissions, or impact on tool definitions. This is insufficient for a tool that modifies system behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two sentences. The first sentence captures the core purpose, and the second lists actions. It is front-loaded and efficient, though some might desire more structure or detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, multiple actions, nested objects, no output schema), the description is too brief. It does not explain how to use each action, what the tool returns, or provide a workflow. The schema covers parameter details, but the description lacks actionable context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already described adequately in the schema. The description adds no extra semantic value beyond listing the action enum values, which are already in the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool is for overriding tool descriptions and defining custom tools, listing the specific actions. This distinguishes it from sibling tools like manage_mcps or execute_tool, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists available actions but does not explicitly explain when to use this tool versus alternatives. It implies usage through the name and actions, but no guidance on when not to use it or which other tools to consider.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute tool on MCP server. Passes parameters through. Returns underlying MCP response as-is.
| Name | Required | Description | Default |
|---|---|---|---|
| mcp_name | Yes | Target MCP name | |
| tool_name | Yes | Tool to execute | |
| parameters | No | Parameters passed to tool verbatim |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses passthrough behavior and that response is returned as-is, which is helpful. However, it does not mention side effects, authentication requirements, rate limits, or error handling, leaving gaps for a mutation-capable tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loaded with the core action. Every sentence contributes value with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a generic executor with moderate complexity (3 params, nested object) and no output schema, the description adequately states the basic behavior. However, it omits potential errors, prerequisites, and behavior when the target tool is missing, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter having a description. The description adds 'passes parameters through' which reinforces the meaning but does not provide additional context beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute tool on MCP server' with specific verb+resource. It adds that parameters are passed through and response is returned as-is, distinguishing it from sibling tools like manage_mcps or search_tools which have more specific purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for executing any tool on an MCP server, but does not provide explicit guidance on when to use it versus alternatives like search_tools or get_metadata. No when-not or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Metadata for connected MCPs. Compact by default (names+descriptions). verbose=true for full schemas. mcp_name+tool_name for single-tool schema.
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No | Include full input schemas (default: false; always included for mcp_name+tool_name queries) | |
| mcp_name | No | Limit to one MCP | |
| file_path | No | Write metadata to file | |
| tool_name | No | Limit to one tool (use with mcp_name) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently describes output defaults and filtering behavior, but it does not disclose whether the operation is read-only, whether it has side effects, or any auth/error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no filler. Key behavior is front-loaded and every sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a metadata retrieval tool, the description covers the main output modes and filter combinations sufficiently. It does not describe the file_path write format or error behavior, but those are secondary and the schema supplies the parameter intent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all four parameters, and the description adds useful semantics beyond the schema: it explains that default output is names+descriptions, that verbose=true yields full schemas, and that combining mcp_name and tool_name returns a single-tool schema. This helps an agent use the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (connected MCPs) and the function (returning metadata), and the tool name reinforces the retrieval action. It is distinguishable from siblings like manage_mcps and execute_tool, but the phrasing omits an explicit verb such as 'Retrieves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains output modes and parameter combinations (compact default, verbose=true, mcp_name+tool_name), but it does not explicitly state when to choose this tool over related siblings such as search_tools, manage_mcps, or execute_tool. Usage is implied rather than directly specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage MCP connections. Actions: register, unregister, reconnect, list, status, health_check, list_stale_overrides. Returns text.
| Name | Required | Description | Default |
|---|---|---|---|
| env | No | Environment variables | |
| url | No | Server URL (HTTP transports) | |
| args | No | Command arguments | |
| name | No | MCP name (required for register/unregister/reconnect) | |
| type | No | Transport: command (default), sse, or streamable | |
| scope | No | Persistence: memory (default, runtime only), user ($XDG_CONFIG_HOME/slop-mcp/config.kdl or ~/.config/slop-mcp/config.kdl), project (.slop-mcp.kdl) | |
| action | Yes | Action: register, unregister, reconnect, list, status, health_check, or list_stale_overrides | |
| command | No | Executable for command transport | |
| dynamic | No | Always re-fetch tool list, skip cache | |
| headers | No | HTTP headers (HTTP transports) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must bear full burden. It only states 'Returns text' and lists actions, failing to disclose side effects (e.g., state changes from register/unregister/reconnect), authorization needs, or any behavioral nuances per action. This is dangerously vague for a management tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with purpose and action list. It is efficient but could be slightly improved by grouping actions by type or adding minimal context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high complexity (10 parameters, multiple actions, no output schema), the description is extremely brief. It omits action-specific details, parameter dependencies, return format beyond 'text', and any operational constraints. This is far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, so baseline is 3. The description adds no additional parameter context beyond the schema. It does not specify which actions require which parameters, leaving the agent to infer from schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: managing MCP connections, with a list of specific actions. This distinguishes it from siblings like auth_mcp or execute_tool. However, it could be improved by briefly describing what each action does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor when to choose one action over another. For a multi-action tool, this omission significantly hinders correct selection and invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute SLOP script with access to all registered MCPs. Inline script or file path. Returns final expression value as text.
Call MCP tools as mcp_name.tool_name(param: value). Example patterns:
Chain results between tools: data = api.fetch(id: 42) summary = ai.summarize(text: data["content"]) emit(summary)
Loop and collect: results = [] for id in [1, 2, 3]: results = results + [api.get(id: id)] emit(items: results, count: len(results))
Transform with builtins: repos = github.search(query: "mcp") names = map(repos, |r| r["name"]) emit(join(names, "\n"))
Pipe for chaining transforms (left value becomes first arg): [1, 2, 3, 4, 5] | filter(|x| x > 2) | map(|x| x * 10) data | json_stringify()
Session memory persists across run_slop calls (thread-safe): store_set("key", value) prev = store_get("key")
Persistent memory survives restarts (disk-backed): mem_save("bank", "key", value, description: "what this stores") data = mem_load("bank", "key") entries = mem_list("bank") matches = mem_search("query")
Use recipe parameter: recipe: "list" to see available templates, recipe: "" to load one. Use slop_reference to browse built-in functions (map, filter, reduce, json_parse, regex_match, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
| recipe | No | Embedded recipe: 'list' to enumerate, or recipe name to load | |
| script | No | Inline SLOP script | |
| file_path | No | Path to .slop file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool executes scripts with access to all MCPs, returns the final expression value, and provides session (thread-safe) and persistent (disk-backed) memory features. It does not explicitly warn about potential side effects from calling external tools, but the examples make it clear the script can invoke any MCP tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, with sections for chaining, loops, transforms, pipes, memory, and recipes. Every sentence serves a purpose—examples are essential for a scripting language tool. While it could be slightly tightened, the structure and front-loading of the main purpose make it effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (arbitrary script execution with MCP access) and the absence of an output schema, the description is complete: it states the return format, covers memory persistence, recipe usage, and provides syntax examples. It addresses everything an agent needs to invoke it correctly, including edge cases like recipe listing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds substantial meaning beyond the schema. It explains the recipe parameter ('list' to enumerate, name to load), illustrates inline script usage with syntax, and clarifies file_path is a path to a .slop file. The detailed examples for script and recipe usage far exceed what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute SLOP script with access to all registered MCPs. Inline script or file path. Returns final expression value as text.' It distinguishes itself from siblings like execute_tool (single tool execution) and slop_help/slop_reference (reference/help) by focusing on multi-step scripting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool—for executing SLOP scripts, chaining MCP calls, loops, and transforms—and gives extensive examples. It also mentions using slop_reference for built-in functions, but does not explicitly state when NOT to use it (e.g., for single tool calls, execute_tool might be preferable). This is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fuzzy search tools across connected MCPs. Ranked results. Paginated (default: 20, max: 100). Use offset for next page. Response includes total and has_more.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default: 20, max: 100) | |
| query | No | Search query matched against tool names and descriptions | |
| offset | No | Results to skip for pagination (default: 0) | |
| mcp_name | No | Limit results to one MCP |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses pagination defaults (default: 20, max: 100), offset usage, and response fields (total and has_more). It also mentions ranked results, giving a clear behavioral picture for a read-only search operation. It doesn't cover every edge case but is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no waste. The purpose is front-loaded, followed by essential pagination and response details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers pagination and response metadata (total, has_more), which is helpful given no output schema. It doesn't specify the structure of individual result items, but for a search tool the agent can infer the general shape. The absence of an output schema is partially compensated by the description's mention of response fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters. The description adds minimal value beyond the schema, mainly reaffirming pagination details already present. It doesn't introduce format or syntax specifics, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: fuzzy searching tools across connected MCPs, with ranked results. It uses a specific verb ('search') and resource ('tools across connected MCPs'), and it distinguishes itself from sibling tools like manage_mcps or execute_tool by focusing on discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding tools and provides pagination guidance ('Use offset for next page'), but it does not explicitly contrast with alternatives or state when not to use it. The context is clear but no exclusions or sibling references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full details for SLOP function by name. Returns formatted text.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | SLOP function name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only indicates that the output is 'formatted text' but does not specify the format (e.g., markdown, plain text), whether the tool is read-only, error handling, or prerequisites. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with one sentence, but it sacrifices clarity by omitting important context. While front-loaded, it could be expanded slightly to improve completeness without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description should provide more context about what 'full details' includes (e.g., description, parameters, examples) and the output format. Currently, it does not give enough information for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter 'name' as 'SLOP function name'. The description adds 'by name', which is redundant. It does not clarify permissible values, how to find valid names, or any additional semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'Full details for SLOP function by name' and returns formatted text, which identifies the tool's purpose. However, it does not distinguish from the sibling tool 'slop_reference', which might also provide details, reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'slop_reference', 'search_tools', or 'run_slop'. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search SLOP built-in functions. Compact output (name+signature) by default. verbose=true for full details. list_categories=true for category counts.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default: 10) | |
| query | No | Matches name, signature, description | |
| verbose | No | Include description, example, returns (default: false, compact shows name+signature) | |
| category | No | Filter: math, string, list, map, random, type, json, regex, time, encoding, functional, crypto, slop | |
| list_categories | No | Return category counts instead of functions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It mentions output modes but fails to disclose side effects, rate limits, authorization needs, or that the operation is read-only. For a search tool, these are critical gaps without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that front-load the purpose and efficiently explain the key flags. Every word serves a purpose; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 5 parameters, the description could provide more context about default behavior, pagination, or result format for compact mode. The mention of 'name+signature' helps, but the agent might lack full understanding of the expected response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description repeats information already present in the schema (e.g., verbose and list_categories effects), adding no new meaning beyond what the schema provides. No additional value is delivered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search SLOP built-in functions.' It includes specific details about output modes (compact, verbose, list_categories) that differentiate it from sibling tools like search_tools and slop_help, ensuring an agent can identify its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives, nor does it state when not to use it. While it implies usage for looking up SLOP functions, it lacks explicit context or exclusions, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.15.0agnt_watchget_metadatarun_slopsearch_toolsv0.14.5agnt_watchget_metadatarun_slopsearch_toolsv0.14.4manage_mcps1 field changedInput schema / properties / scope / descriptionPrevious value: -"Persistence: memory (default, runtime only), user (~/.config/slop-mcp/config.kdl), project (.slop-mcp.kdl)"New value: +"Persistence: memory (default, runtime only), user ($XDG_CONFIG_HOME/slop-mcp/config.kdl or ~/.config/slop-mcp/config.kdl), project (.slop-mcp.kdl)"v0.0.0agnt_watchauth_mcpcustomize_toolsexecute_toolget_metadatamanage_mcpsrun_slopsearch_toolsslop_helpslop_referenceScored 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.
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
MCP-Native LLM Orchestration Agent
Protocol-native energy infrastructure orchestration for AI data centers. Provides 46 MCP tools across 8 grid protocols (IEC-61850, DNP3, Modbus, OCPP, OpenADR, IEEE 2030.5, IEC 60870-5-104, ICCP) with 5 core API primitives: connect, dispatch, settle, comply, and intel. Enables AI agents to programmatically interact with substations, grid interfaces, and energy assets for real-time workload-grid coordination.
