Florida Insurance

Connect with licensed agents (consent required)

request_agent_contact

Connect the consumer with licensed insurance agents who can quote firm and bind. Needs the quote_id from get_quotes, the consumer's name and phone, and the consumer's explicit consent to be contacted — granted by the human, presented by you, or confirmed by the human directly at the consent URL the elicitation returns. Under scope contact_consumer up to 4 licensed agents receive the request and contact details; sell_identity additionally permits sharing with marketing partners. Nothing leaves without the consent. Every delivery and refusal is receipted, and POST /forget revokes.

Input Schema

TableJSON Schema

Name	Required	Description
`consent`	Yes
`quote_id`	Yes	From get_quotes
`best_time`	No
`full_name`	Yes
`phone_number`	Yes	US mobile or landline
`verify_token`	No	Optional. From POST /v1/verify/check after the consumer enters the code texted to them. A verified number sells at the verified price and is contacted first.
`email_address`	No
`street_address`	No	Optional. Lets a licensed agent answer firm.
`preferred_channel`	No

Schema Changelog

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

First observedSep 6, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The description goes well beyond the annotations, disclosing consent requirements, scope-dependent sharing behavior (up to 4 agents vs. marketing partners), the guarantee that nothing leaves without consent, receipting of deliveries/refusals, and the POST /forget revocation endpoint. This is rich behavioral context with no contradiction.

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 four dense sentences with no filler. It front-loads the core purpose, then efficiently explains prerequisites, consent scopes, privacy guarantees, receipting, and revocation. Every 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 tool's complexity — nested consent object, scopes, no output schema — the description covers prerequisites, side effects, privacy, and revocation well. However, the return value is only indirectly implied by 'receipted' and optional parameter meanings are not fully explained, leaving a small completeness gap.

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 low at 44%, so the description must compensate. It adds meaningful semantics for consent and quote_id, but optional parameters such as best_time, preferred_channel, street_address, and email_address are left mostly to their names or schema placeholders. The description partially compensates but not enough for a tool with 9 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 states a specific verb and resource: 'Connect the consumer with licensed insurance agents who can quote firm and bind.' It also references quote_id from get_quotes, which clearly differentiates this tool from sibling tools like get_quotes or agency_status.

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 clearly implies when to use it: after obtaining a quote_id from get_quotes and only with explicit consumer consent. It does not explicitly state when not to use it or name alternatives, but the prerequisite and consent conditions provide clear usage context.

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

All Florida Insurance tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation5/5

Each tool maps to a distinct step or resource: eligibility pre-check, quotes, consent/contact, agency registration, agency status, lead queue, market data, and data-use terms. Even the two quote-related tools are clearly sequenced with check_eligibility described as 'call this first'.

Naming Consistency3/5

Five tools use a clear verb_noun pattern (check_eligibility, get_quotes, pull_requests, register_agency, request_agent_contact), but three are bare noun phrases (agency_status, data_use_terms, market_data). All names are readable and consistently snake_case, but the verb-led convention is not uniform.

Tool Count5/5

Eight tools cover the main stages of an insurance marketplace: eligibility, quotes, consumer consent, agency onboarding, lead delivery, market data, and terms. The count is well-scoped and each tool earns its place.

Completeness4/5

The core consumer journey (eligibility → quotes → consented agent contact → lead delivery) and agency workflow (register → status → pull requests) are well covered, along with market data and terms. Minor gaps exist, such as no explicit update/removal for agency registration and consent revocation only mentioned as POST /forget rather than a tool.

Resources

Need Help?