bizinsured

Server Details

AI-powered commercial insurance carrier recommendations for small businesses.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 100.0% over 43 days
Last Tested: 2026-09-29 15:53
Transport: Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.7/5.0

Scored 2026-09-27 16:40 across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: classification, coverage suggestion, coverage explanation, carrier recommendation, and agent handoff. The descriptions explicitly guide sequencing, so an agent can easily select the right tool.

Naming Consistency5/5

All tool names use a consistent verb_noun pattern in snake_case (classify_business, suggest_coverages, get_carrier_recommendations, etc.). The only minor variation is connect_with_agent, which still follows the same readable style.

Tool Count5/5

Five tools is well-scoped for this advisory insurance workflow. Each tool is necessary, and no redundant or filler tools are present.

Completeness5/5

The surface covers the core lifecycle: classify a business, suggest coverages, explain coverage details, get carrier matches with estimates, and hand off to an agent. No obvious gaps for the stated recommendation-and-handoff purpose.

Available Tools

5 tools

classify_businessAInspect

Takes a natural language business description and returns matched class codes (NAICS, ISO GL, NCCI WC). Always call this first to understand the user's business type before making recommendations.

ParametersJSON Schema

Name	Required	Description	Default
`state`	No	Two-letter state code
`business_description`	Yes	User's description of their business

TDQS

A4.2/5.0

Behavior3/5

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 states the action (takes and returns) but does not disclose whether the operation has side effects, requires authentication, or is read-only. Given the lookup nature, this is adequate but not thorough.

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

Conciseness5/5

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

Two sentences deliver the function and usage guidance with no filler. The information is front-loaded and each sentence earns its place.

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

Completeness4/5

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

Given the absence of an output schema and annotations, the description provides essential details: what it does, what it returns, and when to use it. It could detail return structure or state handling, but the current description is sufficient for a classification tool.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters are already documented. The tool description reinforces the primary role of business_description but does not add new meaning beyond the schema, especially for the state parameter.

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

Purpose5/5

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

The description clearly states the tool's function: taking a natural language business description and returning matched class codes (NAICS, ISO GL, NCCI WC). This distinguishes it from sibling recommendation tools by positioning it as the upfront classification step.

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

Usage Guidelines5/5

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

Explicitly says 'Always call this first' and explains why (to understand the user's business type before making recommendations). This provides clear when-to-use guidance and implies ordering against the other tools.

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

connect_with_agentAInspect

Generates a handoff to connect the user with a matched independent agent. Pass recommendation_id from get_carrier_recommendations when you have one, so the agent receives the estimate, and list every coverage the user asked for in risk_profile.desired_coverages, including ones that could not be estimated. Omit user_zip_code unless the user gave a ZIP code; never guess one.

ParametersJSON Schema

Name	Required	Description	Default
`user_state`	Yes
`risk_profile`	Yes
`user_zip_code`	No	Business ZIP code. Include only if the user gave it. Never guess or use a placeholder.
`recommendation_id`	No
`recommended_carriers`	No
`user_contact_preference`	No		either

TDQS

A4/5.0

Behavior3/5

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

No annotations exist, so the description carries the full behavioral burden. It usefully discloses that the receiving agent gets the estimate and the full coverage list, but does not say whether this triggers outbound contact, requires user consent, is idempotent, or what happens on failure.

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

Conciseness4/5

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

Purpose is front-loaded in the first sentence, followed by three actionable directives. The later sentences are clause-heavy but every clause carries a distinct instruction, so there is little waste.

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

Completeness3/5

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

For a side-effecting handoff tool with a nested schema, no annotations, and no output schema, the description covers the two riskiest inputs but omits the outcome (does the agent contact the user?), how user_state or recommended_carriers should be populated, and which nested risk_profile fields matter.

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

Parameters4/5

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

Schema description coverage is only 17%, so the description must compensate and largely does for the key inputs: it explains recommendation_id's origin, prescribes full coverage enumeration in risk_profile.desired_coverages, and adds a firm never-guess rule for user_zip_code beyond the schema's note. It still leaves user_state, recommended_carriers, user_contact_preference, and most nested risk_profile fields unaddressed.

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

Purpose5/5

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

States a specific verb and outcome: 'Generates a handoff to connect the user with a matched independent agent.' It also names the sibling relationship by sourcing recommendation_id from get_carrier_recommendations, so an agent can place this tool in the workflow without opening other schemas.

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

Usage Guidelines4/5

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

Gives conditional rules: pass recommendation_id 'when you have one,' list every requested coverage even if it could not be estimated, and omit user_zip_code unless the user supplied it. Strong context for invoking correctly, though it never states when this tool should not be used (e.g., user only wants quotes/info).

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

explain_coverageCInspect

Explains a commercial insurance coverage type in plain language.

ParametersJSON Schema

Name	Required	Description	Default
`coverage_type`	Yes
`business_context`	No

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations, the description carries the full burden, but it only states the output register. It does not disclose return format, behavior for unknown coverage types, the role of business_context, or any other behavioral traits.

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

Conciseness4/5

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

The description is a single, compact sentence with no redundant wording. It is front-loaded and easy to parse, even though it could be more informative.

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

Completeness2/5

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

Given the absence of annotations and output schema, the description is too thin. It does not explain what a 'plain language' explanation looks like, how business_context affects the result, or what happens with invalid inputs.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not compensate. The phrase 'coverage type' loosely maps to coverage_type, but business_context is entirely unexplained, and no example values or constraints are given.

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

Purpose5/5

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

The description uses a specific verb ('Explains') and resource ('commercial insurance coverage type') and adds the qualifier 'in plain language'. This clearly distinguishes it from sibling tools like suggest_coverages or get_carrier_recommendations.

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

Usage Guidelines2/5

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

No guidance is given about when to use this tool versus alternatives. The context is only implied by the verb 'explains', with no mention of scenarios, prerequisites, or exclusions.

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

get_carrier_recommendationsBInspect

Returns carrier matches and market budget estimates. Supply confirmed classification and actual exposures. Missing inputs, unsupported terms and partial coverage are returned explicitly. State-fund WC is returned separately in stateFundEstimates, including an Ohio BWC estimate from published rates that is not a BWC quote.

ParametersJSON Schema

Name	Required	Description
`city`	No
`state`	Yes
`source`	No
`zip_code`	No
`naics_code`	No
`deductibles`	No
`has_alcohol`	No
`iso_gl_code`	No
`serves_food`	No
`has_delivery`	No
`prior_losses`	No
`vehicle_count`	No
`vehicle_types`	No
`annual_payroll`	No	Actual annual payroll; never infer from revenue
`annual_revenue`	Yes
`building_value`	No
`effective_date`	No
`employee_count`	No
`square_footage`	No
`coverage_limits`	No
`current_carrier`	No
`payroll_by_class`	No	Actual payroll split by state and workers compensation classification
`desired_coverages`	Yes
`years_in_business`	No
`prior_loss_details`	No
`experience_modifier`	No
`business_description`	No
`business_property_value`	No
`current_policy_expiration`	No	When the current policy expires or renews (YYYY-MM-DD), if known. Omit dates more than 365 days past or 730 days ahead

TDQS

B3.1/5.0

Behavior3/5

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 does disclose that missing inputs, unsupported terms, and partial coverage are returned explicitly, and that state-fund WC is separated into stateFundEstimates with a specific Ohio BWC estimate behavior. This adds some behavioral context, but it doesn't cover side effects, rate limits, or other potential behaviors. Given zero annotation coverage, it's a modest disclosure.

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

Conciseness5/5

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

Three sentences with no wasted words. It front-loads the main purpose, then adds prerequisite, error handling, and a special case. Each sentence provides distinct value, and the structure is logical and efficient.

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

Completeness2/5

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

For a tool with 29 parameters, no output schema, and no annotations, the description is incomplete. It mentions stateFundEstimates but doesn't describe the overall return structure or what 'carrier matches' entails. It lacks details on how parameters interrelate, optionality, or expected response shape. An agent would be left guessing on many aspects.

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

Parameters1/5

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

Schema description coverage is only 10%, and the description does not compensate. It mentions 'confirmed classification and actual exposures' but doesn't map to specific parameters or explain their meaning. With 29 parameters, the description provides almost no guidance on what values to supply, making it insufficient for effective parameter usage.

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

Purpose4/5

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

States a clear purpose: returns carrier matches and market budget estimates. It also specifies prerequisites (confirmed classification and actual exposures). However, it doesn't explicitly differentiate from sibling tools like suggest_coverages, which might also return coverage recommendations, so it's clear but lacks explicit sibling differentiation.

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

Usage Guidelines3/5

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

Provides a clear prerequisite: supply confirmed classification and actual exposures. It also indicates that missing inputs are handled explicitly. However, it does not mention when to use this tool versus alternatives, nor does it give any exclusions or routing guidance. The usage context is implied rather than explicit.

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

suggest_coveragesCInspect

Suggests which insurance coverages a business likely needs, ranked by importance.

ParametersJSON Schema

Name	Required	Description
`state`	Yes
`vertical`	No
`naics_code`	No
`iso_gl_code`	No	Confirmed ISO GL code. For NAICS 531110 it separates 1-4 family rentals (63010) from apartment buildings (60010).
`serves_food`	No
`has_vehicles`	No
`does_delivery`	No
`employee_count`	No
`serves_alcohol`	No
`business_description`	Yes
`handles_customer_data`	No
`has_physical_location`	No

TDQS

C2.8/5.0

Behavior2/5

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. It states that output is a ranked set of coverage suggestions, but it does not explain how suggestions are derived, what inputs are most important, whether external data is consulted, or what the response shape looks like.

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

Conciseness4/5

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

The description is a single, front-loaded sentence with no filler or repetition. It is appropriately concise, though additional usage or parameter detail would improve it without making it verbose.

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

Completeness2/5

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

For a tool with 12 parameters, no annotations, no output schema, and sibling tools to disambiguate, this description is incomplete. It does not explain required inputs, output format, or when to choose this versus sibling tools.

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

Parameters1/5

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

Schema description coverage is only 8%, and the description adds essentially no parameter meaning. It does not clarify the role of business_description, state, naics_code, vertical, or any of the boolean flags, leaving agents without the guidance needed to populate 12 parameters.

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

Purpose5/5

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

The description uses a specific verb ('suggests') with a clear resource ('which insurance coverages a business likely needs') and adds the ranked-by-importance output property. This distinguishes it from siblings like classify_business, explain_coverage, and get_carrier_recommendations.

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

Usage Guidelines2/5

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

The description gives no guidance about when to prefer this tool over the sibling tools, nor does it mention any prerequisites or alternatives. Usage context is only implied by the tool's name and purpose.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

1 tool updateSep 25, 2026

Changedconnect_with_agent3 fields changed

addedInput schema / properties / user_zip_code / description

Added value: +"Business ZIP code. Include only if the user gave it. Never guess or use a placeholder."

addedInput schema / properties / user_zip_code / pattern
```
Added value: +"^\\d{5}(-\\d{4})?$"
```

changedInput schema / required

Previous value: -[
-  "risk_profile",
-  "user_state",
-  "user_zip_code"
-]New value: +[
+  "risk_profile",
+  "user_state"
+]

3 tool updatesSep 22, 2026

Changedconnect_with_agent2 fields changed

addedInput schema / properties / risk_profile / properties / current_carrier
```
Added value: +{
+  "maxLength": 200,
+  "type": "string"
+}
```

addedInput schema / properties / risk_profile / properties / current_policy_expiration

Added value: +{
+  "description": "When the current policy expires or renews (YYYY-MM-DD), if known. Omit dates more than 365 days past or 730 days ahead",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

Changedget_carrier_recommendations1 field changed

addedInput schema / properties / current_policy_expiration

Added value: +{
+  "description": "When the current policy expires or renews (YYYY-MM-DD), if known. Omit dates more than 365 days past or 730 days ahead",
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

Changedsuggest_coverages1 field changed

addedInput schema / properties / iso_gl_code

Added value: +{
+  "description": "Confirmed ISO GL code. For NAICS 531110 it separates 1-4 family rentals (63010) from apartment buildings (60010).",
+  "type": "string"
+}

2 tool updatesSep 13, 2026

Changedconnect_with_agent1 field changed

addedInput schema / properties / recommendation_id

Added value: +{
+  "format": "uuid",
+  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+  "type": "string"
+}

Changedget_carrier_recommendations37 fields changed

addedInput schema / properties / annual_payroll

Added value: +{
+  "description": "Actual annual payroll; never infer from revenue",
+  "maximum": 1000000000000,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / annual_revenue / maximum
```
Added value: +1000000000000
```
addedInput schema / properties / annual_revenue / minimum
```
Added value: +0
```

addedInput schema / properties / building_value

Added value: +{
+  "maximum": 1000000000000,
+  "minimum": 0,
+  "type": "number"
+}

removedInput schema / properties / business_description / default
```
Removed value: -""
```
addedInput schema / properties / business_description / maxLength
```
Added value: +4000
```

addedInput schema / properties / business_property_value

Added value: +{
+  "maximum": 1000000000000,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / city

Added value: +{
+  "maxLength": 200,
+  "type": "string"
+}

addedInput schema / properties / coverage_limits

Added value: +{
+  "additionalProperties": {
+    "maxLength": 100,
+    "minLength": 1,
+    "type": "string"
+  },
+  "propertyNames": {
+    "enum": [
+      "BOP",
+      "GL",
+      "WC",
+      "commercial_auto"
+    ],
+    "type": "string"
+  },
+  "type": "object"
+}

addedInput schema / properties / current_carrier

Added value: +{
+  "maxLength": 200,
+  "type": "string"
+}

addedInput schema / properties / deductibles

Added value: +{
+  "additionalProperties": {
+    "maximum": 1000000000000,
+    "minimum": 0,
+    "type": "number"
+  },
+  "propertyNames": {
+    "enum": [
+      "BOP",
+      "GL",
+      "WC",
+      "commercial_auto"
+    ],
+    "type": "string"
+  },
+  "type": "object"
+}

addedInput schema / properties / desired_coverages / maxItems
```
Added value: +20
```
addedInput schema / properties / desired_coverages / minItems
```
Added value: +1
```

addedInput schema / properties / effective_date

Added value: +{
+  "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+  "type": "string"
+}

removedInput schema / properties / employee_count / default
```
Removed value: -1
```
addedInput schema / properties / employee_count / maximum
```
Added value: +1000000
```
addedInput schema / properties / employee_count / minimum
```
Added value: +0
```
changedInput schema / properties / employee_count / type
```
Previous value: -"number"New value: +"integer"
```

addedInput schema / properties / experience_modifier

Added value: +{
+  "exclusiveMinimum": 0,
+  "maximum": 10,
+  "type": "number"
+}

addedInput schema / properties / iso_gl_code / pattern
```
Added value: +"^\\d{3,6}$"
```
addedInput schema / properties / naics_code / pattern
```
Added value: +"^\\d{6}$"
```

addedInput schema / properties / payroll_by_class

Added value: +{
+  "description": "Actual payroll split by state and workers compensation classification",
+  "items": {
+    "properties": {
+      "class_code": {
+        "pattern": "^\\d{1,6}$",
+        "type": "string"
+      },
+      "class_system": {
+        "maxLength": 30,
+        "minLength": 1,
+        "type": "string"
+      },
+      "payroll": {
+        "exclusiveMinimum": 0,
+        "maximum": 1000000000000,
+        "type": "number"
+      },
+      "state": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "state",
+      "class_code",
+      "payroll"
+    ],
+    "type": "object"
+  },
+  "maxItems": 100,
+  "minItems": 1,
+  "type": "array"
+}

addedInput schema / properties / prior_loss_details

Added value: +{
+  "maxLength": 4000,
+  "type": "string"
+}

removedInput schema / properties / prior_losses / default
```
Removed value: -false
```
addedInput schema / properties / serves_food
```
Added value: +{
+  "type": "boolean"
+}
```

addedInput schema / properties / source

Added value: +{
+  "maxLength": 50,
+  "type": "string"
+}

addedInput schema / properties / square_footage / maximum
```
Added value: +1000000000000
```
addedInput schema / properties / square_footage / minimum
```
Added value: +0
```
addedInput schema / properties / vehicle_count / maximum
```
Added value: +1000000
```
addedInput schema / properties / vehicle_count / minimum
```
Added value: +0
```
changedInput schema / properties / vehicle_count / type
```
Previous value: -"number"New value: +"integer"
```

addedInput schema / properties / vehicle_types

Added value: +{
+  "items": {
+    "maxLength": 100,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 50,
+  "type": "array"
+}

removedInput schema / properties / years_in_business / default
```
Removed value: -1
```
addedInput schema / properties / years_in_business / maximum
```
Added value: +300
```
addedInput schema / properties / years_in_business / minimum
```
Added value: +0
```
addedInput schema / properties / zip_code / pattern
```
Added value: +"^\\d{5}(-\\d{4})?$"
```

changedInput schema / required

Previous value: -[
-  "naics_code",
-  "state",
-  "annual_revenue",
-  "desired_coverages"
-]New value: +[
+  "state",
+  "annual_revenue",
+  "desired_coverages"
+]

5 tool updatesMar 31, 2026
- First observedclassify_business
- First observedconnect_with_agent
- First observedexplain_coverage
- First observedget_carrier_recommendations
- First observedsuggest_coverages

Related MCP Connectors

Insurance Research Expert by Spot A
insure.spot
Commercial insurance research: provider comparisons, pricing, and fit guidance.
Finance Research & Data
91
Foresee A
io.github.Foresee-Tech
Let AI assistants shop for home and auto insurance: compare instant quotes across every carrier.
Finance
21
Hedge BrokerOAuth
com.hedgespecialty.www
Wholesale commercial insurance appetite, submissions, policies, payments, and broker workflows.
Payments & Billing
1
mind-of-mylo-quotes A
com.choosemylo
Machine-learning-backed insurance premium estimates from Mylo, comparing 100+ carriers.
AI & Machine Learning Finance
32

Related MCP Servers

Quotor
Finance
quotor
A
license
Not graded
quality
C
maintenance
Enables AI agents to get real home & auto insurance quotes and start binding through a network of licensed independent agencies.
Updated 2 months ago (2026-07-14 17:42 UTC)
1
Apache 2.0
Insurance Campaign MCP Server
Marketing Autonomous Agents App Automation
AlandeXiong
F
license
Not graded
quality
D
maintenance
Enables AI-powered insurance marketing campaign management with audience targeting recommendations and personalized content generation for different insurance products and marketing channels.
Updated a year ago (2025-09-25 15:05 UTC)
-
EasyAiFlows Automation
AI & Machine Learning App Automation
Ronnie-Nutrition
A
license
A
quality
C
maintenance
Assess your business's AI automation readiness across 20 industries. Get a personalized score, specific recommendations, and time/revenue impact estimates
Updated 6 months ago (2026-04-06 02:44 UTC)
2
6 npm
1
MIT
Insurance MCP Demo
Finance Customer Support
Sarthak-Singh2005
F
license
Not graded
quality
C
maintenance
Provides an AI-powered insurance assistant with tools for customer, policy, claim, premium, fraud detection, and policy renewal operations.
Updated 3 months ago (2026-07-12 06:35 UTC)
-

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?