This server currently exposes only two read-only stub endpoints for inspecting the router.
status — returns router status: version, racked servers (stub), and health.
list_rack — lists currently racked MCP servers (stub).
No actual task planning, routing, tool calls, or memory operations are exposed yet; the schema reflects a minimal scaffold rather than the full agent-swarm control plane described in the README.
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., "@SuperAgenticMCP Plan this task, route each step to the right MCP server, and persist the results."
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.
The switchboard for your agent swarm.
SuperAgenticMCP is a production-oriented, MCP-native router and multi-agent control plane. It sits between your agents and the MCP servers they need — planning the task, routing each tool call to the right server, streaming every step, and filing results into memory.
Patch every agent into every tool.
Support Agentic OS Kernels ($99) · Agentic OS Cycle ($0.75) · Public Goods Support · USDC
Layout standard: Server OS — see docs/LAYOUT.md.
Surface | Entry |
Web control plane |
|
MCP Server |
|
CLI |
|
SDK |
|
Board (target) |
|
Skills |
|
AGENTS.md | Coding-agent contract |
Verify |
|
CI |
|
Related MCP server: Peta Core
Problem | Approach |
Agents need many MCP servers | One process racks servers and routes by capability |
Tool calls are opaque | Live patch board + JSONL log + run receipt |
Multi-agent coordination is ad-hoc | Built-in planner / worker / critic loop |
Memory evaporates between runs | Memory scope constellation of artifacts |
Config drifts from reality | Rack toggles generate |
Capability | Status |
MCP over stdio (+ streamable HTTP planned) | ✅ scaffold |
Capability-first routing + latency tie-break | 🚧 / demo in hero |
Planner → parallel workers → critic | 🚧 / demo in hero |
Hot-swap server rack | 🚧 / demo in hero |
Live patch board + phosphor log | ✅ hero |
Memory scope (3D constellation) | ✅ hero |
Call budgets + offline skip | 🚧 |
Dynamic | 🚧 |
Server OS layout + verify contract | ✅ |
Self-learning model routing (bandit) | 🚧 |
Agentic commerce (x402) | ✅ routes to x402-cloudflare-starter |
Commerce is not reimplemented here. Rack the x402 Worker; keep Stripe Payment Links for humans. Receipts are not Desk unlocks.
git clone https://github.com/ANAMIZED/SuperAgenticMCP
cd SuperAgenticMCP
python -m venv .venv && source .venv/bin/activate
pip install -e ".[dev]"
superagenticmcp # MCP server (stdio)
superagenticmcp-cli status
make test
bash scripts/verify.shZero-install hero:
{
"mcpServers": {
"superagenticmcp": {
"command": "superagenticmcp",
"args": []
}
}
}docker compose up --buildProtocol — Model Context Protocol; one session per racked server.
Agent loop — Planner decomposes; workers run in parallel where allowed; critic checks before ship.
Routing — Capability match first, latency as tie-break, fallback when a server drops.
Guardrails — Per-server allow-lists and per-run call budgets.
Telemetry — JSONL lines + board replay.
Footprint — Single process for the core path; no DB required.
src/superagenticmcp/ # MCP, CLI, SDK
skills/ # Packaged skills (Server OS style)
web/ # Control-plane path
scripts/verify.sh # Verify contract
tests/ # Smoke + contract tests
superagenticmcp.html # Hero demo
docs/LAYOUT.md # Permanent layout standard = Server OS
AGENTS.md # Agent contractOffer | Link |
Support Agentic OS Kernels — $99 | |
Agentic OS Cycle — $0.75 | |
Public Goods Support |
GitHub Sponsors: ANAMIZED
Non-custodial addresses controlled by ANAMIZED. Pure x402 micropayments preferred for agents — see x402-cloudflare-starter.
Network | Address | Explorer |
Base |
| |
Ethereum |
| |
Solana |
|
Send only USDC on the matching network. Wrong asset or chain can mean permanent loss.
server-os — layout standard · agents as processes
OpenGOS — grants + public-goods funding MCP
LRSI — local recursive self-improvement kernel
x402-cloudflare-starter — USDC micropayments (Base + Solana)
Apache-2.0
Built for the Model Context Protocol · Unit 001 · SA-MCP MK.4 · Server OS layout
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only a title with no readOnlyHint or destructiveHint, so the description carries full responsibility. It discloses read-only behavior, that it 'Does not probe remote health,' and that an empty list means no servers registered in this process. These are meaningful behavioral details beyond the 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?
Four tightly packed sentences: purpose and fields, when to use, empty-list meaning, read-only safety and non-probing behavior. Every sentence adds value and the key information is front-loaded in the first sentence.
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 zero-parameter read-only tool, the description covers purpose, usage timing, result interpretation, and behavioral caveats. An output schema exists to document return values, so nothing essential is missing. The sibling context and the boundary with rack_add/rack_remove are clearly articulated.
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 tool has zero parameters and the schema has 100% coverage (empty object), which meets the baseline of 4. The description adds no parameter details because none exist, but it does describe the output fields, which is a small bonus. No deduction needed for a parameterless tool.
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 a specific verb and resource: 'List MCP servers currently mounted on the SuperAgentic rack' and even enumerates the returned fields (name, command or URL, notes). It differentiates itself from mutating siblings by explicitly labeling the operation read-only and naming rack_add/rack_remove as the mutation tools.
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 explicit when-to-use guidance: 'Use after rack_add to confirm membership.' It also clarifies the empty-list interpretation, preventing false conclusions, and explicitly routes mutations to rack_add/rack_remove. This is strong usage direction with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Short rack key used by route_task and rack_remove. | |
| notes | No | Optional human note describing capabilities. | |
| command | Yes | stdio command or streamable HTTP URL for the child MCP server. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no safety annotations beyond the title, the description carries the full burden and does so excellently. It discloses that the operation is an idempotent upsert ('Overwrites an existing entry with the same name'), that it does not start the child process, does not validate the command, and is a local write only. This is far more than the structured annotations provide.
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 sentences with no filler. It front-loads the primary purpose, then adds side-effect warnings, then provides sibling routing. 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 tool is simple, the input schema covers all parameters, and an output schema exists. The description fully covers behavior, side effects, idempotency, validation limits, and sibling alternatives, leaving no significant gap for an agent to call it correctly.
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%, so the schema already documents all three parameters in detail. The description adds a small amount of meaning by explaining how 'name' connects to route_task and rack_remove and by clarifying that 'command' is not validated, but it does not substantially extend the parameter 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 the tool's action: 'Register an MCP server on the in-memory rack so later route_task calls can target it by name.' It names the specific resource (the rack) and the purpose, and it differentiates itself from siblings by explicitly mentioning route_task, list_rack, and rack_remove.
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 practical usage context: it says the tool is for registration, does not start or validate the child process, and explicitly points to list_rack for inspection and rack_remove for deletion. It could be slightly stronger by explicitly stating when not to use this tool, but the alternatives are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Rack key previously passed to rack_add. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations carry only a title, so the description bears the full disclosure burden and meets it: it flags 'Destructive', specifies that missing names return an error object instead of raising, and explains the narrow side effect of dropping only the catalog entry. This is exemplary transparency for a mutation 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?
Five short sentences, each carrying distinct information: action, destructiveness, error behavior, side-effect scope, and prerequisite. The main verb is front-loaded and no sentence is redundant.
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 single-parameter, in-memory destructive tool with an output schema present, the description covers the action, risks, error semantics, partial effects, and a confirmation step. Nothing essential to a correct call is missing.
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 documents the sole parameter fully ('Rack key previously passed to rack_add'), and the description's 'by name' adds little beyond reinforcing that the identifier is a string key. With 100% schema coverage, the baseline of 3 applies.
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 opens with a specific verb and resource: 'Remove one MCP server from the in-memory rack by name.' This is not a tautology of the title and clearly differentiates from siblings like rack_add and list_rack by naming the action and target.
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?
It gives an explicit precondition ('Use list_rack first to confirm the name') and clarifies a limitation ('Does not stop a running child'), which tells the agent when this tool is not sufficient. It stops short of naming a sibling alternative for stopping a child, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Natural-language goal to route across racked MCP servers. | |
| preferred_server | No | Optional rack name to prefer. Empty means first match / all. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide only a title, so the description carries the full burden. It discloses that the planner is a deterministic stub, lists candidates only, does not execute downstream tools, is read-only with respect to the rack, and makes no network calls. This is unusually 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 compact and front-loaded with the core purpose, followed by behavioral constraints and usage guidance. Every sentence adds value, and there is no redundant restating of the tool name or schema.
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 two-parameter tool with an output schema, the description covers purpose, behavior, limitations, and usage sequencing. The agent has everything needed to decide when to call it and what to expect.
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%, so the schema already documents both parameters. The description adds context about the overall task-routing purpose but does not add new parameter-specific meaning beyond 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 uses a specific verb-resource pair ('produce a routing plan for a natural-language task against the current rack') and immediately clarifies the current behavior (deterministic stub that lists candidate servers). This clearly distinguishes it from rack-management siblings like rack_add and rack_remove.
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 explicitly says 'Use after rack_add' and 'Not a substitute for status', giving both sequencing and an exclusion. It also tells the agent that the planner does not execute downstream tools, so the agent knows not to expect execution side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite minimal annotations, the description explicitly states 'Read-only local state' and 'Does not call downstream MCP servers (not open-world),' which are critical behavioral traits for an agent deciding whether this is safe to invoke. This goes beyond what the title and annotations alone convey.
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?
Three sentences deliver purpose, usage guidance, and behavioral constraints without wasted words. The primary outcome is front-loaded, and every remaining clause adds decision-relevant 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?
For a zero-parameter status probe with an output schema, this is complete: it states what is returned, when to use it, what it does not do, and how it relates to sibling tools. No additional context is needed for correct selection and invocation.
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 tool has zero parameters, so the baseline for this dimension is 4. The description adds no parameter-level semantics because there are no parameters to document.
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 uses a specific verb ('Return') and names the exact resource: SuperAgenticMCP router health. It enumerates concrete output contents (version, process status, racked server count) and explicitly contrasts itself with list_rack for the actual catalog, making sibling differentiation clear.
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 explicitly directs when to use the tool: 'Use this as a connectivity probe before list_rack or route_task.' It also tells the agent to pair with list_rack for the catalog, providing clear guidance on which sibling to use for a different purpose.
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.2.0rack_addrack_removeroute_taskv0.1.0list_rackstatusEach 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.
Agent-native collaboration network: orchestrate a team of long-running agents from any MCP client.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Hosted MCP runtime where the agent is the operator: sign up by tool call, publish your own tools.
Hosted MCP memory and agent control plane for durable conversations, jobs, and operations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ANAMIZED/SuperAgenticMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
