Oklahoma Insurance

Get indicative quotes

get_quotes

Read-only

Return indicative auto insurance prices from multiple carriers, where this entity is licensed to show them. Takes rating facts only — no name, phone, email, SSN or licence number is required for an indicative price. Where we are not licensed to show prices, the request is still registered and a quote_id returned so licensed agents can quote it. If facts are missing the server asks for exactly what it needs and nothing more.

Input Schema

TableJSON Schema

Name	Required	Description
`state`	No	Optional; derived from the ZIP when absent
`coverage`	Yes
`garaging_zip`	Yes	Five-digit ZIP where the vehicle is kept
`vehicle_year`	Yes
`date_of_birth`	Yes
`annual_mileage`	No
`violations_3yr`	No
`years_licensed`	No
`prior_continuous`	No
`vehicle_make_model`	Yes

Schema Changelog

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

First observedSep 6, 2026

TDQS

A3.6/5.0

Behavior1/5

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

The description adds useful context about licensing, quote_id fallback, and missing-facts prompts, but it also says the request is 'still registered and a quote_id returned,' which implies persistence/side effects. This contradicts the readOnlyHint=true annotation, so per the rubric it must score 1.

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 compact sentences, front-loaded with the core purpose, followed only by behavior and constraints. 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?

For a 10-parameter tool with no output schema, the description covers the main return value (prices from carriers), the unlicensed fallback (quote_id), and the missing-facts interaction. It does not specify the exact response shape for licensed quotes, but it is otherwise sufficient.

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?

With only 20% schema description coverage, the description compensates by framing inputs as 'rating facts only,' excluding PII, and noting the server will ask for missing facts. However, it does not explain individual fields such as prior_continuous or violations_3yr, leaving them to inference.

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 and resource: it 'Return[s] indicative auto insurance prices from multiple carriers' and scopes this to where the entity is licensed. This clearly differentiates it from siblings such as check_eligibility and market_data.

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?

It clearly conveys when to use the tool (to get an indicative quote using rating facts only) and explicitly says no PII is required. It does not name alternatives or state when not to use it, so it falls short of a 5.

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

All Oklahoma 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

Disambiguation4/5

Each tool covers a distinct function: eligibility, quoting, consent terms, agency registration/status, lead pulling, market data, and agent contact. The only mild overlap is between check_eligibility and get_quotes, but their descriptions make clear one is a pre-check for licensing/state capacity while the other returns actual indicative prices.

Naming Consistency3/5

Names are uniformly snake_case and mostly follow a verb_noun pattern like check_eligibility, get_quotes, pull_requests, register_agency, and request_agent_contact. However, agency_status, data_use_terms, and market_data are noun phrases rather than actions, so the pattern is mixed but still readable.

Tool Count5/5

Eight tools is well-scoped for this insurance-agency lead and quote platform. Each tool earns its place in the workflow, with no redundant sprawl and no feeling of an underbuilt or overloaded surface.

Completeness3/5

The primary flow is covered: eligibility, quoting, consent, agent contact, agency registration/status, lead pulling, and market data. Missing lifecycle operations include updating an agency registration, managing credits/payments, and an explicit consent-revocation tool, since POST /forget is referenced but not exposed as an MCP tool.

Resources

Need Help?