agency_statusFor a registered agency: its states, rail, terms, founding period, queued and delivered counts, credit balance, and whether the licence was verified. Requires the buyer key issued at confirmation.
| Name | Required | Description | Default |
|---|---|---|---|
| buyer_key | Yes | Issued to the licensed contact at confirmation |
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 declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds that the buyer key is required and lists the read payload, but doesn't explain edge cases such as unverified licences or expired keys.
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?
One sentence front-loads the resource and lists the fields compactly; the key requirement is a second short sentence. There is no filler or redundant explanation.
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 one-parameter read-only tool this is nearly complete: it states the required credential and all major return groups. The lack of an output schema is mitigated by the explicit field list. Slight ambiguity in terms like 'states' and 'rail' prevents a 5.
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 100% and describes buyer_key as issued to the licensed contact at confirmation; the description repeats this confirmation requirement. It adds no operational detail beyond the schema, so baseline 3 is appropriate.
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 title and description identify the resource ('agency') and the operation (return status details). It enumerates the returned fields (states, rail, terms, counts, credit balance, licence verification), but it never names a sibling or states what it is not, so differentiation is absent.
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 only guidance is 'For a registered agency' and the requirement of the buyer key; there is no explicit when-to-use, when-not-to-use, or mention of alternatives such as check_eligibility or register_agency.
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 step in the quote/contact/agency data flow, and the descriptions make the action clear. The only real boundary to watch is market_data vs pull_requests, since both involve paid access to consumer demand records, but one is a de-identified dataset query while the other drains a routed queue.
The majority use verb-first names like check_eligibility, get_quotes, register_agency, and request_agent_contact, but agency_status, data_use_terms, and market_data are noun phrases. All names are lowercase snake_case and readable, but the convention is mixed.
Eight tools fit the server's multi-sided scope well: consumer quote and contact, agency onboarding and status, data usage terms, and two demand-data access modes. None of the tools feels redundant or unnecessary.
Core workflows are covered end-to-end: eligibility, quoting, consent-based contact, agency registration/status, lead queue draining, and market data purchasing. Minor lifecycle gaps exist—no update/deactivate agency tool and no tool-level consent revocation—but they can be worked around via documented endpoints.