Loading ToolBench
A powerful Model Context Protocol (MCP) server for Payload CMS that enables AI assistants to help you develop, manage, and extend your Payload CMS projects
The server provides 4 tools with explicit Zod schemas and basic descriptions. However, the implementation has moderate gaps: (1) descriptions are generic and lack actionable guidance for when to use each tool vs. alternatives; (2) parameter descriptions are minimal (most are 1-3 words); (3) output schemas are not documented, responses are text-only without structured field definitions; (4) error handling returns plain text error messages without recovery guidance; (5) no tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk profiles. The schema definitions are present and mostly typed, placing this in the 'fair' range (C-D). Most parameters are constrained (enums), which is positive. However, the weak descriptions and undocumented output structure prevent this from reaching 'good' (70+).
Generate template code for Payload CMS components including collections, fields, configs, access control, hooks, endpoints, plugins, blocks, migrations, and components
Process a query string to validate and provide suggestions for Payload CMS queries
Generate a complete Payload CMS project scaffold based on the website template with collections, globals, blocks, plugins, and full project structure
Validate Payload CMS code for syntax, best practices, security issues, and performance issues
Output schemas are not documented. All tools return plain text responses (text/plain content type) without specifying structured fields. LLMs cannot infer what fields to extract or how to compose downstream tool calls.
Parameter descriptions are generic or missing. Examples: 'Configuration options for the generator' (options param in generate_template), 'Custom collection configurations' (collections param in scaffold_project), 'Check best practices' (checkBestPractices in validate_code). These lack format guidance, constraints, or examples that would help an LLM construct valid input.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). scaffold_project is marked WRITE risk but has no destructiveHint; generate_template and validate_code are READ_ONLY but lack readOnlyHint. Agents cannot determine retry safety without these hints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Error handling returns plain text error messages ('Generation error: ...', 'Query processing error: ...') without recovery guidance. LLMs cannot determine if the error is retryable, user-fixable, or fatal.
process_query lacks format specification for 'queryString'. Is it GraphQL? SQL? A Payload CMS DSL? The description doesn't clarify, forcing the LLM to guess. No example provided.
scaffold_project accepts nested array parameters (collections, globals, blocks) but the schema for these nested objects is not documented in the tool description. LLMs must read the source code to understand what fields are required vs. optional.
validate_code boolean flags (checkSyntax, checkBestPractices, etc.) lack default behavior documentation. Does validation run all checks by default, or only the enabled ones? This ambiguity invites wrong assumptions.
Tool descriptions do not explain mutual relationships. When should an LLM call generate_template vs. scaffold_project? What's the difference between process_query and validate_code? No guidance provided.