Which integrations are available for this server?

Provides tools to interact with Drupal 10+ sites via the JSON:API, allowing for content querying, searching across all content types, and retrieving detailed node information including relationships.

How do I use Drupal 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., "@Drupal MCP Server search for content with 'tutorial' in the title" 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.

Drupal MCP Server

by peximo

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Drupal MCP Server

A Model Context Protocol (MCP) server that enables Claude to interact with Drupal 10+ sites via JSON:API. This server allows Claude to query, search, and retrieve content from your Drupal installation.

Features

Query Content: Search and filter nodes by content type with flexible options
Get Node Details: Retrieve complete node information including relationships
List Content Types: Discover all available content types on your site
Search Across Types: Search for content across all content types by title

Related MCP server: optimizely-cms-mcp

Prerequisites

Node.js 18+ and npm
TypeScript 5+
A Drupal 10+ site with JSON:API enabled (enabled by default)
Valid Drupal credentials (username/password or OAuth token)

Installation

# Clone or create the project directory
mkdir drupal-mcp-server
cd drupal-mcp-server

# Initialize and install dependencies
npm init -y
npm install @modelcontextprotocol/sdk axios
npm install -D typescript @types/node

Project Structure

drupal-mcp-server/
├── src/
│   ├── index.ts          # Main MCP server
│   ├── drupal-client.ts  # Drupal API client
│   └── types.ts          # TypeScript type definitions
├── dist/                 # Compiled JavaScript (generated)
├── package.json
└── tsconfig.json

Building

# Compile TypeScript
npm run build

# Watch mode (optional)
npm run watch

The compiled JavaScript files will be output to the dist/ directory.

Configuration

For Claude Desktop

Edit your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json

Add the following configuration:

{
  "mcpServers": {
    "drupal": {
      "command": "node",
      "args": ["/absolute/path/to/drupal-mcp-server/dist/index.js"],
      "env": {
        "DRUPAL_BASE_URL": "https://your-drupal-site.com",
        "DRUPAL_USERNAME": "your-username",
        "DRUPAL_PASSWORD": "your-password"
      }
    }
  }
}

Note: Replace /absolute/path/to/drupal-mcp-server with the actual path on your system. Use pwd in the project directory to get the full path.

For Cline (VS Code)

Add to your VS Code settings.json:

{
  "cline.mcpServers": {
    "drupal": {
      "command": "node",
      "args": ["/absolute/path/to/drupal-mcp-server/dist/index.js"],
      "env": {
        "DRUPAL_BASE_URL": "https://your-drupal-site.com",
        "DRUPAL_USERNAME": "your-username",
        "DRUPAL_PASSWORD": "your-password"
      }
    }
  }
}

Environment Variables

DRUPAL_BASE_URL (required): Your Drupal site URL
DRUPAL_USERNAME (optional): Basic auth username
DRUPAL_PASSWORD (optional): Basic auth password
DRUPAL_ACCESS_TOKEN (optional): OAuth access token (alternative to username/password)

Testing

Manual Server Test

Test the server directly from the command line:

cd /path/to/drupal-mcp-server

DRUPAL_BASE_URL="https://your-site.com" \
DRUPAL_USERNAME="admin" \
DRUPAL_PASSWORD="password" \
node dist/index.js

You should see:

Drupal MCP Server running
Connected to: https://your-site.com

Press Ctrl+C to stop.

Test Connection to Drupal

Verify your Drupal site is accessible:

curl -I https://your-site.com/jsonapi

Should return a 200 OK status.

Testing in Claude Desktop

Restart Claude Desktop after updating the configuration
Look for the 🔌 icon at the bottom of the interface
Click it to see connected MCP servers
Start a new conversation and try:

What tools do you have available?

Example Queries

List content types:

List all available content types on my Drupal site

Query content:

Show me 5 published articles

Search content:

Search for content with "tutorial" in the title

Get node details:

Get the full details of node [UUID]

Complex query:

1. List all content types
2. Find 3 articles
3. Show me the complete details of the first article

Available Tools

`query_content`

Search and filter Drupal content by type.

Parameters:

contentType (required): Machine name of the content type (e.g., "article", "page")
limit (optional): Maximum results to return (default: 10)
title (optional): Filter by title (partial match)
status (optional): Filter by publication status (true/false)

`get_node`

Retrieve complete details of a specific node.

Parameters:

nodeId (required): UUID or numeric ID of the node
include (optional): Array of related entities to include (e.g., ["field_image", "uid"])

`list_content_types`

List all available content types on the site.

Parameters: None

`search_content`

Search across all content types by title.

Parameters:

searchTerm (required): Text to search for in titles
limit (optional): Maximum results (default: 10)

Troubleshooting

"Server disconnected" error

Check that the server starts manually
Verify the path in the configuration is absolute

Check Claude Desktop logs:

# macOS
tail -f ~/Library/Logs/Claude/mcp*.log

SSL Certificate errors (DDEV/local development)

If using self-signed certificates, the server automatically disables certificate verification for local development.

Permission errors

Ensure your Drupal user has permission to access JSON:API endpoints. The "View published content" permission is usually sufficient for read operations.

JSON:API not enabled

JSON:API is enabled by default in Drupal 10+. If you get 404 errors, verify it's enabled at: /admin/modules → Search for "JSON:API"

Development

Adding new tools

Define the tool schema in TOOLS array in src/index.ts
Implement the handler in the CallToolRequestSchema switch statement
Add any new methods to DrupalClient class as needed
Rebuild: npm run build

Extending functionality

Potential enhancements:

Create/update content (POST/PATCH requests)
Manage taxonomy terms
Query users
Execute Views
Upload media/files
Manage menus

License

MIT

Contributing

Contributions are welcome! Please feel free to submit issues or pull requests.

Available Tools

4 tools

get_nodeB

Retrieve complete details of a specific Drupal node by its ID

ParametersJSON Schema

Name	Required	Description
`nodeType`	Yes	The machine name of the content type (e.g., "article", "page", "blog_post")
`nodeId`	Yes	The UUID or numeric ID of the node
`include`	No	Related entities to include (e.g., ["field_image", "uid"] to include image and author)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. States 'complete details' but doesn't clarify what is included by default, error behavior if node doesn't exist, authentication requirements, or whether this operation is read-only and safe (though implied by 'Retrieve').

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 10-word sentence that front-loads the verb. No redundancy or filler. Efficiently conveys core purpose without waste.

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?

Adequate for a simple retrieval tool with well-documented schema, but gaps remain: no output schema means description should hint at return structure (fields, revisions), and complete absence of behavioral annotations leaves agent without safety/permission context.

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?

With 100% schema coverage, baseline is 3. Description mentions 'by its ID' which maps to nodeId, but adds no semantic context for nodeType expectations or the include parameter's relationship to field API names beyond what the schema already provides.

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?

States specific action (Retrieve) and resource (Drupal node details) with clear scope (specific node by ID). Implicitly distinguishes from siblings via 'specific' and 'by its ID' versus query/search operations, though explicit differentiation is absent.

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?

Provides no guidance on when to use this tool versus alternatives like query_content or search_content. Does not mention prerequisites (e.g., needing the node ID from prior search) or when to prefer listing content types first.

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

list_content_typesB

List all available content types on the Drupal site

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided. While 'List' implies read-only, the description omits what constitutes a content type (machine name, label, fields), response structure, pagination behavior, or caching characteristics. Carries full disclosure burden but provides minimal behavioral 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 of 9 words. Front-loaded with action verb. No redundancy or filler. Perfectly efficient for a zero-parameter tool.

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?

Adequate for a simple discovery tool, but lacks description of return values given no output schema exists. Should mention what properties define a content type (e.g., machine name, human-readable label) to set expectations.

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?

Zero parameters exist (empty schema). With 100% schema coverage vacuously satisfied and no parameters requiring semantic explanation, this meets the baseline expectation.

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?

States specific verb (List)andresource(content types) with scope (Drupal site). The term 'content types'implicitly distinguishes from siblings (get_node, query_content, search_content) which operate on content instances,though it doesn't explicitly clarify this distinction.

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 provided on when to use this versus siblings. Does not mention typical use cases (e.g., discovering available types before creating content) or prerequisites.

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

query_contentB

Search and filter Drupal content by type. Returns a list of nodes matching the criteria.

ParametersJSON Schema

Name	Required	Description
`contentType`	Yes	The machine name of the content type (e.g., "article", "page", "blog_post")
`limit`	No	Maximum number of results to return (default: 10)
`title`	No	Filter by title (partial match)
`status`	No	Filter by publication status (true = published, false = unpublished)

TDQS

B3.3/5.0

Behavior3/5

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 the return value ('list of nodes') but omits safety confirmations (read-only status), pagination behavior beyond the limit parameter, and error handling for invalid content types.

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?

Two efficient sentences with zero waste. The first sentence front-loads the purpose, while the second explains the return value—essential information given the absence of an output schema.

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?

Adequate for a 4-parameter query tool with full schema coverage, but gaps remain. The description fails to clarify the relationship to 'search_content' (likely full-text vs structured filtering) and assumes familiarity with Drupal 'nodes' without context.

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%, establishing a baseline of 3. The description mentions filtering 'by type' which aligns with the contentType parameter, but adds no semantic detail for the title, status, or limit parameters beyond what the schema already provides.

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?

Clear verb+resource ('Search and filter Drupal content') and specifies the filtering dimension ('by type'). However, it does not explicitly differentiate from sibling tool 'search_content', leaving ambiguity about when to choose this over alternatives.

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?

Provides no guidance on when to use this tool versus siblings ('search_content', 'get_node', 'list_content_types'). No prerequisites, exclusions, or workflow context is mentioned.

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

search_contentA

Search across all content types by title. Useful when you don't know the specific content type.

ParametersJSON Schema

Name	Required	Description	Default
`searchTerm`	Yes	The text to search for in content titles
`limit`	No	Maximum number of results (default: 10)

TDQS

A3.9/5.0

Behavior3/5

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 the search is limited to titles ('by title'), which is a key behavioral constraint. However, it lacks details on case sensitivity, fuzzy matching, or what the return structure contains.

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?

Two sentences, zero waste. First sentence defines functionality, second provides usage context. Appropriately front-loaded and sized.

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?

Lacks output schema and description does not hint at return format (IDs, full objects, etc.), which is important for an agent to know whether subsequent calls to get_node are needed. Parameters are fully covered by schema.

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% (both searchTerm and limit have descriptions), so the baseline score applies. The description does not add significant parameter semantics beyond what the schema already documents, though it reinforces that searchTerm applies to titles.

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 provides specific verb (search), resource (content), and scope (by title, across all types). It effectively distinguishes from siblings by emphasizing 'across all content types' and the condition 'when you don't know the specific content type', positioning it against query_content.

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?

Provides clear when-to-use guidance ('when you don't know the specific content type'), implicitly distinguishing it from query_content. However, it does not explicitly name the alternative tool or state negative conditions (when not to use).

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

B3.2/5.0

Disambiguation3/5

There is some overlap between query_content and search_content, as both involve searching for content, though their descriptions clarify that query_content filters by type while search_content searches by title across all types. get_node and list_content_types are distinct, but the two search tools could cause confusion without careful reading of descriptions.

Naming Consistency4/5

Tool names follow a consistent verb_noun pattern (get_node, list_content_types, query_content, search_content), with clear and readable conventions. There are no deviations in style, making them predictable and easy to understand.

Tool Count3/5

With only 4 tools, the set feels thin for a Drupal content management server, lacking essential CRUD operations like create, update, or delete nodes. While the tools cover basic retrieval and listing, the scope seems incomplete for typical content management workflows.

Completeness2/5

The tool surface is significantly incomplete for a Drupal content management domain. It includes retrieval and search functions but lacks any create, update, or delete operations, which are core to content lifecycle management. This gap will likely cause agent failures when trying to perform full content management tasks.

Maintenance

ActivityInactive

ResponsivenessSyncing

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

ProWebStore
io.github.prowebstore-online
AI-operated knowledge-graph CMS for business websites: entities, pages, blocks, media, domains.
Knowledge & Memory
1
Brainiall Web A
com.brainiall
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
Browser Automation Web Scraping
51
StewAI
com.stewai
Discover, preview, estimate, run, and retrieve reusable AI workflows.
AI & Machine Learning Autonomous Agents
1
Remly
it.remly
Search and retrieve permission-aware knowledge from connected sources through Remly.
RAG Systems Search
1

Related MCP Servers

Strapi Content MCP
Content Management Systems Developer Tools
PaulBratslavsky
A
license
Not graded
quality
D
maintenance
Enables AI assistants to interact directly with Strapi v5 CMS content through full CRUD operations, media uploads, and content type exploration using Strapi's Document Service API.
Updated 8 months ago (2026-01-05 06:43 UTC)
201
1
MIT
optimizely-cms-mcp
Content Management Systems Search
first3things
A
license
Not graded
quality
D
maintenance
Enables AI assistants to interact with Optimizely CMS via its GraphQL and Content Management APIs, supporting dynamic content discovery, retrieval, and management.
Updated a year ago (2025-10-13 10:50 UTC)
11
6
MIT
Axolot MCP Serverofficial
Content Management Systems Design Tools
AxolotDevelopment
A
license
Not graded
quality
D
maintenance
Enables AI assistants to interact with Axolot CMS for content, design tokens, media, and module management with site context awareness.
Updated 3 months ago (2026-05-29 14:33 UTC)
31
MIT
Kontent.ai MCP Serverofficial
Content Management Systems Developer Tools
kontent-ai
A
license
Not graded
quality
A
maintenance
Enables AI tools to manage Kontent.ai content through natural language, supporting content types, items, assets, workflows, and more.
Updated 3 hours ago (2026-09-03 14:13 UTC)
189
9
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/peximo/drupal-mcp-server'

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

Drupal MCP Server

Features

Prerequisites

Installation

Project Structure

Building

Configuration

For Claude Desktop

For Cline (VS Code)

Environment Variables

Testing

Manual Server Test

Test Connection to Drupal

Testing in Claude Desktop

Example Queries

Available Tools

query_content

get_node

list_content_types

search_content

Troubleshooting

"Server disconnected" error

SSL Certificate errors (DDEV/local development)

Permission errors

JSON:API not enabled

Development

Adding new tools

Extending functionality

License

Contributing

Available Tools

TDQS

TDQS

TDQS

TDQS

TDQS

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Strapi Content MCP

optimizely-cms-mcp

Axolot MCP Serverofficial

Kontent.ai MCP Serverofficial

Latest Blog Posts

MCP directory API

`query_content`

`get_node`

`list_content_types`

`search_content`