The Concrete CMS MCP server defines 2 tools with clear verb-based names and well-structured schemas. Both tools have descriptions in the 150-250 char range (within the productive 10-1024 baseline). Input schemas are present with type information and descriptions for all parameters. However, output schemas are not formally documented, the tool code returns JSON but the expected response structure is not declared in the tool definition. Error handling is implemented but lacks recovery guidance (e.g., 'If you see BlockRemapError, try...'), and descriptions could be more specific about prerequisites and when to use each tool over alternatives. Tool annotations (readOnlyHint, destructiveHint) are present and correct. Overall, this server meets the bar for 'good' work, solid foundations with room for output schema documentation and error recovery guidance.

• Add formal outputSchema declarations to both tool definitions. Document the exact structure returned by jsonResult(): for get_page_content, document {id, path, name, description, version, html, html_raw, text}; for update_page_content, document {id, path, name, description, version, blocks: [{areaHandle, oldBlockID, newBlockID, ok, error?}], note}.
• Enhance error messages with recovery hints. Example: Instead of 'pageID must be a positive integer', return 'Invalid pageID: must be a positive integer. Call search_pages() with a keyword to find the page ID.' This guides the LLM to the next step.
• Add explicit prerequisites to update_page_content description: 'Call get_page_content first to retrieve the current page version and block IDs. Pass the blockID values from that response to this tool.'
• Document partial failure behavior in update_page_content: 'If multiple blocks are provided, each is updated independently. The response includes a blocks array where each entry has an ok flag. If ok is false, the error field explains why that specific block failed. Retry failed blocks individually or adjust the payload and resubmit.'
• Expand the 'page' parameter schema in update_page_content. Define allowed properties: {name?: string, description?: string, type?: string, template?: string, attributes?: object}. Add a note: 'Only properties you wish to update; omit others. Omitting all fields creates a new version without changing metadata.'
• Consider adding a dry-run parameter to update_page_content. This aligns with the pattern:confirmation-request pattern: 'Provide dry_run: true to validate block IDs and payloads without committing changes. Useful for previewing complex multi-block updates.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry