Single tool 'roundtable' has a well-structured input schema with proper types and descriptions for all parameters (question, heads, rounds, research). The tool description is comprehensive (194 chars) and explains the council deliberation model clearly. However, the output schema is not documented, the description mentions 'markdown transcript' but does not specify the response structure, fields, or format. Parameter descriptions are good (e.g., 'Optional comma-separated subset of heads...'), but lack explicit constraints on the 'heads' enum values in the schema itself (they are listed in the description but not as a formal enum constraint). The tool is read-only and idempotent, which is appropriate, but these properties are not annotated in the schema.

• Document the output schema explicitly. Specify: Is it a string (markdown text)? An object with fields like {transcript: string, consensus: boolean, head_responses: [...]}? Include field types and descriptions so LLMs know what to extract.
• Convert the 'heads' parameter description into a formal enum constraint in the JSON Schema: "enum": ["grok", "codex", "openai", "glm", "minimax", "claude", "gemini"]. This prevents hallucinated values.
• Add tool annotations to the schema: set readOnlyHint=true and idempotentHint=true to signal that the tool is safe to retry and does not modify state.
• Document error handling: explain what happens when a head's API key is missing (is that head omitted from the response? does the response include a 'skipped_heads' field?). Provide recovery guidance: 'If a head fails, check its API key via `roundtable auth` and retry.'
• Add a maximum constraint to 'rounds' (e.g., maximum=10) to prevent runaway deliberation loops. Document the expected time and cost per round in the description.