SuperAgenticMCP
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 | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| statusA | Return SuperAgenticMCP router health: version, process status, and how many MCP servers are currently racked. Use this as a connectivity probe before list_rack or route_task. Read-only local state. Does not call downstream MCP servers (not open-world). Pair with list_rack for the actual catalog. |
| list_rackA | List MCP servers currently mounted on the SuperAgentic rack (name, command or URL, notes). Use after rack_add to confirm membership. Empty list means no servers have been registered in this process. Read-only; use rack_add / rack_remove to mutate. Does not probe remote health. |
| rack_addA | Register an MCP server on the in-memory rack so later route_task calls can target it by name. Overwrites an existing entry with the same name (idempotent upsert). Does not start the child process and does not validate the command. Use list_rack to inspect and rack_remove to delete. Local write only. |
| rack_removeA | Remove one MCP server from the in-memory rack by name. Destructive. Missing names return an error object rather than raising. Does not stop a running child — only drops the catalog entry. Use list_rack first to confirm the name. |
| route_taskA | Produce a routing plan for a natural-language task against the current rack. In this release the planner is a deterministic stub: it lists candidate servers and does not execute downstream tools. Use after rack_add. Not a substitute for status. Read-only with respect to the rack; no network calls yet. |
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 5 tools
Each tool has a distinct role: status reports router health, list_rack shows catalog contents, rack_add and rack_remove mutate the rack, and route_task plans routing. There is no meaningful overlap or ambiguity between tools.
Most tools follow a clear verb_noun snake_case pattern such as list_rack, rack_add, and rack_remove. The lone status tool breaks the verb_noun pattern, but it is still a simple, readable name and does not cause confusion.
Five tools is well-scoped for a router/rack management server. Each tool covers a necessary operation without redundancy or unnecessary bloat.
The surface covers the core lifecycle: health check, catalog listing, add/upsert, remove, and routing plan generation. Minor gaps exist such as no single-server detail endpoint and route_task being a deterministic stub, but the main workflows are supported.