Provides tools to analyze and manage Drupal projects using ITK Dev Docker templates, including detecting project configuration, comparing against templates, and listing available templates.
Provides tools to analyze and manage Symfony projects using ITK Dev Docker templates, including detecting project configuration, comparing against templates, and listing available 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., "@ITK Dev Docker MCP Server List all available ITK Dev Docker 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.
Model Context Protocol (MCP) server that provides AI coding assistants with access to ITK Dev Docker documentation and project analysis tools.
MCP (Model Context Protocol) is an open protocol that enables AI assistants like Claude to access external resources and tools. This server provides:
Documentation Resources: Access to ITK Dev Docker documentation
Project Tools: Analyze, detect, and compare ITK Dev projects
Related MCP server: Docker MCP Server
This MCP server is part of the ITK Dev Claude Plugins.
Install through the ITK Dev plugin marketplace:
/plugin marketplace add itk-dev/itkdev-claude-plugins
/plugin install itkdev-tools@itkdev-marketplaceThe MCP server will be automatically configured.
For development or standalone use:
Node.js 18 or later
npm
git clone https://github.com/itk-dev/mcp-itkdev-docker.git
cd mcp-itkdev-docker
npm install
npm run buildAdd to ~/.claude.json or .mcp.json in your project:
{
"mcpServers": {
"itkdev-docker": {
"command": "npx",
"args": ["-y", "github:itk-dev/mcp-itkdev-docker"]
}
}
}Or for local development:
{
"mcpServers": {
"itkdev-docker": {
"command": "node",
"args": ["/path/to/mcp-itkdev-docker/dist/index.js"]
}
}
}Restart Claude Code and check that the MCP server is connected. You can ask Claude:
"What ITK Dev templates are available?"
Claude should be able to list templates using the itkdev_list_templates tool.
URI | Description |
| CLI tool commands, templates, and setup procedures |
| Docker Compose patterns and configurations |
| Taskfile automation patterns |
List all available ITK Dev Docker templates with their characteristics.
Example prompt:
"What templates are available for Drupal projects?"
Analyze a directory to detect ITK Dev project configuration.
Parameters:
path (required): Absolute path to the project directory
Example prompt:
"Analyze the project at /Users/me/projects/mysite"
Returns:
Project type (Drupal/Symfony)
Template in use
PHP version
Web root
Services defined
ITK version
List all files that would be installed by a template.
Parameters:
template (required): Template name (e.g., drupal-11)
Example prompt:
"What files does the drupal-11 template include?"
Compare a project against its template to find differences.
Parameters:
path (required): Absolute path to the project
template (optional): Template to compare against (auto-detected from .env)
Example prompt:
"Is my project at /Users/me/projects/mysite up to date with its template?"
Returns:
Missing files
Outdated files (with version comparison)
Matching files
Update recommendations
Get the content of a specific file from a template.
Parameters:
template (required): Template name
file (required): Relative file path
Example prompt:
"Show me the docker-compose.yml from the drupal-11 template"
"I need to set up a new Drupal 11 project. What template should I use and what are the steps?"
Claude will read the documentation and provide step-by-step instructions.
"Analyze my project at /path/to/project and tell me if it needs updates"
Claude will detect the project configuration and compare against the template.
"What services are included in the drupal-11 template and what do they do?"
Claude will read the documentation and explain each service.
"My Docker containers won't start. Can you help debug?"
Claude will read troubleshooting documentation and analyze your project configuration.
npm run devRebuilds on file changes.
mcp-itkdev-docker/
├── src/
│ └── index.ts # MCP server implementation
├── dist/ # Compiled output (gitignored)
├── docs/ # Documentation served as MCP resources
│ ├── itkdev-docker-cli.md
│ ├── itkdev-docker-compose.md
│ └── itkdev-task-files.md
├── package.json
├── tsconfig.json
└── README.mdIf using the plugin, verify installation with /plugin list
For manual installation, check that the path is absolute and correct
Check Node.js version (node --version should be 18+)
Restart Claude Code after configuration changes
Verify the MCP server is running (check Claude Code status)
For manual installation, ensure npm run build completed successfully
Look for error messages in Claude Code's output
Compare a project's Docker configuration against its template to find missing, outdated, or extra files
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the project directory | |
| template | No | Template to compare against (auto-detected from .env if not provided) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral burden. It usefully discloses the three result categories (missing, outdated, extra), implying a read-only drift analysis, but never states side effects, permissions, or return shape explicitly.
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 sentence that front-loads the action and resource and ends with the concrete result categories. Nothing is redundant or padded.
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 no annotations, the description must carry more weight, and it does mention the result categories, which is helpful. However, it omits how the comparison is scoped or what the output looks like, leaving gaps for an agent predicting 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 100%, so both 'path' and 'template' are already documented, including the auto-detection fallback for template. The description adds no syntax or format detail beyond the schema, so the baseline of 3 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?
States a specific verb (compare), two concrete resources (project's Docker configuration and its template), and the outcome (missing, outdated, extra files). It is clearly distinct from the sibling retrieval tools, though it does not name any of them explicitly to reinforce the distinction.
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 what the comparison yields but gives no guidance on when to prefer it over siblings like itkdev_detect_project or itkdev_get_template_files, and no prerequisites or exclusions. Usage can only be inferred from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a directory to detect ITK Dev project configuration, template type, PHP version, and framework
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the project directory to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. 'Analyze' implies a read-only inspection, but the description never confirms it is non-mutating, says nothing about what happens if detection fails, and does not indicate whether it inspects the filesystem recursively. For a tool with zero annotation coverage this is thin.
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 front-loaded sentence with no filler; the verb and detected attributes are stated immediately.
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, the description usefully enumerates the four things detection returns (configuration, template type, PHP version, framework), which is enough for an agent to know what to expect. It falls short only on error/edge-case behavior for a missing or invalid path.
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 100% and the single 'path' parameter is fully documented in the schema as an absolute path. The description adds no format, constraint, or edge-case detail beyond that, so the baseline 3 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?
States a specific verb (Analyze) and resource (a directory) and enumerates what is detected: ITK Dev project configuration, template type, PHP version, and framework. This clearly separates it from siblings like itkdev_list_templates and itkdev_get_template_content, though it never names those alternatives explicitly.
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 reach for this tool versus itkdev_compare_project or the template-fetching siblings, nor any stated prerequisites (e.g., the directory must exist or be a valid project). The agent must infer usage entirely from the purpose sentence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the content of a specific file from a template
| Name | Required | Description | Default |
|---|---|---|---|
| file | Yes | Relative file path within the template (e.g., docker-compose.yml) | |
| template | Yes | Template name (e.g., drupal-11) |
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 says nothing about whether content is truncated, how binary files are handled, error behavior for missing files/templates, or permissions.
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?
One concise sentence that is front-loaded and free of filler. It is appropriately sized but does not exploit the space to add value.
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 retrieval tool with no annotations and no output schema, the description should explain return content or behavior. It doesn't, so an agent lacks key information about what it will get back.
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 100% with clear examples for both the file path and template name, so the schema already fully documents the parameters. The description adds no parameter detail beyond that.
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?
States a specific verb ('Get') and resource ('content of a specific file from a template'), so the operation is unambiguous. It doesn't distinguish itself from siblings like itkdev_get_template_files, but the purpose is clear.
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 indication of when to use this tool versus the sibling itkdev_get_template_files, no prerequisites, and no context about calling this before or after detection/listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all files that would be installed by a specific template
| Name | Required | Description | Default |
|---|---|---|---|
| template | Yes | Template name (e.g., drupal-11, symfony-6, drupal-module) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden, and 'would be installed' usefully signals this is a non-mutating preview rather than an install. That said, it does not state whether the template must exist locally, whether it fetches remotely, or what happens on an unknown template 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?
A single tight sentence with the key qualifier 'would be installed' front-loaded; nothing is wasted and it is immediately scannable.
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 one-parameter read tool with full schema coverage and no output schema, the description is adequate but leaves gaps: how files are returned, whether nested paths appear, and how it differs from itkdev_get_template_content are all unaddressed.
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 100%, so the single 'template' parameter is already fully documented with examples (drupal-11, symfony-6, drupal-module). The description adds no parameter meaning beyond the schema, so the baseline 3 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?
States a specific verb (List) and resource (files installed by a template), with the qualifying scope 'would be installed' making the read-only preview nature clear. However, it does not distinguish itself from siblings like itkdev_get_template_content, which the agent must infer is different by name alone.
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?
Usage is implied by the description — use it to see a template's file manifest — but there is no explicit when-to-use guidance, no mention of when to prefer itkdev_get_template_content or itkdev_compare_project, and no stated prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available ITK Dev Docker templates with their PHP versions and characteristics
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation is an enumeration and what each entry contains, implying a safe read, but it does not state permissions, whether results are paginated, or whether the template set is static or dynamic.
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 front-loaded sentence with no filler; the verb and resource lead immediately and every clause 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?
For a zero-parameter, no-annotation list tool with no output schema, the description gives enough to call it correctly and hints at the return shape (PHP versions, characteristics). It could be slightly more complete by noting this is a prerequisite step for the other template tools.
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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Schema coverage is 100% but empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (List) and resource (ITK Dev Docker templates) and previews the returned attributes (PHP versions and characteristics). It is clearly distinguishable from siblings like get_template_content or compare_project, though it does not explicitly differentiate itself.
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?
Usage is only implied: as the sole catalog/list tool among siblings, an agent can infer it should be called for discovery. There is no explicit when-to-use, no prerequisites, and no mention of when an alternative sibling is preferable.
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.
v0.1.2itkdev_compare_projectitkdev_detect_projectitkdev_get_template_contentitkdev_get_template_filesitkdev_list_templatesScored across 5 tools
Each tool targets a distinct action: detect inspects a project, list_templates enumerates templates, get_template_files and get_template_content retrieve file listings vs. file bodies, and compare_project diffs configs. The template-listing vs. template-file-content pair is clearly separated by naming and description, so misselection is unlikely.
All five tools share the itkdev_ prefix and a consistent snake_case verb_noun pattern (detect_project, get_template_files, compare_project, get_template_content, list_templates). The convention is uniform and predictable, with no mixing of styles.
Five tools is a tight, well-scoped set that matches the narrow template-inspection domain, with no redundant entries. It sits at the lower end of the range and feels slightly thin given that the server appears to be a scaffolding helper.
The surface is entirely read-only: detection, listing, content retrieval, and diffing are covered, but there is no tool to actually apply/install a template or initialize a project from one. For a Docker scaffolding server that is a notable gap, leaving agents to perform the core write action outside the toolset.
Versioned documentation registry and semantic search for AI tools and coding assistants.
Read and write KukGit repositories, files, issues and pull requests from an AI assistant.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
