Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@striderlabs/mcp-progressive Get an auto insurance quote for a 2021 Honda Accord in ZIP 43215."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Progressive Insurance MCP connector for personal AI agents. Provides tools to get quotes, look up policies, check claims, manage payments, retrieve ID cards, get coverage recommendations, and request roadside assistance.
Instant quotes for auto, home, and renters insurance
Policy lookup with full coverage and premium details
Claims tracking with timeline, adjuster info, and pending actions
Payment management — view balance, pay, set up autopay, update methods
Coverage recommendations personalized to your profile
Digital ID cards in text, PDF, or wallet pass format
Roadside assistance dispatch with live ETA and tracking
Related MCP server: @striderlabs/mcp-statefarm
npm install @striderlabs/mcp-progressive~/Library/Application Support/Claude/claude_desktop_config.json){
"mcpServers": {
"progressive": {
"command": "npx",
"args": ["-y", "@striderlabs/mcp-progressive"]
}
}
}mcp.json){
"servers": {
"progressive": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@striderlabs/mcp-progressive"]
}
}
}{
"mcpServers": {
"progressive": {
"command": "node",
"args": ["/path/to/node_modules/@striderlabs/mcp-progressive/dist/index.js"]
}
}
}Tool | Description |
| Get an auto, home, or renters insurance quote |
| Look up policy details by number or credentials |
| Check claim status, adjuster, timeline, and actions |
| View balance, pay, autopay, update payment methods |
| Get personalized coverage recommendations |
| Retrieve digital insurance ID card |
| Request, track, or cancel roadside assistance |
Get me an auto insurance quote for a 2021 Honda Accord in ZIP 43215.
Driver: Jane Doe, born 1988-04-15. I want standard coverage.Look up my Progressive policy number 912345678.What's the status of my Progressive claim XX-1234567-XX?Pay $126.50 on my Progressive policy 912345678
using my Visa card ending in 4242.I have a flat tire. Request roadside assistance on my policy 912345678.
I'm at 123 Main St, Columbus OH 43215.
Call me at (614) 555-0100 when the driver is close.What coverage should I add to my Progressive policy 912345678?Show me my insurance ID card for policy 912345678 as a wallet pass.git clone <repo>
cd striderlabs-mcp-progressive
npm install
npm run build
npm startThis connector returns simulated data for demonstration purposes. Integration with Progressive's live API requires OAuth credentials obtained through Progressive's developer program.
Contact Progressive at 1-800-776-4737 or visit progressive.com for real account operations.
MIT
Check the status of an existing Progressive insurance claim. Returns claim details, current status, assigned adjuster, and any pending action items.
| Name | Required | Description | Default |
|---|---|---|---|
| claim_number | No | Progressive claim number (e.g., 'XX-XXXXXXX-XX'). | |
| date_of_loss | No | Date of the incident in YYYY-MM-DD format. Used to help locate a claim. | |
| policy_number | No | Policy number to list all claims if no specific claim number is provided. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries transparency burden. It implies read-only by stating 'check' but does not explicitly confirm no side effects. Lacks details on authorization or rate limits.
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 pack purpose and outputs efficiently. No redundant words; front-loaded with key info.
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?
Describes returned info types but no output schema. Does not explain parameter interaction (e.g., if claim_number and policy_number are both provided, which takes precedence). Lacks error handling cues.
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 covers all 3 parameters with descriptions. Description does not add new meaning beyond 'check status' and listing return fields. Baseline 3 for full schema 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?
Description explicitly states the tool checks claim status and lists specific outputs (details, status, adjuster, action items). Clearly differentiates from siblings like progressive_policy_lookup and progressive_get_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?
No guidance on when to use this tool vs. alternatives. Does not mention prerequisites or that at least one parameter (like claim_number) should be provided. No explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get personalized insurance coverage recommendations from Progressive based on your profile, assets, and risk factors. Returns suggested coverage types, limits, and estimated cost impact.
| Name | Required | Description | Default |
|---|---|---|---|
| profile | No | Customer profile for new recommendation without an existing policy. | |
| coverage_type | No | Coverage type to get recommendations for. Defaults to 'all'. | |
| policy_number | No | Existing policy number to base recommendations on current coverage. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It mentions return types (suggested coverage, limits, cost impact) but lacks details on computational behavior (e.g., algorithm basis, authentication needs). Adequate but not rich.
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 a single concise sentence that is front-loaded with the key action and resource. Efficient, though could be slightly more structured.
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 no output schema, the description adequately covers return values (coverage types, limits, cost impact). The tool's complexity is moderate, and sibling tools provide context. Sufficiently complete for this use case.
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 baseline is 3. The description adds minimal semantic context beyond the schema (e.g., 'based on your profile, assets, and risk factors'), but does not significantly enhance parameter understanding.
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 uses a specific verb ('Get') and resource ('personalized insurance coverage recommendations'), and clearly differentiates from siblings like progressive_policy_lookup (policy lookup) and progressive_get_quote (quote for specific coverage).
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 indicates when to use (based on profile, assets, risk factors) but does not explicitly state when not to use or name alternatives, though siblings provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an insurance quote from Progressive for auto, home, or renters policies. Returns an estimated premium range, coverage options, and a quote ID for follow-up.
| Name | Required | Description | Default |
|---|---|---|---|
| drivers | No | Array of driver info objects (auto only). | |
| property | No | Property details (home or renters only). | |
| vehicles | No | Array of vehicle info objects (auto only). | |
| zip_code | Yes | 5-digit ZIP code for the primary insured location. | |
| coverage_tier | No | Desired coverage tier. Defaults to 'standard' if omitted. | |
| insurance_type | Yes | Type of insurance policy to quote. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose whether the tool is read-only or creates data, does not mention authentication, rate limits, or side effects. The term 'Get' may mislead about mutability.
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?
Single sentence, 22 words, front-loaded with action and returns. No redundant phrasing. Could benefit from slight structuring (e.g., bullet points) but remains concise.
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?
No output schema, so description must explain returns. It mentions premium range, coverage options, and quote ID but is vague (e.g., not specifying that driver info is required for auto). Lacks details on error handling or required nested objects.
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 baseline is 3. Tool description adds context about insurance types and returns but does not enhance per-parameter meaning beyond 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?
Description clearly states it gets an insurance quote for auto, home, or renters policies from Progressive, and lists specific returns (premium range, coverage options, quote ID). This differentiates it from sibling tools like policy lookup or claims.
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?
Implies usage for obtaining quotes but provides no explicit guidance on when to use this tool vs alternatives (e.g., progressive_coverage_recommendations). No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a digital insurance ID card for a Progressive auto policy. Returns card details (policy number, vehicle, coverage dates) that can be shown to law enforcement or stored digitally.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format. 'text' returns plain-text card details, 'pdf_url' returns a download link, 'wallet_pass' returns an Apple/Google Wallet add link. | |
| vehicle_vin | No | Specific vehicle VIN if policy has multiple vehicles. Returns ID card for all vehicles if omitted. | |
| policy_number | Yes | Progressive auto policy number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions return content (policy number, vehicle, coverage dates) but does not disclose read-only nature, authentication needs, or limitations (e.g., only valid during coverage period). Adequate but not detailed.
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, front-loaded with action verb, no redundant words. Every sentence adds value.
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 simple retrieval tool with 3 parameters and no output schema, description provides essential return details and format options. Minor gap: does not specify that policy must exist or be active.
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 coverage is 100% and description adds minimal extra meaning beyond schema. The description notes what is returned but does not clarify parameter behaviors (e.g., format enum implications beyond 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?
Clearly states 'Retrieve a digital insurance ID card for a Progressive auto policy'. Differentiates from siblings like policy_lookup, get_quote, claims_status by specifying a retrieval of an ID card for law enforcement or digital storage.
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?
Implies usage for proof of insurance ('shown to law enforcement or stored digitally') but provides no explicit guidance on when to use this tool versus siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage payments for a Progressive policy. Supports viewing payment history, upcoming due dates, making a payment, setting up autopay, and updating payment methods.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Payment action to perform. | |
| policy_number | Yes | Policy number to manage payments for. | |
| payment_amount | No | Amount to pay in USD (required for make_payment). | |
| payment_method | No | Payment method details (required for make_payment, setup_autopay, update_payment_method). | |
| autopay_schedule | No | Autopay billing schedule (required for setup_autopay). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It lists supported actions but omits behavioral traits such as side effects (e.g., destructive writes), authentication needs, or rate limits.
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 a single concise sentence with a clear list of supported actions, no wasted words, and the main purpose front-loaded.
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 (5 parameters, nested objects, multiple actions) and no output schema, the description lacks details on parameter-action dependencies and usage flows, making it incomplete for correct agent invocation.
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%, and the description does not add additional meaning beyond the parameters defined in the schema. 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 it manages payments for a Progressive policy and lists specific actions, distinguishing it from sibling tools like progressive_policy_lookup or progressive_get_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 implies usage through its name and action list, but does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an existing Progressive policy by policy number or customer credentials. Returns policy details including coverages, deductibles, premium, and renewal date.
| Name | Required | Description | Default |
|---|---|---|---|
| No | Account email address for lookup without policy number. | ||
| last_name | No | Last name on the policy (required with email lookup). | |
| date_of_birth | No | Date of birth in YYYY-MM-DD format (required with email lookup). | |
| policy_number | No | Progressive policy number (e.g., '912345678'). Provide this OR email + last_name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns policy details including coverages, deductibles, premium, and renewal date, indicating a read operation. However, it does not cover error scenarios, rate limits, or authorization requirements.
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 a single, well-structured sentence that conveys purpose, lookup methods, and return data without redundancy or wordiness.
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 no output schema, the description adequately names the key return fields (coverages, deductibles, premium, renewal date). It covers the two lookup modes. However, it lacks information on error handling or what happens if no policy is found.
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 each parameter having a clear description. The tool description adds value by clarifying the 'OR' relationship between policy_number and the email+last_name+date_of_birth triplet, which is not explicit in 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 looks up an existing Progressive policy by policy number or customer credentials, and lists returned details. This specifically distinguishes it from sibling tools like progressive_get_quote or progressive_claims_status.
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 implies two lookup methods (policy number vs. email+credentials) but does not explicitly state when to prefer one over the other, nor does it mention alternatives from sibling tools. There is no guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request roadside assistance through Progressive. Supports towing, flat tire, lockout, jump start, fuel delivery, and winch-out services. Tracks dispatch and ETA.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Roadside assistance action to perform. | |
| location | No | Vehicle location (required for request_service). | |
| request_id | No | Existing roadside request ID (required for check_status and cancel_request). | |
| service_type | No | Type of service needed (required for request_service). | |
| vehicle_info | No | Vehicle details for the disabled vehicle (required for request_service). | |
| contact_phone | No | Phone number for the service provider to call (required for request_service). | |
| policy_number | Yes | Progressive policy number with roadside coverage. | |
| tow_destination | No | Destination address for towing service (optional, defaults to nearest covered repair shop). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It describes supported services and tracking but does not disclose side effects (e.g., dispatching a truck) or request lifecycle details (e.g., cancellation consequences). It adds moderate context beyond an empty description.
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?
Three sentences with the core purpose first, followed by supported services and tracking capability. No fluff or redundancy; efficient and well-structured for quick parsing.
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?
Despite having 8 parameters (including nested objects) and no output schema, the description does not explain the different actions (request_service, check_status, cancel_request), required parameters per action, or response format (e.g., request ID, ETA). It leaves significant gaps for a tool of this complexity.
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 coverage is 100% with adequate descriptions for all parameters. The description adds no new meaning beyond enumerating service types, which is already covered by the service_type enum. Baseline of 3 applies.
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 explicitly states 'Request roadside assistance through Progressive' and lists six specific services (towing, flat tire, etc.). It clearly distinguishes from sibling tools that handle policy lookup, quotes, and claims.
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 implies usage for roadside assistance but provides no when-to-use or when-not-to-use guidance. It does not mention prerequisites like having roadside coverage or alternative tools for non-Progressive customers.
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.
v1.0.0progressive_claims_statusprogressive_coverage_recommendationsprogressive_get_quoteprogressive_id_cardprogressive_payment_managementprogressive_policy_lookupprogressive_roadside_assistanceEach of the seven tools has a clearly distinct purpose: policy lookup, quote, claims, payments, recommendations, ID card, and roadside assistance. There is no overlap in functionality.
All tool names follow a consistent 'progressive_' prefix followed by a verb_noun pattern (e.g., progressive_policy_lookup, progressive_get_quote). The naming is uniform and predictable.
Seven tools is an appropriate number for an insurance MCP server, covering core customer-facing actions without being overwhelming or too sparse.
The tool set covers most key insurance interactions (quotes, policies, claims, payments, roadside assistance, ID cards, recommendations). Missing are policy binding, cancellation, or update tools, but the core workflow is well-represented.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Real, bindable home & auto insurance quotes via MCP (Texas, expanding); human-completed bind.
Agent-native insurance quoting protocol — sandbox, MCP + REST, eligibility pre-flight
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Let AI agents query data and act across all your business apps via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/markswendsen-code/mcp-progressive'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
