Autopilot America: Chicago parking

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark it as read-only, non-destructive, and idempotent. The description adds useful behavioral context: it is just a link, the user enters their address on the page, no card is required, and it explains the notification timing. This goes beyond the annotations without contradicting them.

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 key purpose and includes necessary details in a single sentence. It is slightly dense but every element (free, address entry, timing, no card) 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 zero-parameter informational tool with a clear read-only annotation, the description provides everything an agent needs: what it is, who it is for, how it works, and what the user must do. No gaps remain.

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?

With zero parameters, the baseline is 4. The description does not need to explain parameters, and it appropriately describes the user action on the linked page instead.

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 states the tool's purpose: a sign-up link for free Chicago street cleaning alerts. It distinguishes itself from the schedule lookup sibling by focusing on reminders and the sign-up mechanism, not on retrieving dates.

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 specifies the target audience ('For people who want reminders to move their car for street cleaning'), giving clear context for when to use it. However, it does not explicitly name alternatives (e.g., street_cleaning_schedule) or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety burden is covered. The description adds meaningful context by naming the data provenance ('City permit zone records and ordinance hours') and enumerating the three things returned, which matters since there is no output schema.

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?

Three sentences, all front-loaded: purpose first, then usage trigger, then scope and provenance. No redundancy and every sentence carries 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?

For a single-parameter read tool with no output schema, the description is nearly complete: it says what is returned and where data comes from. It stops short of describing behavior for non-Chicago or unparseable addresses, which would fully close the loop.

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% and the single address parameter is fully documented in the schema with a format example. The description adds no additional guidance on address formatting or invalid-input handling, so 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?

States a specific verb and resource ('Check whether a Chicago street address is in a residential permit parking zone') plus the exact outputs (zone, hours). This clearly separates it from siblings like street_cleaning_schedule and ticket_win_rate, which address different parking concerns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete triggering situation ('if they can park on a block without a permit, or what zone their address is in') and a hard scope boundary ('Chicago only'). It does not explicitly name sibling tools to redirect to when the question is about street cleaning or tickets, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds genuinely useful context beyond them: the exact informational payload (deadline, dismissal rate, best reason, help resources) and the 'Not legal advice' disclaimer, which tells the agent how to frame the response. It stops short of saying whether rates are aggregate estimates or jurisdiction-wide.

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?

A single dense sentence that front-loads the audience and then lists the four outputs in the order the agent will use them, followed by a short scope disclaimer. No 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 does the necessary work of enumerating what comes back, and the one parameter is fully specified by the schema. Minor gap: it does not indicate that the guidance is based on aggregate historical data rather than the specific citation's facts, which affects how the agent should present it.

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?

With a single required parameter at 100% schema description coverage and a fully enumerated value set, the schema carries the semantics. The description only loosely corroborates it by scoping to 'parking or camera' tickets, matching the enum's red_light/speed_camera entries; it adds no new meaning about how violation_type drives the answer.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific resource (Chicago parking or camera ticket) and enumerates exactly what the agent gets back: deadline, dismissal frequency, the winning reason, and where to get help contesting. It is clearly distinct from schedule/lookup siblings, though it never explicitly names ticket_win_rate, which overlaps with the 'how often dismissed' output.

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 audience framing ('for someone holding a Chicago parking or camera ticket') implies when to call it, and 'Not legal advice' sets a boundary. But there is no explicit when-not guidance and no routing to or from ticket_win_rate, which appears to return a subset of this data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing the concrete return: "one sign-up link with the plate filled in," and the two follow-up steps the user must complete on that page (sign the contest authorization, add a card). It also pre-empts confusion about pricing. It does not say what happens if the plate is already enrolled or ineligible, 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?

Three sentences, front-loaded with what the tool does, then eligibility context, then return value. The pricing aside is slightly compressed with the return-value sentence but each clause carries information the agent needs to explain the tool to a user.

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 correctly fills that gap by describing the single return (a sign-up link with the plate pre-filled) and the user's downstream steps. What's missing for a signup/enrollment tool is failure-mode behavior — ineligible plate, already-enrolled plate, or state outside Illinois — which would matter for an agent handling a real request.

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 plate, state, last_name and the plan enum with pricing and defaults. The description only restates the plan economics ("Safety Net is $0 to join; Pro is the all-included plan") and says nothing about state or last_name, so it adds little beyond the schema. Baseline 3 is correct here.

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 sentence gives a specific verb and resource (start Autopilot America for a plate) plus the actual mechanism: checking the plate for new Chicago parking/camera tickets and contesting by mail. This is clearly distinguishable from siblings like should_i_contest and ticket_win_rate, which are advisory rather than enrollment.

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?

"For when someone wants their Chicago tickets handled, fought, contested or watched going forward" states the triggering intent clearly, and the whole description is scoped to Chicago tickets. It stops short of explicitly naming the alternative siblings (e.g. use should_i_contest for advice instead of signing up), so it falls just 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, so the description correctly spends its words elsewhere: data provenance (the City's published schedule), geographic scope, and the shape of what comes back (dates plus ward and section). The only gap is that 'upcoming' is left unquantified — no horizon or result cap is stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences plus a short provenance line; the capability statement and the trigger conditions are both front-loaded with no filler. The trailing 'Source:' sentence is mildly redundant with 'City of Chicago' earlier but does convey trust/provenance.

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?

A single-parameter read tool with full annotation coverage and no output schema needs little more than this, and the description does note what is returned (dates, ward, section) so the agent knows a structured result is coming. The unspecified time horizon for 'upcoming' is the one small unknown left.

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% and the address parameter already carries a format example ('2300 N Lincoln Ave'). The description adds only the 'Chicago only' constraint, which is close to what the schema implies; it gives no extra syntax guidance such as handling intersections or missing house numbers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — looking up upcoming City of Chicago street cleaning dates for an address — and even names the secondary return fields (ward, section). It does not explicitly name a sibling such as free_street_cleaning_alerts to distinguish a one-off lookup from an ongoing alert subscription, so it stops just 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?

Gives concrete triggering intents ('when street cleaning is on their block', 'whether they need to move their car'), which maps directly to how an agent would route a user request. The scope limit 'Chicago only' also acts as a when-not condition for non-Chicago addresses, though no alternative tool is named for out-of-scope requests.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety needs no restating. The description adds genuinely new context: the data provenance (City hearing records obtained under Illinois FOIA) and the scope restriction that the rate only covers tickets contested by mail, which materially affects interpretation. It does not mention sample sizes or staleness of the records, which keeps it off 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?

Two sentences, zero filler. The definition of the metric comes first and the parameter handling comes second, so an agent reading only the opening clause still knows what it gets.

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 single-optional-parameter read tool with no output schema, the description covers what is measured, where the data comes from, and how the response changes when the parameter is omitted. What is missing is any hint about the shape or reliability of the returned rate (e.g. whether low-volume types are reported, or whether counts accompany the percentage).

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% and the enum enumerates all violation types, so the baseline is 3. The description earns above baseline by explaining the semantics of omitting the sole optional parameter — the response changes shape to an overall rate plus a list of types, which the schema does not convey.

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-and-resource combination: how often Chicago parking/camera tickets 'of a given type are dismissed when contested by mail.' The 'contested by mail' qualifier makes the measured population precise, which is more than most descriptions do. It does not explicitly contrast itself with the sibling should_i_contest, 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 only usage guidance is parameter-level: 'Omit violation_type for the overall rate and the list of types.' That is helpful invocation guidance but not tool-selection guidance. Nothing tells the agent when to consult this rate table versus calling should_i_contest, or that should_i_contest is the decision-oriented sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.