Loading ToolBench
A CMS MCP server for managing content, templates, assets, and settings with OAuth 2.1 authorization and semantic search capabilities.
Scoring was not performed
Output schemas are not documented. The source code shows tool registration but does not define what fields agents should expect in responses. This forces LLMs to infer structure from actual results, increasing hallucination risk and breaking tool chaining.
Destructive operations lack confirmation or dry-run mechanisms. delete_asset, update_template, and search_replace_execute can permanently modify or destroy data without agent confirmation. search_replace_preview exists as a mitigation but is not enforced.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 27 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Parameter enums and constraints are missing. search_content accepts search_type but no enum is declared (should be 'name'|'fulltext'). end_user_search accepts mode but lacks enum validation (should be 'exact'|'semantic'|'hybrid'). limit parameter in end_user_search has no max constraint despite description claiming 1-50. Free-form strings invite hallucinated values.
Error handling lacks recovery guidance. The code returns errorResult(err) which likely formats API errors, but source shows no examples of how errors guide the agent. Errors should tell the LLM 'Asset not found. Try list_assets() with a folder filter' rather than a raw error code.
Parameter get_asset accepts both 'id' and 'path', but both are optional. The implementation returns an error if neither is provided, but this is a user-fixable error, the description should state 'either id or path is required' and provide guidance on which to use when.
Pagination and result limits are not explicitly addressed. list_assets, search_content, and list_templates do not declare limit/offset parameters visible in schema. If they return unbounded results, large asset libraries or content stores could overflow the context window.
Tool composition for template updates lacks clear sequencing. update_template warns that changing HTML layout will 'regenerate all content' but does not document what that means for agents, is it async? Does it return a job ID? Can the operation fail mid-way? Agents need clear side-effect documentation.
Numeric parameter constraints are missing or implicit. upload_asset's DataBase64 is required but has no size limit documented, base64-encoded files could be arbitrarily large, causing timeout or memory exhaustion. end_user_search's limit parameter claims 1-50 but the constraint is not enforced in schema.