Loading ToolBench
The Umbraco MCP server provides 6 tools with basic to moderate quality. While tool names follow the verb_noun convention appropriately (e.g., get-server-configuration, initiate-workflow-action), several critical gaps significantly reduce overall quality. Most tools have descriptions, but they are generic and often redundant with the response examples. Input schemas are not visible in the source code, the server uses Zod schema builders (postActionInitiateBody.shape) that are referenced but not inspected. For read-only tools, input is empty {}, which is appropriate but uninformative. Parameter-level descriptions are completely absent. Error handling exists in the CreateUmbracoTool wrapper (basic try-catch with error logging) but provides no recovery guidance to the LLM. The server lacks output schema documentation, tool annotations (readOnlyHint, destructiveHint, idempotentHint), and does not employ pagination or result limiting patterns despite returning arrays (e.g., get-server-troubleshooting returns an 'items' array). Overall structure shows competent implementation but falls short of production-grade tool patterns.
Gets the server configuration settings. Returns an object containing: - allowPasswordReset: Whether password reset is allowed (boolean) - versionCheckPeriod: The period between version checks in minutes (number) - allowLocalLogin: Whether local login is allowed (boolean) Example response: { "allowPasswordReset": true, "versionCheckPeriod": 1440, "allowLocalLogin": true }
Gets information about the Umbraco server. Returns an object containing: - version: The Umbraco version (string) - assemblyVersion: The assembly version (string) - baseUtcOffset: The server's UTC offset (string) - runtimeMode: The server's runtime mode, one of: 'BackofficeDevelopment', 'Development', 'Production' (string) Example response: { "version": "15.3.1", "assemblyVersion": "15.3.1.0", "baseUtcOffset": "-07:00:00", "runtimeMode": "BackofficeDevelopment" }
Gets the current status of the Umbraco server. Returns the server status (serverStatus) which can be one of: - Unknown: Status cannot be determined - Boot: Server is starting up - Install: Server is in installation mode - Upgrade: Server is performing an upgrade - Run: Server is running normally - BootFailed: Server failed to start Example response: { "serverStatus": "Run" }
Gets server troubleshooting information. Returns an array of diagnostic items, where each item contains: - name: The name/identifier of the diagnostic check (string) - data: The diagnostic data or result for that check (string) Example response: { "items": [ { "name": "Server OS", "data": "Darwin 23.6.0 Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6000" }, { "name": "Server Framework", "data": ".NET 9.0.0" }, { "name": "Default Language", "data": "en-US" }, { "name": "Umbraco Version", "data": "15.3.1" }, { "name": "Current Culture", "data": "en-US" }, { "name": "Current UI Culture", "data": "en-US" }, { "name": "Current Webserver", "data": "Kestrel" }, { "name": "Models Builder Mode", "data": "InMemoryAuto" }, { "name": "Runtime Mode", "data": "BackofficeDevelopment" }, { "name": "Debug Mode", "data": "True" }, { "name": "Database Provider", "data": "Microsoft.Data.SqlClient" }, { "name": "Current Server Role", "data": "Single" } ] }
Input schemas not visible in source code. Tools reference Zod builders (postActionInitiateBody.shape) that are not inspected, making it impossible to verify schema completeness, parameter types, descriptions, constraints, or enums. For initiate-workflow-action, the schema is inferred but not directly visible.
No parameter-level descriptions. All tools lack descriptions for their input parameters. For example, initiate-workflow-action accepts a 'model' parameter of type 'InitiateWorkflowRequestModel' with no documentation of its structure, required fields, or constraints. This forces LLMs to guess at parameter semantics.
Output schemas not documented. Tool descriptions include example responses (JSON snippets) but do not formally document output structure as schema. LLMs cannot reliably parse response fields or plan downstream tool calls without explicit output schema definitions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 53 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 35 | - | v1 |
Checks the server upgrade status and requirements. Returns an object containing: - type: The type of upgrade information (string) - comment: A description or message about the upgrade (string) - url: A URL with more information about the upgrade (string) Example response: { "type": "UpgradeAvailable", "comment": "A new version of Umbraco is available", "url": "https://our.umbraco.com/download/releases/15.3.2" }
Initiates a workflow approval process for content changes before they are published. This is the RECOMMENDED approach when content requires review/approval before going live. The variant parameter should be the culture string (e.g., en-US) or use '*' for all cultures.
No pagination or result limiting for array-returning tools. get-server-troubleshooting returns an unbounded 'items' array with no limit, offset/page, or cursor parameters. Large result sets will bloat context and degrade LLM reasoning.
No tool annotations. Tools lack readOnlyHint, destructiveHint, or idempotentHint attributes. get-server-configuration and other read-only tools should carry readOnlyHint=true to signal safety. initiate-workflow-action (marked WRITE) should carry destructiveHint or equivalent to warn of side effects.
Generic/redundant tool descriptions. Descriptions repeat the response example in prose form without adding actionable context for LLM selection. E.g., 'Gets server configuration settings. Returns an object containing...' simply rephrases the JSON example. Descriptions should explain WHEN to call this tool and WHY it differs from similar tools.
Error handling provides no recovery guidance. CreateUmbracoTool wrapper catches errors and logs them but returns raw error messages or stack traces to the LLM with no actionable guidance (e.g., 'try a different parameter', 'call search_* first'). Errors should guide the agent toward next steps.
initiate-workflow-action description includes example values ('en-US', '*') in documentation, which LLMs may reuse literally in real calls. Should use an enum or formal constraint for the 'variant' parameter instead.