Verified answers with named sources: UK parking appeals, NYC dismissal rates, UK MTD tax facts.
Average 4.1/5 across 9 of 9 tools scored. Lowest: 3.5/5.
Several tools overlap in subject matter: borough_odds, violation_dismissal_rates, and plate_lookup all touch NYC hearing outcomes, while operator_route_lookup and popla_outcomes both expose POPLA operator records. The descriptions are detailed enough to separate them on close reading, but an agent could easily select the wrong one when asking for odds or appeal outcomes.
The names are uniformly lowercase snake_case and readable, but the pattern is mixed: get_mtd_answer, list_doors, and search_mtd_answers use a verb_noun form, while borough_odds, popla_outcomes, and violation_dismissal_rates are noun phrases, and plate_lookup/operator_route_lookup use noun_lookup compounds. There is no single consistent naming convention across the set.
Nine tools is within the ideal range and each tool represents a distinct, substantive data product or query endpoint. For a gateway spanning multiple domains, this is well-scoped and not bloated.
The main query surfaces are covered: NYC parking has plate, borough, and violation-type views; UK parking has operator routing, deadline calculation, and POPLA outcomes; and MTD has search plus full-answer retrieval. Minor gaps exist, such as IAS appeal outcomes and a way to list all MTD answers without searching, but these are workable rather than blocking.
borough_oddsAInspectNYC hearing outcomes by borough/county: the share of decided hearings dismissed outright and dismissed-or-reduced in each borough, from the City's own records. Same ticket, different borough — measurably different odds.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add useful behavioral context: data source (City's own records), the metric (share of decided hearings), and the two outcome categories. It does not disclose limitations, output format, or whether only certain hearing types are included, leaving some ambiguity.
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 compact, front-loads the key content in the first sentence, and uses a short punchline to reinforce the tool's analytical point. No wasted words.
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 zero-parameter, no-output-schema tool, the description is largely sufficient: it names the data source, granularity, and exact statistic. It could be more complete by specifying how results are presented or whether the data covers parking/transit violations specifically, but nothing critical is missing for basic invocation.
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 tool has zero parameters, so the description does not need to document any. The schema coverage is vacuously 100%, and there is nothing for the description to compensate for regarding parameter meaning.
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 identifies the tool's output: NYC hearing outcomes by borough/county, specifically the share of decided hearings dismissed outright and dismissed-or-reduced. It is specific about both geography and metric, though it lacks an explicit imperative verb and does not directly contrast with siblings like violation_dismissal_rates.
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 implies when to use it: when you need borough-level NYC hearing dismissal odds from city records. However, it gives no explicit when-not-to-use guidance or alternatives, relying on the phrase 'by borough/county' to indicate scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
deadline_calculatorAInspectWork out the deadlines that follow from a private parking charge notice: when the discounted amount ends, when the appeal to the operator is due, and when the independent appeal to POPLA or the IAS is due. Give the notice date; give the operator to get the correct independent body and window, and the rejection date to get an actual independent-appeal date rather than a number of days.
| Name | Required | Description | Default |
|---|---|---|---|
| operator | No | Operator name, trading name or slug. Without it the independent window can only be given as 'POPLA 28 / IAS 21'. | |
| notice_date | Yes | Date printed on the parking charge notice, YYYY-MM-DD. | |
| rejection_date | No | Date the operator rejected the appeal, YYYY-MM-DD. The independent clock runs from this date, not from the notice. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses key behavioral traits: the result depends on operator for the independent body and on rejection_date for an actual date rather than a generic day count. It could also mention that no mutation occurs or that results are estimates, but the core conditional behavior is transparent.
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 tight sentences with no filler. The first states what the tool computes; the second gives the instructions needed to get the desired output. Every clause earns its place, and the conditional behavior is front-loaded.
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 three-parameter calculator with no output schema, the description covers the required input, explains the effect of each optional input, and names the outputs the caller should expect. It does not describe return structure or example values, but it gives enough to invoke the tool correctly in all intended modes.
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 structured schema already explains notice_date, operator, and rejection_date. The description reinforces the semantics but does not add substantial meaning beyond what the schema provides, so the baseline of 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?
States a specific verb ('Work out') and a specific resource (deadlines from a private parking charge notice), then names the exact deadlines it computes: discounted amount end, operator appeal due, and independent appeal to POPLA/IAS. This clearly distinguishes it from siblings like operator_route_lookup or popla_outcomes, which have different purposes.
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?
Gives concrete guidance on which inputs to provide and why: notice date is required, operator selects the correct independent body and window, rejection date yields an actual independent-appeal date instead of a day count. It lacks explicit exclusions or references to when a sibling tool would be preferred, so it stops one step short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_mtd_answerAInspectOne MTD answer in full: the question, the short answer, the complete plain-text body, the FAQ pairs, and every GOV.UK/HMRC source page the answer rests on. Use the slug from search_mtd_answers.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Answer slug, e.g. 'mtd-deadlines', 'who-has-to-use-mtd-in-2026'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the full return contract—question, short answer, body, FAQ pairs, and source pages—which makes behavior predictable. It does not cover auth, error cases, or side effects, but for a read-only get-by-slug tool this is a reasonable disclosure.
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 with no filler. The first sentence front-loads everything the agent needs to know about the return value, and the second sentence gives the critical input source. Every word earns its place.
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 one-parameter retrieval tool with no output schema, the description is largely complete: it defines what is returned, how to obtain the required slug, and the relationship to the sibling search tool. The only gap is unspecified error behavior, which is minor here.
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 schema already documents the slug parameter with examples at 100% coverage. The description adds meaning beyond the schema by specifying that the slug must come from search_mtd_answers, which clarifies provenance and avoids arbitrary slug guesses.
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 names a specific verb and resource: retrieving one MTD answer in full. It enumerates the answer's complete contents (question, short answer, plain-text body, FAQ pairs, source pages) and explicitly differentiates from search_mtd_answers by requiring its slug.
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 instruction 'Use the slug from search_mtd_answers' gives a concrete prerequisite and workflow, effectively telling the agent when this tool is appropriate: after locating an answer via the sibling search tool. It does not explicitly state when not to use it, but the contrast with search_mtd_answers is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_doorsAInspectThe Axion Doors registry: every machine-callable door this estate operates, each with the trust block an agent should read before believing a tool result — the named source the data comes from, the validation method actually applied to it, the date the source was last checked, and an honesty grade saying where the measurement is weak. Also lists the free endpoints, the MCP servers, and the priced doors that are dormant (they answer HTTP 402 with an empty accepts[] until a payment rail is live). Filter by zone, or ask for one field across every zone.
| Name | Required | Description | Default |
|---|---|---|---|
| zone | No | Zone hostname or a fragment of it — e.g. 'appealsdesk', 'nyc', 'mtd'. Omit for every zone. | |
| trust_only | No | Return only the trust blocks — source, validation method, check date, honesty grade — without the endpoint lists. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does substantial work: it discloses the trust-block contents, honesty grades, and the HTTP 402 behavior of dormant priced doors with empty accepts[] until payment rails are live. It does not mention pagination, rate limits, or exact response shape, but the core behavior is clearly disclosed.
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 relatively dense but front-loaded with the core purpose ('The Axion Doors registry') and packs useful behavioral detail into a compact space. It is not perfectly concise due to the long first sentence, but every clause contributes 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?
There is no output schema, so the description must convey what the tool returns, and it does: trust blocks with four named fields, free endpoints, MCP servers, and dormant priced doors. It is complete enough for an agent to select and invoke the tool, though the ambiguous 'one field' phrase and absence of an explicit return envelope keep it from being fully complete.
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 baseline is 3. The description adds 'Filter by zone', which mirrors the schema, but does not meaningfully enrich either parameter. The phrase 'ask for one field across every zone' is ambiguous and does not map to any documented parameter, so it does not add clear value beyond the schema.
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 identifies the tool as a registry of every machine-callable 'door' (endpoint/tool) and explicitly says it also lists free endpoints, MCP servers, and dormant priced doors. The verb 'lists' is explicit, the resource is well-scoped, and this is clearly distinct from the specific sibling lookup tools.
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 gives clear context for when to use the tool: before trusting results from other tools, an agent should read the trust block it provides, and it is the place to discover free endpoints and dormant doors. It does not explicitly name sibling alternatives or state when not to use it, so it stops 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.
operator_route_lookupAInspectLook up a UK private parking operator and get the independent appeals body that hears its appeals (POPLA or the IAS), the appeal window in days, the operator's own appeal and discount windows, and POPLA's decided-appeal record for it. Accepts a company name, a trading name, or an Appeals Desk slug. The route matters: BPA members go to POPLA (28 days), IPC members go to the IAS (21 days), and an appeal sent to the wrong body is wasted.
| Name | Required | Description | Default |
|---|---|---|---|
| operator | Yes | Operator company name, trading name, or slug — e.g. 'ParkingEye', 'Euro Car Parks', 'apcoa-parking'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing accepted input forms (company name, trading name, or slug) and the practical consequence of misrouting appeals. It stops short of describing error behavior or explicitly confirming a read-only operation, but the lookup framing and domain warning cover the main behavioral risks.
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 dense sentences front-load the tool's purpose and output, then provide accepted input forms and the critical routing rule. Every sentence earns its place, and there is no fluff or repetition of schema content.
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 lookup with no output schema, the description explains both the inputs and the expected return content well. It could go slightly further by noting what happens when an operator is not found, but the essential information an agent needs to call it successfully is 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?
Schema coverage is 100%: the only parameter, 'operator', is fully described with accepted types and examples. The description adds no new parameter meaning beyond what the schema already provides, so the 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 description uses a specific verb ('look up') and names the exact resource (UK private parking operator) plus the key outputs (POPLA/IAS, appeal windows, POPLA record). It clearly differentiates this tool from siblings like popla_outcomes and deadline_calculator by tying operator lookup to appeal routing.
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 provides clear contextual guidance: BPA members go to POPLA with 28 days, IPC members go to the IAS with 21 days, and sending an appeal to the wrong body wastes it. It does not explicitly name sibling alternatives or state when not to use this tool, but the routing guidance gives enough context for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plate_lookupAInspectLook up every OPEN parking and camera violation for a New York plate, live from the City of New York's public Open Data API. Returns each ticket (violation, date, amounts, judgment status), the totals owed, an estimated judgment outlook per ticket, the boot-risk position against the city's $350 judgment-debt threshold, and the citywide dismissal rate for each ticket's violation type. Privacy: the plate is sent to the City's API and back inside this one request — never stored or logged by this server.
| Name | Required | Description | Default |
|---|---|---|---|
| plate | Yes | License plate, letters and digits only — e.g. 'ABC1234'. | |
| state | Yes | Two-letter registration state, e.g. 'NY', 'NJ'. | |
| license_type | No | Optional plate class code (PAS, COM, OMT, SRF, OMS, APP, TRC, TRL, MOT). Omit to search all types — most drivers should omit it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does meaningful work: it states the data is live, limited to OPEN violations, and never stored or logged by the server. It could add authentication/rate-limit details, but the privacy and live-data traits are valuable beyond the tool name.
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 purpose is front-loaded in the first sentence, the return payload is summarized in one sentence, and privacy is one final sentence. It's dense but not padded; every sentence contributes.
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?
Given there is no output schema, the description compensates by enumerating the return fields (ticket details, totals owed, judgment outlook, boot-risk threshold, dismissal rate). It doesn't spell out error handling or exact response structure, but an agent has enough to understand what comes back.
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 schema already explains plate, state, and license_type with examples and the advice to omit license_type. The free-text description adds little parameter detail beyond saying the plate is a New York plate, which is already implied.
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 opening sentence names a specific action (look up every OPEN parking and camera violation) and resource (City of New York's public Open Data API). It is clear enough to distinguish from sibling tools like borough_odds or deadline_calculator, though it never explicitly names an alternative such as violation_dismissal_rates.
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 gives no when-to-use guidance or exclusions versus siblings. It implies usefulness for checking current tickets and boot risk, but it never tells the agent when to prefer this tool over violation_dismissal_rates or other lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
popla_outcomesAInspectPOPLA's own record of how private parking appeals were decided, per operator, across its 2023, 2024 and 2025 annual reports. Give an operator for its three-year series and its change in percentage points; omit it for the all-operator totals and a ranking. These are decided appeals only — appeals an operator withdraws end in the driver's favour without a ruling and are counted separately.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many operators to return in the ranking when no operator is given. Default 20. | |
| order | No | Ranking order when no operator is given. Default best_for_driver. | |
| operator | No | Operator name, trading name or slug. Omit for the estate-wide summary and ranking. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden, and it handles the most important behavioral nuance: 'decided appeals only' and the note that withdrawn appeals end in the driver's favour but are counted separately. This prevents a likely misinterpretation of what the data includes. It does not discuss output format or access constraints, but the core counting boundary is clearly disclosed.
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 source, period, per-operator vs aggregate behavior, and the crucial counting caveat, with no filler. The most actionable guidance is front-loaded, and the withdrawal nuance is separated cleanly at the end.
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 tool with no annotations and no output schema, the description gives a complete enough mental model: the source, the three-year scope, what happens when an operator is supplied versus omitted, and the decided-appeals definition. The ranking options and limits are already covered by the schema, so nothing essential appears missing.
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 schema already documents all three parameters, including defaults and the omit-operator instruction; the baseline is therefore 3. The description does add some color by tying the operator parameter to a 'three-year series' and 'change in percentage points,' but that is more output semantics than additional parameter syntax or format detail.
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 opening clause clearly identifies the resource and scope: POPLA's appeal outcomes per operator across the 2023–2025 annual reports. The imperative guidance — give an operator for a series and percentage-point change, omit it for totals and ranking — makes the query behavior concrete. It does not explicitly distinguish itself from siblings like violation_dismissal_rates, so it stops short of a 5.
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 gives explicit usage direction for the key branch: supply an operator for its series, or omit it for the all-operator totals and ranking. It also clarifies that only decided appeals are included and that withdrawals are handled separately. It does not state when to prefer this tool over sibling tools, so an explicit exclusion is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_mtd_answersAInspectSearch 30 plain-English answers about UK Making Tax Digital for Income Tax — thresholds and start dates (£50k Apr 2026 / £30k Apr 2027 / £20k Apr 2028), quarterly update deadlines, digital records, penalties, exemptions, sign-up, software. Every answer is sourced line-by-line to named GOV.UK/HMRC pages, re-checked 14 August 2026. Returns the matching questions with short answers; call get_mtd_answer for the full text and sources.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, default 5. | |
| query | Yes | The question or topic, e.g. 'when do landlords have to start', 'quarterly deadline', 'penalties for missing an update'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a good job: it discloses the return shape ('matching questions with short answers'), the source freshness ('re-checked 14 August 2026'), and intentionally omits full text/sources. This prevents an agent from expecting more than the tool delivers.
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 dense, front-loaded sentences with no filler. The core action and scope come first, followed by sourcing trust signals and the sibling pointer. Every clause adds operational value.
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 two-parameter search tool with no output schema or annotations, the description covers return behavior, source verification, and the full-text alternative. Minor gaps like result ranking or empty-result behavior are not critical enough to lower the score further.
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%, so the 'query' and 'limit' parameters are already documented with examples and constraints. The description reinforces the topical scope but adds no new parameter syntax or semantics beyond the schema.
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 starts with a concrete verb and resource: 'Search 30 plain-English answers about UK Making Tax Digital for Income Tax.' It also distinguishes itself from the sibling detail tool by explicitly saying 'call get_mtd_answer for the full text and sources.'
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?
It gives clear usage context by explaining what this tool returns and directing the agent to get_mtd_answer when full text and sources are needed. It doesn't explicitly exclude other siblings, but the search-vs-detail relationship is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
violation_dismissal_ratesAInspectHow New York City parking and camera tickets are actually decided at hearing, violation type by violation type — the share dismissed outright and the share dismissed or reduced, computed from the City's own published hearing records (119.8M rows). Give a violation to get its rates (partial names match, e.g. 'SIDEWALK' or 'MUNI METER'); omit it for a ranking of all 80 violation types.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many rows in the ranking. Default 20. | |
| order | No | Ranking order when no violation is given. Default most_dismissed. | |
| violation | No | Violation name as printed on the ticket, or a fragment of it. Omit for the full ranking. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does substantial work: it discloses the data source and scale ('119.8M rows'), the two output modes, partial-name matching, and the fact that all 80 violation types are ranked when no violation is given. It does not state exact response field names or error behavior for unmatched violations, but the core behavior is transparent.
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 compact at two sentences and front-loads purpose before usage, with no wasted boilerplate. The first sentence is somewhat convoluted ('How ... are actually decided at hearing, violation type by violation type'), but every clause adds either scope, output semantics, or source credibility.
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?
Because no output schema exists, the description appropriately explains what the tool returns: per-violation dismissal rates and a ranking of all 80 violation types. It is complete enough for an agent to choose parameters, though it could clarify the exact response shape for a single violation and behavior when a partial name matches multiple violation types.
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%, so the schema already documents limit, order, and violation. The description adds value beyond the schema by explaining partial-name matching with examples ('SIDEWALK' or 'MUNI METER') and relating order/limit to the ranking of all 80 violation types.
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 identifies a specific resource ('New York City parking and camera tickets'), the exact output metrics ('share dismissed outright and the share dismissed or reduced'), and the computation source ('the City's own published hearing records'). It clearly differentiates from siblings by focusing on violation-type dismissal rates from hearing data rather than borough odds, deadlines, or plate lookups.
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?
It gives explicit invocation guidance: 'Give a violation to get its rates' versus 'omit it for a ranking of all 80 violation types,' including the partial-match behavior. It does not name alternative tools or state when not to use this tool, so it stops short of full alternative-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Independent fact-checking for AI answers: a verdict and sources for every claim.
Current UK tax-year rates and thresholds, verified against gov.uk with source URLs and dates.
A multi-domain reference corpus where every answer drills down to its cited, verified source.
Fact-check citations: resolve, match, support claims. Arithmetic rechecked. Free to start.
