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., "@Lemonade MCP Server Get a renters insurance quote for ZIP code 10001"
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.
An MCP (Model Context Protocol) connector for Lemonade insurance. This package enables AI assistants like Claude to interact with Lemonade's insurance services for renters, homeowners, pet, and car insurance.
This MCP server provides tools to:
Get insurance quotes for renters, homeowners, pet, and car insurance
View existing policy details
File insurance claims
Check claim statuses
Update policy coverage
Retrieve policy documents
Contact Lemonade customer support
The server uses Playwright for browser automation against lemonade.com and communicates via stdio transport following the Model Context Protocol specification.
Related MCP server: Playwright MCP Automation
Node.js 18 or later
Playwright with Chromium browser installed
npm install @striderlabs/mcp-lemonade
npx playwright install chromiumOr install globally:
npm install -g @striderlabs/mcp-lemonade
npx playwright install chromiumAdd the following to your Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"lemonade": {
"command": "npx",
"args": ["@striderlabs/mcp-lemonade"]
}
}
}If installed globally:
{
"mcpServers": {
"lemonade": {
"command": "mcp-lemonade"
}
}
}For any MCP-compatible client, configure the server to run:
npx @striderlabs/mcp-lemonadeThe server communicates over stdio.
get_quoteGet an insurance quote from Lemonade.
Parameters:
Parameter | Type | Required | Description |
| string (enum) | Yes | One of: |
| string | Yes | ZIP code for the insurance location |
| number | No | Desired coverage amount in dollars |
| object | No | Additional information specific to the insurance type |
Example:
Get me a renters insurance quote for ZIP code 10001 with $50,000 coverageview_policyView details of an existing Lemonade insurance policy.
Parameters:
Parameter | Type | Required | Description |
| string | Yes | Email address associated with the policy |
| string | No | The policy ID to retrieve |
Example:
Show me my Lemonade policy details for user@example.comfile_claimFile a new insurance claim with Lemonade.
Parameters:
Parameter | Type | Required | Description |
| string | Yes | The policy ID for which to file the claim |
| string | Yes | Type of claim (e.g., theft, damage, medical) |
| string | Yes | Detailed description of the incident |
| string | Yes | Date of the incident (YYYY-MM-DD format) |
| number | No | Estimated loss amount in dollars |
Example:
File a theft claim for policy LM-12345, my laptop was stolen on 2024-01-15, estimated loss $1,500check_claim_statusCheck the status of an existing Lemonade insurance claim.
Parameters:
Parameter | Type | Required | Description |
| string | Yes | The claim ID to check |
| string | Yes | Email address associated with the claim |
Example:
Check the status of claim CLM-67890 for user@example.comupdate_coverageUpdate coverage on an existing Lemonade insurance policy.
Parameters:
Parameter | Type | Required | Description |
| string | Yes | The policy ID to update |
| object | Yes | Object describing the coverage changes |
| number | No | New coverage amount in dollars |
| number | No | New deductible amount in dollars |
| string[] | No | List of add-ons to add or remove |
Example:
Update policy LM-12345 to increase coverage to $75,000 and lower deductible to $500get_documentsRetrieve policy documents from Lemonade.
Parameters:
Parameter | Type | Required | Description |
| string | Yes | The policy ID to get documents for |
| string | Yes | Email address associated with the policy |
| string (enum) | No | One of: |
Example:
Get the declarations page for policy LM-12345 associated with user@example.comcontact_supportContact Lemonade customer support.
Parameters:
Parameter | Type | Required | Description |
| string | Yes | Subject of the support request |
| string | Yes | Detailed message for support |
| string | Yes | Email address for the response |
| string | No | Policy ID related to the support request |
| string (enum) | No | One of: |
Example:
Contact Lemonade support about a billing question for policy LM-12345, prefer email contactHere are some natural language prompts you can use with Claude after configuring this MCP server:
"Get me a homeowners insurance quote for ZIP 90210"
"What are my Lemonade policy details? My email is john@example.com"
"I need to file a water damage claim for policy LM-98765. The incident happened on 2024-01-20 and estimated damage is $3,000"
"Check the status of my claim CLM-11111, my email is jane@example.com"
"Update my renters insurance policy LM-55555 to add jewelry coverage"
"Download my insurance ID card for policy LM-77777, email is user@example.com"
"I have a question about my premium increase. Contact Lemonade support by phone for policy LM-33333"This package uses Playwright for browser automation to interact with lemonade.com. You must install the Chromium browser separately:
npx playwright install chromiumThe browser runs in headless mode by default. Some operations (viewing policies, filing claims, updating coverage, getting documents) require Lemonade account authentication and will return step-by-step instructions for completing the action in the Lemonade app or website, as automated login is not supported for security reasons.
# Clone and install dependencies
git clone <repo-url>
cd mcp-lemonade
npm install
# Install Playwright browsers
npx playwright install chromium
# Build
npm run build
# Run in development mode
npm run devMIT - Strider Labs
Check the status of an existing Lemonade insurance claim
| Name | Required | Description | Default |
|---|---|---|---|
| claim_id | Yes | The claim ID to check | |
| Yes | Email address associated with the claim |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It implies a read-only operation via 'Check' and constrains scope with 'existing', but lacks details on return format, error handling (e.g., claim not found), idempotency, or authentication requirements. Adequate but minimal for a simple status retrieval 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?
Single sentence of eight words with action verb front-loaded. Zero redundancy or waste. Every word serves the purpose of identifying the tool's function.
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 two-parameter tool without output schema, the description adequately covers the core function but has clear gaps regarding return values (what status states exist), error scenarios, and pagination (if applicable). Minimum viable for the complexity level.
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 has 100% description coverage ('The claim ID to check', 'Email address associated with the claim'). The description reinforces the 'existing' constraint for claim_id but adds no syntax details, format examples, or cross-parameter validation rules (e.g., email must match claim owner). Baseline 3 appropriate when schema does heavy lifting.
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 uses specific verb 'Check' with clear resource 'status of an existing Lemonade insurance claim'. The term 'existing' effectively distinguishes this from sibling 'file_claim' (new claims), while 'status' differentiates it from 'get_documents', 'view_policy', and other siblings.
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 word 'existing' implies this is for previously filed claims, providing implicit context for when to use versus 'file_claim'. However, there is no explicit guidance on when to use this tool versus alternatives, prerequisites, or exclusion criteria (e.g., claim age limits).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Contact Lemonade customer support
| Name | Required | Description | Default |
|---|---|---|---|
| subject | Yes | Subject of the support request | |
| message | Yes | Detailed message for support | |
| policy_id | No | Policy ID related to the support request (optional) | |
| contact_method | No | Preferred contact method | |
| Yes | Email address for the response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to specify response expectations (async vs sync), whether a ticket ID is returned, rate limits, or confirmation mechanisms. 'Contact' implies the action but not the outcome.
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 single sentence is efficient with no redundant words, achieving brevity. However, it is underweight for a 5-parameter tool with no output schema, leaving significant informational gaps that additional sentences could fill.
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 tool with 5 parameters (3 required) and no output schema or annotations, the description is inadequate. It omits what the tool returns (ticket reference?), response timeframes, and the relationship between the optional policy_id parameter and the support request routing.
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 input schema has 100% description coverage, documenting all 5 parameters including the enum values for contact_method. The description adds no parameter-specific guidance, but with complete schema coverage, the baseline score 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 clearly states the action ('Contact') and target ('Lemonade customer support'), providing specific verb and resource identification. However, it fails to explicitly distinguish from siblings like 'file_claim' or 'view_policy' regarding when human support is preferable to automated operations.
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 no guidance on when to use this tool versus handling issues through other available tools (e.g., checking claim status first, or filing a claim directly). It lacks prerequisites, escalation criteria, or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
File a new insurance claim with Lemonade
| Name | Required | Description | Default |
|---|---|---|---|
| policy_id | Yes | The policy ID for which to file the claim | |
| claim_type | Yes | Type of claim (e.g., theft, damage, medical) | |
| description | Yes | Detailed description of the incident | |
| incident_date | Yes | Date of the incident (YYYY-MM-DD format) | |
| estimated_loss | No | Estimated loss amount in dollars |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. While 'File' implies a write operation, the description omits critical behavioral details: whether the action is reversible, what confirmation or claim ID is returned, authentication requirements, or side effects like policy notifications.
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 single sentence is efficient and front-loaded, but arguably too minimal for a 5-parameter mutation tool with no annotations. It represents under-specification rather than optimal conciseness given the operational complexity.
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 mutation tool handling financial transactions with 4 required parameters and no output schema or annotations, the description is inadequate. It lacks explanation of return values, success/failure behavior, or post-filing workflow that would help an agent handle the response appropriately.
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%, documenting all 5 parameters (policy_id, claim_type, description, incident_date, estimated_loss). The description adds no parameter-specific context beyond the schema, which aligns with the baseline score for high-coverage schemas.
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 ('File') with a clear resource ('insurance claim') and provider context ('with Lemonade'). It effectively distinguishes from siblings like check_claim_status (query vs. create) and contact_support (communication vs. transaction).
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 states what the tool does but provides no guidance on when to use it versus alternatives. It fails to mention prerequisites (e.g., active policy required), preconditions (e.g., verify claim doesn't already exist via check_claim_status), or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve policy documents from Lemonade (declarations page, policy contract, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| policy_id | Yes | The policy ID to get documents for | |
| document_type | No | Type of document to retrieve | |
| Yes | Email address associated with the policy |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. While it lists document types, it fails to specify return format (URL, base64, email attachment?), idempotency, or sensitivity handling. The email requirement implies verification occurs, but this isn't explained.
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, efficient sentence with action verb front-loaded. Parenthetical examples are high-information and zero waste. Appropriate length for the tool's complexity.
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?
Adequate for parameter documentation given 100% schema coverage, but lacks critical behavioral context: no output schema exists, yet the description doesn't explain what the tool returns (download link, document content, or email trigger), which is essential for invocation confidence.
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%, establishing baseline 3. Description adds value by mapping technical enum values to user-friendly examples ('declarations page' vs 'declarations') and providing provider context (Lemonade) that clarifies the policy_id domain.
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?
Specific verb (Retrieve) + resource (policy documents) + provider context (Lemonade) + concrete examples (declarations page, policy contract) clearly distinguish this from sibling tools like view_policy (which likely returns metadata rather than actual documents).
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 implied usage context (when you need policy documents), but lacks explicit when-to-use guidance versus alternatives like view_policy, and doesn't specify prerequisites or exclusions (e.g., whether policy must be active).
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 Lemonade for renters, homeowners, pet, or car insurance
| Name | Required | Description | Default |
|---|---|---|---|
| insurance_type | Yes | Type of insurance to get a quote for | |
| zip_code | Yes | ZIP code for the insurance location | |
| coverage_amount | No | Desired coverage amount in dollars (optional) | |
| additional_info | No | Additional information specific to the insurance type |
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 fails to disclose whether the tool creates persistent quote records, requires authentication, has rate limits, or what errors might occur. It does not indicate if this is a read-only calculation or a write operation.
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, efficient sentence with no filler. It immediately communicates the action, provider, and applicable insurance types without redundant phrasing.
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 presence of a nested object ('additional_info') and no output schema, the description meets minimum viability but lacks elaboration on what specific data belongs in the nested object or what the tool returns. It relies entirely on the schema for parameter documentation.
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%, establishing a baseline of 3. The description mirrors the enum values in the schema (renters, homeowners, pet, car) and adds provider context ('Lemonade'), but does not elaborate on the nested 'additional_info' object or provide syntax examples beyond what the schema specifies.
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 provides specific verb ('Get'), resource ('insurance quote'), provider ('Lemonade'), and exact insurance types. It clearly distinguishes from siblings which focus on claims (file_claim), existing policies (view_policy), or support (contact_support).
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 when-to-use or when-not-to-use guidance is provided. However, the scope is clear enough implicitly (prospective quotes vs existing policy management) that an agent can infer appropriate usage contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update coverage on an existing Lemonade insurance policy
| Name | Required | Description | Default |
|---|---|---|---|
| policy_id | Yes | The policy ID to update | |
| coverage_changes | Yes | Object describing the coverage changes to make |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden of behavioral disclosure. 'Update' implies mutation but does not specify if changes are immediate, reversible, trigger billing adjustments, or require additional approval. Critical gaps for a financial mutation 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?
Single sentence of 7 words with no redundancy. Information is front-loaded. Deduction from 5 due to extreme brevity given the lack of annotations and output schema, which creates an incomplete picture despite the concise phrasing.
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 zero annotations, no output schema, and nested object complexity, the description is insufficient. For an insurance policy mutation, it should disclose side effects (billing, effective dates) or refer to the nested coverage_changes structure, but it provides only nominal identification.
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%, establishing baseline 3. The description adds minimal param context beyond the schema—only the 'Lemonade' domain reference slightly enriches the policy_id semantics, but no syntax or format details are added.
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 verb (Update), resource (coverage), and scope (existing Lemonade insurance policy). The word 'existing' distinguishes it from get_quote (new policies), while 'coverage' distinguishes it from file_claim or view_policy.
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 versus alternatives. The word 'existing' provides weak implicit context that this is not for new policies, but lacks explicit exclusions like 'Do not use for filing claims—use file_claim instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View details of an existing Lemonade insurance policy
| Name | Required | Description | Default |
|---|---|---|---|
| policy_id | No | The policy ID to retrieve | |
| Yes | Email address associated with the policy |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but only offers minimal information. While 'view' implies read-only access, the description fails to specify error handling (e.g., policy not found), data scope (what specific details are returned), or whether this operation is safe/non-destructive.
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, efficient sentence of nine words with the action verb front-loaded. There is no redundant or wasteful text; every word contributes to understanding the tool's function.
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 simplicity (two flat parameters, no output schema), the description is minimally adequate. However, without an output schema, it could improve by specifying what policy details are returned (e.g., coverage amounts, effective dates) to set appropriate expectations for the agent.
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 input schema has 100% description coverage, establishing a baseline score of 3. The description does not add meaningful constraints or clarify the relationship between parameters (e.g., that 'email' is required but 'policy_id' is optional for lookup), but the schema documentation is sufficient.
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 ('View') and resource ('details of an existing Lemonade insurance policy'), including the specific provider context. However, it does not explicitly differentiate from the sibling tool 'get_documents', which could also return policy-related information, preventing a perfect score.
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 no guidance on when to use this tool versus alternatives like 'get_documents' (which may return policy files) or 'check_claim_status' (for claim-related lookups). There are no stated prerequisites or conditions for use.
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.0check_claim_statuscontact_supportfile_claimget_documentsget_quoteupdate_coverageview_policyEach tool has a clearly distinct purpose targeting specific insurance operations: checking claim status, contacting support, filing claims, retrieving documents, getting quotes, updating coverage, and viewing policies. There is no overlap or ambiguity between these functions.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., check_claim_status, file_claim, get_quote). The naming is uniform and predictable across all seven tools.
With 7 tools, the server is well-scoped for an insurance domain, covering key operations like quotes, policies, claims, and support. Each tool earns its place without being excessive or insufficient.
The tool set provides strong coverage for core insurance workflows, including quoting, policy management, claims, and support. A minor gap exists in lacking a tool for purchasing a policy after getting a quote, but agents can likely work around this.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
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-lemonade'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
