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?
Annotations already cover readOnly/idempotent/non-destructive, and the description adds useful context: it discloses what the call returns (licensed states, what can be done in each, and agent counts) and notes that no personal details are needed. This is meaningful behavior beyond the annotation flags.
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: purpose, ordering, and return contents. Front-loaded and tight, with every sentence earning its place and no redundant wording.
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?
The description covers purpose, sequencing, and return values, but it omits the optionality of the state parameter and what happens when state is omitted. It also does not connect to sibling tools beyond 'call first,' leaving small but real gaps for an agent deciding how to invoke it.
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?
Schema coverage is about 50%: 'state' has a description, while 'product' only has an enum with a default. The description clarifies the state parameter's role and broadens the output scope, but it does not mention that state is optional or explain product semantics; the schema's enum/default partially compensates.
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 states a specific action ('check whether we can return quotes') and a clear scope ('for a state'), with a temporal qualifier ('before any personal details are collected'). It is distinct enough but does not explicitly name any sibling tool, so it stops short of the strongest differentiation.
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?
The phrase 'Call this first' gives explicit sequencing guidance, and 'before any personal details are collected' provides a clear precondition. However, it does not mention alternatives or state when not to use this tool, so it lacks full routing information.
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 tool targets a distinct part of the workflow: eligibility pre-check, quote generation, consent/terms, agency registration, queue draining, status, market data, and agent contact. Even related tools like check_eligibility and get_quotes are clearly separated by their role in the process.
All names are snake_case and readable, but the pattern is mixed: five tools start with an imperative verb (check_, get_, pull_, register_, request_) while three are noun phrases (agency_status, data_use_terms, market_data). This is inconsistent enough to prevent a higher score, though not chaotic.
Eight tools is well within the ideal range and each one maps to a meaningful operation in the platform: eligibility, quotes, consent, registration, queue management, status, terms, and market data. No tool feels redundant or unnecessary.
The core consumer and agency workflows are covered: check eligibility, get quotes, request agent contact, register agency, pull requests, and monitor status. Minor gaps exist, such as no MCP tool for consent revocation or agency profile updates, but they do not block the main use cases.