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 readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds behavioral context by stating that the buyer key is required and was issued at confirmation, which is an important access prerequisite not fully captured by the annotations.
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?
The description is a single efficient sentence that front-loads the resource and returned fields, then states the key requirement. There is no filler or redundant restatement of the tool name.
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 simple read-only status endpoint with one parameter and rich annotations, the description covers the essential information: what data is returned and what credential is needed. It does not describe error behavior or edge cases, but those are not critical for this tool's simple scope.
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 description coverage is 100%, so the buyer_key parameter is already documented. The description repeats the authentication requirement without adding meaningful new detail beyond the schema, meriting the baseline score for well-covered parameters.
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 clearly enumerates the resource (a registered agency) and the specific status fields returned, such as rail, terms, credit balance, and verification. It stops short of an explicit verb like 'retrieves' or 'returns', and does not directly contrast with sibling tools, though the title and content make the purpose unambiguous.
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 description establishes clear usage context: it applies to a registered agency and requires the buyer key issued at confirmation. It does not explicitly state when to prefer this over sibling tools, but the prerequisites and data scope give an agent enough context to use it appropriately.
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 addresses a distinct function—eligibility, quotes, terms, agency registration/status, market data, lead pulling, and contact requests—with no functional overlap. Even the similar request/pull tools are clearly separated by actor and action.
Names mix imperative verb-object forms (check_eligibility, get_quotes, register_agency) with noun phrases (agency_status, data_use_terms, market_data) and an ambiguous pull_requests. There is no uniform verb/noun pattern or consistent prefix.
Eight tools is well within the ideal range for this domain and covers both consumer-facing and agency-facing operations without redundancy or bloat.
Core quote and lead flows are present, but lifecycle coverage is incomplete: there is no tool to update or disable an agency, revoke consent/opt out, or manage the status of pulled leads. The privacy terms reference revocation but no corresponding action exists.