Server has 9 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-50 chars, mostly under the 50-200 char LLM-optimized range), and input schemas are present with type definitions. However, output schemas are completely undocumented, LLMs cannot plan downstream calls or extract return data. Parameter descriptions are minimal (e.g., 'The ID of the page to retrieve' for pageId). No error handling guidance, no recovery paths, and no distinction between retryable vs. fatal errors. Tool naming follows verb_noun convention (getPage, createPage, deletePage) but lacks clarity on when to use similar tools (getPage vs. getPages). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. Composition is reasonable, tools are single-purpose, but missing pagination details and chaining IDs in responses.

• Document output schemas for all tools. Example for getPage: 'Returns {id: string, title: string, spaceId: string, version: number, content: string, ancestors: [{id, title}]}'. This enables LLMs to chain tools and extract IDs for downstream calls.
• Expand tool descriptions to 50-150 chars with WHEN guidance. Example: 'Retrieve a single Confluence page by ID. Use this when you have a specific page ID; use getPages() to search within a space first.'
• Add tool annotations to schema. Mark deletePage with destructiveHint: true, createPage/updatePage with idempotentHint: false (or true if idempotent), and read tools with readOnlyHint: true.
• Add error handling guidance in tool descriptions. Example for createPage: 'Returns 400 if spaceId is invalid (call getSpaces first), 401 if token expired, 409 if title already exists in space.'
• Document pagination behavior. Example for getPages: 'Returns up to 'limit' results (default 25, max 100). Use 'start' to fetch next page. Response includes total count to determine if more pages exist.'