get_policy_statusDemo tool — retrieve the simulated status of a demo parametric policy record. Returns simulated client details, trigger threshold, premium, payout amount, dates, and trigger history. No payment is accepted and no real policy or settlement is affected.
| Name | Required | Description | Default |
|---|---|---|---|
| policy_id | Yes | Policy ID returned by bind_policy. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals no mutation. The description adds that no payment is accepted and no real policy or settlement is affected, clarifying it's a demo tool. It also lists the data returned, giving more behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each carrying essential info: the first states the purpose and return content, the second clarifies the demo nature and lack of side effects. Front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lists key return fields (client details, threshold, premium, payout, dates, history), giving a good idea of output. No output schema exists, but for a demo tool this is sufficient. Could mention response format or error behavior, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents the single parameter policy_id as 'Policy ID returned by bind_policy,' which is clear and ties to a sibling. The description does not add further parameter details, but schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States 'retrieve the simulated status of a demo parametric policy record' — a specific verb and resource. It distinguishes from siblings by focusing on a single policy's status, including history, unlike check_trigger which likely checks trigger conditions or bind_policy which creates records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that it retrieves status of a simulated policy, but does not explicitly state when to use it versus sibling tools like check_trigger or get_parametric_quote. No exclusions or alternatives are mentioned, so the agent must infer usage from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool serves a distinct role in the parametric insurance workflow: risk assessment, quoting, binding, trigger checking, policy status, and carrier listing. There is no overlap or ambiguity in purpose, and the entry point is clearly marked.
All tool names follow a consistent verb_noun snake_case pattern (assess_weather_risk, bind_policy, check_trigger, get_parametric_quote, get_policy_status, list_carriers). No mixed conventions or irregularities.
Six tools is well-scoped for a demo parametric insurance server, covering the essential lifecycle steps without redundancy or unnecessary expansion. Each tool has a clear purpose.
The tool set covers the primary flow: assess risk, get quote, bind policy, check trigger, and retrieve status. It lacks update/cancel policy operations, but for a demo environment focused on quoting and triggering, this is a minor gap.