The Decide MCP server exposes two specialized policy-checking tools with well-structured input schemas and clear, domain-specific descriptions. Both tools declare explicit enums and required parameters, following constrained-input patterns. However, output schemas are not documented in the visible code, and descriptions, while clear, are moderately detailed but lack actionable guidance on error recovery and when to call each tool versus the other. Tool naming follows verb_noun convention. The server is clearly built for a specific domain (US subscription refunds and cancellations) with narrow scope, which is appropriate for a specialized policy engine.

• Document the output schema for both tools. Specify: What fields are returned when the tool succeeds? (e.g., {decision: 'ELIGIBLE'|'INELIGIBLE'|'UNKNOWN', reasoning: string, policy_version: string}). LLMs need to know what to extract and how to chain results downstream.
• Add recovery guidance to tool descriptions. Example: 'If the result is UNKNOWN, the vendor may require manual review or approval. Call [escalation_tool] to request manual policy review.' This tells the LLM what action to take when the tool cannot decide.
• Expand tool descriptions to clarify decision boundaries. Add: 'Use refund_eligibility to check if a refund is authorized under policy. Use cancellation_penalty to check if early cancellation incurs fees. Call refund_eligibility first to determine eligibility, then cancellation_penalty if the user wants to understand penalty terms.'
• Make cancellation_penalty parameter requirements explicit. Add a note: 'Most parameters are only required for Typeform (plan=basic). For other vendors, only vendor, region, and plan are required.' Consider splitting the schema or adding conditional examples in the description.
• Document the policy versioning and source attribution. The description mentions 'versioned source-backed rules' but does not explain how the version is determined or how to interpret policy changes. Add: 'Results reflect policy as of [date]. Policies are versioned and sourced from [vendor documentation URLs].'
• Add error classification to descriptions. Example: 'Returns INELIGIBLE when the policy explicitly denies the refund (e.g., outside refund window). Returns UNKNOWN when required conditions are missing or manual review is needed.' This guides the LLM on whether to retry, ask the user, or escalate.