The aem-mcp-server demonstrates solid fundamental quality with 28 well-defined tools covering AEM page, component, asset, and workflow operations. All tools have names starting with action verbs (fetch, list, create, update, delete, search, get), descriptions between 34-194 chars, and documented input schemas with parameter types and descriptions. However, several systematic gaps reduce the score below 70: (1) Output schemas are not explicitly documented, the source shows tool registration with inputSchema but no visible outputSchema declarations or return type documentation; (2) Error handling lacks recovery guidance, tools do not appear to provide actionable error messages guiding the LLM to fallback tools or retries; (3) Tool descriptions are functional but often terse (34-72 chars baseline) and missing WHEN-to-use context that helps LLMs select between similar tools; (4) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible despite the rubric requiring these for production-grade tools; (5) Complex parameters like 'properties' (object type) lack structured schema definitions of what keys are valid; (6) Some tools accept free-form predicates or arbitrary properties without enums or validation guidance; (7) Parameter descriptions sometimes omit format/range constraints (e.g., 'fileName' says alphanumeric/dot/dash/underscore but doesn't state max length or why). Strengths: consistent verb-noun naming, all tools and parameters have descriptions, schemas include type information, tools are logically grouped by domain (discovery, pages, components, assets, search, workflow), and destructive operations are clearly marked with risk labels. The 28-tool catalog is well-sized with no obvious oversplitting or conflation.

• Add explicit outputSchema or return type documentation to all tools. Example for listPages: 'Returns {pages: [{title, path, createdBy, lastModified}], totalCount, hasMore}'.
• Register tool annotations with server.registerTool(). Update the catalog tool definitions to include annotations object with readOnlyHint: true for all READ_ONLY tools, destructiveHint: true for DESTRUCTIVE tools, and idempotentHint: true for idempotent operations.
• Enhance error handling to return structured recovery guidance. Example: if path validation fails, return {error: 'Invalid path', details: 'Path must start with /content/dam', suggestion: 'Call listChildren("/content/dam") to discover valid paths'}.
• Define structured schemas for object parameters. For 'properties' on createPage/createComponent, document: {properties: {type: 'object', additionalProperties: true, examples: [{jcr:title: 'My Page', jcr:description: '...'}], description: '...'}}, or restrict to known properties with an enum.
• Expand tool descriptions to 100-150 chars. Add WHEN-to-use guidance. Example for getPageContent: 'Retrieve the full component and content structure of a page. Use before updateComponent to understand layout. Returns pagePath, jcr:content with component tree and depth limit enforcement.'
• Document activatePage and deactivatePage constraints in descriptions: mention that tree activation is not supported and must be called per-page, potentially recommend a batch/workflow approach for multi-page scenarios.
• For searchContent, provide example predicates or link to AEM QueryBuilder predicate documentation. Constrain or enumerate common predicates (type, daterange, nodename, etc.) if possible.

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

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