Verified answers with named sources: UK parking appeals, NYC dismissal rates, UK MTD tax facts.
Scored across 11 tools
Several tools draw on the same underlying datasets and can answer similar questions: nyc_ticket and violation_dismissal_rates both surface violation-type dismissal rates, and parking_route embeds the same POPLA operator record that popla_outcomes is dedicated to. The descriptions are detailed enough to steer an agent to the right tool, but the boundaries are not as clean as they could be.
Most data-lookup tools use descriptive noun phrases (borough_odds, nyc_ticket, popla_outcomes), while three tools use verb-led names (get_mtd_answer, list_doors, search_mtd_answers), and related MTD tools don't share a consistent style (mtd_scope vs search/get). All names are readable and snake_case, but no single predictable convention runs through the set.
11 tools is a reasonable size for a gateway that exposes several distinct consumer lookup domains, plus a registry door (list_doors). Each tool appears to earn its place and the set avoids both bloat and an under-equipped surface.
Coverage within each advertised niche is strong: NYC parking has plate-level and aggregate views, MTD has scope plus searchable answers, and US denial/screening tools are one-call complete. Minor gaps remain, such as no equivalent IAS outcomes data for UK private parking operators that appeal through the IPC rather than POPLA.
NYC 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.
One call for a denied US health-insurance claim: both free appeal clocks with your actual dates where they can be computed, which external-review route applies (state, federal, or the federal one regardless of your state because the plan is self-funded), what the CMS file records for external reviews filed and overturned in that state and for that insurer — or 'not reported' where the file does not carry it — the insurer's own published appeal procedure where we have read it, and your state insurance department's consumer line with the date we read it from their own site. Free, no key, attribution required. Source: CMS Transparency in Coverage Public Use File (PY2026 release), 45 CFR 147.136.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | US state name, slug or two-letter code. Decides the external-review route and the consumer line. | |
| insurer | No | Insurer slug or name — the free index is https://denialfacts.com/api/insurers. An unresolved value comes back named in `unresolved`, never as a 404. | |
| denial_date | No | Date on the denial notice, YYYY-MM-DD. Gives an actual internal-appeal deadline. The external-review deadline runs from the FINAL internal denial and is never derived from this date. | |
| self_funded | No | True if coverage is through a job and the employer pays the claims itself (a self-funded plan, 63% of covered workers). If true the state process does not apply whatever your state operates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite the annotations already covering read-only and idempotent behavior, the description adds meaningful behavioral insight: 'Free, no key, attribution required', a named data source, 'or "not reported" where the file does not carry it' describing fallback, and the date the consumer line was ingested. These traits go beyond 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 dense and prioritized: it opens with the main outcome and the key differentiators, then adds source and attribution. A single long sentence with many distinct outcomes is not broken into bullet points, but every clause is loaded with relevant detail and nothing is filler.
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?
No output schema exists, but the description enumerates all the outputs: both appeal clocks, the external-review route, CMS file records, insurer's procedure, and the consumer line with the date it was read. It also covers caveats ('where they can differ', 'where not report') and the license. This is a full account of what the tool returns.
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 elaborates all 4 parameters. The description echoes some parameter implications, such as how self-funded plans are dealt with and that the external-review deadline is not computed from denial date, but it adds no new detail beyond the schema. Baseline 3 is therefore adequate.
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 immediately identifies the tool as a comprehensive response for a denied US health-insurance claim: 'One call for a denied US health-insurance claim: both free appeal clocks...' and enumerates specific deliverables. This is a specific verb (one call/lookup) plus resource and distinguishes its domain from all sibling tools, which are about parking/ticketing/door topics.
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 opening 'for a denied US health-insurance claim' clearly defines the invocation context, and parameters like state, insurer, self-funded, etc., map to the decision logic. It does not name alternatives or say when not to use it, but no sibling tool appears to overlap in domain, so the use case is sufficiently navigable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One 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.
The 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.
One call for UK Making Tax Digital for Income Tax scope: give gross qualifying income (self-employment plus UK and foreign property, before expenses) and get whether you are in, from which date, which threshold and which tax return decided it, your first quarterly update deadline and all four dates, how many quarterly updates you owe (a foreign property is a SEPARATE business from a UK one), and the automatic exemptions. Answers the £20,000-or-less automatic exemption and the not-yet-but-soon case explicitly rather than returning nothing. Free, no key, attribution required. Every fact is traced to a named GOV.UK/HMRC page on mtdfacts.co.uk; the governing law is the Income Tax (Digital Obligations) Regulations 2026 (SI 2026/336).
| Name | Required | Description | Default |
|---|---|---|---|
| return_year | No | Which tax return the figures are from. Defaults to 2024-25, the return that decides MTD from 6 April 2026. | |
| has_property | No | True if any of that income is UK property income. Decides how many quarterly updates are due, not whether you are in scope. | |
| qualifying_income | Yes | Gross qualifying income in pounds: self-employment income plus UK and foreign property income, BEFORE expenses, from the tax return named by return_year. Employment (PAYE), partnership profit share, dividends and pensions are excluded. | |
| has_self_employment | No | True if any of it is self-employment income. Also a separate business for quarterly updates. | |
| has_foreign_property | No | True if any of it is foreign property income. A foreign property business is SEPARATE from a UK one: its own quarterly update, and separate digital records for each individual foreign property. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds meaningful behavior beyond that: it explicitly handles edge cases rather than returning nothing, treats foreign property as a separate business, notes there is no key, says attribution is required, and cites traceable sources plus the governing regulation. No contradiction with 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 front-loaded with the core one-call framing and outputs, but the first sentence is a long, run-on enumeration. The closing sentences about sourcing and the governing regulation are relevant for trust and attribution but are slightly tangential to calling the tool; overall it's dense but not bloated.
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?
With no output schema, the description does the needed work by enumerating what the caller gets: in/out status, scope date, threshold, deciding tax return, quarterly deadlines and count, exemptions, and special cases. It also communicates service constraints (free, no key, attribution required, sourced facts), making it sufficient for an agent to invoke the tool without major unknowns.
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 input schema already documents all five parameters at 100% coverage, so the baseline is 3. The description reinforces the meaning of qualifying income and warns that foreign property is separate, but most of that is already present in the schema's property descriptions, so the description adds little beyond the structured documentation.
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 a clear 'One call for UK Making Tax Digital for Income Tax scope' and specifies exact inputs and outputs (income, in/out status, date, threshold, tax return, deadlines, exemptions). It is unambiguous and domain-specific, but it does not explicitly contrast the sibling tools like get_mtd_answer or search_mtd_answers, so it stops short of full 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 description gives a strong contextual sense that this is the purpose-built tool for MTD scope: yielding income as input and returning scope details, including automatic exemption and 'not-yet-but-soon' cases. However, it never names alternatives or conditions for when NOT to use this tool, so usage guidance is clear by context but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One call for a New York plate: every OPEN parking and camera violation live from the City's own Open Data API, what is owed and what is already in judgment, the citywide dismissal and dismissed-or-reduced rate for each ticket's violation type from the City's published hearing records, and the clocks — 30 days from the date on the ticket to request a hearing before late penalties start, roughly 100 days from issue before an unanswered ticket goes into judgment, and the $350 judgment-debt level at which a car can be booted. Disputing is free at nyc.gov and always has been. PRIVACY: the plate goes to the City's API and back inside this one request and is never stored or logged here. Free, no key, attribution required.
| Name | Required | Description | Default |
|---|---|---|---|
| plate | Yes | License plate, letters and digits only — e.g. 'ABC1234'. Sent to the City's public API and back inside this request; never stored. | |
| 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?
The description goes beyond the readOnly/destructive annotations by revealing that the plate is sent to the City's live Open Data APIional and is never stored or logged, plus that it is free, requires no key, and needs attribution. It also explains external side effects and privacy behavior clearly.
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 main purpose is front-loaded with 'One call for a New York plate,' and the rest is a well-organized stream of relevant details. It is dense and a bit long, but all the extra data points (deadlines, boot threshold, pricing/privacy) are directly useful rather than filler.
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?
Since there is no output schema, the description usefully enumerates what is returned: open violations, owed amounts, dismissal odds, and deadlines/thresholds. It also mentions privacy and cost model. It doesn't discuss pagination, error cases, or how to interpret combined data, but it is largely self-contained.
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 parameters are already fully described in the schema: 'plate' and 'state' with license_type as an optional class code with enumerated values. The description adds no additional parameter-level guidance beyond the schema, so the baseline score of 3 applies.
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 begins with 'One call for a New York plate' and then enumerates the exact outputs: open violations, amounts owed, judgment status, dismissal rates, and deadlines. This makes the tool's purpose very clear, though it does not explicitly distinguish it from sibling tools such as borough_odds or list_doors.
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 makes the primary use case clear — a single lookup for an NYC plate that combines violations, odds, and deadlines. It implies when to use it but does not explicitly state when not to use it or name alternatives, so it stops short of a full usage decision guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One call for a UK private parking charge notice: which independent appeals body hears this operator's appeals (POPLA for BPA members, the IAS for IPC members) with the published source for the window, all three deadlines computed from your dates (the discount window, the appeal to the operator, the independent appeal), and POPLA's own record for that operator — appeals decided, appeals allowed, the allowed share, the three-year series and how many the operator did not contest. Sending an appeal to the wrong body wastes the one free independent appeal and neither service forwards to the other, so an ambiguous operator name returns the candidates rather than a guess. Free, no key, attribution required. Source: POPLA Annual Report Appendices 2023-2025 and the published BPA and IPC member lists.
| Name | Required | Description | Default |
|---|---|---|---|
| issuer | Yes | The parking operator's company or trading name as printed on the notice — e.g. 'ParkingEye', 'Euro Car Parks', 'APCOA'. An ambiguous name returns candidates, never a guess. | |
| notice_date | No | Date printed on the parking charge notice, YYYY-MM-DD. Without it no deadlines are computed. | |
| rejection_date | No | Date the operator rejected your appeal, YYYY-MM-DD. The independent-appeal clock runs from this date, not from the notice. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructiveHint. The description adds meaningful behavioral detail: ambiguous operator names return candidates instead of a guess, sources are published, the tool is provided free without a key, and dates trigger deadline computation. No contradiction exists.
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 dense but focused and front-loads the tool's purpose. It covers the three main output categories plus important caveats in about 200 words. It is a single long paragraph, though; bulleted or segmented structure would make it even easier to scan.
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 3-parameter read-only, non-destructive tool, this is a near-complete description: it enumerates the output content (body, three deadlines, POPLA history, dispute rate) and notes the candidate-instead-of-guess behavior. No output format is specified, but the context and annotations supply enough for an agent to invoke or supply.
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% because each property already has a clear explanation. The description adds semantic links beyond the schema: issuer maps to the appeals body, rejection_date drives the independent-appeal clock, and no notice_date means no deadlines are computed. This gives the agent reasoning guidance, not just type information.
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 specifies the tool's scope: a single call that returns the correct appeals body, three deadlines, and the POPLA record for a UK private parking charge. It is a specific verb-and-resource bundle, but it does not explicitly differentiate itself from the sibling popla_outcomes, which overlaps on the POPLA-record portion.
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 the tool would be used — for a UK private parking charge with the notice date and rejection date — and warns that the wrong appeal body wastes the free appeal. It does not state when to prefer siblings such as popla_outcomes or denial_clock for more restricted runs, nor does it name alternatives in those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
POPLA'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.
Given a US tenant- or employment-screening company (Checkr, HireRight, First Advantage, Sterling, LexisNexis, ChexSystems, SafeRent, RentGrow, TransUnion Rental, AppFolio, RealPage, CoreLogic, Experian RentBureau, Early Warning), return that company's verified dispute route (portal URL, phone, email, postal address, each with the date it was read from the company's own site), the FCRA clock that applies after an adverse action (60 / 30 / 45 days, cited to statute), what the federal CFPB complaint record shows happened to people who complained about that company, and whether the screening company or the platform is the party that can actually fix the error. Free, no key, attribution required. Source: CFPB Consumer Complaint Database; narrative-derived counts cover 2011 - 14 Aug 2026, when the CFPB ceased publishing narratives.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Two-letter US state code. | |
| company | No | One of the fourteen screening-company slugs. Free index: https://screeningfacts.com/api/companies. | |
| situation | No | One of the eight situation slugs. Free index: https://screeningfacts.com/api/situations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, but the description adds substantial context: it is free, requires no key, mandates attribution, specifies the data source (CFPB database with narrative counts through 14 Aug 2026), and notes that dispute route dates are read from the company's own site. This goes well beyond the annotations, making the tool's side effects, data freshness, and usage constraints 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 a single dense paragraph but well-structured: it opens with the input condition, lists the return items, and then gives source and attribution details. It front-loads the most critical info (what it returns) before the source details. While it is long, every sentence carries necessary information for such a complex tool, and there is no fluff. It earns a 4 for being appropriately detailed without being rambling.
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 fully specify what the agent can expect. It enumerates every return component: the dispute route (portal URL, phone, email, postal address, each with date read), the FCRA clock (60/30/45 days cited to statute), the CFPB complaint record narrative, and whether the company or platform can fix the error. It also notes the source and attribution requirement. An agent has everything needed to call the tool correctly and interpret the result.
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 input schema already provides 100% coverage with descriptions for each parameter, so the baseline is 3. The description adds value by clarifying that `company` and `situation` are slugs, and it provides free index URLs for both (`https://screeningfacts.com/api/companies` and `/api/situations`). It also implicitly clarifies the meaning of the parameters by explaining what the tool returns for each. This goes beyond the schema's bare definitions.
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 verb ('return') and a precise resource: the dispute route, FCRA clock, CFPB record, and responsible party for a named screening company. It lists the fourteen companies and clearly differentiates from sibling tools by focusing on screening disputes (vs. tickets, parking, or MTD answers). An agent can immediately tell what this tool does and when it applies without ambiguity.
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 conveys its purpose clearly but does not explicitly discuss when to use it versus alternatives (e.g., denial_clock or parking_route). It relies on the subject matter to distinguish itself, which is sufficient given the distinct sibling names, but it lacks an explicit 'use this when…' or 'for X, use Y instead' statement. The context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 32 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 disclosure burden. It reveals the corpus size (32 answers), topical scope, sourcing method, and verification date, and states what is returned. It doesn't explicitly state read-only behavior or limitations like ranking or missing matches, but a search tool's side effects are minimal.
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 that front-load the topic and scope, then add provenance and routing. No filler or redundancy.
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?
Complexity is moderate; no output schema exists, so the description must summarize return shape. It says 'matching questions with short answers,' which is sufficient for basic invocation. Missing exact result fields or match behavior are minor given the sibling tool handles full text.
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 baseline is 3. Description adds value by giving concrete example queries ('when do landlords have to start', 'quarterly deadline') that clarify the expected input format for the query parameter. Limit's behavior still relies on 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 uses a specific verb ('Search') and a precise resource ('32 plain-English answers about UK Making Tax Digital for Income Tax'), enumerating the question topics. It clearly distinguishes this from get_mtd_answer, which an agent can infer is for full answers rather than search snippets.
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?
Explicitly routes the agent: use this tool to get matching questions with short answers, and 'call get_mtd_answer for the full text and sources.' This directly states the alternative and the condition that selects it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
deadline_calculatordenial_clockmtd_scopenyc_ticketoperator_route_lookupparking_routeplate_lookupscreening_disputedeadline_calculator1 field changedInput schema / properties / operator / descriptionPrevious value: -"Operator name, trading name or slug. Without it the independent window can only be given as 'POPLA 28 / IAS 21'."New value: +"Operator name, trading name or slug. Without it the body cannot be named — the window is 28 days at either body, but the appeal still has to reach the right one."borough_oddsdeadline_calculatorget_mtd_answerlist_doorsoperator_route_lookupplate_lookuppopla_outcomessearch_mtd_answersviolation_dismissal_ratesIndependent fact-checking for AI answers: a verdict and sources for every claim.
Check and appeal UK parking tickets (PCNs): grounds, deadlines, draft letters and filing.
Current UK tax-year rates and thresholds, verified against gov.uk with source URLs and dates.
Free, no key: UK parking ticket appeal guides, PCN contravention codes and deadline calculator.
Add one secure layer between your agents and this server.
