check_eligibilityCheck whether we can return quotes for a state before any personal details are collected. Call this first. Returns the states we are licensed in, what we can do in each, and how many licensed agents can take a request there.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Two-letter US state code, e.g. NV | |
| product | Yes | auto |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, idempotent, and non-destructive behavior, so the description does not need to restate safety. It adds value by disclosing the response contents: licensed states, per-state capabilities, and licensed agent counts. It also implies an operational trait that the state parameter is optional, since it says 'states we are licensed in' rather than only the requested state.
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 sentences carry the full definition with no filler. The primary action and sequencing instruction are front-loaded, and the return value summary is packed into a single efficient sentence that adds real decision-relevant 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 low-complexity tool with no output schema, the description covers purpose, when to call, and the high-level return shape. It does not specify the exact response format or behavior for invalid or unsupported states, but the decision-relevant facts—licensing, capabilities, and agent availability—are all present.
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?
The description adds meaning to the state parameter by implying it can be omitted to return all licensed states. However, the product parameter is not mentioned at all, and with schema coverage at 50%, the description only partially compensates. The omission of product is minor because the schema marks it as required with a single 'auto' enum value, but it still leaves an undocumented parameter.
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 'Check whether we can return quotes for a state', naming a specific verb, resource, and precondition. It clarifies the tool's role as a pre-check that happens before any personal details are collected, and it previews what the result will contain, making the purpose unmistakable.
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?
'Call this first' provides explicit and actionable sequencing guidance, and 'before any personal details are collected' defines the condition under which this tool is the right choice. No alternatives or exclusions are named, but with no sibling tools provided in the context, the guidance is sufficiently clear for agent selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each public- to-consumer and agency-facing tool serves a clearly separate step in the workflow: eligibility, quotes, consent, contact, registration, status, queue draining, and data purchase. There is no meaningful overlap between tool purposes.
All tool names are snake_case and generally descriptive, but they mix action-oriented names like get_quotes and pull_requests with noun-style resource names like market_data and agency_status. This is a minor consistency deviation rather than a chaotic pattern.
Eight tools cover the platform's distinct functional areas without bloat: consumer quote/contact flow, agency registration and queue management, and data market access. Each tool appears necessary and the total count is well-scoped for the server's purpose.
The core workflows are supported end to end: eligibility check leads to quotes, consent leads to agent contact, and agencies can register, check status, and pull routed records. The main gaps are minor administrative operations such as updating agency details or an explicit tool for revoking consent, although POST /forget is referenced.