AI-native parametric insurance infrastructure. Assess weather risk, generate quotes, bind policies, and monitor triggers programmatically. Live paid endpoint via x402 (USDC on Solana).
[$0.10 USDC/call · Solana USDC · x402] Entry point for every agent flow. Given a business location and type, returns a weather risk score (0-1), the top perils ranked by severity, historical frequency data, and an overall risk level (low/moderate/high/severe). Powered by 20 years of Open-Meteo historical data — returns real data, not sandbox. Always call this first before requesting a quote.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | City and state of the business, e.g. 'Tampa, FL' or 'Kansas City, MO'. | |
| business_type | Yes | Type of business. Determines which perils are most relevant. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it returns real data, not sandbox, and mentions the cost per call. It also notes the data source (20 years of Open-Meteo historical data). The readOnlyHint annotation is present, and the description aligns with it. It doesn't describe the exact output structure, but the description provides enough context about what the tool returns.
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?
The description is concise and front-loaded with the most important information (cost, entry point). It uses a clear structure: cost, purpose, output, data source, and usage instruction. Every sentence adds value, and it's not overly verbose.
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?
Given the tool's complexity (returns multiple data points), the description is fairly complete. It mentions the risk score, perils, historical data, and risk level. It also notes the data source and the fact that it's real data. The lack of an output schema is compensated by the description's detail. It could mention the exact output format, but the description is sufficient for an agent to understand what to expect.
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 already has 100% description coverage for both parameters, so the description doesn't need to add much. However, the description adds context that business_type determines which perils are most relevant, which is not in the schema. This adds value beyond the schema.
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?
The description clearly states the tool's purpose: it assesses weather risk for a business location and type, returning a risk score, perils, historical data, and risk level. It distinguishes itself from siblings by being the entry point for every agent flow and explicitly says to call it first before requesting a quote.
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?
The description provides explicit usage guidance: 'Entry point for every agent flow' and 'Always call this first before requesting a quote.' It also mentions the cost per call, which is important for the agent to decide when to use it. It doesn't explicitly name alternatives, but the context of being the first step in a flow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Demo tool — simulate accepting a demo quote and binding a policy. Returns a demo policy_id, dates, trigger details, and confirmation. No real carrier is bound, no premium is charged, and no coverage is issued. No payment is accepted for this demo. Pass quote_id from the demo get_parametric_quote tool.
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | Yes | Quote ID returned by get_parametric_quote. | |
| broker_email | Yes | Email of the placing broker. | |
| payment_method | Yes | Payment method for the policy premium. Sandbox: no charge applied. | |
| client_business_name | Yes | Legal name of the insured business. | |
| client_contact_email | Yes | Email address of the client contact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the readOnlyHint annotation (false), providing extensive behavioral disclosure: it's a simulation, no real carrier bound, no premium charged, no coverage issued, and no payment accepted. It also specifies the return payload categories, giving the agent a clear picture of what to expect. This is exemplary transparency for a demo tool.
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?
The description is three brief sentences that efficiently convey purpose, returns, and demo constraints. It front-loads the core function and adds essential caveats without redundancy. Every sentence earns its place, and it avoids unnecessary detail.
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?
For a demo tool with 5 required parameters and no output schema, the description fully covers what it does, what it returns, and the demo limitations. The precondition (quote_id from get_parametric_quote) is stated. There are no nested objects or complex outputs requiring elaboration, so nothing essential is missing.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter-specific value beyond the schema: it repeats the quote_id source (already in the schema) and mentions payment_method only implicitly via 'No payment is accepted'. It does not explain broker_email, client_business_name, or client_contact_email beyond their schema descriptions, so no significant added meaning.
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?
The description clearly states the tool simulates accepting a demo quote and binding a policy, and lists the specific returns (demo policy_id, dates, trigger details, confirmation). It distinguishes itself from siblings by emphasizing the demo nature and referencing the get_parametric_quote tool as the source of quote_id, making its purpose unambiguous.
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?
It explicitly instructs to pass quote_id from the demo get_parametric_quote tool, establishing a clear precondition and sequence. It also clarifies this is a demo with no real carrier, premium, or coverage, which guides appropriate use. However, it does not mention alternative tools for different actions (e.g., get_policy_status for checking policy) or explicitly state when not to use it, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Demo tool — simulate whether a demo policy's parametric trigger is met. Returns a simulated observed weather value, trigger threshold, outcome, and data source. 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to state read-only. It adds valuable context: 'No payment is accepted and no real policy or settlement is affected' and details the simulated output (observed value, threshold, outcome, data source). This goes beyond the annotation and clarifies the tool's simulated nature and return components.
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?
The description is two sentences with no redundant words. The first sentence immediately states the core function and outputs, and the second adds the critical caveat about demo realism. It is front-loaded and efficient, earning every word.
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?
Given the simple single-parameter tool with annotations and no output schema, the description is sufficiently complete. It enumerates the return elements (observed value, threshold, outcome, data source) and clarifies the demo nature. It doesn't detail error handling or exact output format, but for a demo tool this is not a significant gap.
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?
Schema description coverage is 100%, with policy_id documented as 'Policy ID returned by bind_policy.' The description does not add any additional meaning or context for the parameter; it only mentions the tool's purpose, not how policy_id is used. Since the schema fully covers the parameter, the baseline score of 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?
The description clearly states the tool's purpose: 'simulate whether a demo policy's parametric trigger is met.' It specifies the action (check trigger), the resource (demo policy), and the output components (observed weather value, threshold, outcome, data source). This is distinct from siblings like assess_weather_risk (assessment) or get_policy_status (status), so it stands alone.
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?
The description identifies the tool as a 'demo tool' but offers no explicit guidance on when to use it versus alternatives. It does not mention sibling tools or state conditions for using this over assess_weather_risk or get_parametric_quote. The demo context is implied, but there's no clear when-to-use or when-not-to-use instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Demo tool — request a simulated parametric quote for a specific peril and coverage period. Returns a demo quote_id, carrier, premium, trigger threshold, payout amount, and coverage terms. No real carrier is involved and no payment is accepted. Pass the quote_id to the demo bind_policy tool.
| Name | Required | Description | Default |
|---|---|---|---|
| location | Yes | City and state of the business, e.g. 'Miami, FL'. | |
| peril_type | Yes | Weather peril to insure against. | |
| payout_limit | Yes | Maximum payout amount in USD (e.g. 50000 for $50,000). | |
| revenue_band | No | Optional. Annual revenue band for premium calibration. | |
| coverage_period_end | Yes | Coverage end date in YYYY-MM-DD format. | |
| coverage_period_start | Yes | Coverage start date in YYYY-MM-DD format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that this is a simulation ('Demo tool', 'simulated', 'No real carrier is involved and no payment is accepted'), which supplements the readOnlyHint:false annotation by clarifying there are no real-world side effects. Adds meaningful context about the non-production nature 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 with no wasted words. The purpose is front-loaded, return values are listed, and the demo qualifier is stated upfront. Every sentence earns its place.
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?
Since there is no output schema, the description compensates by listing the return fields (quote_id, carrier, premium, trigger threshold, payout amount, coverage terms). It also explains the demo nature and the next step (bind_policy). It is reasonably complete, though it could briefly mention the revenue_band parameter or any validation rules, but these are in the schema.
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?
Schema description coverage is 100%, so parameter details are already documented. The description reinforces that it takes a specific peril and coverage period but adds no additional syntactic or formatting detail beyond the schema. Baseline 3 is appropriate given the high coverage.
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 explicitly that it requests a simulated parametric quote for a peril and coverage period, and lists the return payload (quote_id, carrier, premium, etc.). It distinguishes itself from siblings by marking itself as a demo tool and mentioning the follow-up to bind_policy, making its role clear.
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?
Clearly frames the tool as a demo and provides a workflow direction ('Pass the quote_id to the demo bind_policy tool'). This implies when to use it (before binding) but doesn't explicitly contrast with alternatives like assess_weather_risk or check_trigger. Good context but no explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Demo 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. |
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.
Demo tool — list simulated carriers registered in the ParaSure demo environment. Returns a carrier name, supported perils, regions, and products. No payment is accepted; the only listed carrier is simulated and live carrier integrations are not yet available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds valuable context: it's a demo tool, only one simulated carrier exists, no payment is accepted, and live integrations are not available. This helps set expectations about data quality and scope, which the annotation alone does not convey.
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?
The description is two concise sentences with no fluff. The core purpose and key constraints are front-loaded, and every sentence adds information. It is well-structured and scannable.
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?
For a zero-parameter demo tool without an output schema, the description covers what it returns, the simulation nature, and payment restrictions. It lacks details like pagination or response format, but these are less critical for a simple demo list tool. A 4 is appropriate.
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 tool has zero parameters, so no parameter explanation is needed. The baseline for zero parameter tools is 4, and the description doesn't need to add anything further.
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?
The description clearly states the action ('list') and the resource ('simulated carriers registered in the ParaSure demo environment'), and distinguishes it from the mutating and quoting sibling tools. It also specifies the return fields (carrier name, perils, regions, products), making the purpose unambiguous.
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?
No explicit guidance on when to use this tool versus alternatives. The description hints at a demo/read-only context but does not mention when to prefer it over, say, get_parametric_quote or check_trigger. It lacks 'when not to use' clauses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
assess_weather_riskbind_policycheck_triggerget_parametric_quoteget_policy_statuslist_carriersClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
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.