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., "@Magento Spec MCP review my custom module for Magento coding standards compliance check"
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.
This repo is a Central Knowledge Library (Single Source of Truth - SSOT) for Magento 2.4.8-p5 / PHP 8.3 standards, with a built-in MCP Server Stdio.
This repo does not contain processes or task/feature management. You can connect this MCP Server to any Magento project so that the AI Agent in that project can reference the technical standards.
config/ — Source of truth:
constitution.md — PHP 8.3 & Magento core technical standards.
checklist.md — Review Gate & DoD criteria.
magento-patterns.md — Design map (Plugin, Event, GraphQL, REST, Admin...).
references/ — Detailed code sample guides for each component.
glossary.md — Magento core terminology.
examples/ — Sample code blueprints by topic (see examples/INDEX.md to choose).
src/index.js — MCP Server (stdio).
Related MCP server: Coding Tools MCP
Claude Code (recommended scope user to be available in all projects):
claude mcp add magento-spec -s user -- node /path/to/spec/src/index.jsCursor (~/.cursor/mcp.json), Antigravity (~/.gemini/antigravity/mcp_config.json) and other clients:
{
"mcpServers": {
"magento-spec": {
"command": "node",
"args": ["/path/to/spec/src/index.js"]
}
}
}
SPEC_ROOT(env) is optional — by default the server takes the repo's root directory. Only set if you place the repo elsewhere and want to override.
Tool | Description |
| Quickly load Constitution, Checklist & Pattern index. |
| Get detailed code sample by name (e.g., |
| Search standards/rules/blueprints by keyword in |
| Load the code quality checklist before completion. |
| Read any documentation file in the repo ( |
Before coding: get_team_standards → load Constitution + Checklist + Pattern index.
When implementing: get_pattern_reference / search_standards / read_spec_file to look up patterns — do not guess from memory.
Before reporting done: get_review_gate → go through §12 Review Gate in checklist.md.
Get specific Magento pattern reference doc from config/references/ (e.g. core/plugin-patterns.md, core/declarative-schema.md). Call without path to list all available references.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | Relative path under config/references/ (e.g. core/plugin-patterns.md). Omit to list all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the directory scope and the two behaviors (list all vs. fetch one), but does not mention read-only behavior, expected return format, error cases, or availability constraints. 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?
Two sentences, zero wasted words. The first sentence states the action and target, the second provides usage alternatives. Perfectly front-loaded and efficient.
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 low complexity (1 optional param, no output schema), the description covers the invocation mechanics well. However, it lacks details about the response structure, file format constraints, and error scenarios, which a complete agent aid might include.
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% (1 param with description). The description adds value by clarifying the base path ('config/references/') and giving concrete examples (core/plugin-patterns.md, core/declarative-schema.md), which go beyond the schema's generic description.
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 tool retrieves a 'Magento pattern reference doc' from a specific directory 'config/references/', and distinguishes between fetching a specific file by path or listing all available references. This is precise, specific, and differentiates from siblings.
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 provides explicit usage pattern: provide the path to get a specific doc, omit it to list all references. It doesn't explicitly say when not to use it or name alternatives, but the context is clear enough for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load code review gate checklist and DoD criteria for Magento code before marking done.
| 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 full burden for behavioral disclosure. It states 'Load' suggesting a read operation, but fails to mention side effects, error states, authentication needs, or what happens if the review gate is missing. The description is too minimal to inform safe invocation.
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, self-contained sentence that communicates the tool's purpose without any wasted words. For a tool with no parameters, this is appropriately concise and front-loaded.
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 tells what the tool does and when to use it, but given no output schema and no annotations, it lacks details about the return format or structure of the checklist/DoD criteria. It is adequate but not complete for an agent to fully anticipate the output.
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 schema description coverage is 100% trivially. The description does not need to add parameter semantics, and the baseline for 0-parameter tools is 4.
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 uses a specific verb ('Load') and resource ('code review gate checklist and DoD criteria for Magento code'), clearly distinguishing it from siblings like 'get_team_standards' or 'get_pattern_reference'. It also provides context ('before marking done') that narrows its use.
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 ('before marking done') but gives no explicit guidance on when to use this tool versus alternatives (e.g., 'search_standards' or 'read_spec_file'). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load Magento 2.4.8-p5 / PHP 8.3 team standards, constitution, checklist, and pattern index (Single Source of Truth - SSOT).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool loads a static collection of documents (standards, constitution, etc.), implying a non-destructive read operation. However, it does not mention any potential side effects, permissions required, or the exact scope of documents returned. The description is adequate but not comprehensive.
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, well-formed sentence that front-loads the key details: version specifics, the list of documents included, and the SSOT designation. Every part of the sentence adds 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 no parameters and no output schema, the description is fairly complete for a read-only loader. It names the specific version and content areas. However, it could mention that the tool returns a large block of text or references, and could clarify if any filtering is possible (e.g., by revision date). The lack of an output schema reduces the demand on the description, so a 4 is appropriate.
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% (the schema trivially states no properties). The description effectively adds no parameter-level meaning, but since there are no parameters to describe, the baseline is 4 (no compensation needed). The description adds context about what the tool returns, which is relevant.
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 uses a specific verb ('Load') and clearly identifies the resource ('Magento 2.4.8-p5 / PHP 8.3 team standards, constitution, checklist, and pattern index'). It also notes that this is the 'Single Source of Truth - SSOT', distinguishing it from sibling tools like 'search_standards' or 'get_pattern_reference'.
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 this tool is used to retrieve the authoritative standards and index (SSOT), but does not explicitly state when to use it versus siblings like 'search_standards' (for searching) or 'get_pattern_reference' (for specific patterns). There is no guidance on exclusions or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read any markdown documentation file in this spec repository — config/, examples/, README.md, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Repo-relative file path (e.g. config/constitution.md, examples/INDEX.md) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states that the tool reads markdown files, but does not disclose whether it returns raw content, whether it is read-only (should be obvious), what happens on missing paths or invalid paths, any access restrictions, or file size limits. The minimal description leaves the agent without key behavioral expectations beyond the basic action.
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 of ~10 words, front-loaded with the verb and resource. It contains no extraneous information, no repetition of schema details, and every word earns its place. Highly concise for the job it does.
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 read operation with one parameter and no output schema, the description covers the essential purpose and scope. It specifies that it reads markdown documentation files and hints at typical paths. It does not address error handling or output format, but given the low complexity and reliance on schema for parameters, the completeness is adequate. A small improvement would be to mention that it returns the file content.
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% and the schema's 'path' description includes a clear example ('e.g. config/constitution.md, examples/INDEX.md'). The description adds a few more examples ('config/, examples/, README.md, etc.') but does not significantly extend the meaning provided by the schema. Baseline 3 is appropriate.
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 uses a specific verb ('Read') and resource ('markdown documentation file') and clarifies the scope ('in this spec repository'). It also lists example paths ('config/', 'examples/', 'README.md') which aids understanding. The sibling tools have distinct purposes (get team standards, get review gate, etc.), so this tool is clearly differentiated as the general file reader for spec documents.
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 tells what the tool does but provides no explicit guidance on when to use it vs the sibling tools. While the sibling names suggest alternative use cases (standards, review gate, patterns), the description does not state when not to use this tool or direct users to a sibling for related tasks. Usage context is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Magento standards, rules, patterns, and example blueprints by keyword (scans config/ and examples/).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keyword or phrase to search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It communicates that the tool performs a scan (implying read-only, but not explicitly), but does not describe result limits, case sensitivity, partial matching behavior, or performance characteristics. A 3 is appropriate as it adds moderate value but leaves some behavioral gaps.
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, front-loaded sentence that efficiently conveys purpose and scope without any filler. Every word earns its place, making it highly concise and structured.
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 (1 parameter, no output schema, no nested objects, no enums), the description is reasonably complete. It explains what is searched, how (by keyword), and where (config/ and examples/). The only minor gap is lack of detail on search behavior (e.g., exact match vs fuzzy), but for a simple search tool this is acceptable.
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% (the single parameter 'query' has a description: 'Keyword or phrase to search'). The tool description adds no additional parameter meaning beyond what the schema provides, so the baseline of 3 is correct.
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 uses a specific verb ('Search'), identifies the resource ('Magento standards, rules, patterns, and example blueprints'), and clarifies scope ('scans config/ and examples/'). This clearly distinguishes it from sibling tools like get_team_standards or get_pattern_reference, which likely fetch specific items rather than performing a keyword search.
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 'Search... by keyword' and specifies the search domains ('config/ and examples/'), giving clear context for when to use this tool. However, it does not explicitly state when NOT to use it or name alternatives, which would improve the score to a 5.
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.
v1.1.0get_pattern_referenceget_review_gateget_team_standardsread_spec_filesearch_standardsScored across 5 tools
The tools are mostly distinct: get_team_standards, get_review_gate, get_pattern_reference, search_standards, and read_spec_file each target different types of content. However, get_team_standards and get_review_gate could be confused as both relate to standards/checklists, and read_spec_file overlaps with get_pattern_reference since pattern references are spec files.
Tool names follow a consistent verb_noun pattern with 'get_' and 'search_' prefixes, and all use snake_case. The mix of 'get_' (4 tools) and 'search_' (1 tool) is slightly unbalanced but still predictable.
With 5 tools, the server is well-scoped for its purpose of providing Magento documentation access. Each tool serves a distinct retrieval function without unnecessary duplication.
The tool set covers core retrieval operations (load standards, search, read files) but lacks any write or update capabilities. Since the server seems focused on reading spec content, this may be intentional, but the absence of logging or progress-tracking tools is a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Compliance frameworks (SOC 2, ISO 27001, CMMC, NIST, more) delivered to AI agents as MCP tools.
Your memory, everywhere AI goes. Build knowledge once, access it via MCP anywhere.
AI-security knowledge as MCP: standards-mapped tools (OWASP, NIST, MITRE) for AI agents.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
