Wiki MCP Server has 4 tools with basic verb-noun naming (create_page, update_page, delete_page, search_page). All tools have descriptions (10-30 chars, below the 50-200 char LLM-optimized baseline). Input schemas are present with type definitions, but parameter descriptions are minimal (5-15 chars, well below the 72-char baseline). Output schemas are not documented. No error handling guidance, no recovery paths for destructive operations, and no permission gates on write/delete tools. Tool composition is reasonable but lacks idempotency guarantees and confirmation patterns for destructive ops.

• Expand tool descriptions to 100-150 chars. E.g., 'Create a new wiki page in the specified space. Returns the page ID and URL. Use this when the user wants to add new content; use update_page to modify existing pages.'
• Add format/constraint guidance to parameter descriptions. E.g., 'space_key: Confluence space identifier (2-10 uppercase letters, e.g., PROJ). Required.' and 'wiki_type: Optional wiki instance type (alm_confluence, wpb_confluence, etc.). If omitted, inferred from user_query.'
• Document output schemas explicitly. E.g., 'Returns WikiPage object with fields: id (string), title (string), url (string), space (string). Use id for downstream update_page or delete_page calls.'
• Add confirmation pattern for delete_page: require a confirm_delete parameter or implement a two-step flow (dry-run first, then confirm). Include error guidance: 'Page not found. Try search_page() first to verify the page exists.'
• Implement permission checks and audit logging. Gate delete_page and update_page behind role checks. Log caller identity, tool name, parameters (excluding secrets), timestamp, and result for compliance.

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

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