The 'scan' tool has a basic schema with two parameters (target, max_tokens) but suffers from critical definition gaps. The tool description is minimal (58 chars) and lacks context on when/why to use it, what it returns, or how errors are handled. Parameter descriptions are present but generic. No output schema is documented. The tool appears to be a wrapper around audit logic but the MCP registration is opaque, the actual tool definition is built via cognis_core.mcp.build_mcp_server(), making it impossible to verify the full schema from source. This violates the 'see actual tool definition' rule, capping the score at 50 for that tool. The server is STDIO-only, which is a hard transport cap of 50 for protocolReadiness.

• Expand tool description to 100 - 200 chars: 'Audit OpenTelemetry GenAI spans for security risks (secrets, injection, dangerous tools, broken traces). Returns findings sorted by severity and metrics (span count, LLM calls, tool calls, errors). Call this first to validate trace integrity before replay.'
• Document output schema explicitly: {findings: [{severity, code, span_id, message}], metrics: {spans, llm_calls, tool_calls, errors}, failing: boolean}. Include example output in MCP tool registration.
• Add constraint descriptions to parameters: target='Path to .json/.jsonl file or directory (required, must exist, readable)'; max_tokens='Token budget per trace (optional, default 100000, range 1000 - 1000000)'.
• Add error handling guidance: 'If JSON parse fails, ensure file is valid JSON or JSONL. If no spans found, check that objects have span_id/spanId/id field. If parent_span_id missing, trace is incomplete, consider re-collecting.'
• Make tool definition explicit in source: replace cognis_core.mcp.build_mcp_server() with direct MCP SDK registration so schema, descriptions, and error handling are visible and auditable.