Agent Guard has 11 tools with moderate definition quality. Most tool names follow verb_noun patterns (task/get, evidence/submit, artifact/get), which is good. However, descriptions are present but often terse (10-50 chars), lacking LLM-guidance on WHEN to use tools and what prerequisites exist. Schemas are partially defined, several tools have input parameters with types and descriptions (e.g., evidence/submit has evidence_id and data with types), but critical output schemas are NOT documented anywhere in the visible code. Tool descriptions rarely explain state transitions, error conditions, or recovery paths. Parameter descriptions are minimal and do not follow the pattern of stating constraints, formats, or ranges. No visible error guidance or recovery hints. Security concerns: tools like task/complete and artifact/put perform state-modifying operations without explicit confirmation or dry-run support. The codebase shows audit events are logged, but tool descriptions do not declare what permissions each tool requires (no scope declarations). Overall, the server is functional but lacks the polish and LLM-friendliness expected of production-grade agent tools.

• Add output schema documentation to every tool. Create a comment block above each handler listing return fields, types, and examples. E.g., 'Returns: {contract_id: string, task: object, evidence: object, bounds: object}'.
• Expand all descriptions to 50-200 chars with explicit WHEN/WHY guidance. Example: 'Get the current task contract. Call this first to see what evidence is required, then call evidence/submit for each requirement. If task is already done, use status/get instead.'
• Add descriptions to ALL parameters. For 'data' in evidence/submit, document the expected structure: 'Evidence data (object). Required fields depend on evidence_id, see task/get to review the schema for each requirement.'
• Add error recovery hints to descriptions. E.g., evidence/submit: 'Returns error if evidence_id is invalid (try task/get to list valid IDs) or if max submissions exceeded (current limit: 50).'
• Implement a dry-run or confirmation mode for destructive tools. Add optional 'dry_run: bool' parameter to task/complete and task/cancel-child. Document the two-phase flow in descriptions.
• Add scope/permission declarations to tool descriptions. E.g., 'Requires: write:tasks, read:contracts. Audit event recorded.' This matches the code's audit logging and helps agents self-restrict.
• Document required evidence schema for each task. When task/get returns a contract, include an 'evidence_schema' field that maps evidence_id → required fields. Then evidence/submit description can say: 'data must match schema from task/get.'

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

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