Two tools with partial definitions. Both have reasonable names (vote, council_status) and descriptions, but schema quality is mixed. The 'vote' tool has a clearly-visible Zod schema with one parameter; 'council_status' has an empty input schema. Descriptions are functional but brief (53 chars for vote, 62 chars for council_status, both within acceptable range but toward the short end). No parameter descriptions beyond the schema itself. Output structure is formatted as text via formatVoteResult(), not a structured schema. No error classification, no recovery guidance beyond a generic catch block. No tool annotations (readOnlyHint, idempotentHint). No pagination, no chaining IDs, no rich output metadata. Both tools are READ_ONLY operations, which reduces risk, but the lack of structured output and incomplete error handling limits agent reasoning and integration.

• Define and return a structured output schema for 'vote': e.g., { response: string, votes: array, proposals: array, tieBreak?: object, evictions: array }. Document this schema in the tool's response specification so LLMs know what fields to expect.
• Define and return a structured output schema for 'council_status': e.g., { members: [{ id, name, values }], candidates: [{ id, name, fitness }], statistics: { roundsSinceEviction, targetPoolSize } }. Return JSON, not markdown.
• Add constraint hints to the 'prompt' parameter: e.g., 'The query or request (max 2000 chars, non-empty) to submit to the council for deliberation.'
• Add readOnlyHint annotations to both tools in registerTool options: `{ description: '...', inputSchema: {...}, readOnlyHint: true }`
• Categorize errors in the vote tool: check for 'insufficient members' (user-fixable, tell them to wait), timeout/LLM service errors (retryable), and invalid input (ask user to rephrase). Return error category in response: `{ content: [...], isError: true, errorCategory: 'user_fixable' }`
• Document the background practice round behavior: add a note that vote() may trigger a background task and explain any observable side effects, so LLMs understand idempotence guarantees.
• Return pagination hints in council_status if the candidate pool or member list grows large (e.g., limit and offset parameters). Current implementation does not paginate.
• Include IDs in structured output (member.id, candidate.id) so downstream tools or future integrations can reference council entities uniquely.

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

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