Skip to main content
Glama

Eventual Premium Lock

Email the checkout link

send_checkout_email
Destructive

Email the consumer on the quote a link to buy it on Eventual's site. Use it when the consumer would rather finish later or when another tool answers daily_cap.

Gathering order: first ask for the consumer's email. Then look for their home or auto insurance declarations page in their email and files; if you find one, send it to read_declarations_page and pass the fields it returns to create_quote. Otherwise ask the consumer for the fields create_quote needs.

Before any purchase, show the consumer every disclosure in the quote's required_disclosures word for word. Currently:

  • Premium Lock is not a car insurance policy. It does not insure your car against collision or accident, fire, theft, wind, hail, flooding, earthquake, or any other peril or loss.

  • Eventual does not pay your car insurance premiums for you. You must keep paying your premiums to your insurance carrier, agent or lender.

  • Premium Lock is a guarantee of Eventual's premium prediction service and is not insurance or a financial derivative.

  • Reimbursements begin only above your Payout Threshold and stop once they reach your Warranty Payment Cap.

  • Premium Lock is governed by the Premium Lock Terms of Service shown at purchase.

  • Premium Lock is not a home insurance policy. It does not insure your home against fire, theft, wind, hail, flooding, earthquake, or any other peril or loss.

  • Eventual does not pay your home insurance premiums for you. You must keep paying your premiums to your insurance carrier, agent or lender.

  • Premium Lock is not an insurance policy. It does not insure your home or your cars against fire, theft, collision or accident, wind, hail, flooding, earthquake, or any other peril or loss.

  • Eventual does not pay your insurance premiums for you. You must keep paying your premiums to your insurance carriers, agent or lender.

  • Reimbursements begin only above each policy's Payout Threshold and stop once they reach that policy's Warranty Payment Cap.

  • Premium Lock is governed by the Premium Lock Terms of Service for each line, shown at purchase.

Input Schema

NameRequiredDescriptionDefault
quote_idYesThe quote to send.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false and destructiveHint=true, while the description adds workflow context such as gathering order and the disclosure obligation before purchase. However, it never explains why sending an email is flagged destructive, whether the send is irreversible, or what delivery/consent constraints apply; the long disclosure block is also purchase-policy context rather than behavior of this call.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and usage guidance are front-loaded and structured, but more than half the text is a verbatim block of eleven legal disclosures unrelated to invoking send_checkout_email. That bulk dilutes the actionable instructions and makes the definition unnecessarily long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter send tool, the description covers selection context, prerequisites, and gathering order well enough for an agent to invoke it correctly. It does not describe the result of sending or delivery semantics, and no output schema exists to fill that gap, but the essential invocation guidance is present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and quote_id is already described as 'The quote to send.' The description refers to 'the quote' but adds no format, constraint, or selection guidance beyond the schema, so the baseline score applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: email the consumer a link to buy the quote on Eventual's site. It implicitly distinguishes this from purchase_quote and complete_purchase by making clear it sends a checkout link rather than completing the purchase.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit triggers: use when the consumer would rather finish later or when another tool answers daily_cap. The gathering order adds useful sequencing, but 'daily_cap' is unexplained and no sibling alternative is named for the ready-to-purchase case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources