Provides tools for managing Docker containers, images, and Docker-related operations.
Provides tools for managing GitHub repositories, issues, pull requests, and other GitHub resources.
Provides tools for interacting with Slack, including sending messages, managing channels, and more.
Provides tools for interacting with Stripe, including payment processing, customer management, and subscription handling.
Provides tools for managing infrastructure with Terraform, including state management, plan execution, and resource operations.
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., "@DynamicMCPProxy handshake: Python, FastAPI, Postgres for building a REST API"
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.
A smart MCP proxy server that lazily loads relevant MCP tool servers based on your project context, keeping AI tool counts within recommended limits (≤ 50 tools for Google Antigravity). Designed specifically for high-autonomy environments where agents need to evolve their own toolsets.
Part of the Anti-Gravity Agents Prompt Protocol ecosystem.
This project is a working, client-agnostic solution to anthropics/claude-code#7336 — Feature Request: Lazy Loading for MCP Servers and Tools. See Related Work below.
IDE connects → proxy exposes proxy_* tools + MCP Resources + Prompts
AI calls proxy_handshake({ tech_stack, task_description })
→ Matcher scores catalogue entries
→ Top-5 servers activated (lazily mounted as stdio subprocesses or SSE)
→ tools/list now includes those servers' tools
→ Budget cap (50 tools) enforced via LRU evictionRelated MCP server: MCP Coordinator
Catalogue servers run via npx (Node.js) and uvx (uv). These must be on the PATH your IDE uses when spawning the proxy. Add them explicitly in the MCP config env block (see below). Find your paths with type npx and type uvx.
Install with the hardened installer (clone-or-install-in-place):
curl -fsSL https://raw.githubusercontent.com/SPhillips1337/DynamicMCPProxy/main/install.sh -o install.sh
chmod +x install.sh
./install.sh --dir "$HOME/DynamicMCPProxy"If you already cloned the repository, run the installer from the project root:
./install.shThe installer validates that an existing target directory is this repository before updating it, checks for required tools (git and uv), runs uv sync, and creates proxy_config.json from proxy_config.json.example when needed. For inspect-first installs, download and review the script before executing it; avoid piping remote scripts directly into a shell unless you trust the source.
Manual install remains:
uv syncCopy the example config:
cp proxy_config.json.example proxy_config.jsonSet up your environment and private catalogue:
cp .env.example .env # fill in your API keys
# user.catalogue.json is auto-created or copy from your IDE's mcp_config.json{
"mcpServers": {
"dynamic-proxy": {
"command": "uv",
"args": [
"run",
"--quiet",
"--project",
"/path/to/dynamic-mcp-proxy-server",
"python", "-m", "src.proxy_server"
],
"env": {
"PATH": "/home/user/.nvm/versions/node/v20.18.1/bin:/home/user/.local/bin:/usr/local/bin:/usr/bin:/bin"
}
}
}
}Adjust PATH to match your system (type npx and type uvx show the right directories).
Tool | Description |
| Context handshake — activates relevant servers |
| Currently mounted servers + tool counts |
| Browse catalogue |
| Mount a server (deferred by default) |
| Generate & mount server from OpenAPI/GraphQL (lean=True uses LAP for smaller specs) |
| Free up tool budget |
| Add an ad-hoc server (SSE/HTTP only) |
| List exact names of all mounted tools |
| Diagnostic: Full dump of current tool registry |
| Live memory/CPU/uptime metrics |
| Server usage counts for self-evolving ranking |
| Reset usage stats (for testing/re-baselining) |
URI | Description |
| Static metadata (version, capabilities) |
| Live health (uptime, memory, active tools) |
| Full server inventory (active + available) |
MCP Method | What the AI Sees |
| Minimal |
| Live health, proxy info, server inventory |
|
|
catalogue.json — 49 public MCP servers (GitHub, Docker, Postgres, Slack, Stripe, etc.).
user.catalogue.json — your private overlay (gitignored). Add personal servers here — local paths, private APIs, custom tools. Entries with the same name override the public catalogue.
[
{
"name": "my-server",
"description": "My private MCP server",
"command": "python /path/to/server.py",
"tags": ["custom"],
"tech_stack": ["any"],
"runtime": "stdio",
"env_vars": ["MY_API_KEY"],
"pick": ["id", "status"],
"token_budget": 500
}
]Optimize AI context usage by shaping server responses before they reach the LLM. Applied to any server (stdio, SSE, REST):
pick: Array of dot-notation paths to keep (all others dropped).
omit: Array of paths to remove.
template: Python-style format string (e.g., "{id}: {content}") to flatten complex JSON into readable text.
token_budget: Hard character cap (approx tokens * 4) to prevent context flooding.
The proxy supports runtime: "rest", allowing it to act as a bridge for any OpenAPI or GraphQL API.
Auto-Generation: Use proxy_activate_from_spec(name, url) to generate a server config in ./configs/ and mount it instantly.
Manual Config: Add an entry with "runtime": "rest" and "config_path": "configs/mysvc.json". The proxy uses the 40mcp engine to map MCP tool calls to REST/GraphQL requests.
.env (gitignored) is loaded automatically at startup. Copy .env.example to get started:
cp .env.example .envKeys follow the env_vars field in each catalogue entry. Values in real environment variables always take precedence over the .env file.
proxy_config.json (gitignored, auto-generated with safe defaults):
{
"tool_budget": 50,
"auth_enabled": false,
"guardrails_enabled": true,
"rate_limit_rpm": 120,
"catalogue_path": "catalogue.json",
"audit_log_path": "audit.log",
"receipts_enabled": true,
"otel_enabled": false,
"otel_service_name": "dynamic-mcp-proxy",
"otel_exporter_otlp_endpoint": null,
"otel_capture_content": false
}Key settings:
tool_budget — max tools exposed at once (default 50, matches Antigravity limit)
auth_enabled — JWT RS256 + HMAC API key auth for production use
guardrails_enabled — prompt-injection scanning + result size caps
receipts_enabled — write JSONL receipts to audit_log_path with run_id, span_id, caller, status, latency, server/tool names, and privacy-safe argument summaries
otel_enabled — optionally mirror receipt events into OpenTelemetry when opentelemetry-* packages are installed; JSONL receipts continue to work without those optional packages
otel_capture_content — defaults to false; do not capture raw prompts, customer content, API keys, or tool payloads in traces by default
DynamicMCPProxy is the right place to collect agent receipts because every server activation and child MCP tool call passes through it. Receipts are enabled by default as local JSONL in audit.log and are designed for security-first debugging:
Every record includes a run_id and span_id; related operations can pass a parent span where available.
HMAC/JWT callers are identified by auth type, not by secret value. For example, sidecar HMAC calls record service:hmac.
Tool arguments are summarized as keys, types, lengths, and SHA-256 fingerprints. Raw strings, nested payloads, passwords, tokens, cookies, and API keys are not logged.
OpenTelemetry export is optional and dependency-optional. If enabled without the OTel packages installed, the proxy logs one warning to stderr and continues with JSONL receipts.
Example JSONL record shape:
{
"ts": "2026-07-04T12:00:00+00:00",
"event_type": "mcp.tool.call",
"run_id": "run_...",
"span_id": "...",
"tool": "github_search",
"caller": "service:hmac",
"outcome": "ok",
"latency_ms": 42.1,
"server": "github",
"argument_keys": ["query"],
"redacted_args": {
"query": {"type": "str", "length": 12, "sha256": "..."}
}
}When auth_enabled = true:
JWT (RS256) — set jwt_public_key_path to your RSA public key PEM
HMAC API key — set hmac_api_key (passed via X-API-Key header)
Guardrails — 8 prompt-injection pattern checks on all tool descriptions
Audit log / receipts — every tool call logged to audit.log (JSON lines) with privacy-safe argument fingerprints, not raw secrets or payloads
Rate limiting — configurable RPM per caller
Drop any executable MCP server script into ./plugins/. The proxy detects it via watchdog and registers it live — no restart needed.
The real power of this proxy lies in Runtime Mutation. Unlike static MCP configurations, this proxy allows an agent to "evolve" its toolbox as the task progresses:
Just-in-Time Activation: A2A (Agent-to-Agent) workflows that run for hours can activate sequential-thinking only when hitting a complex logic gate, then swap it for docker or terraform during the execution phase.
Autonomous Bootstrap: An agent can research a new tool, configure its environment via proxy_add_custom_proxy, and begin using it immediately without human intervention.
Self-Correction: If a tool is missing, an agent can literally write a new MCP server to ./plugins/ and the proxy will hot-plug it instantly.
Token Sustainability: By keeping the active toolset lean (via LRU eviction), long-running agents avoid context-window saturation and maintain peak focus on the task.
uv run python scripts/sync_catalogue.pyuv run pytest tests/ -vDisabled by default. Enable with ENABLE_HTTP_SIDECAR=1:
curl -X POST http://localhost:8765/handshake \
-H "Content-Type: application/json" \
-d '{"tech_stack": ["python", "fastapi"], "task_description": "Building a REST API"}'This project uses the Anti-Gravity LTM protocol. The repo ships canonical memory in docs/memories/. Per-developer context lives in .antigravity/memories/ (gitignored):
patterns_and_lessons.md — solved problems, failure post-mortems
codebase_insights/ — module-level hidden knowledge
architectural_decisions/ — design tradeoffs and rationale
Bootstrap your local LTM by following BOOTSTRAP.md from the protocol repo. See AGENTS.md for the full agent protocol.
README.md — user overview and getting started
CONTEXT.md — concise operating manual (stack, rules, decisions, guidance)
AGENTS.md — agent behavior, workflow rules, and LTM protocol (HERMES equivalent)
docs/memories/ — living memory: patterns, insights, architectural decisions
research/ — external references, comparisons, and notes (not source of truth)
anthropics/claude-code#7336 documented a real problem: loading all MCP servers at session startup can consume 54 % of the available context window (~108k of 200k tokens) before a single message is sent. Several approaches have been proposed or built:
Project | Approach | Limitation |
Offline registry generator — produces a lightweight token index from your MCP config | No runtime injection; explicitly lists "Automatic lazy loading at runtime" as needing Claude Code support | |
Replaces all tools with 3–4 generic | Hard-coded, requires fork-and-edit per stack; the AI loses full tool type-safety and discovery | |
This project | Smart proxy that activates only the servers relevant to the current project context via | Works with any MCP client today — no IDE changes required |
Client-agnostic — the proxy handles lazy loading transparently for any MCP client (Claude Code, Windsurf, Antigravity, opencode, Claude Desktop…), not just one IDE.
proxy_handshake() already delivers the "After" UX from the issue — the feature request's ideal example shows > Auto-loading: context7, magic [+3.5k tokens] after detecting keywords in user input. That is exactly what proxy_handshake({ tech_stack, task_description }) does today.
No fork required — add servers to catalogue.json or user.catalogue.json; the matcher and budget enforcement are automatic.
Generate an MCP server from an OpenAPI/GraphQL spec and activate it.
Args: name: A unique name for this generated server spec_url: URL to the OpenAPI spec (JSON/YAML) or GraphQL endpoint spec_type: 'openapi' or 'graphql' eager: If True, mount the server immediately lean: If True, attempt to use LAP (https://lap.sh) to produce a dramatically leaner input spec before 40mcp generation (F-12 research slice). Falls back gracefully if LAP CLI not available.
| Name | Required | Description | Default |
|---|---|---|---|
| lean | No | ||
| name | Yes | ||
| eager | No | ||
| spec_url | Yes | ||
| spec_type | No | openapi |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains parameter-level behavior (eager mounts immediately, lean uses LAP with graceful fallback) but does not disclose broader behavioral traits such as permissions required, destructiveness (e.g., whether it overwrites existing servers), or what happens after activation. With no annotations, more transparency is expected.
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 at roughly 140 words with a lead sentence and a well-structured bullet list for arguments. Every sentence contributes value with no redundancy or filler.
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 5 parameters, no annotations, and an output schema, the description covers input semantics well but lacks context on error handling, network requirements, and what the output represents. The output schema may compensate, but the description itself is only moderately 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 and does fully explain all 5 parameters in a clear 'Args' section. It adds meaning beyond the schema by detailing the purpose of each parameter (e.g., 'spec_type' values, 'lean' LAP behavior, 'eager' immediate mounting).
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 action: 'Generate an MCP server from an OpenAPI/GraphQL spec and activate it.' It uses a specific verb and resource and distinguishes from siblings like proxy_activate_server, which activates an existing server rather than generating one from a spec.
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?
While the description implies the tool is used when you have a spec to generate a server, it does not explicitly state when to use this versus alternatives like proxy_activate_server. No explicit context for when-not-to-use or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Activate (mount) a server from the catalogue by name.
By default the server is registered as a deferred stub ({name}_load tool)
and only fully spawned when first used. Pass eager=True to mount immediately.
Args: name: Server name as shown in proxy.list_available_servers() eager: If True, spawn the subprocess immediately instead of deferring.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| eager | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the defer mechanism, the creation of a `_load` tool, and the eager option. Missing details on idempotency or error behavior if server already active, but the core behavioral traits are well communicated.
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: one sentence for purpose, then a bullet-like explanation of behavior and parameters. No wasted words; front-loaded with the core action.
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 sibling tools and an output schema exists, the description covers activation behavior and parameter details sufficiently. The lack of output description is acceptable because the output schema provides that information.
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 provides essential parameter meaning. It explains 'name' as the server name from proxy.list_available_servers() and 'eager' as immediate spawn vs deferral, adding value beyond the schema's type/default.
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 specifies the action 'Activate (mount) a server from the catalogue by name', distinguishing it from sibling tools like proxy_list_available_servers (listing) and proxy_deactivate_server (deactivation). The verb and resource are explicit.
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 explains default behavior (deferred stub) and the alternative (eager=True), plus references proxy.list_available_servers() for valid names. However, it does not explicitly state when not to use this tool (e.g., if server already active), though the purpose itself differentiates from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a custom (non-catalogue) MCP server and optionally activate it. Only SSE and HTTP runtimes are accepted; stdio is restricted to prevent arbitrary command execution.
Args: name: A unique identifier for this server url: SSE URL (e.g. http://localhost:8100/sse) or HTTP URL tags: Tag list for future discovery matching runtime: "sse" or "http" (stdio is not permitted for custom proxies) activate_now: If True, mount the server immediately
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| name | Yes | ||
| tags | No | ||
| runtime | No | sse | |
| activate_now | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains security restriction on stdio, optional activation, and parameter defaults. Could elaborate on duplicate name handling, but covers key behavioral traits.
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?
Concise one-line summary followed by structured Args list. Every sentence is informative with no redundancy.
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 5 parameters and presence of output schema, description covers core functionality and constraints. Could mention error cases (e.g., duplicate name) or behavior when activate_now is false, but overall sufficient.
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 0%, so description carries full burden. The Args block explains each parameter's purpose, allowed values (e.g., runtime only sse/http), and defaults, adding significant value.
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 registers a custom MCP server, distinguishing from sibling tools that handle activation or catalogue-based servers.
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?
Provides guidance on accepted runtimes (SSE/HTTP) and explicitly restricts stdio for security. Does not mention when to use alternatives like proxy_activate_from_spec, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deactivate (unmount) a currently loaded or pending server to free up tool budget.
Args: name: Server name as shown in proxy.list_active_servers()
| Name | Required | Description | Default |
|---|---|---|---|
| name | 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 full burden. It discloses the deactivation effect and budget freeing but lacks details on reversibility, permissions, or side effects. 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 short and front-loaded with the purpose, followed by a clear parameter description. No unnecessary words; but the 'Args:' style is slightly redundant given the 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?
Given the tool's simplicity, one parameter, and existing output schema, the description provides sufficient context for an agent to understand when and how to use it. It covers the action and parameter source adequately.
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 compensates for zero schema description coverage by explicitly telling the user to get the server name from proxy.list_active_servers(), adding meaningful context beyond the schema's type definition.
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 deactivates/unmounts a server to free up tool budget, with specific verb and resource that distinguishes it from sibling tools like proxy_activate_server.
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 advises that the server name should be obtained from proxy.list_active_servers(), providing a clear workflow hint. However, it does not specify when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return live process metrics for the proxy itself. Mirrors the mcp://proxy/health resource as a callable tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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 full burden. It only states it returns 'live process metrics' and mirrors a resource, but does not disclose destructive potential, authentication needs, rate limits, or side effects. The description is insufficient for an agent to understand behavioral implications.
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, front-loaded with the main action, and contains no extraneous information. Every word 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?
Given zero parameters and an output schema (which covers return values), the description is mostly complete. It clarifies that it mirrors a resource, which provides context. However, it could be slightly more specific about what 'live process metrics' includes, but overall adequate for a simple tool.
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 coverage is 100% (empty schema). Per the guidelines, 0 parameters baseline is 4. The description adds no parameter info, but none is needed. It does not provide additional meaning beyond the schema, but meets the baseline.
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 returns live process metrics for the proxy itself. It distinguishes from sibling tools like proxy_get_usage by focusing on process metrics, and mentions it mirrors a resource, providing a specific verb-resource pair.
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 explicit guidance on when to use this tool vs alternatives. While it mentions mirroring a resource, it does not specify contexts where this tool is preferred over siblings like proxy_get_usage or proxy_list_tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return current server usage counts for self-evolving ranking (F-13).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only states the tool returns usage counts, with no mention of side effects, access requirements, or limitations. Minimal behavioral disclosure for a potentially sensitive 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?
Single sentence that is front-loaded with the core action. However, the parenthetical 'F-13' is extraneous and reduces clarity slightly.
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?
With an output schema present and a simple retrieval tool, the description provides adequate context. However, it does not explain what the output contains beyond 'usage counts', relying on the schema.
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?
Tool has zero parameters, so the baseline is 4. The description does not need to add parameter information.
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?
Clearly states the tool returns usage counts for server ranking. The verb 'Return' and resource 'current server usage counts' are specific. The cryptic reference to 'self-evolving ranking (F-13)' slightly obscures purpose but does not mislead.
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 on when to use this tool versus siblings like proxy_get_metrics or proxy_list_active_servers. The description implies it is for retrieval, but lacks explicit context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send your project context to the proxy. It will activate the most relevant MCP servers from the catalogue and return a summary of available tools.
Args: tech_stack: Languages and frameworks in use, e.g. ["python", "fastapi", "postgres"] task_description: Free-text description of what you are working on open_files: File paths currently open in the IDE (optional, helps infer stack) requirements: Package names from requirements.txt / package.json (optional)
| Name | Required | Description | Default |
|---|---|---|---|
| open_files | No | ||
| tech_stack | Yes | ||
| requirements | No | ||
| task_description | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full disclosure burden. It states it activates servers but doesn't reveal side effects (e.g., whether it deactivates existing servers, requires network, is destructive, or idempotent). This is insufficient for a potentially state-changing 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 concise with a brief introductory sentence and a parameter list. However, it could be more structured with clearer separation of purpose from args, and front-loading the key behavior.
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 complexity of activating multiple servers and the presence of many sibling tools, the description lacks prerequisites, error handling, and limitations (e.g., network dependency, no-match behavior). The output schema exists but isn't leveraged. More context is needed for safe use.
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?
Despite 0% schema description coverage, the tool description explains each parameter's purpose and optionality (e.g., tech_stack for languages, task_description for free-text). This adds significant meaning beyond the schema's type-only definitions.
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: sending project context to activate relevant MCP servers and returning a summary. This is distinct from siblings like proxy_activate_server (manual activation) and proxy_list_* (listing only).
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 explicit guidance on when to use vs alternatives. While the purpose implies it's for initial context-based activation, it doesn't mention scenarios where manual activation is preferred or if it should be avoided when specific servers are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diagnostic tool: Expose proxy state and server counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description labels the tool as 'Diagnostic tool', implying a read-only operation, but provides no further behavioral details such as authentication requirements, side effects, rate limits, or data freshness. With no annotations, the description should carry the full burden of disclosure.
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, concise sentence with no wasted words. It is front-loaded and easily digestible.
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 zero parameters and an existing output schema, the description covers the tool's purpose adequately. However, for a diagnostic tool, additional context about usage frequency or impact would improve completeness.
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?
No parameters exist, so the description need not add parameter semantics beyond the schema. Baseline 4 applies, and the description is consistent with the empty 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's a diagnostic tool that exposes proxy state and server counts. It is specific (verb+resource) but does not differentiate from siblings like 'proxy_list_active_servers' or 'proxy_get_metrics', which have overlapping 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?
No guidance on when to use this tool versus other proxy tools. The description does not provide context on typical use cases, prerequisites, or scenarios where alternatives would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all currently mounted MCP servers and their estimated tool counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior. It implies a read operation ('list') and mentions output (tool counts), but lacks details on whether data is cached, response size, or authentication requirements. Adequate but minimal.
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?
A single, efficient sentence with no extraneous words. Perfectly concise while conveying core purpose.
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 zero parameters and an output schema exists, the description adequately covers the operation. It could explicitly contrast with siblings, but overall it provides enough context for a simple listing tool.
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?
No parameters exist, so baseline 4 applies. The description does not need to add parameter info; it correctly states the tool's action. No additional meaning required beyond 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 lists currently mounted MCP servers and provides estimated tool counts. It uses a specific verb ('list') and resource ('mounted MCP servers'), distinguishing it from siblings like proxy_list_available_servers.
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 provided on when to use this tool versus alternatives (e.g., proxy_list_available_servers for unmounted servers, proxy_list_tools for specific server tools). The description is insufficient for an agent to decide between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List MCP servers in the catalogue that are not yet mounted.
Args: filter_tag: Optional tag filter, or free-text query (uses search_servers for discovery).
| Name | Required | Description | Default |
|---|---|---|---|
| filter_tag | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the filter_tag parameter can act as a free-text query and uses search_servers for discovery, adding behavioral context beyond the schema. No annotation contradictions are present.
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 consists of two concise sentences, front-loading the purpose and then explaining the parameter. No extraneous or 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 description adequately covers the purpose and parameter semantics. Given the simple tool and presence of an output schema, it is sufficiently complete, though it could mention the output format explicitly.
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?
With 0% schema description coverage, the description fully explains the parameter's dual role as a tag filter or free-text query, significantly adding meaning beyond the type and default value.
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 verb 'List' and the resource 'MCP servers in the catalogue that are not yet mounted', effectively distinguishing it from the sibling tool 'proxy_list_active_servers' which lists already mounted servers.
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 indicates when to use this tool (to list unmounted servers) and implicitly contrasts with the sibling for active servers. While not explicit about alternatives, the context is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered tools by inspecting the FastMCP instance. If server_name is provided, filters for tools from that child server.
| Name | Required | Description | Default |
|---|---|---|---|
| server_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are missing, so description carries full burden. It discloses the basic behavior (listing tools, optional filter) but does not mention any side effects, performance implications, or error handling. Adequately minimal for a simple read operation.
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?
Two sentences, front-loaded with the core action. Every word adds value; 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 the tool's simplicity (one optional parameter, output schema exists), the description is nearly complete. It covers the main functionality but could briefly mention the return format, though the output schema likely handles that.
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?
With 0% schema description coverage, the description compensates by explaining the server_name parameter's purpose—filtering by child server. This adds clear meaning beyond the schema's type definition.
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 lists all registered tools and optionally filters by server_name, which distinguishes it from sibling tools that list servers or search 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?
No explicit guidance on when to use this tool versus siblings like proxy_search_tools or proxy_list_active_servers. The use case is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reset usage stats (all or for one server). Useful for testing or re-baselining.
| Name | Required | Description | Default |
|---|---|---|---|
| server | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states a destructive action (reset) but does not disclose side effects, auth requirements, or reversibility.
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?
Two sentences, first states action and scope, second adds usage context. No redundancy or wasted words.
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?
Low complexity with one optional parameter and output schema. Description covers core purpose and parameter but lacks details on what 'reset' entails (e.g., resets to zero) and prerequisites.
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?
Description explains the single parameter 'server' meaning: if provided, resets for that server; if null, resets all. Adds value beyond schema name with 0% schema coverage.
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?
Description clearly states the action 'reset usage stats' and scope 'all or for one server', distinguishing it from sibling tools like proxy_get_usage which reads stats.
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?
Description mentions 'useful for testing or re-baselining' implying appropriate contexts, but lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the catalogue for relevant servers/tools using free-text query. Enables on-demand discovery (lazy loading pattern) so the AI can find specific capabilities without the full catalogue bloating context.
Returns ranked list of matching servers (name, desc, score, tags). Use proxy_activate_server on results, or let handshake do it.
Inspired by MCP tool search / lazy discovery best practices (Anthropic, Stacklok, etc.).
| 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?
Discloses that it is a lazy loading search that returns a ranked list (name, desc, score, tags). No annotations provided, but description does not mention side effects or safety; assumes read-only. Could be more explicit about no destructive 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?
Concise at 4 sentences. Front-loaded with purpose and usage. The last sentence about inspiration is slightly extraneous but not harmful.
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?
Explains purpose, usage, and output. Lacks details on query syntax, limit effect, and error handling. Since output schema exists, return values are covered, but tool behavior could be more 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 0% (no parameter descriptions in schema). Description only refers to 'free-text query' for the query parameter and mentions output format but not limit. Insufficient to clarify parameter usage beyond basic intent.
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?
Clearly states it searches the catalogue for servers/tools using free-text query. Distinguishes from siblings by emphasizing lazy loading pattern for on-demand discovery, avoiding context bloat.
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?
Explains when to use (on-demand discovery to find specific capabilities) and what to do after (use proxy_activate_server or handshake). No explicit exclusions but enough context for selection.
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.1.0proxy_activate_from_specproxy_activate_serverproxy_add_custom_proxyproxy_deactivate_serverproxy_get_metricsproxy_get_usageproxy_handshakeproxy_inspect_registryproxy_list_active_serversproxy_list_available_serversproxy_list_toolsproxy_reset_usageproxy_search_toolsEach tool has a clearly distinct purpose: handshake, listing servers, searching, activation/deactivation, spec generation, metrics, usage tracking, etc. No two tools appear to overlap in functionality.
All tools follow the 'proxy_verb_noun' pattern with consistent snake_case. Verbs like 'list', 'activate', 'get', 'reset' are used uniformly, making the naming predictable.
13 tools is well-scoped for a proxy management server, covering setup, discovery, activation, inspection, and usage tracking without being overwhelming or too sparse.
The tool surface covers the core workflows (handshake, list, search, activate, deactivate, add custom, metrics, usage). A minor gap is the lack of a tool to get detailed server info (beyond counts), but overall it's quite complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Search, vet & assemble MCP servers from your agent: verified tools, risk labels, and trust scores.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/HappyMonkeyAI/DynamicMCPProxy'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
