Find Car Parking

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds nothing beyond the annotations: it doesn't say what a result looks like, what happens with an invalid or nonexistent parking_id, or how availability is determined (dates? time window?).

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 no waste. It is arguably too terse for the ambiguity it leaves, but it is not padded or disorganized.

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 trivial one-parameter read tool this is close to sufficient, but with no output schema the description should say what the check returns (boolean vs. detail object) and how an unknown ID is handled. Those gaps keep it at minimum viable.

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 the single parking_id fully documented. The description adds no semantics beyond the schema (e.g., whether the ID must exist or how to obtain it), 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?

Names a specific verb ('check') and resource ('parking space availability'), so the purpose is unambiguous. However, it does not distinguish itself from the sibling 'list_available_parkings', which an agent could easily confuse with this single-space check.

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 guidance on when to use this versus list_available_parkings (bulk availability) or get_parking_details. The usage context is only implied by the word 'specific'.

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 safety is covered. The description adds nothing beyond 'detailed information' — no indication of what the detail record includes, whether a missing area_id errors, or how results differ from the list endpoints, so it contributes no behavioral context of its own.

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 or repetition. It is efficient, though its brevity borders on under-specification rather than tight precision.

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 is the only place that could explain what 'detailed information' returns, and it does not. For a detail-retrieval endpoint surrounded by list/detail siblings, that leaves the agent unable to predict the response content.

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 one required parameter at 100% schema coverage, the schema already documents area_id fully and the description adds no format, source, or lookup guidance. Baseline 3 applies since the schema does all the work.

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 verb ('Get') and resource ('area') plus scope ('specific area', 'detailed information'), which distinguishes it somewhat from list_areas. However, it never clarifies what a 'detail' view contains versus the sibling detail tools like get_parking_details or get_parking_reviews, so an agent gets only a vague sense of the payload.

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 statement of when to use this tool instead of list_areas, list_nearby_areas, or the parking detail tools, and no prerequisite or exclusion guidance. The agent must infer routing from the names alone.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds one useful behavioral fact – the result is scoped to the authenticated SimplyGuest customer, implying an auth requirement – but says nothing about what the counts mean (e.g. whether 'used' is lifetime or per-period).

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 that identifies the actor, the resource, and exactly which values are returned. 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?

For a no-parameter, read-only tool with full annotation coverage, the description supplies the two things that matter: who the data belongs to and what values come back. There is no output schema, so a note on count semantics or units would have closed the last gap.

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, which is the baseline-4 case. There is nothing for the description to disambiguate.

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 (Show) and resource (token wallet) and names the exact quantities returned (available and used token counts). Scoped to the authenticated customer, which separates it from sibling listing tools like list_my_token_history and list_my_token_orders, though those siblings are never explicitly referenced.

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?

Usage is implied by 'available and used token counts' – an agent can infer this is a balance-check tool. However, there is no explicit when-to-use signal, no statement of when to prefer it over list_my_token_history or list_my_token_orders, and no prerequisites mentioned.

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 that this is read-only, idempotent, non-destructive, and closed-world. The description adds useful context that the check is customer- and listing-specific, but it does not describe permissions, possible returned states, or rate behavior.

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 wasted wording. It communicates the core purpose efficiently.

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

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

For a simple, read-only status check with one fully described parameter and rich annotations, the description is nearly complete. It could be stronger by clarifying the expected result state or relation to redemption, but no major invocation detail 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 single parking_id parameter is fully documented in the schema with a clear description. The tool description adds no parameter-level meaning beyond the schema, so the high coverage 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 check operation and resource: whether this customer has already unlocked owner contact for a parking listing. It implicitly differs from redemption, but does not explicitly name the related redeem_token_for_owner_contact sibling.

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 this is an access-status check, likely useful before attempting redemption, but it gives no explicit when-to-use guidance, exclusions, or alternatives. The presence of redeem_token_for_owner_contact makes that missing routing guidance notable.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — it does not clarify what 'detailed information' includes (e.g., that the review_limit parameter implies reviews are embedded), nor describe any response shape or pagination behavior.

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 redundant filler. It is efficient, though efficient here partly reflects under-specification rather than disciplined editing.

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 explaining what 'detailed information' returns, yet it stays vague and never mentions the embedded reviews implied by review_limit. For a fetch-by-ID tool, this leaves the agent unable to predict the response contents.

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 both parameters (parking_id and review_limit) are already documented in the schema. The description adds no meaning beyond the schema — notably it never mentions that review_limit controls how many reviews come back, which would have tied the parameter to the tool's purpose.

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 ('detailed information about a specific parking space'), which distinguishes it from list_* and search_* siblings. However, it does not explicitly differentiate from the closest sibling, get_parking_reviews, which also returns details about a parking space.

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?

There is no guidance on when to use this versus get_parking_reviews, search_parkings, or list_available_parkings. It also omits the obvious prerequisite that an agent must first obtain a parking_id (e.g., via search_parkings) before it can call this.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond that—no mention of ordering, pagination behavior, or what happens for an unknown or review-less space.

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 zero filler or repetition. Its brevity is efficient rather than padded, though it leaves little room for the routing context an agent would want.

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

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

For a simple two-parameter read tool with full annotation coverage and no output schema, the essentials are present. Still, the description omits result ordering, default page size behavior, and the sibling relationship, which an agent must guess.

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 both parking_space_id and limit are already documented in the schema. The description adds no meaning beyond it, 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?

States a specific verb ('Get') and resource ('reviews for a specific parking space'), which is unambiguous. It does not, however, distinguish itself from the sibling list_recent_reviews, leaving the agent to infer the difference from names alone.

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 statement of when to use this versus list_recent_reviews or other review-related siblings, and no prerequisites or exclusions. Usage is only implied by the tool name and the required parking_space_id.

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, non-destructive and closed-world, so the safety profile is covered. The description adds nothing beyond that — no note on result size, ordering, or behavior when city_id/city_slug are omitted — which is notable given the schema marks both as optional.

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 efficient sentence with the scoping condition front-loaded and no filler. It is short enough that the missing detail is more of a gap than bloat.

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

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

For a simple read-only list tool with full schema coverage and annotations, the essentials are present. The omission of default behavior when no city is passed is the main remaining gap.

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%, with both parameters individually documented, so the baseline is 3. The description's 'a specific city' slightly implies a required city filter even though both params are optional, adding no real meaning 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 and resource ('List all areas'), so the agent knows exactly what it returns. However, it does not distinguish itself from the close siblings list_nearby_areas and list_cities, leaving the agent to guess which listing tool fits.

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?

'within a specific city' implies the city-scoped use case, but there is no explicit when-to-use vs list_nearby_areas or list_cities, and no guidance on what happens when neither optional city parameter is supplied.

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 destructiveHint=false, so the safety profile is covered. The description adds the 'available only' filter and area scoping, but says nothing about result ordering, pagination beyond the limit param, or what an empty result means.

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 wasted words. It is efficient, though its brevity edges into under-specification given the crowded sibling set.

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 only two optional parameters, annotations covering safety, and no output schema, the description is minimally adequate. It is missing the differentiation from sibling search tools that would make the definition complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters (limit, area_id) are already fully documented in the schema. The description adds only that results are filtered to availability and to an area, without new syntax or format detail. 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 verb and resource ('List ... parking spaces') with a scope qualifier ('available', 'in an area'), which is more than a tautology. However, it does not distinguish itself from nearby siblings like search_parkings or check_availability, so an agent cannot tell from the description alone which of these to use.

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?

There is no statement of when to use this tool versus search_parkings, search_by_location, or check_availability, all of which appear to return parking-related data. Usage is only implied by the word 'available'.

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, destructiveHint=false, and a closed-world scope, so the safety profile is covered. The description adds only the 'all available' completeness cue; it says nothing about result ordering, pagination, caching, or size of the city set.

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. There is no wasted verbiage and the scope qualifier comes before any other content.

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 trivial zero-parameter list call the description is close to sufficient, but with no output schema it leaves the shape of a city entry (name only, or name plus id/region) entirely unknown, which matters because a returned identifier likely feeds resolve_location or search_by_location.

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 and the schema is an empty object with additionalProperties=false, so there is nothing for the description to disambiguate. Baseline 4 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: enumerate all cities on the platform. The 'all available' wording makes the scope unambiguous. It does not, however, contrast itself with similarly named siblings like list_areas or list_available_parkings, so an agent must infer the city-vs-area 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?

The description contains no when-to-use guidance, no prerequisites, and no mention of alternatives. It does not say whether this is meant as a first-step discovery call before resolve_location or search_by_location, so routing between it and those siblings is left entirely to inference.

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 the safe read-only, idempotent, closed-world profile, so the description's job is lighter. It adds genuinely useful context beyond annotations: the response deliberately omits owner contact details, which matters given siblings like get_owner_contact_access and redeem_token_for_owner_contact exist. It stops short of describing result fields or ordering.

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 that carries the resource, the scope, and the privacy guarantee with no filler. 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?

With no output schema and no parameters, the description is the only place to convey what a history entry contains (dates, amounts, parking references, pagination). It covers scope and privacy but leaves the return shape entirely unspecified, which is a real gap for a listing 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter detail is missing or needed.

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 (List) and resource (parking token history) scoped to the authenticated customer, which cleanly separates it from sibling tools like get_my_token_wallet and list_my_token_orders. It doesn't explicitly name those siblings, so it falls short of 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?

Usage is only implied by the word 'history' and the 'authenticated customer' scoping; there is no explicit when-to-use guidance and no named alternative such as the wallet or orders tools. An agent can infer the purpose but must reason about the boundary itself.

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 and closed-world, so the safety profile is covered; the description adds the caller-scoped boundary (only the authenticated customer's records) and the explicit negative capability. It does not say anything about result volume, ordering, or whether refunds are always present, which are minor residual gaps.

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 short sentences, no filler, and the operative scope statement is front-loaded ahead of the exclusion. Every clause carries information an agent would otherwise have to guess.

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 parameters, no output schema and full annotation coverage, the description supplies exactly the scope and capability boundaries an agent needs to select it. It could be slightly richer about what an 'order' record or 'refund state' contains, but the essential decision information is present.

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 the baseline is 4; there is nothing parameter-related that the description needs to compensate for. The mention of 'refund state' is a bare hint about the result shape rather than parameter semantics.

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 (read) and resource (the authenticated customer's token orders and refund state), with the scope explicitly limited to the caller's own data. The negative clause ('cannot purchase tokens') further sharpens what the tool is, distinguishing it from checkout/purchase siblings and from get_my_token_wallet.

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 rules out two adjacent intents (purchasing tokens, obtaining checkout links), which is real when-not-use guidance rather than implied. It stops short of naming the sibling to use instead (e.g., a purchase or wallet tool), so the routing is left slightly to the agent.

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, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds nothing beyond them: no note on how the radius interacts with defaults, no statement about what an empty anchor yields, no mention of pagination behavior despite limit/offset existing.

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 is efficient but arguably over-trimmed, since the brevity leaves the anchor-parameter ambiguity unaddressed.

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 five-parameter read tool with no output schema, the description covers the core idea but omits the one thing an agent must resolve: nothing is required, so it must be told whether area_id or area_slug is mandatory or preferred. Return shape is not needed given no output schema, but usage prerequisites are.

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 every parameter is already documented in the schema; the description's "anchor area" and "radius" wording merely echoes area_id/area_slug and radius_km. Baseline 3 is correct here — it adds no format, unit, or mutual-exclusivity detail 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 ("List") and resource ("areas") plus the distinguishing scope: proximity to a "given anchor area within a radius." That separates it from list_areas, but it never names a sibling or clarifies how it differs from search_by_location, which could plausibly do something similar.

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 guidance on when to choose this over list_areas, search_by_location, or list_available_parkings. Since the area anchor is the defining input and neither area_id nor area_slug is required, the description should say which to supply and what happens if neither is given, but it says nothing.

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 non-destructive/openWorld=false, so the safety profile is covered. The description adds the cross-space scope but says nothing about ordering ('recent' is undefined), the default of 3 results, or whether results are paginated.

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 ten-word sentence with zero redundancy, and the scope qualifier is placed where it matters, immediately after the resource.

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

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

For a simple, fully optional, read-only list tool with rich annotations, complete schema coverage, and no output schema, this is nearly sufficient. The remaining gap is that 'recent' has no defined window or sort order, which an agent would have to guess.

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 both optional parameters (limit with default 3, only_available with default false) are already fully documented in structured data. The description adds no format or interpretation details beyond the schema, 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?

Clear specific verb (List) plus resource (recent reviews) and an explicit scope ('across all parking spaces'), which distinguishes it from the per-space sibling get_parking_reviews. It stops short of naming that sibling, so the differentiation must be inferred from the scope phrase.

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?

Usage is implied: the phrase 'across all parking spaces' suggests this is the cross-space feed as opposed to per-space review retrieval, but neither get_parking_reviews nor any other sibling is named, and there is no explicit when/when-not guidance.

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 the mutation profile (readOnly=false, destructive=true, idempotent=true), so the description's real contribution is the cost model: exactly one token is spent and repeat calls are free. It does not say what happens when the wallet is empty (error vs. no-op) or that the spend is irreversible.

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 with the action/outcome front-loaded and the idempotency caveat immediately after; nothing is wasted.

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 signals the payoff (owner contact) and the cost, which is what an agent needs to decide. It is slightly short on failure modes — insufficient tokens, invalid or already-owned listing — but otherwise complete for a single-parameter 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?

Only one parameter with 100% schema coverage, so the schema already explains parking_id as a public listing ID. The description reinforces that this is the 'listing' being unlocked but adds no format or lookup guidance 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 ('consume one token') and a specific resource/outcome ('unlock a parking owner's contact'), which is clearly distinct from read-oriented siblings like get_owner_contact_access or get_my_token_wallet. An agent can pick this out 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?

The second sentence implies when the call is pointless (already unlocked) but never explicitly routes the agent to get_owner_contact_access for non-consuming reads or get_my_token_wallet to check balance. Usage is inferable rather than stated.

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, and closed-world, so the safety profile is covered. The description adds only that multiple candidates may come back ('candidate suggestions'); it says nothing about ambiguity handling, failure when no match is found, or ranking of candidates.

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 efficient sentence with the core action front-loaded and no filler. It is perhaps slightly under-specified for the space available, but nothing is wasted.

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 4 well-documented params and full annotation coverage, the essentials are present, and no output schema exists so return values need not be detailed. Still, the relationship between text and the optional city hints—the one thing most likely to trip an agent—is left unaddressed.

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 all four parameters (text, city, city_slug, candidate_limit) are already documented in the schema. The description adds no extra meaning about how the city hints interact with the free text, 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: 'resolve a location string into a city and area with candidate suggestions'. Clear what the tool produces. However, it does not distinguish itself from siblings like search_by_location or list_cities, which an agent could plausibly pick instead.

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 use case is implied by 'user-provided location text' resolving to city/area, but there is no explicit when-to-use or when-not-to-use statement. Given the sibling set contains search_by_location, list_areas, and list_cities, an explicit routing rule was warranted and is absent.

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, closed-world and non-destructive, so the safety profile is covered. The description adds only that queries are 'conversational', with nothing on how freeform text is interpreted, how results are ranked, or what default filtering applies (schema default available_only=true).

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 is efficient, though its brevity borders on under-specification rather than optimal density.

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 9-parameter search tool with no output schema, the description says nothing about result shape, ordering, pagination interactions, or how the freeform query combines with the structured hints (city, area_id, radius_km). An agent must reverse-engineer intended behavior from parameter names alone.

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 all nine parameters are documented in the schema itself. The description adds no meaning beyond that, which is the baseline for a fully-described 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 concrete verb and resource ('Search for parking spaces') plus the input mode ('conversational query'), which implicitly separates it from structured siblings like search_by_location and search_by_price. It does not name those siblings, so the distinction relies on inference.

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?

Usage is only implied: an agent can guess this is for freeform/natural-language queries, but there is no explicit 'use this when X, use search_by_price when Y' guidance. No exclusions or prerequisites are given.

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 state readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds no behavioral context about defaults (available_only=true), the potential conflict with include_unavailable, radius behavior, or pagination semantics.

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

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

The description is a single front-loaded sentence with no wasted words. Its brevity is efficient, though it also reflects the missing guidance noted elsewhere.

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?

This is a 9-parameter search tool with multiple modes (area anchoring, city filtering, nearby radius, availability toggles) and many sibling search/list tools. The one-sentence description is not complete enough for an agent to choose among those modes without studying the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 9 parameters and the baseline is 3. The description mentions location name or landmark, which maps loosely to the required search_term, but it adds no meaning 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 gives a specific verb ("Search") and resource ("parking spaces") and narrows the query dimension to "location name or landmark." That implicitly distinguishes it from search_by_price, but it does not explicitly name or route against the many search/list siblings.

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 implies usage by name, but there is no explicit when-to-use guidance, no exclusions, and no comparison with search, search_parkings, list_nearby_areas, or checkbox-style availability tools. An agent must infer the routing decision entirely from the tool name.

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 non-destructive behavior, so the safety profile is covered. The description adds only the price-range scope; it says nothing about default filtering (available_only defaults to true) or pagination behavior, which would be valuable 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?

A single efficient sentence with no filler, and the key scoping concept is front-loaded. It is short but not under-specified relative to its claim.

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 11 parameters and no output schema, the description is thin: it omits mention of area/city/radius filtering, sorting, and availability defaults that materially shape results. The schema compensates, making it minimally adequate rather than complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every one of the 11 parameters is documented in the schema itself. The description only echoes the price-filter concept and adds no format, unit, or interaction detail beyond the schema; 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 ('Search parking spaces') plus the scoping dimension ('by price range'). However, it does not distinguish itself from siblings like search, search_by_location, or search_parkings, leaving overlap ambiguous.

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 guidance on when to prefer this over search_by_location or search_parkings, and no mention of prerequisites or exclusions. The agent must infer selection from the name alone.

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, non-destructive, and closed-world, so safety is covered. The description adds nothing beyond that — no note on pagination behavior, result ordering, or how the availability defaults interact. For an annotated tool this is a thin contribution.

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?

It is a single, front-loaded sentence with no filler, but the terseness reflects under-specification rather than efficient communication. Nothing in it is wasted, but little is earned either.

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 five parameters, a default that filters to available-only, and no output schema, the description should explain what comes back and how the availability flags combine. It covers none of this, so an agent cannot predict result contents or resolve the conflicting availability options from the definition alone.

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 all five parameters are self-documenting and the baseline is 3. The description adds no extra meaning, and notably does not clarify the interaction between available_only (default true) and include_unavailable, which is a genuine ambiguity the schema alone leaves open.

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 verb and resource ("Search for parking spaces") plus a scope ("by area"), so the basic action is clear. But it does nothing to distinguish this from siblings such as search_by_location, search_by_price, or list_available_parkings, leaving the agent to guess which search variant applies.

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?

There is no statement of when to use this tool versus the many sibling search/list tools, and no exclusions or prerequisites. The only implicit guidance is that an area_slug is required, which comes from the schema rather than the description.

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