Cycles MCP server has well-structured tool definitions with consistent naming (verb_noun pattern: cycles_reserve, cycles_commit, etc.) and complete parameter descriptions. All 9 tools have descriptions (avg ~80 chars) and input schemas with typed parameters. However, output schemas are not documented in the visible code, parameter constraints lack enums/ranges, and error handling guidance is absent. Tool descriptions are functional but generic, they state WHAT but not WHEN or WHY to use each tool. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Idempotency keys are present across write operations, which is good practice.

• Add output schema documentation to each tool. Example: 'Returns: {reservationId: string, status: "ACTIVE"|"COMMITTED"|"RELEASED"|"EXPIRED", createdAt: ISO8601, expiresAt: ISO8601, estimatedCost: {unit: string, amount: number}, actualCost?: {unit: string, amount: number}}'
• Implement tool annotations in the MCP server registration. Map risk classifications to hints: WRITE → destructiveHint=true, READ_ONLY → readOnlyHint=true, REVERSIBLE → idempotentHint=true (for release/extend with idempotencyKey).
• Convert status and enum-like parameters to formal enum constraints in JSON Schema. Example: 'status': {type: 'string', enum: ['ACTIVE', 'COMMITTED', 'RELEASED', 'EXPIRED']}
• Expand tool descriptions with WHEN/WHY context. Example for cycles_reserve: 'Use this to pre-allocate budget before an expensive operation. Use cycles_decide first to check if an action is allowed without reserving. Use cycles_commit after the operation completes to record actual cost.'
• Add error handling guidance to descriptions. Example: 'Returns error if budget exhausted (retryable after extending budget) or if reservation expired (non-retryable; create new reservation). If idempotencyKey is reused, returns cached result.'