SecAgent has 4 tools with minimal schema documentation and generic descriptions. All tools have basic input schemas with type and description fields, but lack output schema documentation entirely. Descriptions are present but generic (10-50 chars), falling below the 50-200 char LLM-optimized baseline. No parameter validation constraints (enums, ranges, patterns). No error handling guidance. Tool names follow verb_noun convention (secagent_*) but are overly prefixed and lack clarity on when to use each tool vs alternatives. No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The codebase shows multi-language architecture (Rust, Go, C++, Python) but the MCP server implementation (python-agents/secagents/mcp_server.py) is not fully visible, tool definitions are inferred from the feature list rather than directly inspected in source.

• Expand tool descriptions to 50-200 characters. Include: what the tool does, when to use it (vs alternatives), what it returns, and any prerequisites. E.g. 'Scan a target URL for security vulnerabilities using Nuclei templates. Returns open ports, service versions, and CVE matches. Use this before verify_poc to identify exploitable services.'
• Document output schemas for all tools. Specify field names, types, and what data each field contains. E.g. secagent_scan should return {findings: [{type, severity, description, affected_service}], scan_duration_ms, target_url}.
• Add input validation constraints. For 'target' parameter: add pattern (regex for valid URL/domain), minLength, maxLength. E.g. pattern: '^[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$' for domains.
• Add error handling guidance to descriptions. E.g. 'If scan times out, try a smaller target scope. If PoC verification fails, check that the vulnerability is still present on the target.'
• Provide tool annotations (readOnlyHint, idempotentHint) to clarify which tools are safe to retry and which modify state. All four tools appear read-only, annotate them explicitly.