Server has 27 tools with consistent naming (verb_noun pattern: list_, get_, resolve_, calculate_, analyze_, prioritize_, generate_, update_, add_). All tools have descriptions (10-100 chars, mostly 30-80 chars). Input schemas are present and typed for all tools. However, parameter descriptions are minimal (often just 'The X' without context, constraints, or format guidance). Output schemas are not documented, LLMs cannot predict response structure. Error handling is absent from tool definitions. Write tools (update_finding_status, add_finding_note) implement confirmation tokens (good pattern), but no dry-run or preview mechanism is visible. Read-only tools dominate (25/27), which is appropriate for a DefectDojo adapter. Pagination is implemented (limit/offset) but return structure (has_more, next_offset) is not documented.

• Document output schemas for all tools. Include field names, types, and pagination metadata (has_more, next_offset, total_count). Use JSON Schema or explicit examples.
• Expand parameter descriptions to include format, constraints, and defaults. E.g., 'limit: Number of results per page (1 - 100, default 20)' instead of 'Number of results per page'.
• Add error handling guidance to tool descriptions. E.g., 'Returns 404 if finding not found, try list_findings() to verify the ID exists.'
• Implement capability negotiation (via MCP extensions or _meta) to advertise which optional tool groups (DB, write) are enabled. Prevents silent tool disappearance.
• For write tools (update_finding_status, add_finding_note), document the two-step confirmation flow explicitly: 'Call once to preview and get confirmation_token, then call again with token to apply.'

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

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