Drupal MCP Server

Tool Scores

• get_nodeB
  3.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
  3.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
  3.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
  3.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.