Click on "Deploy 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-statefarm Auto quote for 2021 Toyota Camry in 90210"
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.
State Farm Insurance connector for personal AI agents — get quotes, manage policies, file claims, and more.
Built by Strider Labs using the Model Context Protocol.
Insurance Quotes — Get auto, home, life, and renters quotes with estimated premiums
Policy Management — Look up policy details, coverage, and renewal dates
Claims — File new claims and check status on existing ones
Payments — View balances, make payments, and manage autopay
Digital ID Cards — Access and share your auto insurance ID card
Find Local Agents — Locate State Farm agents near any address
Roadside Assistance — Request towing, battery jumps, lockout help, and more
Bundle Recommendations — Get personalized multi-policy bundle suggestions with savings estimates
Related MCP server: AgentPhone MCP Server
npm install -g @striderlabs/mcp-statefarmOr run directly with npx:
npx @striderlabs/mcp-statefarmAdd to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"statefarm": {
"command": "npx",
"args": ["-y", "@striderlabs/mcp-statefarm"]
}
}
}{
"servers": {
"statefarm": {
"command": "npx",
"args": ["-y", "@striderlabs/mcp-statefarm"],
"transport": "stdio"
}
}
}Tool | Description |
| Get insurance quotes for auto, home, life, or renters |
| View policy coverage, deductibles, and renewal info |
| Initiate a new insurance claim |
| Check status on an existing claim |
| View balance, make payments, manage autopay |
| Get your auto insurance ID card |
| Find State Farm agents near a location |
| Request or check roadside assistance |
| Get personalized bundle savings recommendations |
Get me an auto insurance quote for a 2021 Toyota Camry in ZIP code 90210 for 2 drivers.The agent will call statefarm_get_quote with:
{
"insurance_type": "auto",
"zip_code": "90210",
"vehicle_year": 2021,
"vehicle_make": "Toyota",
"vehicle_model": "Camry",
"drivers_count": 2
}I was in a car accident today at 3pm at 123 Main St. My policy number is 123-4567-A01. Another driver was involved.The agent will call statefarm_file_claim with the incident details and return a reference number plus step-by-step filing instructions.
I own a home and a car in ZIP 60601. I have 3 kids and make about $120k/year. What should I bundle?The agent will call statefarm_bundle_recommendations and return prioritized bundle options with estimated savings.
My car battery died. I'm at 456 Oak Ave, Chicago. My callback number is 312-555-0100.The agent will call statefarm_roadside_assistance with action: "request_service" and service_type: "battery_jump".
Find me a Spanish-speaking State Farm agent near Dallas, TX.The agent will call statefarm_find_agent with location and language filter, returning a link to the agent locator pre-filtered for your search.
statefarm_get_quoteParameter | Type | Required | Description |
|
| ✅ | Type of insurance |
| string | ✅ | Quote location |
| number | Auto only | Model year |
| string | Auto only | Manufacturer |
| string | Auto only | Model name |
| number | Auto only | Number of drivers |
| number | Home only | Estimated home value (USD) |
| number | Home only | Year built |
| number | Home only | Square footage |
| number | Life only | Desired coverage (USD) |
| number | Life only | Applicant age |
|
| Life only | Policy type |
| number | Renters only | Belongings value (USD) |
statefarm_roadside_assistanceAction | Description |
| Dispatch roadside help to your location |
| Verify if your policy includes roadside |
| Track a dispatched service provider |
Available service types: towing, battery_jump, flat_tire, fuel_delivery, lockout, winching
statefarm_paymentAction | Description |
| See current amount due |
| View past payments |
| Pay your bill |
| Enable automatic payments |
| Disable automatic payments |
| Change bank account or card |
This connector provides guidance and structured information to help AI agents assist with State Farm insurance tasks
Actions that require account access (payments, policy details) include direct links and instructions for completing them through State Farm's secure portal
For emergencies, always call 1-800-STATE-FARM (1-800-782-8332) or 911 directly
Digital ID cards are legally accepted in all 50 US states
git clone https://github.com/striderlabs/mcp-statefarm
cd mcp-statefarm
npm install
npm run build
node dist/index.jsGet personalized insurance bundle recommendations from State Farm. Analyzes current coverage and suggests bundles that could save money by combining auto, home, life, and renters policies.
| Name | Required | Description | Default |
|---|---|---|---|
| own_home | No | Whether the customer owns their home | |
| priority | No | What to optimize bundle recommendations for (default: savings) | |
| zip_code | Yes | ZIP code for location-based recommendations | |
| own_vehicle | No | Whether the customer owns a vehicle | |
| annual_income | No | Annual household income in USD (used to suggest appropriate coverage levels) | |
| has_dependents | No | Whether the customer has dependents (relevant for life insurance) | |
| household_size | No | Number of people in the household | |
| current_policies | No | List of insurance types the customer currently has |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral disclosure. It does convey that the tool 'analyzes' and 'suggests' rather than executes a purchase or quote, which is useful read-only context. However, it does not explicitly state that no policy is created, that recommendations are non-binding estimates, or whether any external system is affected.
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 concise sentences with no filler. The first sentence front-loads the core action, and the second explains the analysis approach. Every phrase contributes useful meaning, and there is no redundant restatement of the schema.
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 moderate complexity, the detailed schema, and the absence of an output schema, the description provides a solid overview of what the tool does and roughly what it returns (bundle suggestions with savings potential). It could be slightly more complete by stating the output format or emphasizing that only zip_code is required, but the schema compensates for those gaps.
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 parameters are already well documented. The description does not add much beyond mentioning the policy types involved in bundling, which maps to current_policies. Since the schema carries the full semantic load, 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 states a specific action ('Get personalized insurance bundle recommendations') and a clear resource scope: analyzing current coverage and suggesting bundle savings across auto, home, life, and renters. This clearly differentiates it from siblings like statefarm_get_quote or statefarm_policy_details, which are about quotes or policy lookup rather than bundle recommendations.
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 gives clear context for when the tool is appropriate: when a customer wants to save money by bundling multiple insurance lines. It does not explicitly name alternatives or exclusions, but the purpose is distinct enough that an agent can infer when to prefer this over the quote or policy tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of an existing State Farm insurance claim. Returns current status, assigned adjuster contact, estimated timeline, and any action items needed.
| Name | Required | Description | Default |
|---|---|---|---|
| claim_number | Yes | State Farm claim number (provided when claim was filed) | |
| policy_number | No | Policy number associated with the claim (optional, helps narrow lookup) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It communicates a read-only action via 'Check' and discloses exactly what the call returns (status, adjuster contact, timeline, action items). It does not mention authorization or staleness, but for a simple status lookup this is transparent enough.
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?
A single sentence delivers the action, the resource, and the output contents without waste. The most important qualifier ('existing') is placed early, and every phrase 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?
For a two-parameter lookup with no output schema, the description is largely self-sufficient: it names the resource, the action, and the response fields. Optional policy_number and required claim_number are covered in the schema, so the main missing context is any error or availability caveat, which is minor.
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 parameters are already documented. The description adds no extra meaning about claim_number or policy_number beyond the generic 'existing claim,' which is the baseline expectation when the schema is complete.
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 a specific verb ('Check') and resource ('status of an existing State Farm insurance claim'), and enumerates the return values. This clearly separates it from siblings like statefarm_file_claim or statefarm_policy_details, which target different actions and resources.
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 phrase 'existing claim' gives clear context that this tool is for already-filed claims, not for filing or quoting. However, it does not explicitly name alternatives or exclusions, so it stops short of the highest tier.
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 State Farm auto policy. Returns the ID card information including policy details, vehicle info, and coverage period. Can also provide a link to download or share the card.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | How to retrieve the ID card. Default: display | |
| vehicle_vin | No | Vehicle VIN to get ID card for a specific vehicle (optional) | |
| email_address | No | (email format) Email address to send the ID card to | |
| policy_number | Yes | Auto insurance policy number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool returns (policy details, vehicle info, coverage period, link) but is a read operation by nature. It doesn't reveal that it may invoke email sending, what happens if an invalid policy number is provided, whether it performs authentication, or whether the output varies by format. Given no annotations exist, this is a significant gap.
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, front-loads the primary purpose, and adds expected output fields plus an optional link. Every sentence earns its place without 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?
Given the tool has no output schema, no annotations, and a parameter that triggers email sending (email_address format), the description should clarify behavioral nuances like when email is actually sent, whether downloads require authentication, or what display returns. It covers the basics but misses important context about the 'email' and 'download_link' formats. A 3 reflects a functional but incomplete description.
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% – each parameter has a description. The tool description adds value by explaining what the ID card information includes and that a download/share link may be provided, which clarifies the return context. However, it doesn't add meaning beyond the schema for parameters themselves, so a 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?
The description clearly states the tool's function ('Retrieve a digital insurance ID card for a State Farm auto policy') with a specific verb and resource. It distinguishes itself from siblings by focusing on ID card retrieval, not quotes, claims, policies, or roadside assistance.
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 use when the user needs a digital ID card for a State Farm auto policy, which is clear from the context. However, it lacks explicit guidance on when to prefer this over sibling tools like statefarm_policy_details or statefarm_find_agent, which are also policy-related. No exclusion conditions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initiate a new insurance claim with State Farm. Supports auto accidents, home damage, theft, and other covered events. Returns a claim reference number and next steps.
| Name | Required | Description | Default |
|---|---|---|---|
| claim_type | Yes | Type of claim being filed | |
| incident_date | Yes | Date of incident in ISO format (YYYY-MM-DD) | |
| policy_number | Yes | State Farm policy number the claim is filed under | |
| estimated_damage | No | Estimated damage amount in USD (optional) | |
| incident_location | No | Address or location where the incident occurred | |
| injuries_involved | No | Whether any injuries were involved | |
| incident_description | Yes | Description of what happened | |
| police_report_number | No | Police report number if applicable | |
| other_parties_involved | No | Whether other parties (drivers, people) are involved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It discloses that the tool creates a claim and returns a claim reference number and next steps, and it scopes the covered event types. It does not mention extended side effects such as contacting an adjuster or irreversibility, but 'initiate' already signals a state-changing action.
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 short sentences front-load the core action, then add scope and output information. No filler or redundant restatement of the schema.
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 9-parameter schema covers all inputs and the description covers both supported claim types and the output format, an agent has enough to invoke the tool. It could add a caveat about policy validity, but this is not essential for a first call.
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%, so each parameter is already documented. The description adds no new parameter semantics; its mention of auto/home/theft simply restates the claim_type enum values.
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 ('Initiate') with a clear resource ('a new insurance claim with State Farm') and differentiates from siblings like claim_status by emphasizing 'new'. The supported event list further clarifies scope.
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 clearly implies the trigger: when a user needs to file a new claim, not check an existing one. However, it does not explicitly name alternative tools or exclusion criteria, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find State Farm insurance agents near a location. Returns a list of local agents with contact info, office hours, languages spoken, and specializations.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Preferred language for the agent (e.g. Spanish, Mandarin) | |
| location | Yes | City, state, or ZIP code to search near | |
| max_results | No | Maximum number of agents to return (default: 5, max: 20) | |
| radius_miles | No | Search radius in miles (default: 10) | |
| insurance_type | No | Insurance type specialization to filter by (default: any) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It communicates that this is a read-style lookup and lists the output fields, but it does not mention ordering, data freshness, pagination, access requirements, or confirm there are no side effects.
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, front-loaded sentence with no filler. It states the action, the target, the location scope, and the key output fields efficiently.
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 location-based agent search, the description plus fully documented schema provides most of what an agent needs to invoke the tool. Since there is no output schema, the description's return-field summary is valuable, but minor gaps such as result ordering and geocoding behavior keep it from being fully complete.
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 description does not need to restate parameter definitions. It lightly reinforces the language and insurance_type parameters by mentioning 'languages spoken' and 'specializations,' but adds no meaningful semantic detail 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 uses a specific verb and resource: 'Find State Farm insurance agents near a location.' It clearly identifies the tool as an agent-locator service and is distinguishable from siblings like claims, quotes, and payments, though it does not explicitly name an alternative.
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?
There is no explicit guidance on when to use this tool versus alternatives. The phrase 'near a location' implies a location-based lookup, but the description does not state when an agent should prefer this over get_quote, policy_details, or other sibling tools.
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 State Farm. Supports auto, home, life, and renters insurance. Returns estimated premium ranges, coverage options, and next steps to complete the quote online or with an agent.
| Name | Required | Description | Default |
|---|---|---|---|
| zip_code | Yes | ZIP code for the quote location | |
| life_type | No | (Life) Type of life insurance | |
| home_sq_ft | No | (Home) Home square footage | |
| home_value | No | (Home) Estimated home value in USD | |
| vehicle_make | No | (Auto) Vehicle manufacturer (e.g. Toyota, Ford) | |
| vehicle_year | No | (Auto) Vehicle model year | |
| applicant_age | No | (Life) Applicant age | |
| drivers_count | No | (Auto) Number of drivers to insure | |
| vehicle_model | No | (Auto) Vehicle model (e.g. Camry, F-150) | |
| insurance_type | Yes | Type of insurance quote to request | |
| coverage_amount | No | (Life) Desired coverage amount in USD | |
| home_year_built | No | (Home) Year the home was built | |
| personal_property_value | No | (Renters) Estimated value of personal belongings in USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does disclose output behavior ('Returns estimated premium ranges, coverage options, and next steps'), and 'next steps to complete the quote' implies the tool commits to nothing. However, it does not state whether calling it initiates contact with State Farm, collects/stores personal data, or has any side effects — meaningful gaps for an agent deciding whether invocation is safe.
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, each earning its place: the core action, the supported scope, and the delivered output/next steps. The most decision-relevant information is front-loaded, with zero filler or redundancy.
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 13-parameter tool with no output schema and no annotations, the description does meaningful work: it lists all supported insurance types, signals the location requirement implicitly via zip code, and states the return shape, which partially substitutes for the missing output schema. The schema carries parameter semantics well. It falls short of 5 because, with annotations entirely absent, it could also disclose quote validity, non-binding guarantees, or data-handling behavior.
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's insurance-type list weakly reinforces the insurance_type enum, but it adds no format, unit, conditionality, or interaction detail beyond what the schema already provides via its prefixed per-parameter descriptions (e.g., '(Home) Home square footage', '(Life) Applicant age').
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 states a specific verb and resource ('Get an insurance quote from State Farm') and enumerates the full scope of supported insurance types ('auto, home, life, and renters'). The stated return content ('estimated premium ranges, coverage options, and next steps') makes it clearly distinguishable from siblings such as statefarm_file_claim, statefarm_policy_details, or statefarm_payment.
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?
Usage context is implied — the agent can infer this tool is for obtaining a new quote rather than managing an existing policy — but no explicit when-to-use/when-not-to-use guidance is given. Notably, statefarm_bundle_recommendations is a plausible alternative an agent might confuse with this tool, yet the description never routes between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage State Farm insurance payments. View payment history, due dates, make a payment, set up autopay, or update payment method.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Payment action to perform | |
| policy_number | No | Policy number to manage payment for | |
| payment_amount | No | (make_payment) Amount to pay in USD | |
| payment_method | No | (make_payment / update_payment_method) Payment method type |
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, and it falls short for a financial tool. It does not disclose that make_payment will actually charge the customer, that setup_autopay/cancel_autopay alter future billing behavior, or that update_payment_method affects the default method used for charges. It also does not mention any confirmation, idempotency, or authentication expectations. Listing the actions without their material financial consequences is a significant transparency gap.
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 with the core resource front-loaded in the first clause ('Manage State Farm insurance payments') and a compact list of supported operations following. Every phrase earns its place, and it is appropriately sized for a multi-action tool. The slight enumeration length is justified because it previews all six distinct actions an agent can invoke.
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?
This is a moderate-complexity tool with six actions, four parameters, no output schema, and no annotations, yet the description only provides a high-level overview. It omits material operational context: policy_number is not required by the schema but is logically needed for most actions, the financial side effects of mutating actions are unstated, and with no output schema the agent is left with no sense of what each action returns. A financial tool of this scope needs more than a one-line summary.
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 already documented (action enum, policy number, payment amount in USD, and payment method restrictions per action). Per rubric, this sets the baseline at 3, and the description adds no extra parameter-level meaning beyond what the schema provides. The six-action list in the description roughly mirrors the action enum, adding convenience but no new semantic detail.
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 opens with a specific verb-resource pair ('Manage State Farm insurance payments') and enumerates the concrete operations: viewing payment history, due dates, making a payment, setting up autopay, and updating payment method. These operations map directly to the action enum values, making the tool's scope unambiguous. None of the eight sibling tools (claims, quotes, agents, roadside assistance, digital ID) overlap with payment management, so it is clearly differentiated.
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 context by listing payment-related tasks, so an agent can reasonably infer this is the tool for payment activities. However, it provides no explicit when-to-use guidance, no exclusions, and never names alternative tools by condition. For example, it does not say 'for claims use statefarm_file_claim' or note when policy details would be more appropriate. The guidance is implied through the operation list rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve details about an existing State Farm insurance policy. Returns coverage summary, deductibles, premium info, renewal date, and insured items/people.
| Name | Required | Description | Default |
|---|---|---|---|
| policy_type | Yes | Type of policy to retrieve. Use 'all' to list all policies. | |
| policy_number | No | State Farm policy number (e.g. 123-4567-A01-12B) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. 'Retrieve' and 'Returns' clearly signal a read-only lookup, and the listed outputs (coverage summary, deductibles, premium info, renewal date, insured items/people) give a concrete behavioral contract. It does not discuss auth or errors, but none are suggested as relevant for a simple lookup.
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 entire description is one sentence that front-loads the action and then packs the returned fields into a concise list. No filler or redundant information.
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 only two parameters and no output schema, the description is largely complete: it states the operation and enumerates the return content. The schema covers the parameters, so the only minor gap is that the description does not explain when policy_number should be supplied vs. using 'all'.
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 no parameter-level details beyond the schema, but the schema already documents policy_type and policy_number, including the enum values and the 'all' option.
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 ('Retrieve') and names the resource ('existing State Farm insurance policy'), and lists the return contents. It is clear, though it does not explicitly differentiate from sibling tools like statefarm_get_quote or statefarm_claim_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?
No guidance is given about when to choose this tool over the siblings. The word 'existing' hints that it is not for new quotes, but there is no explicit when-to-use or when-not-to-use, and no mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request State Farm roadside assistance or check available roadside services. Can request towing, battery jump, flat tire change, fuel delivery, lockout service, or winching.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| service_type | No | (request_service) Type of roadside assistance needed | |
| policy_number | No | Auto insurance policy number | |
| callback_phone | No | (request_service) Phone number for the service provider to call | |
| current_location | No | (request_service) Your current location or address | |
| service_request_id | No | (track_service) Service request ID to track | |
| vehicle_description | No | (request_service) Vehicle description (year, make, model, color) |
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 it only lists service types and capabilities. It does not mention that requesting service may trigger a real-world dispatch, require a policy number, incur costs, or that the tool can track an existing request. This is a significant gap for a tool that can perform consequential actions.
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 focused sentence that front-loads the main purpose and lists the service types efficiently. Minor redundancy exists ('roadside assistance' and 'roadside services'), but overall it is tight and readable.
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 annotations and no output schema, the description should provide more complete context for a multi-action tool with seven parameters. It does not explain what happens after a request, what check_coverage returns, or that track_service exists. The missing track_service action alone is a notable omission.
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 high at 86%, with most parameters already described with action-specific context. The description adds no new parameter meaning beyond repeating service type names that are already in the enum. Baseline 3 is appropriate since the schema carries the 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?
The description clearly identifies the tool as handling State Farm roadside assistance with a specific list of service types, distinguishing it from the sibling tools (quotes, claims, payments, etc.). However, it omits the 'track_service' action, which is part of the schema, so the full scope of what the tool can do is not completely captured.
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 the tool should be used for roadside assistance scenarios, and the sibling tools are clearly in different domains, so an agent could infer when to use it. There is no explicit guidance on when not to use it or which action to choose in which situation, leaving some ambiguity around check_coverage vs track_service.
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.
v0.1.0statefarm_bundle_recommendationsstatefarm_claim_statusstatefarm_digital_id_cardstatefarm_file_claimstatefarm_find_agentstatefarm_get_quotestatefarm_paymentstatefarm_policy_detailsstatefarm_roadside_assistanceScored across 9 tools
Each tool targets a distinct insurance task: quoting, bundling, finding agents, policies, claims, payments, roadside help, and ID cards. The closest overlap is between get_quote and bundle_recommendations, but their intent differs enough that descriptions clarify the boundary.
All tools share the statefarm_ prefix and use snake_case, which helps consistency. However, some names follow a verb_noun pattern like get_quote or file_claim, while others are pure noun phrases like policy_details, claim_status, and payment, making the action pattern uneven.
Nine tools is a well-scoped size for a State Farm customer-service MCP. Each tool covers a meaningful user need without unnecessary redundancy or feature bloat.
The toolkit covers major customer workflows: getting quotes, managing policies, handling payments, filing and tracking claims, and requesting roadside assistance. Minor gaps exist around policy changes, claim modifications, or purchasing a policy directly, but most workflows have clear next-step guidance.
Connect AI agents to financial institution origination, analytics, and compliance workflows.
Insurance brokerage for AI agents — quote, bind, and settle in USDC
Give your AI agent a phone: place calls, navigate IVRs, wait on hold, get structured answers.
Real, bindable home & auto insurance quotes via MCP (Texas, expanding); human-completed bind.
