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., "@dynamic-mcp create a new tool that runs shell commands"
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 production-grade dynamic MCP server for Node.js that enables runtime tool creation, management, and execution in isolated execution sandboxes (docker or node).
Unlike static MCP servers that define tools at compile time, dynamic-mcp lets AI agents and operators create, update, and delete tools on the fly with full lifecycle management.
Runtime tool management — Create, update, delete, enable/disable tools without restarts via the dynamic.tool.* control plane
Execution backend selection — auto (Docker preferred, Node fallback), or force docker / node
Dual transport — Stdio for local/CLI use, Streamable HTTP for networked deployments with per-session MCP servers
Dual registry backend — File-based (single node) or PostgreSQL (multi-instance) with optimistic concurrency control
Execution guard — Global concurrency and per-scope rate limiting to prevent abuse
JWT authentication — Optional JWKS-based token verification for HTTP mode
Audit logging — Structured JSONL logs with rotation, redaction of sensitive fields, and shutdown flush
Experimental upstream attach — Optional feature-flagged upstream.mcp.attach for lazy discovery of existing MCP servers
Two profiles — mvp (default) for core functionality, enterprise for long-lived sandbox sessions, metrics, and ops tools
Production-ready — Health probes, Prometheus metrics, graceful shutdown, Kubernetes manifests, Docker Compose baselines
Related MCP server: MyPostmanServer
Prerequisites: Node.js >= 20 (Docker recommended)
Fastest way to run stdio (no clone/build):
npx -y dynamic-mcp --transport stdio --profile mvp
# optional: pin version for reproducibility
npx -y dynamic-mcp@<version> --transport stdio --profile mvpFrom source (local development):
# Install dependencies
pnpm install
# Run in stdio mode (default, mvp profile)
pnpm run dev
# Run in HTTP mode
pnpm run dev:http
# Run with enterprise profile
pnpm run dev:enterpriseHTTP mode default endpoint: http://127.0.0.1:8788/mcp
Development / PoC: mvp profile + stdio transport + file backend (.env.example)
Production: enterprise profile + http transport + JWT auth + PostgreSQL backend (.env.prod.example)
This project supports both MCP standard transports:
stdio (recommended for local development/CLI clients)
Streamable HTTP (recommended for remote/network deployment)
Most MCP clients launch your server as a child process in stdio mode.
Option A (recommended for quick setup): run from npm with npx:
npx -y dynamic-mcp --transport stdio --profile mvpOption B (recommended when developing this repo): build local runtime first:
pnpm install
pnpm buildThen use an absolute path to dist/index.js in client config. Example:
node /ABS/PATH/TO/dynamic-mcp/dist/index.js --transport stdio --profile mvpDynamic code execution features use the selected execution backend (docker or node).
Note: sandbox.* tools remain Docker-based; in environments without Docker, use mvp profile or avoid sandbox.*.
Execution backend can be controlled with MCP_EXECUTION_ENGINE / --execution-engine:
auto (default): use Docker when available, fallback to Node sandbox when Docker is unavailable
docker: force Docker
node: force Node sandbox (no dynamic dependency installation)
If Docker is not installed and you want the MCP server to default to Node immediately, set MCP_EXECUTION_ENGINE=node in the client config or append --execution-engine node to the launch command:
npx -y dynamic-mcp --transport stdio --profile mvp --execution-engine nodeClaude Desktop uses a local claude_desktop_config.json file with mcpServers.
macOS path:
~/Library/Application Support/Claude/claude_desktop_config.json
Windows path:
%APPDATA%\Claude\claude_desktop_config.json
Example:
{
"mcpServers": {
"dynamic-mcp": {
"command": "npx",
"args": [
"-y",
"dynamic-mcp",
"--transport",
"stdio",
"--profile",
"mvp"
],
"env": {
"MCP_DYNAMIC_BACKEND": "file",
"MCP_DYNAMIC_STORE": "/ABS/PATH/TO/dynamic-mcp/.dynamic-mcp/tools.json",
"MCP_SANDBOX_DOCKER_BIN": "docker"
}
}
}
}If Docker is not installed, configure the server to use Node explicitly:
{
"mcpServers": {
"dynamic-mcp": {
"command": "npx",
"args": [
"-y",
"dynamic-mcp",
"--transport",
"stdio",
"--profile",
"mvp"
],
"env": {
"MCP_DYNAMIC_BACKEND": "file",
"MCP_DYNAMIC_STORE": "/ABS/PATH/TO/dynamic-mcp/.dynamic-mcp/tools.json",
"MCP_EXECUTION_ENGINE": "node"
}
}
}
}Note: Claude Desktop remote MCP server management is done in app settings (Settings -> Connectors), not in claude_desktop_config.json.
Add local stdio server:
claude mcp add dynamic-mcp -- npx -y dynamic-mcp --transport stdio --profile mvpIf Docker is not installed:
claude mcp add dynamic-mcp -- npx -y dynamic-mcp --transport stdio --profile mvp --execution-engine nodeAdd remote HTTP server:
claude mcp add --transport http dynamic-mcp-http http://127.0.0.1:8788/mcpProject-level .mcp.json example (supports both local and remote server definitions):
{
"mcpServers": {
"dynamic-mcp-local": {
"command": "npx",
"args": [
"-y",
"dynamic-mcp",
"--transport",
"stdio",
"--profile",
"enterprise"
]
},
"dynamic-mcp-http": {
"type": "http",
"url": "http://127.0.0.1:8788/mcp",
"authorization_token": "${DYNAMIC_MCP_JWT_TOKEN}"
}
}
}If Docker is not installed, add "env": { "MCP_EXECUTION_ENGINE": "node" } to the local server entry or append "--execution-engine", "node" to its args.
Claude Code supports environment variable expansion in config values, including ${VAR} and ${VAR:-default}.
Use workspace config file: .vscode/mcp.json.
Local stdio example:
{
"servers": {
"dynamic-mcp": {
"command": "npx",
"args": [
"-y",
"dynamic-mcp",
"--transport",
"stdio",
"--profile",
"mvp"
],
"env": {
"MCP_DYNAMIC_BACKEND": "file",
"MCP_SANDBOX_DOCKER_BIN": "docker"
}
}
}
}If Docker is not installed, set the execution engine to Node:
{
"servers": {
"dynamic-mcp": {
"command": "npx",
"args": [
"-y",
"dynamic-mcp",
"--transport",
"stdio",
"--profile",
"mvp"
],
"env": {
"MCP_DYNAMIC_BACKEND": "file",
"MCP_EXECUTION_ENGINE": "node"
}
}
}
}Remote HTTP + JWT header example:
{
"servers": {
"dynamic-mcp-http": {
"url": "http://127.0.0.1:8788/mcp",
"headers": {
"Authorization": "Bearer ${input:dynamic_mcp_jwt}"
}
}
},
"inputs": [
{
"type": "promptString",
"id": "dynamic_mcp_jwt",
"description": "JWT Bearer token for dynamic-mcp"
}
]
}Server startup example:
pnpm run dev:http
# or:
node /ABS/PATH/TO/dynamic-mcp/dist/index.js --transport http --host 127.0.0.1 --port 8788 --path /mcp
# or:
npx -y dynamic-mcp --transport http --host 127.0.0.1 --port 8788 --path /mcpIn HTTP mode, the server runs as an independent process/container, and MCP clients connect to the configured URL.
HTTP endpoints:
POST /mcp initialize/continue MCP session
GET /mcp session stream
DELETE /mcp close session
GET /livez liveness
GET /readyz readiness
GET /metrics Prometheus metrics
JWT behavior in this repo:
When MCP_AUTH_MODE=jwt, authentication is enforced on MCP endpoint requests (${MCP_PATH}, default /mcp).
/livez, /readyz, /metrics remain anonymous by default.
Production recommendation: keep /livez, /readyz, /metrics behind private networking, ingress allowlists, or a gateway even when JWT is enabled.
MCP_TRANSPORT=http
MCP_PROFILE=enterprise
MCP_HOST=0.0.0.0
MCP_PORT=8788
MCP_PATH=/mcp
MCP_EXECUTION_ENGINE=auto
MCP_DYNAMIC_BACKEND=postgres
MCP_REQUIRE_ADMIN_TOKEN=true
MCP_ADMIN_TOKEN=change-me
MCP_AUTH_MODE=jwt
MCP_AUTH_JWKS_URL=https://your-idp.example.com/.well-known/jwks.json
MCP_AUTH_ISSUER=https://your-idp.example.com/
MCP_AUTH_AUDIENCE=dynamic-mcp
MCP_AUTH_REQUIRED_SCOPES=mcp.invoke
# Optional experimental feature (enterprise only)
MCP_EXPERIMENTAL_UPSTREAM_MCP_ATTACH=false
MCP_EXPERIMENTAL_UPSTREAM_MCP_ATTACH_MAX=8Full variable reference: docs/configuration.md
Production baseline assets:
Document | Description |
System design, module structure, and data flow | |
All environment variables and CLI arguments | |
Complete tool, resource, and prompt reference | |
How to author and manage dynamic tools | |
Security model, sandbox isolation, and authentication | |
Docker, Compose, and Kubernetes deployment guides | |
Production rollout, verification, and rollback steps |
Core dynamic tool engine:
Tool | Description |
| Register a new dynamic tool |
| Modify an existing tool definition |
| Remove a tool |
| List all registered tools |
| Get a single tool definition |
| Enable or disable a tool |
| One-off JavaScript execution in a sandbox |
| Server liveness and uptime |
Everything in MVP, plus:
Tool / Resource | Description |
| Create a reusable container session |
| Run shell commands in a session |
| Run JavaScript in a session |
| Stop a session container |
| List active sessions |
| Concurrency/rate-limit counters |
| Sanitized config snapshot |
| Guard metrics resource |
| Config snapshot resource |
| Service metadata resource |
| Reusable pre-call checklist prompt |
| Experimental upstream MCP attach* |
| Experimental upstream MCP detach* |
* Registered only when MCP_EXPERIMENTAL_UPSTREAM_MCP_ATTACH=true.
Enable with feature flag (enterprise profile only):
MCP_PROFILE=enterprise
MCP_EXPERIMENTAL_UPSTREAM_MCP_ATTACH=true
MCP_EXPERIMENTAL_UPSTREAM_MCP_ATTACH_MAX=8
MCP_ADMIN_TOKEN=change-meThis registers upstream.mcp.attach and upstream.mcp.detach. attach can connect to an existing MCP server (stdio or http) and return its current listTools output.
Current scope is intentionally narrow:
Supported: attach + tool discovery
Supported: attach + detach + tool discovery
Not yet supported: runtime mount/unmount/proxy of upstream tools into dynamic-mcp tool namespace
Security boundary:
transport=stdio can spawn local processes; treat it as privileged
MCP_ADMIN_TOKEN is required when this feature flag is enabled
Pair with MCP_REQUIRE_ADMIN_TOKEN=true and MCP_ADMIN_TOKEN=...
{
"tool": {
"name": "text.uppercase",
"description": "Convert text to uppercase",
"code": "const { text } = args;\nreturn { upper: String(text).toUpperCase() };",
"dependencies": [],
"image": "node:lts-slim",
"timeoutMs": 10000
}
}Then invoke it:
{
"args": { "text": "hello world" }
}See the Dynamic Tools Guide for full details.
docker build -t dynamic-mcp:latest .
docker run --rm -p 8788:8788 dynamic-mcp:latestWhen MCP_EXECUTION_ENGINE=auto (default), dynamic tool execution (dynamic.*, run_js_ephemeral) uses Docker when available and falls back to Node sandbox when Docker is unavailable.
sandbox.* tools remain Docker-based. For those tools in containerized deployments, the running dynamic-mcp process must have:
A Docker CLI binary available in the container (docker)
Connectivity and authorization to a Docker daemon (local socket or remote daemon)
Without that Docker access, sandbox.* calls fail at runtime.
Security note: exposing the host Docker socket gives the container high privilege over the host. Prefer a dedicated remote Docker daemon with network isolation and TLS for production.
docker compose -f deploy/docker-compose.postgres.yml up -d --buildkubectl apply -f deploy/k8s/dynamic-mcp-postgres.yaml
# Optional: HPA + PDB
kubectl apply -f deploy/k8s/dynamic-mcp-scalability.yaml
# Optional: Network policy
kubectl apply -f deploy/k8s/dynamic-mcp-networkpolicy.yamlpnpm run dev # stdio mode, mvp profile
pnpm run dev:mvp # explicit mvp profile
pnpm run dev:http # HTTP mode
pnpm run dev:enterprise # enterprise profile
pnpm run test # run tests
pnpm run lint # lint
pnpm run typecheck # type check
pnpm run build # compile TypeScriptMIT
Create and register a new dynamic tool
| Name | Required | Description | Default |
|---|---|---|---|
| adminToken | No | ||
| tool | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose any behavioral traits such as destructive action, permission requirements, error handling, or side effects like overwriting existing tools.
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?
Extremely concise (one phrase) but at the expense of providing useful information. Oversimplified for a tool with a nested object and multiple parameters.
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 complexity (nested object, many required fields, no output schema), the description is entirely inadequate. It does not explain registration process, field purposes, or expected behavior.
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 description adds no meaning to parameters. The agent receives no help understanding the adminToken or the complex 'tool' object structure.
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 'Create and register a new dynamic tool' uses a specific verb and resource, clearly distinguishing it from sibling tools like delete, enable, get, list, and update.
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 vs alternatives. Missing prerequisites like adminToken authorization, or whether the tool is activated immediately after creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a dynamic tool and unregister it from MCP
| Name | Required | Description | Default |
|---|---|---|---|
| adminToken | No | ||
| name | Yes | ||
| expectedRevision | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. While 'delete' and 'unregister' imply a destructive action, the description omits details such as required permissions, irreversibility, cascading effects, or whether the tool must be disabled first. It adds minimal value beyond the tool's name.
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 sentence, making it brief and front-loaded. However, its brevity leads to under-specification; it does not earn its place because it omits important information that could be included concisely.
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 three parameters, no annotations, and no output schema, the description should provide more context. It fails to cover parameter meanings, side effects, auth requirements, or typical usage flow, making it incomplete for effective agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (adminToken, name, expectedRevision) but zero description coverage. The tool description fails to explain any parameter purpose, meaning of expectedRevision (concurrency control?), or why adminToken is not required. This is a critical gap.
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 ('Delete') and resource ('dynamic tool'), and adds 'unregister it from MCP' to specify the effect. It is distinguishable from sibling tools like 'create' or 'enable', though it could be more explicit about whether it also disables or cleans up related resources.
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 like 'disable' or 'update'. The description does not mention prerequisites, authorization, or scenarios for deletion, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enable or disable a dynamic tool at runtime
| Name | Required | Description | Default |
|---|---|---|---|
| adminToken | No | ||
| name | Yes | ||
| enabled | Yes | ||
| expectedRevision | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects like persistence, authentication needs (adminToken), or concurrency control (expectedRevision). It only says 'at runtime', leaving many behavioral aspects unclear.
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, no redundant phrasing, but it lacks structure (e.g., bullet points or separate sections) for a tool with 4 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a runtime toggle tool with concurrency control and authentication, the description omits critical context like whether the change is immediate or requires a restart, and the role of expectedRevision.
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%, yet the description adds no explanation for any parameter (e.g., adminToken, expectedRevision). The agent must infer meaning from names alone.
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 (enable/disable) and resource (dynamic tool) with a runtime scope. It directly distinguishes from sibling tools like create, delete, or update.
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 alternatives (e.g., update for permanent changes). No prerequisites or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one dynamic tool definition by name
| Name | Required | Description | Default |
|---|---|---|---|
| adminToken | No | ||
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors itself. It only states it gets a definition, omitting details on authentication (adminToken), error handling for missing names, or return structure.
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 very concise (one sentence) and front-loaded, but sacrifices necessary details for brevity.
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 no output schema and two parameters with zero schema descriptions, the description should mention return values or behavior for missing resources, which it does not.
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 explain parameters. Only 'by name' hints at the name parameter, but adminToken and the pattern constraint are left unaddressed.
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 (Get), resource (dynamic tool definition), and identifier (by name), effectively distinguishing it from sibling tools like list or create.
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 usage context—when you need a single definition—but provides no explicit guidance on when to prefer this over dynamic.tool.list or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all dynamic tools currently registered in local storage
| Name | Required | Description | Default |
|---|---|---|---|
| adminToken | No | ||
| includeCode | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states it lists tools in local storage, but does not mention authentication requirements (adminToken), the effect of includeCode, or the format of the output.
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 sentence, front-loaded with the purpose. It is concise but could be more informative 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?
For a simple list tool, the description is adequate but lacks details about what the returned list contains and how it behaves when empty. Given no output schema, more context would be helpful.
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 description does not explain the parameters 'adminToken' or 'includeCode' at all, leaving them completely opaque.
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 'dynamic tools', with the scope 'currently registered in local storage'. It distinguishes itself from siblings like dynamic.tool.get (single tool) and dynamic.tool.create/delete/update.
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 vs. alternatives. For example, it doesn't mention that this is for discovery or debugging, or when to use dynamic.tool.get instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing dynamic tool definition
| Name | Required | Description | Default |
|---|---|---|---|
| adminToken | No | ||
| name | Yes | ||
| patch | Yes | ||
| expectedRevision | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states 'Update an existing dynamic tool definition', revealing nothing about idempotency, validation, permissions (e.g., adminToken requirement), merge semantics, or return behavior. This is critically insufficient.
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 short sentence, which is concise but at the severe cost of completeness. For a tool with a complex input schema (nested object, four parameters), this level of brevity is inappropriate and leaves critical gaps.
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 complexity (4 parameters, nested objects, no annotations, no output schema), the description is woefully incomplete. It fails to explain what happens to existing fields, how patches are applied, or what the response contains. The agent lacks sufficient context to use this 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%, meaning no parameters are documented in the schema, and the tool description adds zero explanation for any of the four parameters (adminToken, name, patch, expectedRevision). The agent cannot understand the role of 'patch' (is it a partial update?) or 'expectedRevision' (optimistic concurrency) without external knowledge.
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 'update' and the resource 'existing dynamic tool definition'. It effectively distinguishes from sibling tools like 'create' or 'delete' by using a different verb. However, it lacks specificity about what 'update' entails (e.g., partial vs full replacement).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'dynamic.tool.enable' or 'dynamic.tool.get'. It does not mention prerequisites (e.g., tool must exist) or side effects. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute one-off Node.js code in the configured execution sandbox (Docker preferred, Node fallback) without persisting a tool
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | JavaScript function body to execute inside export async function run(args) { ... } | |
| args | No | ||
| image | No | Optional Docker image override | |
| dependencies | No | ||
| timeoutMs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions execution sandbox (Docker preferred, Node fallback), but does not disclose error handling, side effects, or rate limits. Moderate 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?
Single sentence front-loading the purpose, but could be slightly more informative without verbosity. No 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?
Given 5 parameters, nested objects, and no output schema, description lacks detail on return values, error handling, and constraints (e.g., code max length 200k). Adequate but not thorough.
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 40%. Description adds value for code (function body inside async export) and dependencies (dependencies array with name/version), but not for args, image, or timeoutMs. Marginal improvement over 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 'Execute one-off Node.js code' with a specific verb and resource. It distinguishes from sibling tools by emphasizing ephemerality and not persisting a tool.
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 one-off execution via 'without persisting a tool', contrasting with dynamic.tool.* siblings for persistent tools. However, it lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return server liveness and uptime info
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| service | Yes | |
| version | Yes | |
| uptimeSeconds | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It states it returns liveness and uptime info, which implies a safe read operation. However, it does not mention authentication requirements or rate limits, which is a gap for a tool that likely does not require auth.
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, front-loaded with action and resource. No wasted words; perfectly concise.
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 no parameters and an output schema (assumed defined), the description is fully sufficient for a simple health endpoint. Covers what the tool does completely.
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?
There are no parameters, and schema coverage is 100% trivially. According to guidelines, 0 parameters yields a baseline of 4, and the description adds meaning by stating what the output contains (liveness and uptime).
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 uses specific verb 'Return' and resource 'server liveness and uptime info', clearly distinguishing it from sibling tools like dynamic.tool.* and run_js_ephemeral that handle different functions.
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 or when not to use this tool versus alternatives. Given sibling tools, it would be helpful to note that this is for health checks before performing other operations, but no such advice is provided.
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.4.1dynamic.tool.createdynamic.tool.deletedynamic.tool.enabledynamic.tool.getdynamic.tool.listdynamic.tool.updaterun_js_ephemeralsystem.healthEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
MCP server for Superserve sandboxes: create, exec, and manage Firecracker microVMs
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
A MCP server built for developers enabling Git based project management with project and personal…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mcpland/dynamic-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
