Strong schema definitions with Pydantic annotations and tool annotations present. All 12 tools have descriptions and input schemas with type constraints. However, descriptions are domain-jargon-heavy ('Gate 4A semantics', 'context abstention', 'HITL') and lack actionable guidance for LLM selection. Parameter descriptions are minimal (often just the constraint, not the purpose). Output schemas are not documented. Error handling is present but generic. Tool composition is sound, each tool has a single responsibility and proper verb naming.

• Rewrite tool descriptions to answer: WHAT does it do? WHEN to call it instead of similar tools? WHAT does it return? Example: 'get_expense_status returns the current approval state and risk classification. Call this to check if an expense is pending, approved, or escalated. Use explain_risk for detailed risk signals.'
• Document output schemas as structured comments or Pydantic models. Specify all returned fields, types, and meanings. Example: 'Returns {expense_id: str, status: "pending"|"approved"|"rejected", risk_score: float, routing_path: str}'.
• Add recovery guidance to error scenarios. Example: 'If expense not found, call list_pending_approvals() to discover available expenses, or search_policy_context() to verify the expense category is valid.'
• For get_decision_trace and verify_decision_provenance, make expense_id and provenance_id mutually exclusive with clear validation. Return error: 'Provide exactly one of expense_id or provenance_id, not both.'
• Replace jargon with plain language. Define 'Gate 4A semantics' inline, explain 'context abstention' as 'preserves policy context separately from risk signals', and clarify 'HITL' as 'human-in-the-loop approval'.

Inferred effective spec: 2026-07-28+.

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