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 "Install 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
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.
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.
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. Dates show when Glama detected each change.
v0.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_referenceEach tool has a distinct focus: authentication, customization, execution, management, and two reference tools with clear differentiation between full details and searchable output. No overlapping purposes.
All names use snake_case, but the pattern is mixed: some start with a verb (auth_mcp, customize_tools, execute_tool, manage_mcps) while two start with 'slop' (slop_help, slop_reference), deviating from the verb_noun convention.
With 6 tools, the server covers authentication, customization, execution, management, and reference—a well-scoped set that is neither too sparse nor too heavy.
The tool surface covers core operations: auth (login/logout/status), customization (overrides and custom tools), execution, connection management, and detailed help/reference. No obvious gaps for its stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/standardbeagle/slop-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
