Parksy

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior; the description adds that it returns likely grounds, jurisdiction routing, a deadline note, and links, plus a 'not legal advice' disclaimer. It does not detail confidence or assessment limitations, but the added output and advisory context is useful beyond annotations.

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

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

The description front-loads the purpose and return summary, then usage, optional-input note, and disclaimer; no sentence is purely filler. The parenthetical input list is dense but earns its place by mapping the question areas.

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 10-parameter, zero-required, read-only informational tool with no output schema, the description covers what it assesses, what it returns, when to use it, optional input handling, and legal disclaimer. More detail on missing-input behavior or output structure could help, but it is broadly 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?

With only 30% schema description coverage across 10 parameters, the description partly compensates by listing the answer categories (signs, markings, machine, notice details, ticket/permit, owner/keeper, mitigating, evidence) and country. It does not explain enum semantics or the omitted issuer_type, so many parameter meanings still rely on 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 action (checks appeal strength), resource (parking fine or parking charge), and the exact user question it answers (appealing, disputing, challenging, chances of winning), which separates it from generic parking search/guide siblings. It also previews the return contents, so an agent knows this is an assessment tool rather than a template or listing tool.

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

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

It gives clear use conditions via 'Use this when someone asks about appealing...' and lists synonymous terms such as PCN, citation, and private parking charge. It does not name sibling tools or state when not to use it, so it falls short of full alternative routing.

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 behavior beyond that: it is a public-record view only, it lists the specific payload the agent can expect despite there being no output schema, and it notes the 'View listing on Parksy' link is where the user contacts the provider. Not covered: failure behavior for an unknown id or malformed URL.

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 resource and its payload, then the input sourcing. The field enumeration is dense but earns its place because no output schema exists.

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-required-parameter, two-alternate-input read tool with no output schema, the description does the heavy lifting by previewing the returned fields and the provider-contact link. Minor gap: it never says what to do when both url and listing_id are omitted or which takes precedence.

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 schema already says the URL is used 'instead of listing_id'. The description reinforces the either/or choice and the provenance of listing_id, but adds no format, precedence, or validation 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?

Specific verb and resource: 'Public details of one Parksy parking listing', followed by an explicit enumeration of the fields returned (title, address, prices, space type, features, vehicle sizes, description, link). It is clearly a single-listing lookup, which distinguishes it from the sibling search_parking that produces the ids.

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 tells the agent exactly what to feed it — a listing_id from search_parking or a parksy.com listing URL — which establishes the upstream workflow. It does not state any when-not-to-use condition or what happens if neither identifier is supplied, so it stops short of a full routing statement.

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 readOnly, idempotent, non-destructive, non-open-world behavior, so the description does not need to argue safety. It does add value beyond the annotations by disclosing the return shape (titles, short summaries, last-updated dates, links), which matters because there is no output schema, and it flags that geographic details are optional. It does not mention result limits or fallback behavior when nothing matches.

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?

Front-loaded with the search verb and resource, then the topic enumeration, then the usage trigger; every clause carries information. The middle enumeration is long but each item corresponds to a real topic enum value, so it earns its space rather than padding. Slightly dense for a single paragraph but structurally sound.

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 article search with five flat parameters, the definition covers what it retrieves, when to use it, and what comes back, which is enough to call it correctly. Remaining gaps are minor: no guidance on result count or how to behave when zero guides match, and no explicit boundary against the similarly named search_parking sibling.

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 60%, so some compensation is required, and the description provides it: it confirms the place/city is optional and effectively maps its topic list onto the topic enum values (free, cheap, costs, fines, towed, disability, permits, signs, street, storage, moving). It adds no detail about limit (default 3, max 5) or the country code, so the low-cost narrowing controls remain schema-only.

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?

Specific verb ('Search') plus specific resource ('Parksy parking guides and articles'), followed by an enumerated subject list (free/cheap parking, rates, fines and appeals, towing, disability, permits, signs, street rules, storage, moving) and the return content. An agent can immediately tell this is an editorial-content search rather than a listing/price lookup like search_parking or a workflow like fine_appeal_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?

Gives an explicit trigger: 'Use this when a driver asks what to do or what the rules are (towed, clamped, fined, permits, signs)', which is a concrete situation with examples. No when-not condition or named alternative is given, even though siblings search_parking and fine_appeal_check sit close to this space, so the routing decision is not fully disambiguated.

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 behavior, so the safety profile is covered. The description adds useful context beyond that: the return shape (letter text plus page and PDF/TXT download links) and the caveat that these are adaptable templates rather than legal advice. It does not discuss coverage limits, letter counts, or what the list response looks like.

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 primary list behavior and followed by the return format and disclaimer. The parenthetical list of example appeal reasons is longer than strictly necessary but does aid selection.

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-optional-parameter read-only tool with no output schema, the description covers both invocation modes, the content of results, and the intended use of the material. Only minor gaps remain, such as list size or pagination, which are unlikely to block correct invocation.

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

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

Schema coverage is 100% and the parameter description already explains that omitting letter_id lists all letters while supplying an id retrieves one. The description's mention of returning 'the text of one letter' reinforces the two modes but adds no syntax or format 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?

The description states a specific verb and resource ('Lists Parksy sample letters for appealing a parking ticket') and also covers the second mode ('returns the text of one letter with its page and PDF/TXT download links'). The enumeration of appeal reasons makes the resource concrete and clearly separable from siblings like fine_appeal_check or parking_guides.

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

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

It gives a clear usage context (appealing a parking ticket) and frames the material as 'Templates to adapt, not legal advice', which tells the agent how to present results. It does not explicitly name alternatives such as fine_appeal_check, so it stops short of full when/when-not routing.

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 openWorldHint=false, so the safety profile is covered. The description adds genuine behavior beyond that: results are capped ("up to 10 listings"), each includes type, price as listed, distance, features and a deep link, and the platform cannot transact bookings. The only gap is that it doesn't mention the default result count or pagination/broadening behavior when few listings match.

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 tight sentences with the core capability front-loaded, followed by result shape and then the booking constraint. Every sentence carries information, though "For daily, monthly or hourly parking" is partly redundant with the sort enum and could have been folded into a sentence about sorting.

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 seven parameters and no output schema, the description correctly compensates by describing the return payload (fields plus a listing link) and the up-to-10 cap. Given the tool is a read-only search with full annotation coverage, little else is strictly required; the main omission is any hint about defaults or how to widen a sparse result set.

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 57%, with place, country, features and radius_km self-documented in the schema. The description adds almost nothing at the parameter level — it never mentions sort, limit, space_type or features, and the only oblique hint is "up to 10 listings" versus a limit default of 5. It also doesn't explain that features are conjunctive or what "price as listed" means across the cheapest_* sort modes, both of which are left entirely to 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 opens with a specific verb and resource set: "Find parking spaces, garages, driveways and car parks listed on Parksy near a place." That is far more informative than the title alone and implies the search-vs-detail split with the get_listing sibling. It stops short of naming get_listing or parking_guides as the alternative, so sibling differentiation is only implicit.

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 "near a place" and "For daily, monthly or hourly parking," which tells the agent the rental horizons this search supports. The booking caveat ("Parksy does not take bookings: people contact the parking provider") usefully signals what the agent must do after searching. However, there is no explicit guidance on when to use this versus get_listing or parking_guides, and no when-not condition.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the baseline is satisfied without effort. The description adds genuine context beyond them: exactly what the result contains (rate ranges plus suggested daily/hourly price), that a listing link to Parksy is included, and the important framing that the figure is an estimate rather than a quote or guarantee. It does not cover failure behavior for an unresolvable place, 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?

The payload description is front-loaded with the outcome and the returned figures, then the usage trigger, then the caveat — a sensible order with no filler sentences. Minor redundancy from repeating the country-disambiguation hint already present in the schema keeps it from a 5.

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 optional parameters, no output schema, and safety already carried by annotations, the description does the remaining work: it explains the shape of the return (rate ranges, suggested price, listing link) and sets expectations that values are estimates. An agent has enough to select and call it correctly; only edge-case behavior (unknown place, ambiguous location returns) 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% and each parameter carries its own explanation (place formats, two-letter country code, optional postcode, indoor/outdoor enum, secure_access meaning). The description's only parameter-adjacent advice, adding the country for common place names, largely restates what the `place` schema field already says. Baseline 3 is correct.

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 verb and resource ("Estimates what a parking provider could charge for a parking space") and even enumerates the returned figures (monthly/weekly range, suggested daily and hourly price) plus a link to list on Parksy. That is far more specific than any sibling (search_parking, get_listing, parking_guides), though it never explicitly contrasts itself with them.

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

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

It gives a concrete trigger phrase set: "Use this when someone asks what a garage, driveway or parking space is worth, could earn or should charge." It also adds an input-shaping rule ("Add the country when a place name is common") and a scope caveat ("An estimate only"). No explicit when-not-use or named alternative is provided, 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.