slop-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| agnt_watchA | Build shell command streaming agnt daemon events via |
| auth_mcpB | OAuth for MCP servers. Actions: login (start flow), logout (drop token), status (check), list (all authenticated). Returns text. |
| customize_toolsB | Override tool descriptions, define custom tools. Actions: set_override, remove_override, list_overrides, define_custom, remove_custom, list_custom, export, import. |
| execute_toolA | Execute tool on MCP server. Passes parameters through. Returns underlying MCP response as-is. |
| get_metadataA | Metadata for connected MCPs. Compact by default (names+descriptions). verbose=true for full schemas. mcp_name+tool_name for single-tool schema. |
| manage_mcpsC | Manage MCP connections. Actions: register, unregister, reconnect, list, status, health_check, list_stale_overrides. Returns text. |
| run_slopA | 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.). |
| search_toolsA | Fuzzy search tools across connected MCPs. Ranked results. Paginated (default: 20, max: 100). Use offset for next page. Response includes total and has_more. |
| slop_helpC | Full details for SLOP function by name. Returns formatted text. |
| slop_referenceB | Search SLOP built-in functions. Compact output (name+signature) by default. verbose=true for full details. list_categories=true for category counts. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.