Citadel's MCP servers have severe definition gaps. Tool descriptions are present but minimal (10-50 chars, well below the 50-200 char baseline for LLM-optimized descriptions). No input schemas are visible in the provided source code, only tool names and brief descriptions appear in .mcp.json config. The actual tool implementations in index.js files are not shown, so parameter types, constraints, and output schemas cannot be verified. Without visible schemas, all tools score 0 on schema dimension. Naming is reasonable (verb_noun pattern: citadel_status, get_architecture, who_imports, dependencies_of, trace_path, impact_of_change), but descriptions lack context on WHEN to use each tool, what prerequisites exist, and what the output structure is. Error handling, recovery guidance, and parameter validation are not documented.

• Expand tool descriptions to 50-200 characters. Example: 'citadel_status' → 'Retrieve current campaign state, fleet health, telemetry metrics, and artifact inventory. Call this first to understand the operational context before invoking workflows.'
• Document all input parameters with type, format, and constraints. Example: 'module_name (string, required): The module identifier to trace (e.g., "core/agents"). Use get_architecture first to discover available modules.'
• Define output schemas explicitly. Example: 'get_architecture returns {modules: [{name, path, dependencies: [string], dependents: [string]}], total_count: number}'
• Add error handling guidance. Example: 'If module not found, call get_architecture to list available modules. If trace_path times out, try a shorter path or check for circular dependencies.'
• Provide parameter constraints and enums where applicable. Example: 'impact_of_change accepts change_type: enum(add_export, remove_export, rename_module, update_dependency)'