dynamic-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_HOST | No | Host to bind for HTTP mode, default 127.0.0.1 | 127.0.0.1 |
| MCP_PATH | No | Path for MCP endpoint, default /mcp | /mcp |
| MCP_PORT | No | Port for HTTP mode, default 8788 | 8788 |
| MCP_PROFILE | No | Profile: mvp or enterprise, default mvp | mvp |
| MCP_AUTH_MODE | No | Authentication mode: none or jwt, default none | none |
| MCP_TRANSPORT | No | Transport mode: stdio or http, default stdio | stdio |
| MCP_ADMIN_TOKEN | No | Admin token for privileged operations | |
| MCP_AUTH_ISSUER | No | JWT issuer | |
| MCP_AUTH_AUDIENCE | No | JWT audience | |
| MCP_AUTH_JWKS_URL | No | JWKS URL for JWT authentication | |
| MCP_DYNAMIC_STORE | No | Path to tools storage file for file backend | |
| MCP_DYNAMIC_BACKEND | No | Backend for dynamic tools: file or postgres, default file | file |
| MCP_EXECUTION_ENGINE | No | Execution engine: auto, docker, or node, default auto | auto |
| MCP_SANDBOX_DOCKER_BIN | No | Docker binary path, default docker | docker |
| MCP_REQUIRE_ADMIN_TOKEN | No | Require admin token for privileged operations, default false | false |
| MCP_AUTH_REQUIRED_SCOPES | No | Required scopes for JWT authentication | |
| MCP_EXPERIMENTAL_UPSTREAM_MCP_ATTACH | No | Enable experimental upstream MCP attach, default false | false |
| MCP_EXPERIMENTAL_UPSTREAM_MCP_ATTACH_MAX | No | Max upstream attach sessions, default 8 | 8 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| system.healthA | Return server liveness and uptime info |
| dynamic.tool.listC | List all dynamic tools currently registered in local storage |
| dynamic.tool.getB | Get one dynamic tool definition by name |
| dynamic.tool.createC | Create and register a new dynamic tool |
| dynamic.tool.updateC | Update an existing dynamic tool definition |
| dynamic.tool.deleteC | Delete a dynamic tool and unregister it from MCP |
| dynamic.tool.enableC | Enable or disable a dynamic tool at runtime |
| run_js_ephemeralA | Execute one-off Node.js code in the configured execution sandbox (Docker preferred, Node fallback) without persisting a tool |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool has a clearly distinct purpose: CRUD operations for dynamic tools, one-off code execution, and system health. No functional overlap.
Six tools follow a consistent 'dynamic.tool.<action>' pattern, but 'run_js_ephemeral' uses snake_case and 'system.health' uses a different namespace, creating minor inconsistency.
8 tools is well-scoped for managing dynamic tools and executing ephemeral code, with no unnecessary bloat or deficiency.
CRUD operations and enable/disable cover the full lifecycle of dynamic tools. The ephemeral runner adds useful functionality. Missing a validation or test tool, but core needs are met.