Which integrations are available for this server?

Provides search and retrieval tools for Magento 2 GraphQL API documentation, including queries, mutations, types, interfaces, code examples, and tutorials for building e-commerce integrations.

How do I use Magento 2 GraphQL Documentation MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Magento 2 GraphQL Documentation MCP Server show me how to create a customer with GraphQL" 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.

Magento 2 GraphQL Documentation MCP Server

by florinel-chis

Overview Schema Related Servers Score Discussions

Python

Local

Magento 2 GraphQL Documentation MCP Server

A local STDIO MCP server that provides tools to search and retrieve Magento 2 GraphQL API documentation from local markdown files.

📖 New to setup? See SETUP.md for a step-by-step quick start guide.

Features

Search Documentation: Full-text search across 350+ GraphQL documentation pages
Get Complete Documents: Retrieve full documentation with metadata
Search GraphQL Elements: Find queries, mutations, types, and interfaces
Get Element Details: View complete schema element definitions with examples
Browse Categories: Navigate documentation hierarchy (schema, develop, usage, tutorials)
Access Tutorials: Get step-by-step learning paths (e.g., checkout workflow)
Search Code Examples: Find working code examples in GraphQL, JSON, JavaScript
Discover Related Docs: Find related documentation automatically
Offline Operation: Works entirely offline using local markdown files
Fast Startup: Only re-indexes if documentation files have changed (<5 seconds)

Related MCP server: GraphQL Schema Explorer

How it Works

Parsing: On startup, the server parses markdown files with YAML frontmatter
Extraction: Extracts metadata, code blocks, and GraphQL schema elements
Indexing: Stores data in SQLite with FTS5 full-text search indexes
Searching: Provides intelligent search across documentation, code, and schema

Quick Start

Step 1: Clone the Documentation Repository

The MCP server requires access to the Adobe Commerce GraphQL documentation markdown files. Clone the official repository:

# Clone the commerce-webapi repository
git clone https://github.com/AdobeDocs/commerce-webapi.git

# The GraphQL docs are located at:
# commerce-webapi/src/pages/graphql/

Step 2: Set Up the Documentation Path

You have two options for configuring the documentation path:

Option A: Using a Symlink (Recommended)

Create a symlink in the project directory:

cd magento-graphql-docs-mcp
ln -s /path/to/commerce-webapi/src/pages/graphql data

Option B: Using Environment Variable

Set the MAGENTO_GRAPHQL_DOCS_PATH environment variable:

export MAGENTO_GRAPHQL_DOCS_PATH="/path/to/commerce-webapi/src/pages/graphql"

To make this permanent, add it to your shell profile (~/.bashrc, ~/.zshrc, etc.):

echo 'export MAGENTO_GRAPHQL_DOCS_PATH="/path/to/commerce-webapi/src/pages/graphql"' >> ~/.zshrc
source ~/.zshrc

Step 3: Verify Documentation Access

Check that the documentation path is accessible:

# If using symlink:
ls -la data/

# If using environment variable:
ls -la $MAGENTO_GRAPHQL_DOCS_PATH/

# You should see files like:
# - index.md
# - release-notes.md
# - schema/ (directory)
# - tutorials/ (directory)
# - develop/ (directory)

Step 4: Install the MCP Server

cd magento-graphql-docs-mcp
pip install -e .

(Optional) Build and Run with Docker

If you prefer Docker, build the image and mount your docs path to /data (or set MAGENTO_GRAPHQL_DOCS_PATH to another location):

docker build -t magento-graphql-docs-mcp -f docker/Dockerfile .
docker run --rm -it \
  -v /absolute/path/to/commerce-webapi/src/pages/graphql:/data \
  magento-graphql-docs-mcp

Auto-fetch fallback: if you do not mount docs, the container can clone them on start. Control this with MAGENTO_GRAPHQL_DOCS_AUTO_FETCH (default: true):

# Let the container clone docs (uses /tmp/commerce-webapi/src/pages/graphql)
docker run --rm -it magento-graphql-docs-mcp

# Disable auto-fetch; require a mount or preset MAGENTO_GRAPHQL_DOCS_PATH
docker run --rm -it \
  -e MAGENTO_GRAPHQL_DOCS_AUTO_FETCH=false \
  -v /absolute/path/to/commerce-webapi/src/pages/graphql:/data \
  magento-graphql-docs-mcp

Host-Side Docker Wrapper (STDIO)

Use the provided wrapper to run the container and forward STDIN/STDOUT for MCP clients (no TTY added):

# From repo root
./run-docker-mcp.sh

What it does:

Builds the magento-graphql-docs-mcp image automatically if it is missing
Mounts MAGENTO_GRAPHQL_DOCS_PATH (or ./data) to /data if it exists; otherwise relies on auto-fetch
Keeps STDIO clean for MCP clients; prints connection instructions on start
Respects MAGENTO_GRAPHQL_DOCS_AUTO_FETCH (set to false to require a mounted path)

Point your MCP client command to the wrapper path. Example Claude Desktop config:

{
  "mcpServers": {
    "magento-graphql-docs": {
      "command": "/absolute/path/to/run-docker-mcp.sh"
    }
  }
}

VS Code MCP Configuration

Example VS Code MCP config using the Docker wrapper:

{
  "servers": {
    "magento-webapi-docs": {
      "type": "stdio",
      "command": "/absolute/path/to/run-docker-mcp.sh"
    }
  }
}

After adding the server entry, open the VS Code MCP/Tools panel and press “Start” for magento-webapi-docs to launch the container-backed STDIO server.

Docker Compose (HTTP/SSE)

Use the provided docker-compose.yml to run the server on HTTP/SSE:

docker compose up --build

This builds from docker/Dockerfile, maps 8765:8765, and sets MAGENTO_GRAPHQL_DOCS_TRANSPORT=http with MAGENTO_GRAPHQL_DOCS_HOST=0.0.0.0. Uncomment the volumes block in docker-compose.yml to bind a local docs checkout; otherwise the image can auto-fetch the docs. Port 8765 is chosen to avoid common 8080 conflicts; adjust as needed.

Step 5: Run and Verify

# Run the server (will parse and index 350 documents on first run)
magento-graphql-docs-mcp

# In another terminal, run verification tests:
python3 tests/verify_parser.py
python3 tests/verify_db.py
python3 tests/verify_server.py

Installation

Requirements

Python 3.10 or higher
Git (to clone the documentation repository)
350+ Magento 2 GraphQL documentation markdown files from AdobeDocs/commerce-webapi

Detailed Setup

1. Clone Both Repositories

# Clone the documentation source
git clone https://github.com/AdobeDocs/commerce-webapi.git

# Clone this MCP server
cd magento-graphql-docs-mcp

2. Configure Documentation Path

The server looks for documentation in this order (with path validation on startup):

Environment variable MAGENTO_GRAPHQL_DOCS_PATH (if set, validates path exists)
./data/ directory (symlink or directory with .md files in project root)
../commerce-webapi/src/pages/graphql/ (sibling directory auto-detection)

If no valid path is found, the server will fail with a helpful error message explaining all three setup options.

Choose the method that works best for your setup:

# Method 1: Symlink (recommended for development)
ln -s ~/projects/commerce-webapi/src/pages/graphql data

# Method 2: Environment variable (recommended for deployment)
export MAGENTO_GRAPHQL_DOCS_PATH="$HOME/projects/commerce-webapi/src/pages/graphql"

# Method 3: Clone commerce-webapi as sibling directory
# magento-graphql-docs-mcp/
# commerce-webapi/
#   └── src/pages/graphql/

3. Install Dependencies

pip install -e .

This installs:

fastmcp - MCP server framework
sqlite-utils - Database management
pydantic - Data validation
python-frontmatter - YAML frontmatter parsing
markdown-it-py - Markdown processing

Usage

Running the Server

Once configured, start the server:

# Start the MCP server
magento-graphql-docs-mcp

# The server will:
# 1. Check if documentation has changed (compares file modification times)
# 2. Parse markdown files if needed (350 files, ~3-5 seconds)
# 3. Index content in SQLite with FTS5
# 4. Start listening for MCP requests over STDIO

On subsequent runs, if the documentation hasn't changed, startup is nearly instant (~0.87s).

Running Over HTTP/SSE

STDIO remains the default. To expose the server via HTTP with SSE (for clients that expect MCP over SSE), set the transport variables:

MAGENTO_GRAPHQL_DOCS_TRANSPORT=http \
MAGENTO_GRAPHQL_DOCS_HOST=0.0.0.0 \
MAGENTO_GRAPHQL_DOCS_PORT=8765 \
magento-graphql-docs-mcp

MAGENTO_GRAPHQL_DOCS_HOST defaults to 127.0.0.1 and MAGENTO_GRAPHQL_DOCS_PORT defaults to 8765 when unset. Port 8765 is frequently used by other services; pick any free port (example above uses the default port 8765).

Configuration

The server uses environment variables for configuration:

Documentation Path

Set where the GraphQL documentation is located:

# Option 1: Absolute path (recommended)
export MAGENTO_GRAPHQL_DOCS_PATH="/Users/you/projects/commerce-webapi/src/pages/graphql"

# Option 2: Relative path (from project root)
export MAGENTO_GRAPHQL_DOCS_PATH="./data"

# Option 3: Home directory relative
export MAGENTO_GRAPHQL_DOCS_PATH="~/repos/commerce-webapi/src/pages/graphql"

Default: The server looks for documentation in these locations (in order, with validation):

MAGENTO_GRAPHQL_DOCS_PATH environment variable (validated on startup)
./data/ directory in project root (must contain .md files)
../commerce-webapi/src/pages/graphql/ (sibling directory auto-detection)

Database Location

Customize where the SQLite database is stored:

# Default: ~/.mcp/magento-graphql-docs/database.db
export MAGENTO_GRAPHQL_DOCS_DB_PATH="/custom/path/magento-graphql.db"

The database directory will be created automatically if it doesn't exist.

Performance Tuning (Optional)

Customize search behavior and limits:

# Number of search results to return (default: 5)
export MAGENTO_GRAPHQL_DOCS_TOP_K=10

# Max fields per GraphQL element (default: 20)
export MAGENTO_GRAPHQL_DOCS_MAX_FIELDS=30

# Max code preview length in characters (default: 400)
export MAGENTO_GRAPHQL_DOCS_CODE_PREVIEW=600

Transport & Port

Control how the MCP server is exposed:

MAGENTO_GRAPHQL_DOCS_TRANSPORT: stdio (default) or http/sse to enable HTTP + SSE
MAGENTO_GRAPHQL_DOCS_HOST: bind address for HTTP/SSE mode (default: 127.0.0.1)
MAGENTO_GRAPHQL_DOCS_PORT: HTTP/SSE port (default: 8765)

FastMCP serves SSE when transport="http".

Using with an MCP Client

Configure your MCP client (e.g., Claude Desktop, Cline, etc.) to use this server.

Example: Claude Desktop Configuration

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):

{
  "mcpServers": {
    "magento-graphql-docs": {
      "command": "magento-graphql-docs-mcp",
      "env": {
        "MAGENTO_GRAPHQL_DOCS_PATH": "/Users/you/projects/commerce-webapi/src/pages/graphql"
      }
    }
  }
}

Example: Using Python Module Directly

{
  "mcpServers": {
    "magento-graphql-docs": {
      "command": "python3",
      "args": ["-m", "magento_graphql_docs_mcp.server"],
      "env": {
        "MAGENTO_GRAPHQL_DOCS_PATH": "/path/to/commerce-webapi/src/pages/graphql"
      }
    }
  }
}

Example: With Custom Database Path

{
  "mcpServers": {
    "magento-graphql-docs": {
      "command": "magento-graphql-docs-mcp",
      "env": {
        "MAGENTO_GRAPHQL_DOCS_PATH": "/path/to/commerce-webapi/src/pages/graphql",
        "MAGENTO_GRAPHQL_DOCS_DB_PATH": "/custom/databases/magento-graphql.db"
      }
    }
  }
}

After configuration, restart your MCP client to activate the server.

Usage Examples

The examples/ directory contains practical usage examples demonstrating all MCP tools:

Available Examples

Product Queries (examples/example_products.py)
- Search product documentation
- Find product GraphQL queries and types
- Explore ProductInterface details
- Search product code examples
Customer Queries (examples/example_customer.py)
- Search customer documentation
- Find customer mutations (create, update)
- Explore authentication and tokens
- Find customer address operations
Cart & Checkout (examples/example_cart_checkout.py)
- Search cart documentation
- Complete checkout workflow tutorial
- Find cart mutations and queries
- Explore checkout step-by-step

Running Examples

# Run individual examples
python3 examples/example_products.py
python3 examples/example_customer.py
python3 examples/example_cart_checkout.py

# Or run all examples at once
bash examples/run_all_examples.sh

See examples/README.md for detailed documentation.

MCP Tools

1. `search_documentation`

Search for documentation pages using keywords.

Parameters:

queries: List of 1-3 short keyword queries (e.g., ["product", "cart"])
category: Optional filter (schema, develop, usage, tutorials)
subcategory: Optional filter (products, cart, customer, etc.)
content_type: Optional filter (guide, reference, tutorial, schema)

Example:

search_documentation(queries=["checkout"], category="tutorials")

2. `get_document`

Get complete documentation page by file path.

Parameters:

file_path: Relative path to document (e.g., "schema/products/queries/products.md")

Returns: Full document content with metadata, frontmatter, and markdown.

3. `search_graphql_elements`

Search for GraphQL queries, mutations, types, or interfaces.

Parameters:

query: Search term
element_type: Optional filter (query, mutation, type, interface, union)

Example:

search_graphql_elements(query="products", element_type="query")

4. `get_element_details`

Get complete details about a specific GraphQL element.

Parameters:

element_name: Element name (e.g., "products", "createCustomer")
element_type: Optional type filter

Returns: Full element definition with fields, parameters, source document, and code examples.

5. `list_categories`

List all documentation categories with document counts.

Returns: Hierarchical category tree showing all available documentation areas.

6. `get_tutorial`

Get complete tutorial with all steps in order.

Parameters:

tutorial_name: Tutorial name (e.g., "checkout")

Returns: Sequential tutorial steps with code examples and explanations.

7. `search_examples`

Search for code examples by topic and language.

Parameters:

query: Search term
language: Optional language filter (graphql, json, javascript, php, bash)

Example:

search_examples(query="add to cart", language="graphql")

8. `get_related_documents`

Find documents related to a specified document.

Parameters:

file_path: File path of source document

Returns: Related documents based on category and keywords.

Verification Scripts

Test each component independently.

Important: Run all tests from the project root directory:

# Navigate to project root
cd magento-graphql-docs-mcp

# Test the markdown parser
python3 tests/verify_parser.py

# Test database ingestion
python3 tests/verify_db.py

# Test MCP server and all 8 tools
python3 tests/verify_server.py

# Run performance benchmarks
python3 tests/benchmark_performance.py

Running tests from other directories will cause import errors.

Database Schema

The server uses SQLite with the following tables:

documents: All documentation pages with FTS5 index
code_blocks: Code examples from documentation
graphql_elements: Extracted GraphQL schema elements with FTS5 index
metadata: Ingestion tracking

Performance

Based on benchmarks (run python3 tests/benchmark_performance.py):

Startup Time: 0.87s (when data unchanged) | 3-5s (first run or files changed)
Search Speed: 5.5ms average (FTS5 direct: 0.7ms)
Document Retrieval: 8.2ms
GraphQL Element Search: 3.4ms
Database Size: ~30 MB for 350 documents
Indexed Content: 350 documents, 963 code blocks, 51 GraphQL elements

All performance targets exceeded: <5s startup ✓, <100ms searches ✓

Example Queries

Query	Tool	Result
"How do I query products?"	search_documentation	Product query documentation
"Show me product query details"	search_graphql_elements	products query definition
"Complete checkout flow"	get_tutorial	Step-by-step checkout guide
"Cart mutation examples"	search_examples	Working GraphQL cart examples
"All B2B documentation"	list_categories + search	B2B schema documentation

Development

Project Structure

magento-graphql-docs-mcp/
├── magento_graphql_docs_mcp/
│   ├── __init__.py
│   ├── config.py          # Configuration
│   ├── parser.py          # Markdown + GraphQL parser
│   ├── ingest.py          # Database ingestion
│   └── server.py          # MCP server with 8 tools
├── tests/
│   ├── verify_parser.py   # Parser verification
│   ├── verify_db.py       # Database verification
│   └── verify_server.py   # Server verification
├── data/
│   └── (symlink to docs)
├── pyproject.toml
├── README.md
└── CLAUDE.md

Architecture

Markdown Files (350)
    ↓
Parser (frontmatter + content + GraphQL extraction)
    ↓
SQLite (documents + code_blocks + graphql_elements + FTS5)
    ↓
FastMCP Server (8 tools via STDIO)
    ↓
MCP Client (Claude, IDE, etc.)

Advantages

vs Web Scraping

✅ Offline operation (no network required)
✅ Fast startup (3-5s vs 30-60s)
✅ Local control (works with custom docs)
✅ No HTML parsing complexity

vs REST API MCP

✅ Includes tutorials and guides (not just API specs)
✅ Code examples searchable
✅ Narrative content for learning
✅ Tutorial workflows

Unique Features

📚 350 documents indexed
🔍 8 specialized search tools
💡 Tutorial support
📝 Code example search
🔗 Related document discovery
⚡ Fast FTS5 search
🎯 GraphQL-aware parsing

Troubleshooting

Documentation Not Found Error

Error: FileNotFoundError: Documentation directory not found!

The server now provides a helpful error message showing all three setup methods.

Solutions:

Verify the documentation repository is cloned:

git clone https://github.com/AdobeDocs/commerce-webapi.git

Check the path is correct:

# If using environment variable:
echo $MAGENTO_GRAPHQL_DOCS_PATH
ls -la $MAGENTO_GRAPHQL_DOCS_PATH

# If using symlink:
ls -la data/
# Should show a symlink pointing to the GraphQL docs

# You should see 350+ markdown files and directories like:
# - schema/
# - tutorials/
# - develop/
# - index.md

Set the correct path (choose one method):

# Method 1: Environment variable (recommended for deployment)
export MAGENTO_GRAPHQL_DOCS_PATH="/path/to/commerce-webapi/src/pages/graphql"

# Method 2: Create symlink (recommended for development)
cd magento-graphql-docs-mcp
ln -s /path/to/commerce-webapi/src/pages/graphql data
# Verify: ls -la data/ should show the symlink

# Method 3: Clone as sibling directory (automatic)
cd parent-directory
git clone https://github.com/AdobeDocs/commerce-webapi.git
# Server will automatically find it

Verify the setup:

# The server validates paths on startup and will show helpful errors
magento-graphql-docs-mcp
# If path is invalid, you'll see exactly which methods were tried

Server Won't Start

Error: ModuleNotFoundError: No module named 'magento_graphql_docs_mcp'

Solution: Install the package in development mode:

cd magento-graphql-docs-mcp
pip install -e .

Error: Server starts but immediately exits

Solution: Check Python version (requires 3.10+):

python3 --version  # Should be 3.10 or higher

No Search Results

Issue: Search returns no results even though documentation exists

Solutions:

Use shorter, simpler keywords:

# Instead of: "customer authentication token generation"
# Try: ["customer", "token"]

# Instead of: "how to add products to cart"
# Try: ["cart", "add"]

Check if database was created:

ls -la ~/.mcp/magento-graphql-docs/
# Should show database.db (around 30 MB)

Verify data was indexed:

python3 tests/verify_db.py
# Should show: 350 documents, 963 code blocks, 51 GraphQL elements

Re-index the database:

rm ~/.mcp/magento-graphql-docs/database.db
magento-graphql-docs-mcp  # Will parse and re-index everything

Database Errors

Error: sqlite3.OperationalError: database is locked

Solution: Another process is using the database:

# Find and kill the process
lsof ~/.mcp/magento-graphql-docs/database.db
kill <PID>

# Or simply remove and recreate
rm ~/.mcp/magento-graphql-docs/database.db
magento-graphql-docs-mcp

Error: sqlite3.DatabaseError: database disk image is malformed

Solution: Database is corrupted, recreate it:

rm -rf ~/.mcp/magento-graphql-docs/
magento-graphql-docs-mcp  # Will recreate from scratch

Slow Performance

Issue: First startup takes >10 seconds

Solution: This is normal! First run parses 350 files. Subsequent runs are <1s.

Issue: Every startup is slow

Solution: Documentation mtime is changing. Check:

# Verify git isn't changing file times
cd /path/to/commerce-webapi
git status
git pull  # Update to latest if needed

Verification Failed

Issue: verify_server.py fails with connection errors

Solution:

# Ensure dependencies are installed
pip install -e ".[dev]"

# Check MCP client libraries
pip list | grep mcp

# Re-run individual verifications
python3 tests/verify_parser.py   # Test parsing
python3 tests/verify_db.py       # Test database
python3 tests/verify_server.py   # Test MCP server

MCP Client Integration Issues

Issue: MCP client shows "Server not found" or "Connection failed"

Solutions:

Verify command is correct:

# Test the command directly
which magento-graphql-docs-mcp
# or
python3 -m magento_graphql_docs_mcp.server

Check environment variables in MCP config:

{
  "mcpServers": {
    "magento-graphql-docs": {
      "command": "magento-graphql-docs-mcp",
      "env": {
        "MAGENTO_GRAPHQL_DOCS_PATH": "/FULL/PATH/to/commerce-webapi/src/pages/graphql"
      }
    }
  }
}

Important: Use absolute paths, not ~ or relative paths in MCP config.

Check logs:
- Claude Desktop: ~/Library/Logs/Claude/ (macOS)
- Look for error messages related to the server

Getting Help

If you're still having issues:

Run all verification scripts:

python3 tests/verify_parser.py
python3 tests/verify_db.py
python3 tests/verify_server.py
python3 tests/benchmark_performance.py

Check your setup:

# Python version
python3 --version

# Documentation path
echo $MAGENTO_GRAPHQL_DOCS_PATH
ls -la $MAGENTO_GRAPHQL_DOCS_PATH | head -20

# Database
ls -la ~/.mcp/magento-graphql-docs/

# Package installation
pip show magento-graphql-docs-mcp

Create a GitHub issue with the output of the above commands.

License

MIT

Contributing

Contributions welcome! Please test all changes with verification scripts before submitting.

Support

For issues or questions:

Run verification scripts to diagnose issues
Check database location and permissions
Verify documentation path is correct

Available Tools

8 tools

get_documentB

Retrieve complete documentation page by file path

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes	File path relative to docs root, e.g., 'schema/products/queries/products.md'

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the operation ('Retrieve') but does not clarify that it is read-only, what happens if the path is invalid, or any side effects. The description is too minimal to adequately inform an agent of behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the verb and resource. It contains no unnecessary words or information, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool has only one parameter, a clear schema description, and an output schema (which obviates the need to describe return values), the description is adequate but minimal. It does not mention error handling, format of the returned page, or any prerequisites. For a straightforward tool, it meets the minimum viable bar but lacks completeness for unexpected scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (the single parameter has a detailed description). The tool's description adds the phrase 'by file path,' which is already implied by the parameter name and schema. Since the schema already explains the parameter meaning, the description provides no additional semantic value, resulting in a baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Retrieve') and resource ('complete documentation page') along with the input ('by file path'). It clearly distinguishes from sibling tools like 'search_documentation' (which searches) and 'get_element_details' (which retrieves a specific element, not a full page).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. It implies usage when the file path is known, but lacks context about when to prefer search over direct retrieval.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_element_detailsA

Get complete details about a specific GraphQL element

ParametersJSON Schema

Name	Required	Description	Default
`element_name`	Yes	Element name, e.g., 'products', 'createCustomer', 'ProductInterface'
`element_type`	No	Optional type filter: query, mutation, type, interface

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description does not mention any behavioral traits such as side effects, auth requirements, or rate limits, leaving the agent with minimal safety context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no superfluous words, effectively conveying the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and clear tool name, the description is fairly complete, though specifying what 'complete details' includes would be marginally better.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers 100% of parameters with descriptions; the description adds no extra meaning beyond the schema, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states retrieving complete details about a specific GraphQL element, which distinguishes it from sibling tools like get_document or search_graphql_elements.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for GraphQL element details but offers no explicit guidance on when to use this tool versus alternatives like search_graphql_elements.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_related_documentsB

Find documents related to the specified document

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	Yes	File path of source document

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fails to disclose any behavioral traits. It does not indicate whether the operation is read-only, whether there are side effects, or any rate limits. The output schema exists but is not referenced in the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that directly states the tool's function. It is front-loaded and concise, with no wasted words. However, it could be slightly expanded to include more context without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, output schema present), the description is mostly complete. It explains the purpose and the parameter sufficiently. The existence of an output schema compensates for the lack of return value detail in the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with the parameter file_path having a clear description. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: finding documents related to a given document. It uses a specific verb ('Find') and resource ('documents related to the specified document'). However, it lacks differentiation from sibling tools like get_document or search_documentation, leaving the concept of 'related' somewhat ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 such as get_document (for a single document) or search_documentation (for keyword-based search). 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_tutorialB

Get complete tutorial with all steps in order

ParametersJSON Schema

Name	Required	Description	Default
`tutorial_name`	Yes	Tutorial name, e.g., 'checkout'

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must convey behavior. It only states the result content ('with all steps in order') but omits any behavioral traits like side effects, authentication needs, rate limits, or how the output is structured.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence that is efficient and focused. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite low complexity and presence of an output schema, the description lacks usage context and behavioral details. It does not differentiate from siblings or explain the tool's role in a workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds no further detail about the 'tutorial_name' parameter beyond what the schema provides (name and example).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'complete tutorial with all steps in order', making the tool's purpose explicit. It is specific enough to distinguish from siblings like 'get_document' or 'search_documentation'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. The description does not mention conditions, exclusions, or related sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_categoriesA

List all documentation categories with document counts

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It indicates a read-only listing operation, which is sufficient for this simple case. No details on ordering or pagination are given, but none are needed given no parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is concise and front-loaded with the key action and resource. Every word is meaningful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, output schema present), the description is complete. It covers what the tool does and what it returns (categories with counts).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, so the baseline is 4. The description adds value by specifying that document counts are included, which is not evident from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List') and the resource ('all documentation categories') with an additional detail ('with document counts'), which differentiates it from sibling tools that focus on documents, elements, or searches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. However, the context signals and sibling names imply this is for listing categories, while other tools handle specific document or element retrieval.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_documentationA

Search Magento 2 GraphQL documentation by keywords. Use SHORT keyword queries (1-3 words) to find documentation pages. Can filter by category, subcategory, or content type.

ParametersJSON Schema

Name	Required	Description
`queries`	Yes	List of 1-3 short keyword queries. Examples: ['product', 'cart'], ['checkout']
`category`	No	Filter by category: schema, develop, usage, tutorials, payment-methods
`subcategory`	No	Filter by subcategory: products, cart, customer, checkout, etc.
`content_type`	No	Filter by content type: guide, reference, tutorial, schema

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the ability to filter and the keyword length constraint, but does not explain return format, performance, or other behavioral traits. Given the existence of an output schema, 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short sentences with no filler, front-loaded with the core purpose. Every sentence adds essential information, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 4-parameter schema and output schema, the description covers the main functionality, search scope, query constraints, and filters. It lacks details on result sorting or case sensitivity, but is largely complete for an agent to use effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by specifying the use of short queries (1-3 words) and explicitly mentioning filtering by category, subcategory, and content type, which goes beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches Magento 2 GraphQL documentation by keywords, distinguishing it from sibling tools like search_graphql_elements and search_examples. The verb 'search' and resource 'documentation' are specific, and the mention of short keywords adds further clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises using short keyword queries (1-3 words), which guides effective usage. However, it does not explicitly contrast with alternatives or state when not to use the tool, so it lacks full exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_examplesC

Search for code examples by topic and language

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search term for code examples
`language`	No	Filter by language: graphql, json, javascript, php, bash

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries burden. It only paraphrases the schema (search by topic and language) and adds no behavioral traits (e.g., result format, pagination, authentication needs). The output schema exists but is not referenced.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no unnecessary words. It is appropriately short for a simple search tool, though additional structure (e.g., bullet points) could improve readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only 2 parameters and an output schema, the description is minimally adequate. It does not explain query syntax, language filter values (though schema has enum), or result handling, leaving gaps for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters. The description adds 'by topic and language' but does not elaborate beyond schema, meeting baseline expectation for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool searches for code examples by topic and language. It distinguishes from sibling tools like search_documentation by specifying 'code examples', though not explicitly contrasting them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 alternative search tools (search_documentation, search_graphql_elements). The description implies usage context but does not provide when-to-use or when-not-to-use criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_graphql_elementsB

Search for GraphQL queries, mutations, types, or interfaces

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search term, e.g., 'products', 'cart', 'customer'
`element_type`	No	Filter by element type: query, mutation, type, interface, union

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits, but it only states the search action. It omits details like read-only behavior, result limits, error handling, or required permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single clear sentence with no redundant wording, making it very concise and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple search tool with a full input schema and an output schema, the description is adequate but minimal. It does not cover edge cases or further behavior, leaving some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters. The tool description adds no extra semantic value beyond the schema, meeting the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Search' and the specific resource 'GraphQL queries, mutations, types, or interfaces'. This differentiates it from sibling tools like search_documentation and search_examples.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 over alternatives. It does not mention scenarios where it is appropriate or inappropriate, nor does it reference sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool has a distinct purpose: retrieving documents by path, element details, related documents, tutorials, categories, and different search types. No overlap.

Naming Consistency5/5

All tools use consistent lowercase with underscores and follow a verb_noun pattern (get_, list_, search_), with predictable naming.

Tool Count5/5

8 tools is well-suited for a documentation server, covering all essential operations without excess or deficiency.

Completeness5/5

The tool set provides comprehensive coverage for documentation access: direct retrieval, tutorials, categories, and multiple search modes (keywords, examples, elements).

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Devdocs Io B
io.github.pipeworx-io
DevDocs.io keyless docs index + entry search + content (Angular, MDN, Rust, etc.).
Documentation Access Search Developer Tools
383
renCosta2025-context7fork
ai.smithery
Get up-to-date, version-specific documentation and code examples from official sources directly in…
Documentation Access Developer Tools Search
2
developer-tools A
goog.workspace-developer
Provides tools for searching Google Workspace documentation and much more.
Developer Tools Documentation Access Search
22
ATProto Data Layer A
dev.workers.filae.atproto-mcp
Search ATProto writing, annotations, identity, agents, and forum posts. 12 read-only tools.
Search Social Media Web3 & Decentralized Tech
2

Related MCP Servers

GitHub GraphQL API MCP
Version Control Developer Tools Search
MCP-Mirror
F
license
Not graded
quality
Not graded
maintenance
Enables querying and exploring the GitHub GraphQL API schema and executing optimized GraphQL queries to retrieve precise GitHub data (repositories, issues, PRs, users) with reduced token consumption.
Updated a year ago (2025-06-25 18:53 UTC)
GraphQL Schema Explorer
Developer Tools API Testing Documentation Access
martinshumberto
F
license
Not graded
quality
D
maintenance
Provides intelligent introspection and exploration of any GraphQL API schema with fuzzy search, type discovery, and field-level information to help understand and navigate GraphQL APIs.
Updated a year ago (2025-06-26 14:55 UTC)
magento-api-mcp
E-commerce & Retail Documentation Access
florinel-chis
F
license
A
quality
D
maintenance
Enables searching and retrieving Magento 2 REST API documentation offline via local OpenAPI parsing, supporting endpoint search, schema lookup, and category browsing.
Updated 10 months ago (2025-11-03 18:04 UTC)
5
7
expo-docs
Documentation Access Developer Tools
Ception
A
license
Not graded
quality
C
maintenance
Enables fast, offline search and retrieval of Expo documentation from local .mdx files, with tools for searching, getting content, listing sections, API references, and quick start guides.
Updated 6 months ago (2026-03-06 03:43 UTC)
191
17
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/florinel-chis/magento-graphql-docs-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Magento 2 GraphQL Documentation MCP Server

Features

How it Works

Quick Start

Step 1: Clone the Documentation Repository

Step 2: Set Up the Documentation Path

Step 3: Verify Documentation Access

Step 4: Install the MCP Server

(Optional) Build and Run with Docker

Host-Side Docker Wrapper (STDIO)

VS Code MCP Configuration

Docker Compose (HTTP/SSE)

Step 5: Run and Verify

Installation

Requirements

Detailed Setup

1. Clone Both Repositories

2. Configure Documentation Path

3. Install Dependencies

Usage

Running the Server

Running Over HTTP/SSE

Configuration

Documentation Path

Database Location

Performance Tuning (Optional)

Transport & Port

Using with an MCP Client

Example: Claude Desktop Configuration

Example: Using Python Module Directly

Example: With Custom Database Path

Usage Examples

Available Examples

Running Examples

MCP Tools

1. search_documentation

2. get_document

3. search_graphql_elements

4. get_element_details

5. list_categories

6. get_tutorial

7. search_examples

8. get_related_documents

Verification Scripts

Database Schema

Performance

Example Queries

Development

Project Structure

Architecture

Advantages

vs Web Scraping

vs REST API MCP

Unique Features

Troubleshooting

Documentation Not Found Error

Server Won't Start

No Search Results

Database Errors

Slow Performance

Verification Failed

MCP Client Integration Issues

Getting Help

License

Contributing

Support

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

1. `search_documentation`

2. `get_document`

3. `search_graphql_elements`

4. `get_element_details`

5. `list_categories`

6. `get_tutorial`

7. `search_examples`

8. `get_related_documents`