Guru-PK MCP has 10 tools with mixed definition quality. Strengths: all tools have names that start with action verbs (start_, get_, generate_, record_, analyze_, export_); all have descriptions; input schemas are visible and use proper JSON Schema. Critical weaknesses: descriptions are consistently too brief (most under 50 chars, many under 20 chars), failing the rubric baseline of 10-1024 chars with 50-200 chars ideal for LLM optimization; parameter descriptions are minimal or missing entirely (most parameters lack descriptions); no output schemas are documented; error handling is absent from all tool definitions; no tool annotations (readOnlyHint, destructiveHint, idempotentHint); composition issues exist (start_pk_session has overlapping responsibility with generate_dynamic_experts, both related to expert management but split into two tools without clear sequencing). The server performs domain-specific expert debate orchestration but lacks production-grade tool engineering patterns.

• Add output schemas for all 10 tools. Document response structure, field types, and required/optional fields. For export_enhanced_session, specify report format (JSON, markdown, etc.) and expected fields.
• Expand all tool descriptions to 50-200 chars following LLM-optimization guidelines. Example: 'start_pk_session' should be 'Initiate an expert debate session with up to 3 domain experts. Optionally provide expert personas; if not provided, call generate_dynamic_experts first to create experts tailored to your question. Batch mode enables concurrent expert responses; sequential mode records responses one expert at a time.'
• Add descriptions to all parameters. For example, persona.core_traits should be 'Array of 3-5 key character traits (e.g., ["analytical", "skeptical", "pragmatic"])', and batch_config.quality_threshold should be 'Float between 0 and 1 controlling response quality filtering; 0.8 is recommended.'
• Add tool annotations: mark record_round_response and record_batch_responses with destructiveHint: true; mark all READ-only tools (get_*, analyze_*, export_*, guru_pk_help) with readOnlyHint: true.
• Document stateful behavior explicitly. If sessions persist across calls, add a 'session_id' field to responses and require it as input for subsequent tools. Clarify whether session context is server-side (user-specific) or request-scoped.
• Clarify tool sequencing. Add to start_pk_session description: 'If you don't have expert personas, call generate_dynamic_experts first with the question, then pass the returned personas to this tool.' Remove ambiguity between these two tools.