Easy Lane: New Orleans Parking

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

Annotations already declare the read-only, idempotent, closed-world safety profile, so the bar is lower. The description adds meaningful provenance beyond them by stating the comparison uses the airport's own posted rates, which tells the agent how much to trust the numbers. It does not say whether taxes/fees are included or how fresh the rates are.

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 core comparison is front-loaded and the example phrasings come last as reinforcement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, read-only comparison tool with no output schema, the description conveys scope, data source, and the shape of the answer (cost comparison against taxi/bus). It leaves the return structure (per-lot breakdown vs single cheapest pick) to inference, but nothing critical to invoking it 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?

Schema coverage is 100%, with both parameters documented including units, defaults, and bounds, so the schema does the heavy lifting. The description only restates the concepts ('trip length and number of people') plus a round-trip framing that isn't in the schema, which is a marginal addition. Baseline 3 is appropriate.

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

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

States a specific verb and resource: compare trip costs across every MSY parking lot against taxi and bus alternatives, scoped to a given trip length and party size. An agent can distinguish it from siblings like find_parking or park_and_ride without opening the schema.

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 questions ('cheapest parking at MSY for 4 days', 'should I park or take a cab') that make the intended use case unambiguous. It stops short of naming which sibling to use for adjacent needs (e.g., check_parking or find_parking), so no explicit exclusions.

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 the read-only/idempotent safety profile, and the description adds genuine behavioral detail beyond them: what the response contains (verdict, tow-risk rule, current cost, events/parades, easiest streets, live Easy Lane link). It stops short of noting rate limits or data freshness/latency.

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 the core purpose and input formats, then the return contents, ending with the usage trigger. Dense but every clause earns its place; 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?

No output schema exists, so the description carries the return-value burden and does so thoroughly (verdict, tow-risk rule, cost, events, nearby streets, link). Combined with 100% parameter coverage and read-only annotations, an agent has everything needed to invoke and interpret 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real value by giving accepted address input formats ('Superdome', '800 Magazine St', 'Frenchmen and Chartres') and clarifying that stay_hours changes the answer over time. It does not restate lat/lon or 'when' 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?

States a specific verb (check), resource (street parking), and geographic scope (New Orleans), with concrete input examples. It is clearly distinguishable from siblings like find_parking, airport_parking, and park_and_ride because it answers a yes/no/where question at a specific place.

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 gives an explicit trigger: 'Use this whenever someone asks where or whether they can park in New Orleans.' That is clear context, but it does not name or exclude alternatives (e.g. find_parking, airport_parking, park_and_ride) despite several plausible siblings existing.

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, and closed-world, so the safety profile is covered; the description usefully adds that results are ranked by parking friction and enriched with lot notes, metered spaces and permit zones. It does not explain how friction is computed or how ties/ranking are ordered, so it adds moderate but not rich behavioral context.

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 waste: the ranking action and geographic scope come first, the returned fields last. Nothing is padded or repeated.

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 right thing by enumerating the return fields (distance, friction, lot notes, metered spaces, permit zones). It stops short of describing result ordering or how the ranking is derived, which is a minor gap for a ranking tool.

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 lat, lon, limit, category and radius_m are already documented with bounds and defaults; the description only echoes lat/lon. Baseline 3 applies since the schema carries the parameter burden.

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: ranks nearby New Orleans stores by parking difficulty given lat/lon. The 'New Orleans stores' scoping and the friction-ranking concept do distinguish it from siblings like check_parking or airport_parking, but no sibling is named explicitly, leaving some routing 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 implies usage by naming lat/lon as inputs, but never says when to choose this over check_parking, park_and_ride, or airport_parking, nor states any prerequisite or exclusion. An agent gets no routing guidance among seven sibling tools.

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=true, idempotentHint=true, and openWorldHint=false, so the safety and repeatability profile is covered. The description adds useful return-content context (what data comes back), but says nothing about data freshness, error behavior for unknown IDs, or rate limits, so it is only a modest addition.

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?

One front-loaded sentence with a colon-delimited payload list; nothing is redundant or padded. Slightly jargon-y terms ('best window', 'neighbor reports') are the only minor cost.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read-only tool with no output schema, the description does the important remaining work of summarizing what is returned, which the schema cannot. The gaps are the absence of sibling routing guidance and any note on failure modes for a bad venue_id.

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?

There is a single parameter at 100% schema description coverage, and the schema already explains that venue_id comes from find_parking. The description's 'one Easy Lane venue' reinforces that a single identifier is expected but adds no format or example detail beyond the schema, so the baseline 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?

States a specific verb+resource (full parking detail for one 'Easy Lane' venue) and enumerates the payload contents (lot info, best window, metered blocks, neighbor reports). It is clear what the tool returns, but it never names or contrasts itself with siblings such as check_parking, airport_parking, or find_parking, so an agent must infer the distinction.

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?

No when-to-use or when-not-to-use guidance appears in the description. The single-venue scope implies a lookup-after-discovery flow, but the explicit routing hint ('venue_id returned by find_parking') lives only in the schema, not the description, so nothing steers the agent between this and its seven siblings.

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 the safety profile is covered. The description adds genuinely new behavioral context by disclosing what the response contains (covered neighborhoods and their centre coordinates) and how that output feeds find_parking, which matters since no output schema 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?

A single front-loaded sentence with no filler. It names the resource first and the practical purpose second, so every clause 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 no-argument, no-output-schema listing tool, the description supplies the two things an agent needs: the scope of coverage and the utility of the returned coordinates. Ordering/format of the returned list is unspecified, a minor gap in an otherwise complete definition.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline for a 0-param tool is 4. The description correctly implies no inputs are required.

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 (List) and resource (New Orleans neighborhoods Easy Lane covers), plus the field of interest (centre coordinates). It is trivially distinguishable from all siblings, none of which enumerate coverage areas.

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 signals the downstream purpose: the coordinates are meant to be passed to find_parking, which tells the agent when this tool is the right first step. No when-not-to-use or exclusion guidance is given, but there is no plausible competing alternative among the siblings.

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 establish this is a read-only, idempotent, closed-world lookup, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the exact payload it produces and the empty-result case when park-and-ride isn't warranted, which an agent needs to interpret a null response correctly.

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?

One dense sentence, but it is front-loaded with the purpose and then ordered as trigger, output contents, and empty-case behavior. No filler, though the parenthetical example list makes it longer than strictly necessary.

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 carries the return-value burden and does so by enumerating the fields returned. The main remaining gap is input guidance for a tool with zero required parameters and two undocumented coordinates.

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 only 33% (only 'address' is documented) and the description adds nothing about inputs. It never clarifies whether lat/lon or address should be supplied, how they interact, or what the coordinate bounds mean, leaving two of three parameters unexplained in both schema and prose.

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: suggest where to park outside the busy area and ride the streetcar in, enumerating the outputs (boarding stop, line, next departures, ride time, final walk). This is clearly distinguishable from siblings like find_parking or check_parking, which deal with parking itself rather than a park-and-ride itinerary.

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 clear trigger condition ('For a hard-to-park New Orleans destination') with concrete examples (French Quarter, CBD, Superdome, Convention Center), plus a negative condition ('returns nothing when parking at the destination is easy enough'). It does not explicitly name sibling tools as alternatives, 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.

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral consequence beyond that: cars on a parade/second-line route get towed, which is the kind of impact an agent should surface to a user. No return-shape detail, but that is minor here.

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 the scope and content types front-loaded, followed by concrete usage examples. Everything earns its place; only slightly verbose in the event-type enumeration.

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, single-parameter list tool with no output schema, the description covers purpose, scope window, content types and usage triggers adequately. Nothing critical to correct invocation 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?

Schema coverage is 100% with a single well-documented 'days' parameter, so the schema already carries the meaning. The description's 'next 1 to 7 days' echoes the schema's range but adds no format or edge-case guidance beyond it, so the baseline 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?

States a specific verb (List) and resource (events/closures affecting parking) and enumerates the concrete content types it returns. It is readily distinguishable in spirit from siblings like find_parking or check_parking, but it never explicitly says what it is NOT, so it stops short of full sibling 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?

Provides clear usage triggers via example questions ('anything going on downtown tonight', 'will parking be bad this weekend'), which tell the agent when to reach for it. There is no explicit when-not guidance or named alternative among siblings, though.

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=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds behavior-relevant context the annotations don't carry: that fees are 'current' and the total is an 'estimate', signaling output is informational and approximate rather than a binding quote.

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 zero filler: the first enumerates the payload, the second lists trigger phrasings. The most decision-relevant content (what the tool returns) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description carries the burden of describing returns — and it does so item by item. Combined with two fully documented optional parameters and a read-only annotation profile, an agent has everything needed to call this correctly.

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 both parameters are already fully documented with units, defaults, and ranges, which sets the baseline at 3. The description's mention of daily storage and an estimated total lightly implies how days_until_pickup and ticket amounts feed the result, but adds no syntax or semantics beyond the schema.

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

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

The description names a specific situation (a car towed in New Orleans) and enumerates exactly what the tool returns: the tow-confirmation phone number, the City tow lot address and hours, current fees (tow, daily storage, boot), and a total estimate. This clearly separates it from siblings like find_parking or airport_parking.

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?

Three concrete trigger phrases ('my car got towed', 'where is the New Orleans impound lot', 'how much to get my car out') make the intended invocation context unambiguous. It does not name when-not-to-use or an alternative sibling, but no sibling covers a towed-vehicle scenario, so the routing is effectively clear.

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