Four tools with basic descriptions but critical schema gaps. All tools lack explicit input parameter type definitions in visible code. Descriptions are present (50-150 chars) but generic, they explain the policy demo rather than guiding LLM tool selection. No output schemas documented. No error handling guidance. Tools are well-named (verb_noun pattern) but parameter descriptions are minimal. Security-focused domain is clear, but tool definitions do not meet production quality baselines.

• Add explicit JSON Schema with 'type' fields for all parameters. E.g., post_webhook: {"url": {"type": "string", "description": "HTTPS webhook URL (must match domain allowlist; see policy.yaml)"}, "body": {"type": "string", "description": "JSON body content (max 10KB)"}}.
• Document output schemas. E.g., post_webhook returns {"status": "success"|"blocked", "message": string, "audit_id": string}. search() returns {"results": [{"text": string, "redacted_fields": [string]}], "total_count": int}.
• Rewrite descriptions for LLM selection, not policy explanation. E.g., 'Send a webhook to an external URL. Use this to trigger integrations or notify external systems. Blocked if destination is outside the allowlist.' Include: what it does, when to use it, what it returns.
• Add error handling guidance in descriptions. E.g., read_file: 'Returns error if path is outside allowlist or file does not exist. Sensitive paths like /etc/passwd are blocked for security.'
• Expand parameter descriptions with constraints and examples. E.g., 'query' → 'Search query string (1-500 chars). Supports AND/OR operators. E.g., "user:admin AND status:active". Results are redacted if they contain PII (emails, API keys).' Use enums for constrained values (e.g., pii_action: ["redact", "block"]).