Loading ToolBench
The server implements 3 tools for searching Drupal.org content with visible, properly-typed input schemas and reasonable descriptions. However, multiple definition quality issues limit the score. All tool descriptions are present but generic (10-30 chars), falling below the 50-200 char baseline for LLM-optimized descriptions. Parameters lack depth, 'type', 'field_issue_status', 'field_issue_priority' have brief descriptions but no enums, range constraints, or format guidance despite being critical filters. The 'projectName' parameter lacks guidance on what 'machine name' means. Output schemas are not documented; responses are text-formatted and lack structured field definitions. Error handling returns generic 'Failed to retrieve' messages with no recovery guidance or categorization. The server design treats Drupal.org as a generic JSON API rather than designing for agent utility, there is no pagination support (despite the API supporting it), no result limiting guidance, and no error enrichment to help the LLM self-correct on invalid inputs. Positively, tool naming follows the verb_noun pattern and schemas use proper Zod typing with type declarations and required flags.
Get issues for a Drupal project
Get security advisories
Search for nodes on Drupal.org
Tool descriptions are 18-22 characters, far below the 50-200 character baseline for LLM-optimized descriptions. 'Get issues for a Drupal project' and 'Get security advisories' lack context on when to use each tool, what they return, and how they differ from other search tools.
Critical filter parameters lack enums and range constraints. 'field_issue_status' and 'field_issue_priority' accept numeric IDs but the code maps these to human-readable values (1→'Active', 2→'Fixed', etc.). These mappings should be exposed as enums in parameter descriptions so LLMs know valid values without trial-and-error. Currently LLMs must guess valid status/priority IDs.
No output schema documentation. All tools return formatted text, but LLMs cannot parse the output structure reliably. The formatNode() and formatIssue() functions produce human-readable strings but agents need structured data (title, type, status, priority as separate fields) to chain tools or extract specific data.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 37 | - | v1 |
'projectName' parameter description says 'Machine name of the project' but does not explain what a machine name is or how to discover it. An LLM seeing 'projectName' might pass 'Drupal Core' (display name) instead of 'drupal' (machine name), causing a failed call. Needs an actionable description like 'The project's system identifier (lowercase, hyphens allowed). E.g. drupal, ctools, views. Call search-nodes() with type=project to discover available project machine names.'
Error handling returns generic messages ('Failed to retrieve nodes', 'No nodes found') with no recovery guidance. Per pattern:recovery-guide, errors should be actionable: 'No issues found for project: myproject. Verify the project machine name is correct, call search-nodes() with type=project to list available projects.'
No pagination support despite the underlying API accepting limit and page. The makeDrupalRequest() function accepts params but there is no guidance on pagination in tool descriptions. Per pattern:paginated-result, tools returning lists should document pagination, return a total count (data.count is returned), and advise agents on batch size and result limits.
Parameter 'limit' and 'page' have minimal descriptions and no constraints. Should specify: 'limit: Number of results per page (1-100, default 20). Limit requests to avoid timeout.' and 'page: Zero-indexed page number. Use limit and page for pagination.'
The 'type' parameter in search-nodes describes 'Content type to filter by' but does not enumerate valid types (node, project, issue, security_advisory, etc.). LLMs will guess invalid values. This parameter should have an enum constraint or description listing the most common types.