Skip to main content
Glama

insurance_quote

Route a quote request to one or all underwriters. Hive forwards the request to the underwriter's own quote endpoint and returns the response verbatim. Hive does NOT bind coverage, accept premium, or take custody.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
protocolYesProtocol/product identifier (e.g. '2' for Nexus Mutual Aave v2, or the productId from /products)
providerNoProvider key. If omitted, quote routes to all four providers. One of: nexus_mutual, sherlock, risk_harbor, insurace
duration_daysYesCoverage duration in days (1–365)
cover_amount_usdYesNotional coverage in USD

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so exceptionally: it discloses that Hive forwards the request, returns responses verbatim, and does NOT bind coverage, accept premium, or take custody. This gives complete transparency about side effects and limitations.

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?

The description is only two sentences, with the core action front-loaded. It contains zero fluff, and every clause adds essential information about routing behavior and operational constraints.

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

Completeness5/5

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

For a tool with no annotations or output schema, the description covers the essential context: what it does, how it interacts with underwriters, what it returns, and what it explicitly does not do. This is enough to safely invoke the tool without missing critical behavioral expectations.

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?

The input schema already provides 100% coverage, including the provider field's description that omission routes to all four providers. The description delegates parameter semantics to the schema and adds no additional meaning, so 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.

Purpose5/5

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

The description clearly states the action: 'Route a quote request to one or all underwriters.' It identifies the specific verb, resource, and target, distinguishing it from siblings like insurance_products (product listing) and insurance_today (current policy info).

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?

The description establishes when to use the tool—for routing a quote request—and clarifies that provider can be omitted to send to all. However, it doesn't explicitly mention when not to use it or name alternative tools, so it stops short of full exclusion guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation5/5

Each tool has a clear, distinct purpose: listing products, requesting quotes, and daily summary. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent 'insurance_' prefix followed by a noun (products, quote, today), making them easy to distinguish.

Tool Count4/5

Three tools is minimal but appropriate for a broker-only service that forwards quotes and lists products without policy management.

Completeness3/5

Covers core broker functions but lacks tools for quote history comparison or user account management, though domain scope justifies limited surface.