Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Tool names follow verb_noun convention (check-cve, recent-cves). Descriptions are present but minimal (18-52 chars, below the 50-200 char LLM-optimized baseline). Input schemas visible with type definitions, but parameter descriptions are sparse. No output schema documentation. No error handling guidance. No tool annotations (readOnlyHint). Composition is sound (single responsibility per tool), but parameter constraints and recovery paths are missing.

• Expand tool descriptions to 80-150 chars. Example for check-cve: 'Check if a CVE ID exists in the CISA Known Exploited Vulnerabilities list. Returns full vulnerability details (vendor, product, required action, due date) if found. Use this to verify if a specific CVE is actively exploited.'
• Document output schemas in tool registration. Add a 'returns' field or inline schema showing CVEResponse structure: {exists: bool, details: {cveID, vendorProject, product, vulnerabilityName, dateAdded, shortDescription, requiredAction, dueDate, knownRansomwareCampaignUse, notes, cwes}}.
• Add regex pattern constraint to cve_id parameter: pattern: '^CVE-\d{4}-\d{4,}$' and update description to 'CVE ID in format CVE-YYYY-NNNNN (e.g., CVE-2024-1234). Must be uppercase.'
• Implement error handling with recovery hints. Catch DuckDB/HTTP errors and return: {exists: false, error: 'CVE lookup failed: CISA API unreachable. Try again in 30 seconds or check your CVE ID format (CVE-YYYY-NNNNN).'} instead of raising exceptions.
• Add readOnlyHint: true to both tool schemas to signal to agents that these tools are safe to call without confirmation and can be retried.