Which integrations are available for this server?

Allows interaction with Drupal sites via JSON:API, enabling listing, searching, creating, updating, and deleting nodes, taxonomy terms, and users.

How do I use drupal-mcp?

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 list recent articles" 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.

de en es ja ko ru zh

drupal-mcp

by lucaspretti

Overview Schema Related Servers Score Discussions

JavaScript

Remote

drupal-mcp

MCP server for Drupal sites via the core JSON:API. List, search, create, update, and delete nodes / taxonomy terms / users on any Drupal 10/11 site with the jsonapi module enabled.

Works two ways:

Claude Code plugin — install via the lucaspretti-plugins marketplace and Claude prompts you for the env vars.
Standalone MCP — node drupal-mcp.js with env vars set. Plug into Claude Desktop, Cline, or any other MCP-compatible client.

Why JSON:API and not the older Drupal MCP module?

The contrib drupal/mcp module currently has ~250 installs and is in flux ("merging with the MCP Server module"). JSON:API is in Drupal core, stable, and standard. This server is a thin wrapper around endpoints your site already exposes — no new module to maintain on the Drupal side.

Related MCP server: WordPress MCP Python

Drupal-side setup (one-time)

Required modules

drush en jsonapi serialization basic_auth -y

jsonapi — exposes /jsonapi/* endpoints. Core module.
serialization — JSON:API dependency. Core module.
basic_auth — required for Authorization: Basic header authentication. Core module, not enabled by default. Without it, only anonymous reads work; every write returns 401.

JSON:API writes

By default JSON:API is read-only. If you need create / update / delete, flip the switch:

drush config:set jsonapi.settings read_only false -y

Or in config/sync/jsonapi.settings.yml (CMI-managed sites):

read_only: false

Keep read_only: true for read-only deployments — the plugin still works for drupal_list_* / drupal_get_node / drupal_query_jsonapi.

Bot role + user

Two patterns, pick one based on how much you trust the bot:

A) Admin role (simplest, recommended for full-access bots). Setting is_admin: true bypasses every permission check, same as the default administrator role. The single setting + a strong password gates all access.

langcode: en
status: true
dependencies: {}
id: mcp_bot
label: 'MCP bot'
weight: 10
is_admin: true
permissions: {}

B) Scoped role (when you want explicit limits). List exactly the perms the bot may use. Note that administer nodes alone does not grant create / edit / delete on bundles — those need either bundle-specific perms ('create article content', 'delete any page content', etc.) or 'bypass node access'.

is_admin: false
permissions:
  - 'access content'
  - 'access user profiles'
  - 'bypass node access'        # or per-bundle perms
  - 'administer taxonomy'
  - 'view own unpublished content'

Then create the user:

drush user:create mcp_bot --password='<strong-pw>'
drush user:role:add mcp_bot mcp_bot

Store the password in your secrets manager.

Install (Claude Code plugin)

/plugin marketplace add lucaspretti/claude-plugins
/plugin install drupal-mcp@lucaspretti-plugins

Set these env vars (via shell, .env, or your secrets manager):

DRUPAL_BASE_URL=https://your-site.example.com
DRUPAL_USER=mcp_bot
DRUPAL_PASSWORD=••••••••

Install (standalone)

git clone https://github.com/lucaspretti/drupal-mcp.git
cd drupal-mcp
npm install
cp .env.example .env  # fill in
node drupal-mcp.js

In your MCP client config (Claude Desktop claude_desktop_config.json, Cline, etc.):

{
  "mcpServers": {
    "drupal": {
      "command": "node",
      "args": ["/absolute/path/to/drupal-mcp/drupal-mcp.js"],
      "env": {
        "DRUPAL_BASE_URL": "https://your-site.example.com",
        "DRUPAL_USER": "mcp_bot",
        "DRUPAL_PASSWORD": "••••••••"
      }
    }
  }
}

Tools

Tool	What it does
`drupal_list_nodes`	List nodes of a bundle, with filter / sort / paginate
`drupal_get_node`	Fetch one node by UUID
`drupal_create_node`	Create a node (POST)
`drupal_update_node`	Patch attributes / relationships
`drupal_delete_node`	Delete by UUID (irreversible)
`drupal_list_taxonomy_terms`	List terms in a vocabulary
`drupal_list_users`	List users
`drupal_query_jsonapi`	Arbitrary GET against `/jsonapi/*` (escape hatch)

Filter shorthand: { field_category: '<uuid>' } → filter[field_category]=<uuid>. Use { field: { value, operator } } for non-equality operators.

CLI flags

Each env var has an equivalent flag, useful when running outside an .env-aware shell:

node drupal-mcp.js \
  --base-url=https://your-site.example.com \
  --user=mcp_bot \
  --password=•••• \
  --jsonapi-prefix=/jsonapi \
  --timeout=30000

node drupal-mcp.js --help for the full list.

Troubleshooting

`Error: fetch failed (cause: getaddrinfo ENOTFOUND <host>${var_name})`

Claude Code's ${VAR} interpolation in .mcp.json substitutes from process.env, not from the settings.json env block alone. When a referenced var is unset upstream, the literal string ${var_name} is passed to the spawned process and concatenated into the URL.

Fix: ensure every var in .mcp.json env is also set in ~/.claude/settings.json (env block) or your shell environment. Or remove optional vars from .mcp.json and rely on the script's defaults.

`Error [ERR_MODULE_NOT_FOUND]: Cannot find module '...zod-to-json-schema/dist/esm/index.js'`

The @modelcontextprotocol/sdk postinstall race occasionally leaves zod-to-json-schema half-built. Reinstall:

cd ~/.claude/plugins/cache/<marketplace>/drupal-mcp/<version>
rm -rf node_modules package-lock.json && npm install

`401 Unauthorized` on every request

The basic_auth core module is not enabled. drush en basic_auth -y.
Or the password is wrong / the user is blocked.

`403 Forbidden` on a specific bundle

The bot role lacks the permission for that bundle. Either grant 'create <bundle> content' / 'edit any <bundle> content' / 'delete any <bundle> content' per bundle, or grant 'bypass node access' for blanket node access, or set is_admin: true on the role for full-trust service accounts.

Note that administer nodes alone is NOT enough — it grants the admin UI but not the per-content-type CRUD permissions.

`405 Method Not Allowed` on writes

jsonapi.settings.read_only is still true. See "JSON:API writes" above.

`301` redirects to a language-prefixed URL

If the language module is enabled, /jsonapi/... redirects to /<langcode>/jsonapi/.... Node's fetch follows automatically; curl needs -L. Nothing to fix on the server side.

Authentication

The plugin currently uses HTTP Basic auth (basic_auth core module). This is the simplest path that works out of the box on any Drupal site.

For a small / single-tenant deployment with a dedicated bot user and HTTPS-only, Basic auth is acceptable. For production or multi-integration setups, OAuth2 via simple_oauth is the correct choice for service accounts:

	Basic auth (current)	OAuth2 client_credentials (roadmap)
Drupal module	`basic_auth` (core)	`simple_oauth` (contrib)
Wire format	`Authorization: Basic <base64(user:pass)>` on every request	`Authorization: Bearer <token>`, token cached + refreshed
Revocation	Change user password (affects UI login too)	Revoke token / consumer atomically
Scopes	None (role permissions only)	Per-token scopes
Setup	Enable module, create user	Install module, generate RSA keys, create consumer

OAuth2 support is planned as an opt-in mode (DRUPAL_AUTH_MODE=oauth + DRUPAL_OAUTH_CLIENT_ID / _SECRET / _TOKEN_URL). Until then, treat the bot password as you would any service-account credential: store it in a secrets manager, scope the role tightly, and rotate periodically.

Security notes

HTTPS only. Basic auth means the bot password travels on every request — don't run against http://.
The Drupal-side bot user's role is the security boundary. Keep it scoped to the bundles and operations you actually need.
JSON:API respects field access, but not entity-access-bypass — be careful with admin-bypass perms on the bot role.
.env is gitignored. Don't commit credentials.

License

MIT

Available Tools

8 tools

drupal_create_nodeA

Create a new node. Pass attributes (and optional relationships) using JSON:API field names.

ParametersJSON Schema

Name	Required	Description
`bundle`	Yes
`attributes`	Yes	e.g. { "title": "...", "body": { "value": "...", "format": "basic_html" }, "status": true }
`relationships`	No	JSON:API relationships object (optional)

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided; description solely states the action and parameter format without disclosing side effects, authentication needs, or return values. Lacks detail on what happens after creation.

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?

Extremely concise: two sentences convey purpose and parameter guidance without unnecessary words.

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?

No output schema exists, and the description does not mention return values or error handling. While it provides some guidance on parameter usage (nested objects), it lacks completeness for a creation tool.

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 description adds value by instructing to use 'JSON:API field names' for attributes and relationships, which is not in the schema. The schema's attribute example also clarifies format. However, the 'bundle' parameter lacks explanation.

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 'Create a new node,' identifying the verb (create) and resource (node). It distinguishes from sibling tools like drupal_delete_node and drupal_update_node by implying creation of new content.

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 (e.g., drupal_update_node for existing nodes). The description focuses only on how to pass parameters, not usage context.

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

drupal_delete_nodeA

Delete a node by bundle + UUID. Irreversible.

ParametersJSON Schema

Name	Required	Description	Default
`bundle`	Yes
`uuid`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Highlights irreversibility, which is critical behavioral info, but doesn't disclose permissions, side effects (e.g., cascading deletes), or confirmation behavior. With no annotations, the description partially fulfills transparency needs.

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 succinct sentences with front-loaded purpose and a key behavioral note. No redundant or extraneous content.

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?

For a simple delete operation, the description covers essential info: what it does and that it's irreversible. Could mention existence precondition or return value, but given no output schema, it's reasonably complete.

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 0%, so description must compensate. It explains that bundle and UUID identify the node, adding meaning beyond raw schema names. However, it doesn't clarify bundle's meaning (content type) or UUID format, leaving some ambiguity.

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 the verb (delete), resource (node), and required identifiers (bundle + UUID). It distinguishes from sibling tools like drupal_create_node or drupal_update_node.

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 alternatives (e.g., drupal_update_node, drupal_get_node). The agent receives no context about prerequisites or exclusions.

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

drupal_get_nodeA

Fetch a single node by bundle + UUID.

ParametersJSON Schema

Name	Required	Description	Default
`bundle`	Yes
`uuid`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided; description only says 'Fetch' implying read-only, but lacks details on not-found behavior, permissions, or side effects.

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

Conciseness5/5

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

Single sentence with no wasted words; front-loaded with verb and resource.

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 simple fetch operation and no output schema, description is nearly complete; could mention not-found handling but otherwise adequate.

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

Parameters2/5

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

Schema description coverage is 0%; description mentions 'bundle + UUID' but does not explain their format or accepted values beyond the schema names.

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 uses specific verb 'Fetch' and resource 'single node by bundle + UUID', clearly distinguishing from sibling tools like drupal_create_node or drupal_list_nodes.

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 vs alternatives; usage is implied by the specificity of fetching a single node by bundle+UUID.

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

drupal_list_nodesA

List nodes of a given bundle (content type). Returns a paginated set of nodes with their attributes flattened. Default sort is by created date desc.

ParametersJSON Schema

Name	Required	Description
`bundle`	Yes	Content type machine name (e.g. "article", "page")
`filter`	No	Optional filter object. Shortcut form: { field_name: { value: 'x', operator: '=' } } or { field_name: 'x' }. Pre-encoded form: { 'filter[status][value]': 1 } also accepted.
`sort`	No	Sort spec (e.g. "-created", "title"). Default "-created".
`limit`	No	Page size (default 25)
`offset`	No	Pagination offset
`include`	No	Relationships to include (e.g. "field_category" or ["field_image","uid"])
`fields`	No	Sparse fieldsets keyed by JSON:API type, e.g. { "node--article": ["title","field_summary"] }

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, description carries full burden. It mentions pagination, default sort, and flattened attributes but does not disclose rate limits, auth needs, or handling of large results. Basic transparency, not thorough.

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, no filler, front-loaded with core purpose. Every sentence adds value.

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?

Covers core purpose, pagination, default sort, and flattened attributes. However, no guidance on using filter/sort/fields effectively compared to the query tool. Given schema richness, description is mostly complete but lacks some strategic 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 description coverage is 100%, so baseline is 3. Description adds no significant parameter details beyond the schema (e.g., default sort is already in sort param description). Minimal added value.

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 lists nodes by bundle (content type), mentions paginated sets and flattened attributes, and is distinct from siblings like drupal_get_node (single node) or drupal_query_jsonapi (flexible query).

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 over alternatives like drupal_query_jsonapi or drupal_list_taxonomy_terms. The context is clear (list nodes by bundle), but exclusions and comparison are missing.

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

drupal_list_taxonomy_termsB

List terms in a vocabulary (e.g. "category", "tags"). Default sort is "weight".

ParametersJSON Schema

Name	Required	Description
`vocabulary`	Yes	Vocabulary machine name
`filter`	No	Optional filter object. Shortcut form: { field_name: { value: 'x', operator: '=' } } or { field_name: 'x' }. Pre-encoded form: { 'filter[status][value]': 1 } also accepted.
`sort`	No
`limit`	No

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It reveals the default sort order ('weight') but omits other important behaviors such as pagination behavior, response format, permission requirements, or limits. The description is insufficient for an agent to fully understand the tool's side effects or constraints.

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 extremely concise with two sentences that are front-loaded. Every word adds value without repetition or fluff. It efficiently conveys the core purpose and a key behavioral detail (default sort).

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?

Given the absence of an output schema and the presence of a nested filter parameter, the description does not adequately prepare an agent. It fails to explain the return structure, any pagination, the format of the filter object, or the maximum limit. The context from sibling tools is not leveraged.

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?

The description adds value by stating the default sort value, which clarifies the 'sort' parameter meaning beyond the schema (which lacks a description for sort). However, the 'limit' parameter has no description, and the 'filter' parameter's complex structure is not elaborated. The schema coverage is 50%, and the description partially compensates.

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's action: 'List terms in a vocabulary' with a specific verb and resource. It provides examples of valid vocabularies ('category', 'tags'), and is distinct from sibling tools which deal with nodes and users.

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 usage via examples of common vocabularies but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusion criteria or alternative tool references are given.

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

drupal_list_usersC

List Drupal users. Requires the configured account to have permission to view users.

ParametersJSON Schema

Name	Required	Description
`filter`	No	Optional filter object. Shortcut form: { field_name: { value: 'x', operator: '=' } } or { field_name: 'x' }. Pre-encoded form: { 'filter[status][value]': 1 } also accepted.
`sort`	No
`limit`	No

TDQS

C2.8/5.0

Behavior2/5

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

No annotations provided; description only states permission requirement, omitting behavioral details like read-only nature, pagination, or error handling.

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?

Two sentences are concise and front-loaded, but brevity sacrifices completeness.

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?

With no output schema and only 33% schema coverage, description lacks essential context on return format, pagination, sorting defaults, and filtering syntax beyond schema.

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

Parameters1/5

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

Schema coverage is low (33%), but description adds no parameter details beyond the schema; does not explain 'sort' or 'limit' parameters.

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?

Directly states 'List Drupal users' with a clear verb and resource, and distinguishes from sibling tools like drupal_list_nodes and drupal_list_taxonomy_terms.

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?

Only mentions a permission requirement; no guidance on when to use this vs alternatives like list_nodes or query_jsonapi.

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

drupal_query_jsonapiA

Escape hatch: arbitrary GET against the JSON:API. Use when the higher-level tools do not cover what you need (custom resources, /jsonapi/index, etc.).

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	JSON:API path relative to the prefix, e.g. "/node/article" or "/taxonomy_term/category"
`query`	No	Raw query parameters (filter[...], sort, page[limit], etc.)

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided; description implies read-only GET but doesn't confirm no side effects, permissions, or rate limits. Could disclose that it performs a GET and what authentication is needed.

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 concise sentences front-load purpose and usage. No superfluous information.

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?

Tool is simple (GET, two params). Description is nearly complete for an escape hatch; only minor omission is mention of return format, but response structure is standard JSON:API.

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% already describing path and query. Description does not add extra meaning beyond the schema, so baseline 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?

Clear verb+resource: "arbitrary GET against the JSON:API". Distinguished from siblings by positioning as "escape hatch" when higher-level tools like drupal_get_node don't suffice.

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

Usage Guidelines5/5

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

Explicitly states use case: when higher-level tools do not cover what you need, e.g., custom resources or /jsonapi/index. Provides clear when-to-use guidance with examples.

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

drupal_update_nodeB

Patch an existing node by UUID. Pass only the attributes / relationships you want to change.

ParametersJSON Schema

Name	Required	Description	Default
`bundle`	Yes
`uuid`	Yes
`attributes`	No
`relationships`	No

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 disclose behavioral traits. It states 'patch' implying mutation but omits details on idempotency, error handling (e.g., missing UUID), required permissions, or whether it returns the updated node.

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 two sentences, front-loaded with the primary action, and every word adds value without redundancy.

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?

Given the tool's complexity (4 params, nested objects, no output schema, no annotations), the description is too sparse. It lacks details on return values, error states, or prerequisites, leaving the agent underinformed.

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?

The description adds meaning by noting that attributes and relationships are for the fields to change, which partially compensates for 0% schema coverage. However, it does not describe the nested object structure or provide format hints.

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 'Patch an existing node by UUID' with a specific verb (patch) and resource (node). It distinguishes from sibling tools (create, delete, get, list) by specifying the partial update nature.

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 implies usage by saying 'Pass only the attributes/relationships you want to change' but does not provide explicit guidance on when to use this tool vs alternatives (e.g., create vs update, or when a full update via put might be needed).

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.6/5.0

Disambiguation5/5

Each tool targets a distinct Drupal resource or action: node CRUD, taxonomy listing, user listing, and a general query fallback. No overlap or ambiguity.

Naming Consistency5/5

All tools follow the consistent 'drupal_verb_noun' pattern in snake_case, e.g., drupal_create_node, drupal_list_users, drupal_query_jsonapi.

Tool Count5/5

8 tools is a well-scoped set for a Drupal MCP server, covering core node operations, taxonomy, users, and an escape hatch, without being overwhelming.

Completeness3/5

Node CRUD is complete, but taxonomy and user operations are limited to listing only, missing create/update/delete. The generic query tool mitigates gaps but does not fully compensate.

Maintenance

ActivitySlowing

ResponsivenessUnresponsive

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

Artificial Wit AI
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
supportsheep
io.github.pooriaarab
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
Customer Support Content Management Systems Marketing
1

Related MCP Servers

mcp-mealie
Content Management Systems Web Scraping Search
obrien-matthew
A
license
B
quality
B
maintenance
MCP server for Mealie that exposes its REST API to manage recipes, meal plans, shopping lists, cookbooks, and taxonomy through natural language.
Updated 2 months ago (2026-07-19 03:55 UTC)
75
MIT
WordPress MCP Python
Content Management Systems E-commerce & Retail
tan-interspace
A
license
Not graded
quality
D
maintenance
A lightweight MCP server that connects to WordPress via REST API, enabling content management (posts, pages, categories, etc.) and site configuration through natural language commands.
Updated 8 months ago (2025-12-29 16:17 UTC)
Apache 2.0
drupalorg-mcp
Content Management Systems Search
zaporylie
A
license
Not graded
quality
B
maintenance
MCP server for drupal.org's public REST API. Enables querying projects, issues, comments, and user information on drupal.org.
Updated a month ago (2026-08-05 12:27 UTC)
17
GPL 2.0
wp-mcp
Content Management Systems Search
cnmbdb
A
license
Not graded
quality
C
maintenance
MCP server for WordPress content management via REST API, supporting posts, pages, media, comments, and terms through natural language interfaces like Cursor, ChatGPT, Codex, and Claude.
Updated 16 days ago (2026-08-18 10:33 UTC)
32
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/lucaspretti/drupal-mcp'

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

drupal-mcp

Why JSON:API and not the older Drupal MCP module?

Drupal-side setup (one-time)

Required modules

JSON:API writes

Bot role + user

Install (Claude Code plugin)

Install (standalone)

Tools

CLI flags

Troubleshooting

Error: fetch failed (cause: getaddrinfo ENOTFOUND <host>${var_name})

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '...zod-to-json-schema/dist/esm/index.js'

401 Unauthorized on every request

403 Forbidden on a specific bundle

405 Method Not Allowed on writes

301 redirects to a language-prefixed URL

Authentication

Security notes

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`Error: fetch failed (cause: getaddrinfo ENOTFOUND <host>${var_name})`

`Error [ERR_MODULE_NOT_FOUND]: Cannot find module '...zod-to-json-schema/dist/esm/index.js'`

`401 Unauthorized` on every request

`403 Forbidden` on a specific bundle

`405 Method Not Allowed` on writes

`301` redirects to a language-prefixed URL