Allows discovery, registration, and management of cookiecutter templates, and generation of projects from those templates.
Click on "Deploy 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., "@Dynamo MCP list all available templates"
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.
Create a small, tested software project from an approved template. Dynamo shows the exact files first, verifies the template fingerprint, then writes a new project without running template scripts or downloading code.
This is a security focused alpha release. The old Python Cookiecutter service is retired because it allowed executable templates and unrestricted output paths. Its historical documentation remains in the migration archive.
Capability | Available behavior |
Project types | Node CLI, Node library, Python CLI |
Preview | Complete rendered files and deterministic SHA256 digest |
Template integrity | Bundled JSON templates pinned by digest in a reviewed manifest |
Generation | Private operator directory, exclusive reservation, staged atomic source publication |
Security | No hooks, no remote downloads, no arbitrary paths, no overwrite, file and project quotas |
Agent tools | Official MCP SDK 2 stdio server, six tools, policy resource |
Evaluation | Generated project tests, hostile fixtures, SDK integration tests, local benchmark |
MetaHarness | Maintainer/security/release/benchmark profiles, sessions, field memory adapter, host configs |
Autogenous | Actual upstream fitness gates, automatic promotion disabled |
Related MCP server: agentic-patterns
Requires Node 22 or 24, npm, and Python 3.11+ for Python template tests. Linux is the validated generation platform.
git clone https://github.com/ruvnet/dynamo-mcp.git
cd dynamo-mcp
npm ci --ignore-scripts
npm test
node src/cli.mjs list
node src/cli.mjs preview '{"template":"node-cli","name":"my-project"}'Create an operator owned output directory with private permissions. Existing project names are never overwritten.
mkdir -m 700 "$HOME/dynamo-projects"
export DYNAMO_OUTPUT_ROOT="$HOME/dynamo-projects"
export DYNAMO_ALLOW_GENERATE=1
node src/cli.mjs generate '{"template":"node-cli","name":"my-project"}'
cd "$DYNAMO_OUTPUT_ROOT/my-project/source"
npm test
npm startA generated harness.json declares validation and ecosystem links; it is not an installed full MetaHarness. The full working MetaHarness belongs to this repository and is installed separately using the linked guide.
Start node /absolute/path/dynamo-mcp/src/cli.mjs mcp from your MCP host. Stdio access inherits the launching operator's authority. No HTTP server is exposed. Generation additionally requires both environment variables above. Validation requires DYNAMO_ALLOW_VALIDATION=1; no tool accepts a shell command, environment map, or output directory.
CLI command | MCP tool |
|
|
|
|
|
|
|
|
|
|
|
|
Resource: ruv://dynamo-mcp/policy. CLI test is explicit local authorization to run the fixed core suite. npm test runs the complete suite, including the MCP client. MCP validation runs the core suite without recursive MCP invocation. Benchmarks measure local template verification and rendering only.
Inputs are capped at 32 KiB, MCP frames at 64 KiB, templates at 256 KiB, files at 64 KiB and 64 per bundle, generated projects at 100 per output root. One generation holds a root lock; two tool calls may be active. Validation is one fixed subprocess with a 30 second deadline and 64 KiB output cap; environment secrets are not forwarded.
A crash leaves a lock and potentially a private staging directory. Stop all Dynamo instances, inspect the incomplete project, and remove the stale lock and incomplete reservation manually before retrying. Dynamo never guesses that a lock is stale. Atomic visibility of the source directory does not guarantee power loss durability. Protect the root and its parents from other writers; this is not isolation from another process running under your own account. Hash receipts prove content consistency, not trusted authorship.
npm test
npm run benchmark
npm auditCI runs Node 22 and 24, all project and SDK tests, audit, and benchmark artifact upload. Tagged releases create a source archive as a CI artifact; no registry or live deployment occurs automatically. ADR, security review, and validation evidence document scope and limitations.
RuFlo coordinates work. MetaHarness evaluates changes. Autogenous supplies fitness gates. Guardrail evaluates policy. Federated MCP provides bounded federation reads. x.ruv.io MCP is a separate federation service; Dynamo does not publish federation messages or acquire credentials.
project benchmark
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite the sparse description, the annotations indicate this is a read-only, non-destructive operation (readOnlyHint=true, destructiveHint=false). The description does not contradict these annotations and adds no conflicting information. However, it also provides no extra behavioral context, but the annotations carry the full burden and are sufficient, so a relatively high score is warranted. This is an exception where annotations compensate for lack of description.
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 extremely short, but it is under-specified rather than concise. A single vague phrase with no useful content fails to earn its place. It should be expanded to include meaningful purpose and usage details.
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 no parameters and no output schema, the description still fails to explain the tool's function. It is completely inadequate—an agent cannot determine what 'project benchmark' does, what inputs it expects (if any), or what outputs it produces. The lack of any descriptive content makes this a severe gap.
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 no parameters, so there is nothing to document. Per the rubric, 0 parameters yields a baseline of 4. The description adds no parameter information, but none is needed.
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 is a tautology—'project benchmark' adds no information beyond the tool name. It states neither a verb nor a resource, making it impossible for an agent to understand what the tool actually does. It provides no differentiation from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. There is no mention of context, purpose, or distinctions from sibling tools like project_generate or project_status. An agent would have to guess the appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate bundled inert project under operator private root; local opt-in required.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| template | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false, openWorldHint=false, destructiveHint=false, so they reveal little. The description adds meaningful context: 'bundled inert' implies a non-executable artifact, 'operator private root' specifies the storage location, and 'local opt-in required' discloses an authorization prerequisite. These details go beyond the annotations and help the agent anticipate side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one 14-word sentence that leads with the action and resource, then adds the key prerequisite. Every word contributes; there is no filler or repetition. This is an example of appropriate conciseness.
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 tool with no output schema, two undocumented required parameters, and several siblings, the description is too thin. It leaves the agent without parameter guidance, output expectations, or pointers to templates_list for valid template values. The single prerequisite is helpful but not enough for correct 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?
Schema coverage is 0% and the description makes no mention of the two parameters, 'template' and 'name'. An agent is left to guess what values these expect (e.g., a template identifier, a project display name) and what format or constraints apply. The description entirely fails to compensate for the undocumented 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 opens with 'Generate', a specific verb for creation, and names the exact resource ('bundled inert project') plus location ('operator private root'). This clearly distinguishes it from sibling tools like templates_list, project_status, or project_validate, which are read/validation operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a clear prerequisite: 'local opt-in required'. This gives the agent an explicit condition that must be met before calling the tool. However, it does not mention alternative tools or when to prefer one sibling over another, so it falls short of the 'explicit when/when-not/alternatives' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
project status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no new behavioral context: it does not state whether the status is cached, whether it incurs any cost, or what happens if the project doesn't exist. Since annotations cover the essential safety profile, a baseline of 3 is appropriate; the description adds little beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short ('project status'), which could be seen as concise, but it is under-specification rather than efficient brevity. It provides no useful content, so the single sentence does not earn its place. There is no attempt to front-load any meaningful information about the status or the tool's 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?
The tool has no parameters, no output schema, and a trivial annotation set (only readOnlyHint and destructiveHint). Given this simplicity, the description barely suffices to indicate it is a read-only status check. However, for a tool that could reasonably return a rich status object, the absence of any detail about what status is returned (current phase, last build result, etc.) leaves an agent guessing. A more complete description would at least say 'Returns the current status of the project, including phase and recent activity.'
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 zero parameters, and the schema is effectively empty (100% schema description coverage). With no parameters to document, the description does not need to add parameter semantics. A baseline of 4 is warranted because there is nothing to explain; the description's lack of parameter detail is not a deficiency when there are no parameters.
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 'project status' is a vague phrase that essentially restates the tool name without specifying what the status is, what it covers, or what the resource is. It fails to indicate whether this returns overall project health, current phase, or build state, and it does not distinguish the tool from siblings like project_generate or project_validate. It is closer to a tautology than a clear purpose statement.
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. While the sibling names (e.g., project_validate, project_generate) imply a family of project tools, nothing in the description explains the specific conditions under which an agent should select project_status. For a status-check tool, one would expect guidance like 'use to get current state before making changes' or 'use instead of project_validate to avoid triggering validation checks.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
project validate
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate readOnlyHint=true and destructiveHint=false, but the description itself discloses no behavioral traits beyond what the name implies. It does not state what is validated, what the validation result looks like, or whether any state is affected.
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 extremely short, but this is under-specification rather than effective conciseness. It contains no front-loaded useful information and does not earn its place as a tool description.
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?
Even though there are no parameters and the safety profile is covered by annotations, the description still fails to explain what 'validate' means, what the tool returns, or how it differs from project_status and project_benchmark. An agent cannot use this description to select or invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter semantics for the description to clarify. The baseline for 0 parameters is 4, and the description adds no unnecessary parameter details.
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 is simply 'project validate', which restates the tool name verbatim and provides no verb-resource clarity. It does not distinguish this from siblings like project_status or project_benchmark, so an agent cannot determine what validation actually does.
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?
There is no guidance on when to use this tool versus alternatives. The description offers no context, conditions, exclusions, or references to sibling tools, leaving the agent to infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
template preview
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| template | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true and destructiveHint=false, so the safety profile is already known. The description adds nothing beyond what the annotations provide — it does not disclose what a preview entails, what it returns, or any constraints. No contradiction, but no added value either.
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, but this is under-specification rather than conciseness. It contains a single sentence that adds no information, so brevity here is not earned value — it is absence of content.
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 2-required-parameter tool with no output schema, no enum hints, and 0% schema coverage, the description fails to provide essential information about parameters, return behavior, or usage context. It is completely inadequate for correct 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?
Schema description coverage is 0%, and the description says nothing about the 'template' or 'name' parameters — their format, meaning, or how they relate. With no schema descriptions and no parameter explanation, the agent is left entirely without semantic guidance for two required parameters.
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 'template preview' is a near-verbatim restatement of the tool name, providing no verb-resource specificity, no object of action, and no differentiation from siblings like templates_list or project_generate. It is a pure tautology.
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 whatsoever on when to use this tool versus alternatives such as templates_list or project_validate. An agent receives zero context about the conditions that select this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
templates list
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. However, the description adds no behavioral detail beyond the name, such as what the list contains, whether it is paginated, or how results are returned.
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?
At two words, the description is short but not usefully concise; it is under-specification. There is no front-loaded action statement or clarifying structure.
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 no output schema and a description that only repeats the name, the agent cannot know what the tool returns or what 'templates' refers to. The description is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema description coverage is 100%, so the schema fully documents the input contract. The description has no obligation to add parameter detail, so the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is 'templates list', which merely restates the tool name without any action verb or resource scope. It also does nothing to distinguish the tool from the sibling template_preview.
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 given about when to use templates_list versus any sibling tool. The description provides no use-case context or exclusions, leaving the agent to infer the intended usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.0-alpha.1project_benchmarkproject_generateproject_statusproject_validatetemplate_previewtemplates_listScored across 6 tools
Each tool targets a distinct resource-action pair: templates list/preview are separate from project generate/status/validate/benchmark. No two tools appear to perform the same function.
All names follow a consistent noun_operation pattern (templates_list, project_generate), with minor inconsistency between plural 'templates_list' and singular 'template_preview'.
Six tools is a well-scoped count for a template/project generation server, covering the core workflow without unnecessary bloat.
The surface covers template discovery and project lifecycle basics (generate, status, validate, benchmark), but lacks explicit project update/delete operations, which agents may need for full lifecycle management.
Create and manage Templated email templates from any MCP client - bring your own model.
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
327 dev tools via REST API and MCP. Generate Dockerfiles, schemas, K8s, APIs, and more.
Governed MCP gateway: one endpoint for your tools, with credential custody and audit log.
