warden (smart-router) is a meta‑MCP server that acts as a single gateway to many downstream MCP servers and skills, exposing only five tools to keep the agent’s context small while providing full discovery and invocation capabilities.
Search (search): Find tools and skills by keyword or regex in names, descriptions, and arguments; results are limited and do not expose the full catalog.
Invoke (call_tool): Execute a downstream MCP tool by specifying its server, name, and optional arguments, typically taken from a search result.
Load Skills (use_skill): Retrieve the full instruction text of a skill (from its SKILL.md) for the agent to follow.
Route (route): Get the best tool or skill for a task, optionally with file context and routing mode; returns ranked candidates and a best choice without executing.
Admin (admin): Manage the registry and configuration dynamically without restarts. Sub‑actions include:
list – view all registered servers, skills, and migrations
register_mcp / register_skill – add new downstream servers or skills
unregister – remove servers or skills
migrate – import servers and skills from Claude Code configuration (dry run or apply)
restore – revert a migration
get_routing / set_routing – view or update routing rules (priority order, exclusions, per‑file rules, mode)
set_auto_start – mark a skill to always be active at session start
Allows routing search and tool calls to the GitHub MCP server, enabling access to GitHub capabilities through smart-router.
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., "@smart-router search for a tool to list my recent pull requests"
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.
warden is one MCP server. It gives an agent access to many other MCP servers and Skills. The agent sees only 5 tools:
search(query, limit=5) — This tool does a regex or keyword search. It looks
in the name, the description, and the arguments of each tool. It also looks in
the name and the description of each Skill. No other data goes to the agent.
call_tool(server, name, arguments) — This tool sends a call to the MCP
server that has the tool. Use a search result to find the server and the
tool.
use_skill(name) — This tool returns the full instructions for a Skill. Use a
search result to find the Skill.
admin(action, params) — This tool controls the registry. It can also move
MCP servers and Skills out of Claude Code. The changes are immediate, and you
do not restart the server. Refer to The admin tool.
route(task, context=None, mode=None) — This tool selects the best tool or
Skill for a task. It ranks the candidates and returns the best one. It does
not run the tool. Refer to Routing.
At start, warden connects one time to each MCP server in the
configuration and gets its tools with list_tools. It also reads each Skill
directory and finds the SKILL.md files. warden keeps this catalog on the
server. The model does not get these definitions. The model gets only search
results, and only when it asks.
The goal is to move your MCP servers and Skills behind warden. Then the Claude context has only the 5 tools. warden supplies the other data only when the agent asks for it.
Install.
pip install -r requirements.txt # or: pip install . (for the warden command)Test first (the safe method). The dry run shows each change. Then apply
the migration to a temporary Claude home. warden does not change your
real ~/.claude.
warden migrate --all # dry run: shows each change
warden migrate --all --apply --home /tmp/fake-claude # apply to a temporary home
warden restore --id <printed-id> --home /tmp/fake-claudeDo the real migration. Remove --home to change your real Claude
configuration. warden adds the items to the registry. warden also
disables the items in Claude.
warden migrate --all --apply # or select items: --plugins X --skills Y --mcp Z
warden list # look at the registryTo move only some items, add them one at a time. Use
warden add-mcp <name> --command <cmd> [--args ...] or
warden add-skill <path>.
Set warden as the only MCP server in Claude. Refer to the JSON in Setup. Then restart Claude Code. Claude Code reads the disabled items at start. warden does not need a restart, because its catalog updates immediately.
Tell the agent to use warden (one command). warden does not start
hidden skills automatically. Run warden init. It writes a short
capability block into your agent-instruction file. The block tells the agent
to call route or search first. The command asks for the scope and the
file, and it does not change anything until you confirm.
warden init # asks the scope and the file, then writesRefer to Limitation for the full text and the manual method.
Use warden. Give Claude a usual instruction. When Claude needs a
tool, it calls route or search. Then it calls call_tool or
use_skill. To add or move more items later, an agent calls the admin
tool, or you use the CLI. To reverse a migration, use
warden restore --id <id>.
Each section below gives more data: CLI,
The admin tool,
Migration from Claude Code.
Related MCP server: fastmcp-gateway
pip install -r requirements.txtwarden reads its catalog from a registry file. The registry file has the
same structure as config.example.json:
{
"mcp_servers": {
"github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": {} }
},
"skill_dirs": ["./skills"]
}You do not have to write the registry manually. The commands
warden add-mcp, add-skill, and migrate make the registry and change
it. An empty registry is also correct. Then warden starts with an empty
catalog and prints one line to stderr. An agent can then fill the registry with
the admin tool.
warden finds the registry in this sequence:
WARDEN_CONFIG — the full path to the config.json file.
WARDEN_HOME — a directory. The registry is <home>/config.json.
The default: ~/.config/warden/config.json (XDG).
All writes go to WARDEN_CONFIG, WARDEN_HOME, or the XDG default.
The commands add-mcp, add-skill, migrate, and the admin tool make these
writes. The writes do not go to the current directory. Therefore the registry
stays available in all sessions and from all directories. For reads, if none of
these are present, warden uses ./warden.config.json.
To start the server, use one of these commands:
python3 -m warden # or: warden (the installed console command)Each command is the same as warden serve.
Set warden as the only MCP server in your MCP client. Example clients are Claude Desktop, Claude Code, Copilot CLI, and Cursor. For example:
{
"mcpServers": {
"warden": {
"command": "python3",
"args": ["-m", "warden"],
"cwd": "/path/to/warden"
}
}
}The same registry operations are available to you as subcommands. The default
subcommand is serve.
Command | Function |
| Runs the MCP server. This is the default. |
| Writes the warden capability block into your agent-instruction file, so the agent calls |
| Adds an MCP server to the registry. |
| Adds a Skill directory to the registry. warden reads its |
| Prints the registry as JSON. It shows the MCP servers, the skill directories, and the migration ids. |
| Moves MCP servers and Skills out of Claude Code. This is a dry run. Add |
| Reverses a migration. It puts back the changes in Claude. Add |
| Prints the routing configuration as JSON. |
| Sets the default routing mode. |
| Adds names to |
| Adds names to |
| Adds a per-file routing rule. |
| Prints the Skills that load at every session start. |
| Marks Skills to load at every session start. Restart the client to apply. |
| Stops the Skills from loading at every session start. |
warden add-mcp github --command npx --args -y @modelcontextprotocol/server-github
warden add-skill ~/my-skills
warden listadmin toolThe admin(action, params) tool gives the registry operations to an agent
through MCP. The agent can set up warden or change it, and the agent does
not restart the server. After each change, warden makes the internal
catalog again. Therefore search shows the change immediately. The actions are:
list — returns {mcp_servers, skill_dirs, migrations}.
register_mcp — params: {name, command, args?, env?}.
register_skill — params: {path}.
unregister — params: {kind: "mcp"|"skill", name}.
migrate — params: {targets: {mcp, plugins, personal_skills}, apply?}. This
is a dry run and returns the plan. Set apply to true to make the changes.
Each target is an array of names or keys, or the text "all".
restore — params: {id}.
get_routing — returns the routing configuration.
set_routing — params: {mode?, priority_order?, exclude?, rules?}. It
changes the routing configuration. Refer to Routing.
set_auto_start — params: {name, enabled?}. It marks a Skill to load at
every session start, or it removes the mark. Refer to
Always-on Skills.
The route tool selects the best tool or Skill for a task. It ranks the
candidates and returns the best one. It does not run the tool. The agent then
calls call_tool or use_skill on the result.
route(task, context=None, mode=None):
task — a description of what you want to do.
context — optional and light. It is {"file_path"?, "extension"?, "project_markers"?}. It holds references only, not file content. If you omit
it, warden still ranks from the configuration.
mode — "auto" returns the single best pick. "ask" returns a ranked list.
The default comes from the configuration. If only one tool is a candidate,
warden returns it directly and does not rank.
The result is {"mode", "single_option", "chosen", "candidates"}. Each
candidate has a name, a score, and reasons.
Routing rules live in the configuration (the routing block). warden reads
them at each call, so a change takes effect immediately.
priority_order — a list of names. An earlier name gets a higher rank and
wins a tie.
exclude — a list of names. warden never routes to these.
rules — per-file rules. Each rule is
{"when": {"extension"?: [...], "path_glob"?: "..."}, "prefer"?: [...], "exclude"?: [...]}. A rule matches the passed context. If you omit the
context, warden skips the context rules and uses priority_order and
exclude only.
Set the rules with the CLI or the admin set_routing action:
warden routing set-mode ask
warden routing prefer ts-tools code-reviewer
warden routing exclude legacy-linter
warden routing add-rule --ext tsx --prefer ts-tools
warden routing showMost Skills stay hidden until search surfaces them. This keeps the context
small. Some Skills only work when they are always active, though. A "think
before you code" ruleset, for example, must sit in the context before the agent
writes anything; it cannot wait for a search. auto_start is the opt-in for
that case.
A Skill flagged auto_start has its full text folded into warden's MCP server
instructions. The MCP client reads those instructions one time, at the start of
each session, so the Skill is always active. warden still stays one MCP server,
and your other Skills stay on demand.
warden add-skill ~/skills/ponytail # register the skill dir first
warden auto-start add ponytail # mark it always-on (by skill name)
warden auto-start list
warden auto-start remove ponytailAn agent can do the same with the admin set_auto_start action.
Keep this set small. Each always-on Skill spends context in every session, which is the cost warden otherwise removes. Note these limits:
It needs a client restart. The MCP client reads the instructions only at
start. So a new or removed auto_start Skill takes effect at the next
restart. The on-demand catalog still updates immediately.
The client must inject server instructions. Claude Code does. Not every MCP client does.
warden caps the size. If the always-on text gets too long, warden truncates it and prints a warning. Flag fewer Skills.
Claude Code loads each MCP tool and Skill into the context at start. The
migrate command moves them behind warden. The command does these tasks:
MCP servers — warden copies the server into the registry.
warden removes the server from ~/.claude.json (the user scope or the
project scope).
Plugins — warden adds the Skills directory of the plugin to the
registry. warden disables the plugin in ~/.claude/settings.json. This
action disables all the functions of that plugin. Look at the dry run first.
Personal skills — warden moves the directory
~/.claude/skills/<name> into a warden directory. warden adds that
directory to the registry.
Before each change, warden makes a backup of the file. warden also
writes a manifest that permits a reverse. Therefore restore --id <id> (or
admin restore) puts back all the changes.
warden migrate --all # dry run: shows each change
warden migrate --all --apply # apply the changes and print the migration id
warden restore --id <id> # reverse the migrationSafe test. By default, migrate and restore change your real ~/.claude.
Add --home <dir> to use a different Claude home. Then you can do a full test of
a migration and its restore. Your real configuration does not change.
warden migrate --all --apply --home /tmp/fake-claude
warden restore --id <id> --home /tmp/fake-claudeRestart Claude Code. Claude Code reads
~/.claude.jsonand~/.claude/settings.jsonat start. Therefore the changes to the MCP servers and the plugins take effect only after a restart. The warden catalog updates immediately.
You get skills behind warden only through route or search. Claude Code
cannot start these skills automatically from their description. This is the cost
to keep them out of the context until you need them. To help, tell the model to
use warden first.
For a Skill that must be active in every session (for example, a "think before
you code" ruleset), use auto_start. That is the
opt-in override to this limitation, for the few Skills that need it.
The easy way. Run warden init. It writes the capability block below into
your agent-instruction file (CLAUDE.md, AGENTS.md, or GEMINI.md). It asks
for the scope (user, project, or local) and for the file, and it writes only
after you confirm. A second run replaces the block in place. warden init --remove strips it again.
warden init # interactive: asks the scope and the file
warden init --print # show the block without writing
warden init --remove # remove the blockThe manual way. Copy this text into your agent-instruction file:
## Capabilities via warden
warden keeps many tools and Skills out of your context. Before you decide
that a capability is not available, use warden first:
1. Call `route` with a short description of the task. Add the current file
path if you have one. `route` returns the best tool or Skill to use.
2. Or call `search` to find a capability by keyword.
3. Then call `call_tool` or `use_skill` on the result.python3 -m unittest discover -s tests -vtests.test_search and tests.test_config are self-contained and need no other
software. tests.test_integration runs the full server through stdio MCP. It
uses a test MCP server and a test skill, and it needs mcp. If mcp is not
installed, this test skips automatically.
The search is one function. It does regex scoring and keyword scoring
together, and it uses only the standard re module. Refer to
warden/search.py.
The call_tool tool opens a new connection to the MCP server for each call.
It does not keep a pool of connections. Refer to warden/downstream.py.
This design is simple and correct. It is sufficient, unless the start time of
the subprocess becomes a measured problem.
The configuration is plain JSON. It does not need a YAML dependency for two keys.
If warden is useful to you, add a star to the repository. A star helps other people find the project. It is optional. It is not a condition to use warden or to contribute.
Manage the warden registry. Actions: list, register_mcp, register_skill,
unregister, migrate, restore, get_routing, set_routing. params carries the
action's arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| params | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only names actions and notes that params carries arguments, but does not reveal that actions like unregister, migrate, and restore are likely mutating or potentially destructive, nor does it mention permissions or side effects.
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 concise and front-loaded with the purpose statement, followed by an efficient action list. It contains no padding, though for eight actions it could benefit from additional detail without becoming verbose.
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?
This is a multi-action admin tool with a minimal schema and no annotations, so the description must compensate. It lists actions and explains the params pattern but fails to specify per-action input requirements, effects, or prerequisites, leaving the agent without enough information to invoke the tool 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 0%, and the schema provides no enum for action and only a generic object for params. The description adds the valid action values and explains that params carries the action's arguments, which is helpful but insufficient; it does not document what parameters each action expects.
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 states "Manage the warden registry" and enumerates eight concrete actions, making the tool's purpose and scope clear. This clearly distinguishes it from siblings such as search, call_tool, use_skill, and route, which focus on other operations.
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 use for warden registry management through the action list, but does not explicitly state when to use this tool versus alternatives. It does not mention exclusions or address possible overlap with the sibling 'route' tool for routing-related actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invoke a downstream MCP tool found via search.
server and name come from a search result of type "tool".
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| server | Yes | ||
| arguments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only says 'Invoke a downstream MCP tool' without mentioning side effects, safety, permissions, error behavior, or whether the call is synchronous. The potential for executing arbitrary tools is a significant transparency gap.
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, both packed with relevant information. The first sentence states the purpose, the second adds essential parameter source context. 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?
The tool is a generic invoker with no output schema and no annotations. The description covers the core purpose and parameter source but does not describe return values, error handling, or the behavior of the invoked tool. For a tool that can execute arbitrary downstream MCP tools, more guidance is needed to be considered 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 0%, so the description must add meaning. It does clarify that server and name come from a search result of type 'tool', which helps. However, it omits any explanation of the 'arguments' parameter, even though the schema only shows it as an object/null. This partial compensation justifies a mid-range score.
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 ('Invoke') and resource ('a downstream MCP tool'), clearly distinguishing it from siblings like 'search' by explicitly saying the tool is found via search. It leaves no ambiguity about what action is performed.
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 second sentence gives clear context on when to use this tool: after a search, using server and name from a result of type 'tool'. This implies when it is appropriate, but it does not explicitly state when not to use it or mention alternatives like use_skill or route, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pick the best tool or skill for task, ranked by server-side routing config.
Returns the selection (chosen / candidates) and NEVER executes anything —
invoke the pick yourself via call_tool or use_skill. context is optional
light file metadata (file_path / extension, references only); mode
overrides the configured auto/ask default for this call.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| task | Yes | ||
| context | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool has no side effects ('NEVER executes anything'), describes the return shape ('selection (`chosen` / `candidates`)'), and clarifies the limits of `context` to 'light file metadata', preventing misuse. This is strong transparency for a routing-only 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 two sentences and every clause earns its place. The first sentence states the core purpose, and the second packs the critical non-execution caveat plus parameter clarifications without unnecessary 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 the tool has an output schema and no annotations, the description covers all key elements: purpose, non-execution behavior, return indication, parameter semantics, and how to proceed with siblings. It is sufficiently complete for an agent 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 0%, so the description must compensate. It does: `task` is the routing input, `context` is clarified as 'optional light file metadata' with `file_path`/`extension` references, and `mode` is explained as overriding the configured auto/ask default. This adds meaningful semantics beyond the bare 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 uses a specific verb ('Pick') and identifies the resource ('best tool or skill for `task`'), clearly distinguishing it from executing tools by stating it 'NEVER executes anything'. It also implies a comparison/ranking role via 'ranked by server-side routing config', which separates it from siblings like `call_tool` and `use_skill`.
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 when to use the tool (to select a tool/skill for a task) and provides clear alternatives: 'invoke the pick yourself via `call_tool` or `use_skill`'. It also documents optional parameters (`context`, `mode`) and their purpose, giving actionable guidance for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search available MCP tools and Skills by name, description, or regex.
Returns up to limit matching entries (each with a "type" of "tool" or
"skill"). Use call_tool on a "tool" match or use_skill on a "skill"
match to actually invoke it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions return behavior ('Returns up to limit matching entries each with a type'), and describes how to act on results, but it does not explicitly state that the operation is read-only or discuss error/pagination behavior. This is adequate but not rich.
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 long, front-loaded with the core purpose, and succinctly adds usage guidance. Every sentence serves a role with no redundant 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?
The tool is a straightforward search operation, output schema exists, and the description covers the query capabilities, limit behavior, and follow-up action (call_tool/use_skill). No significant gaps remain.
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 description adds meaning beyond the schema by explaining that 'query' can be a name, description, or regex, and that 'limit' controls the maximum number of returned entries. Since schema coverage is 0%, this semantic clarification is valuable.
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 function: 'Search available MCP tools and Skills by name, description, or regex.' It uses a specific verb ('Search') and resource ('MCP tools and Skills'), and distinguishes from siblings by explaining that results should be consumed via call_tool or use_skill.
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 defines when to use this tool (for discovery) and explicitly directs the agent to use call_tool or use_skill for invocation. It does not list exclusions or alternatives explicitly, but provides clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load the full instructions for a Skill found via search.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states that the tool loads full instructions, implying a read-only operation, but does not disclose any edge cases, errors, or prerequisites beyond referencing `search`. This meets the minimum threshold but lacks deeper behavioral context.
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 a single, clear sentence with no filler or redundant information. It front-loads the core action and resource, making it highly concise and structurally 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?
The tool is simple, but the description lacks explicit parameter clarification and does not explain the role of the loaded instructions (e.g., how they relate to `call_tool`). Given the sibling tools and output schema, more context about the returned instructions could enhance completeness, but the description is minimally adequate.
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 has zero description coverage for the single 'name' parameter. The description only indirectly implies that 'name' refers to a skill found via search, but it does not explicitly define the content or format of the parameter, nor state that it should be the exact name from search results.
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 action ('Load the full instructions') on a specific resource ('a Skill'), and references the sibling tool 'search' to distinguish its role from searching. It directly addresses what the tool does and how it fits with related 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 phrasing 'found via `search`' clearly implies the intended workflow: first use `search`, then `use_skill` to load details. It does not explicitly state when not to use this tool or mention alternatives, but the context is sufficient for an agent to infer appropriate usage.
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.1admincall_toolroutesearchuse_skillEach tool serves a distinct role: search for discovery, call_tool for execution, use_skill for loading skill instructions, route for recommendations without execution, and admin for registry management. There is no functional overlap; an agent can clearly differentiate when to use each.
All names are lowercase snake_case and readable, but they mix bare verbs (search, route) with verb_noun forms (call_tool, use_skill) and a noun (admin). This is a minor deviation from a fully consistent pattern, though the intent remains clear.
With only 5 tools, the server is tightly scoped to its routing/discovery purpose. Each tool earns its place, covering search, invocation, skill handling, recommendation, and administration without unnecessary bloat.
The surface fully covers the smart-router domain: agents can discover tools/skills, invoke them, load skill instructions, get routing recommendations, and manage the registry. No obvious dead ends or missing lifecycle operations for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Search, vet & assemble MCP servers from your agent: verified tools, risk labels, and trust scores.
Hosted MCP server for live public-data APIs and Skills for AI agents.
The vetted, cross-LLM marketplace of doer agents — itself an MCP server.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/chris-asmussen/warden'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
