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 arguments | |||
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.
Add one secure layer between your agents and this server.
Several tools overlap in subject matter: borough_odds, violation_dismissal_rates, and plate_lookup all touch NYC hearing outcomes, while operator_route_lookup and popla_outcomes both expose POPLA operator records. The descriptions are detailed enough to separate them on close reading, but an agent could easily select the wrong one when asking for odds or appeal outcomes.
The names are uniformly lowercase snake_case and readable, but the pattern is mixed: get_mtd_answer, list_doors, and search_mtd_answers use a verb_noun form, while borough_odds, popla_outcomes, and violation_dismissal_rates are noun phrases, and plate_lookup/operator_route_lookup use noun_lookup compounds. There is no single consistent naming convention across the set.
Nine tools is within the ideal range and each tool represents a distinct, substantive data product or query endpoint. For a gateway spanning multiple domains, this is well-scoped and not bloated.
The main query surfaces are covered: NYC parking has plate, borough, and violation-type views; UK parking has operator routing, deadline calculation, and POPLA outcomes; and MTD has search plus full-answer retrieval. Minor gaps exist, such as IAS appeal outcomes and a way to list all MTD answers without searching, but these are workable rather than blocking.