Verified answers with named sources: UK parking appeals, NYC dismissal rates, UK MTD tax facts.
Scored across 11 tools
Most tools target distinct queries, but there is real overlap: borough_odds, violation_dismissal_rates, and nyc_ticket all deal in NYC hearing outcomes (borough-level, violation-type-level, and per-plate respectively), and parking_route vs popla_outcomes both surface POPLA operator records. The descriptions do differentiate scope (aggregate vs per-item, route vs record), so an agent can usually pick correctly.
Conventions are mixed: verb_noun names (list_doors, get_mtd_answer, search_mtd_answers) sit alongside bare noun phrases (borough_odds, denial_clock, mtd_scope, nyc_ticket, popla_outcomes). Names are readable and snake_case throughout, but the verb/noun style is not predictable.
Eleven tools is a reasonable scope for a multi-domain consumer-rights gateway, and each tool has a distinct underlying data source. It is slightly heavy relative to the loose thematic coherence of the set, but nothing feels redundant in count.
Coverage per topic is largely solid: MTD has search/get/scope, NYC parking has per-plate, violation, and borough views, UK parking has route plus outcome records, and denial_clock and screening_dispute are deep single-call tools. Minor gaps exist (no refresh/provenance-update tool, single points of failure for insurance denial and screening), but the surface has no obvious dead ends.
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?
Annotations already establish read-only, non-destructive, idempotent behavior. The description adds useful context beyond those flags: the data source is 'the City's own records', the denominator is 'decided hearings', and the two computed metrics are dismissed outright and dismissed-or-reduced. It does not contradict the annotations, though it omits format details such as percentage versus fraction.
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 definition is compact, with the core factual content front-loaded in the first sentence. The second sentence is rhetorical rather than operational, but it reinforces the comparison use case. Overall it is appropriately sized with minimal waste.
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, read-only tool, the description supplies the essential context: what is measured, the borough/county breakdown, and the source of the data. No output schema exists, and the description does not spell out exact value formatting or recency, but the low complexity means nothing critical is 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?
The tool has zero parameters and an empty input schema, so there is no parameter burden for the description to carry. Baseline 4 applies because nothing additional is required. The description's metric definitions are the only relevant semantic content, and they are sufficient.
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 resource and metric: dismissal odds for NYC hearings broken out by borough/county. The 'Same ticket, different borough' line signals the geographic-comparison angle that distinguishes it from more general ticket tools. It lacks an explicit verb like 'retrieve' or 'list' and does not name alternatives, so it stops short of top marks.
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 the use case: comparing dismissal odds across boroughs for the same ticket type. However, it does not explicitly state when to choose this tool over siblings like violation_dismissal_rates or nyc_ticket, nor does it mention exclusions. Guidance remains implied rather than actionable.
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. Use it at the second no as well, when the plan has said no again on internal appeal: external review is the step after it, and the CMS figures show how often that step overturned the insurer. 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?
Annotations already declare read-only, idempotent, open-world, non-destructive behavior, so the safety bar is covered. The description adds genuinely useful context beyond them: free with no key, attribution required, the data source and release year, and a regulatory citation (45 CFR 147.136). It stops short of describing response completeness per field, which keeps it from a 5.
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 body is a single sprawling sentence threaded with em-dash clauses, so the key routing information is buried mid-stream rather than front-loaded. Every clause carries information, but the run-on structure makes it hard to scan and is the definition's weakest dimension.
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 and four parameters, the description must describe the return surface itself, and it does: clocks, actual dates where computable, route determination, CMS filed/overturned counts with an explicit 'not reported' fallback, the insurer procedure, and the consumer line with a read date. That is close to complete for an agent to call it correctly, missing only a note on the shape/ordering of the response.
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 every parameter, including the self_funded implication and the denial_date-versus-final-denial distinction. The description adds no syntax or format detail beyond that, so the baseline 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 names a specific resource — a denied US health-insurance claim — and enumerates the concrete outputs: both appeal clocks with dates, the external-review route, CMS filed/overturned figures, the insurer's published procedure, and the state consumer line. It is unambiguous about what it does, though sibling differentiation is moot because the sibling list (parking, NYC tickets, MTD answers) shares no domain.
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 an explicit trigger: 'Use it at the second no as well, when the plan has said no again on internal appeal,' and explains why the external-review step follows. That is clear usage context, but it names no alternative tool or when-not-to-use condition, so it falls 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 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds what data is returned (the full answer structure), which is useful given no output schema. It doesn't contradict annotations and adds value by enumerating the content.
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, front-loaded with what the tool returns, and the usage instruction is placed at the end. No fluff, every word earns its place. Efficient and well-structured.
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 read-only tool with one well-documented parameter and rich annotations, the description is complete. It names the return components, which compensates for the lack of an output schema. It doesn't mention potential errors, but for a simple fetch-by-slug operation, that's acceptable.
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 has 100% coverage for the slug parameter with examples, so baseline is 3. The description adds meaning by stating the slug comes from search_mtd_answers, which tells the agent where to obtain a valid parameter value. This is extra 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 states a specific verb ('get') and resource ('one MTD answer') and enumerates the exact components returned (question, short answer, body, FAQ pairs, GOV.UK sources). It differentiates from the sibling search_mtd_answers by implying this returns a single full answer, while the sibling is for searching.
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 instructs the agent to 'Use the slug from search_mtd_answers', providing a direct workflow: first search, then retrieve by slug. This is a clear when-to-use directive that also implies this tool is not for searching and should be called only after obtaining a slug.
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?
Annotations already mark the operation read-only, idempotent, and non-destructive; the description adds meaningful behavioral detail by disclosing that dormant priced doors answer HTTP 402 with empty accepts[] until a payment rail is live and that honesty grades flag weak measurements. No contradiction with annotations 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 longer than average but information-dense: it covers scope, trust-block contents, dormant-door behavior, and filtering options. It is front-loaded with the registry purpose and contains 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 read-only registry with two optional parameters and no output schema, the description compensates well by explaining the returned trust fields, endpoint categories, honesty-grade caveat, and dormant-door HTTP behavior. It is not fully complete because the exact response shape and the meaning of 'one field across every zone' are left unspecified, but the practical call context is well covered.
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?
Both parameters are fully documented in the schema: zone as a hostname or fragment, and trust_only as a boolean. Because schema coverage is 100%, the description carries little additional semantic burden. The phrase 'ask for one field across every zone' is vague and not clearly mapped to trust_only, limiting added value over 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 list_doors as the registry of every machine-callable door and enumerates the trust-block fields returned: source, validation method, check date, and honesty grade. This distinguishes it from domain-specific siblings like nyc_ticket or popla_outcomes, though it never names a sibling explicitly.
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 advises agents to read the trust block before believing a tool result, giving a clear when-to-use context. It also provides concrete invocation options: filter by zone or request data across every zone. It does not explicitly list exclusions or alternative tools, but the registry role makes the use case reasonably self-evident.
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. Use it at the second no as well, when the operator has rejected the appeal and POPLA has refused it too: the record shows how that operator's decided appeals went, and a POPLA decision binds the operator, not the driver. 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?
With readOnly/idempotent/openWorld already declared, the description still adds substantial context: free, no key, attribution required, ambiguity never guessed, and the crucial warning that sending an appeal to the wrong body wastes the single free independent appeal since neither service forwards. That is genuine behavioral disclosure 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?
Purpose and return contents are front-loaded, and each sentence (routing, deadlines, record, wrong-body warning) carries distinct information. The single dense paragraph is long, but no sentence 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?
With no output schema, the description fully enumerates the return payload — deciding body with source, three deadlines, and POPLA statistics (decided, allowed, allowed share, three-year series, uncontested count). An agent knows exactly what to expect.
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, but the description adds dependency semantics: deadlines are only computable when notice_date is present, and rejection_date is what starts the independent-appeal clock. It clarifies how the dates interact rather than merely restating them.
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 first clause states a specific verb and resource ('One call for a UK private parking charge notice') and then enumerates exactly what is returned: appeals body routing, three computed deadlines, and the POPLA operator record. That precision clearly separates it from siblings like popla_outcomes or denial_clock.
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 concrete usage conditions — use it when routing an appeal, and 'at the second no as well' after operator and POPLA refusal — plus the failure mode that an ambiguous operator name returns candidates. It never names a sibling tool as the alternative to use instead, 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.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context by specifying that only decided appeals are included and that withdrawals end in the driver's favour without a ruling and are counted separately.
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 three sentences with no filler. It front-loads the core purpose, then gives parameter guidance, then clarifies an important data-scope nuance. Every sentence 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?
Given the moderate complexity, full schema parameter descriptions, and strong annotations, the description is complete. It explains the data source, the two calling modes, the output shape (series/change vs. totals/ranking), and the key exclusion of withdrawals. No output schema exists, but the description sufficiently conveys what the caller should expect.
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 value beyond the schema by explaining the semantic difference between supplying an operator (three-year series and percentage-point change) and omitting it (all-operator totals and ranking). This clarifies the operator parameter's role more than the schema alone.
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 resource (POPLA's record of private parking appeal outcomes), the scope (per operator across 2023-2025 annual reports), and the two modes of use (per-operator series vs. all-operator totals/ranking). It is specific enough to distinguish this tool from siblings like violation_dismissal_rates or denial_clock.
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 instructions on when to provide an operator versus omit it, and clarifies that withdrawals are counted separately. It does not name alternative tools or state when not to use this tool, but the usage context is clear and actionable.
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 | A situation slug, or the person's own sentence (e.g. 'wrong criminal record on my background check'), which returns suggested guide slugs to pick from and call again with, never a resolved guide. Free index: https://screeningfacts.com/api/situations. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent/non-destructive, and the description adds meaningful behavioral context beyond them: the CFPB data source, the narrative-derived count coverage window and cutoff date, the no-key/free/attribution requirement, and the fact that dispute-route data is read from companies' own sites with read dates. 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 action and packs useful details about outputs, source, time range, and cost/attribution into two sentences. However, the first sentence is dense and run-on, enumerating many outputs in a way that could be easier to parse with structured formatting.
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 output schema, the description covers the main return content, the data source, the temporal scope, and usage constraints such as attribution. It does not specify the exact output shape or clarify how the state parameter affects results, but the detail provided is adequate for correct 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?
Schema description coverage is 100%, so the baseline is 3. The description adds a few examples of company names and clarifies the free-text situation behavior, but it does not substantially deepen the meaning of the parameters beyond what the schema already documents.
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 resource class (US tenant- and employment-screening companies), a specific verb ('return'), and enumerates four concrete outputs: verified dispute route, FCRA clock, CFPB complaint record, and the party responsible for fixing errors. This clearly distinguishes the tool from its siblings, which are about parking, NYC, and MTD 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?
It gives clear input conditions ('Given a US tenant- or employment-screening company') and explains the situation-parameter behavior ('never a resolved guide'). It does not explicitly state when not to use the tool versus alternatives, but the sibling tools are topically unrelated, so the usage context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 35 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to re-state the safety profile. It adds meaningful transparency about data provenance and freshness ('sourced line-by-line to named GOV.UK/HMRC pages, re-checked 14 August 2026'), which helps an agent trust the results. It does not disclose pagination or result-count behavior beyond 'short answers', but this is not critical for a read-only search.
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 two sentences, both high-signal: the first scopes the resource and topics, the second gives provenance and the routing instruction. No filler or repetition of schema fields.
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 lightweight read-only search tool, the description covers what the tool returns, its scope, provenance, and where to go for full detail. The absence of an output schema is mitigated by 'Returns the matching questions with short answers'. A mention of mtd_scope as a sibling for scope-related queries would make it fully complete, but is not essential.
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 query and limit. The description adds value by giving concrete example query strings ('when do landlords have to start', 'quarterly deadline', 'penalties for missing an update'), which clarifies intended input semantics beyond the schema's generic 'question or topic'.
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 specific verb and resource — 'Search 35 plain-English answers about UK Making Tax Digital for Income Tax' — and enumerates covered topics and key details (thresholds, dates). It also distinguishes itself from get_mtd_answer by stating that it returns matching short answers, not full text.
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 final sentence explicitly routes agents needing full text and sources to the sibling get_mtd_answer, giving a clear alternative and selection condition. This is direct usage guidance within the description itself.
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?
Annotations already carry the read-only, non-destructive, idempotent profile, so the description adds useful behavioral context beyond them: it notes the 119.8M-row public source, partial-name matching behavior, and the two rates produced. It also discloses that omitting the violation produces a full ranking. 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?
Two sentences carry the entire definition with no filler: the first sets the domain and goal, the second covers both invocation modes with examples. Front-loaded and highly scannable.
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 adequately explains what the tool returns—dismissal and dismissal/reduction rates per violation—and how to request single-code versus ranked results. It could mention match edge cases or exact response fields, but the optional-parameter design keeps the missing detail minor.
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 describes all three parameters fully, so the baseline is 3. The description adds meaningful extra semantics: partial string matching for the violation parameter, concrete examples, and the behavior of omitting the violation to get the full ranking.
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 names the analysis being delivered: hearing dismissal rates for NYC parking and camera tickets, computed from a specific data source. It also explains the two primary usage modes—single violation lookup versus full ranking—but does not explicitly distinguish the tool from sibling analytics tools like borough_odds or popla_outcomes.
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 concrete usage context: provide a partial violation name for single-code rates, or omit it for a ranking, with defaults implied. It does not state when not to use this tool or name alternatives, but the intended scenarios are clear enough for an agent to select it appropriately.
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.
screening_dispute1 field changedInput schema / properties / situation / descriptionPrevious value: -"One of the eight situation slugs. Free index: https://screeningfacts.com/api/situations."New value: +"A situation slug, or the person's own sentence (e.g. 'wrong criminal record on my background check'), which returns suggested guide slugs to pick from and call again with, never a resolved guide. Free index: https://screeningfacts.com/api/situations."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.
