KnowChelsea

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add context, and it does: it discloses that records are 'sourced' (provenance is returned) and that shared tags are part of the result. It stops short of explaining failure behavior for invalid or duplicate slugs.

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; the cardinality bound and key are stated before the returned content. 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 must carry return-value information, and it does so at a high level (side-by-side sourced records plus shared tags). For a one-parameter, closed-world tool this is nearly sufficient; only ordering and invalid-slug behavior are unmentioned.

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 single parameter already carries min/max/uniqueItems plus an example. The description's '2 to 4 Chelsea places by slug' merely restates those constraints and adds no new syntax or format guidance, 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?

The description names a specific resource (Chelsea places identified by slug) and a specific operation shape (side-by-side comparison of 2-4 items). It implicitly distinguishes itself from the single-item get_place sibling and the search/list siblings by describing a multi-record comparison output. It loses a point only because the action verb is nominalized ('Side-by-side sourced records...') rather than stated directly.

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 2-to-4 bound implies the comparison scenario, but the description never says when to choose this over get_place or search_places, nor what to do if a slug is unknown. Usage is inferable from the name and the cardinality constraint but not explicitly guided.

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 safety profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add operational context, which it does: only published guides are returned, and the payload includes the introduction plus ranked places with sourced fields. It does not address missing-slug behavior or truncation.

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

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

A single dense sentence, front-loaded with the resource and identifier before the return contents. 'Every field sourced' is slightly cryptic but earns its place by flagging provenance.

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

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

With no output schema, the description carries the burden of describing the return value, and it does so (introduction, ranked places, sourced fields) for a two-parameter read tool. Minor gaps remain around error behavior for unknown or unpublished slugs.

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 explains that slug comes from list_guides and that limit caps places at 50 (default 25). The description only echoes the slug concept and adds nothing about the limit parameter, which is the correct baseline.

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: fetch a single published Chelsea guide identified by slug, returning its introduction and ranked places. The singular 'one ... guide by slug' implicitly contrasts with the sibling list_guides, but no sibling is named explicitly.

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: the singular, slug-keyed lookup signals 'use this to read one guide, not to browse'. There is no explicit when-to-use or when-not guidance and no routing to list_guides, get_place, or compare_places.

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 non-destructive behavior, so the safety profile is covered. The description adds value on top by disclosing what the record contains (the guide's editorial description and the public /place URL), which the annotations do not convey.

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. The retrieval scope and the returned content are stated immediately, and 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 one-parameter read tool with no output schema, the description adequately sketches what comes back (editorial description plus public URL). It omits error behavior for an unknown slug, but that is a minor gap given the tool's simplicity and rich annotations.

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

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

Schema coverage is 100% and the single slug parameter is fully documented with a concrete example, so the schema does the heavy lifting. The description only repeats 'by slug' without adding format or resolution details, 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: a full editorial record for one Chelsea place retrieved by slug. The phrase 'one Chelsea place by slug' implicitly separates it from the plural siblings (list_places, search_places), though no sibling is named explicitly.

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: the agent must infer it should call this when it already has a slug and wants the full record rather than a search or a list. There is no explicit guidance on when to prefer search_places or compare_places instead.

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 read-only, idempotent, non-destructive, and closed-world behavior. Beyond those, the description adds that only published guides are returned, gives the URL shape with {slug}, and discloses entry contents (titles, summaries, place counts) — useful detail since there is no output schema. It omits ordering, total count, and 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?

One front-loaded sentence names the resource, the published filter, the URL pattern, and the returned fields. Nothing is wasted and no sentence needs to be re-read.

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

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

For a zero-parameter, read-only listing with full annotation coverage, the description explains what set is returned and what each guide contains. It is largely sufficient, with minor gaps around ordering/limit and no explicit routing away from get_guide.

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 no parameter meaning for the description to add or omit.

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

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

States a specific resource and filter: 'Published Chelsea themed guides', making clear this is a listing operation. The plural resource distinguishes it from single-item siblings like get_guide, though no sibling is named explicitly.

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 the plural 'guides' and the existence of get_guide (which fetches one guide), but the description never states when to use this versus get_guide or when to avoid it. No alternatives or conditions 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 establish that this is a safe, read-only, idempotent operation, so the description does not need to repeat safety traits. It adds useful context about result URL patterns and ranked category pages, but it does not describe ordering, pagination, or the overall response shape beyond link formats.

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 two tightly written sentences, front-loads the tool's scope, and uses the second sentence efficiently for useful return-link context. There is no filler or redundancy.

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 listing tool with complete parameter documentation and annotations covering safety, this description is mostly complete. It provides scope and useful URL patterns, though without an output schema it could say a bit more about the returned place objects or ordering.

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 the four optional parameters and their enum values. The description reinforces the category, tag, and featured filters but adds little meaning beyond the schema, and it does not mention the limit parameter.

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

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

The description clearly identifies the resource and scope: curated places in Chelsea, with optional filtering by category, tag, or featured picks. It is understandable without opening the schema, but it does not explicitly distinguish this listing tool from siblings such as search_places or nearby_places.

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 explains what can be filtered but gives no explicit guidance on when to use this tool versus alternatives like search_places or nearby_places. Usage is only indirectly implied by the mention of curated places and optional filters.

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 safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds useful context the annotations do not: results are distance-annotated in metres and the dataset is curated rather than exhaustive. It does not disclose ordering, result fields, 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 tightly written sentence with the output unit front-loaded at the end and zero filler. Every clause carries information.

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

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

For a read-only spatial query with no output schema, the description tells the agent the key return fact (distance in metres) and the input coordinate standard. Ordering, default radius/limit behavior, and returned fields are left to the schema, which is acceptable given its parameter-level defaults.

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 40% (latitude and longitude have no descriptions at all), so the description must compensate. It helps by specifying the WGS84 coordinate system for lat/long, but says nothing about limit, radius, or the category enum beyond what the schema already documents.

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 (find nearest curated Chelsea places) with spatial scope and the unit of the result (metres). It is distinguishable from get_place (single lookup) and list_places (listing), though it never names those siblings to sharpen the contrast.

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: 'to a WGS84 coordinate supplied in the request' hints that coordinates are required input, and the nearby framing suggests a spatial-proximity use case. There is no explicit when-to-use, no when-not-to-use, and no routing to get_place or list_places for non-spatial lookups.

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

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

Annotations already cover read-only, idempotent, closed-world, but the description adds genuinely new behavioral facts: every field carries its source, addresses/coordinates/hours/websites/photos are deliberately excluded, and callers must follow the place url for them. It also discloses that open_now only honours owner-supplied or official-site hours and that none are recorded yet, which prevents a wasted filter call.

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

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

Three sentences, capability first, then output limitations, then the open_now caveat — well front-loaded with no filler. The 'ranked like https://knowchelsea.com/best/{category}' phrasing leans on an external URL an agent cannot resolve, which slightly muddies otherwise tight prose.

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 7 all-optional parameters and no output schema, the description carries the burden of explaining results, and it does: sources attached, excluded fields enumerated, and a redirect to the per-place url. What it omits is the actual shape of a returned record and any paging model beyond limit, so the agent still learns the result structure only at call time.

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. The description still adds meaning beyond the schema by explaining that open_now is effectively inert with current data and by characterizing the ranking order (the site's best-of list), neither of which is stated in the property definitions.

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 ('Filter curated Chelsea places') and enumerates the filter dimensions (category, sub-zone, tags, featured picks, text), which is far more than a restatement of the name. It does not name any sibling (list_places, nearby_places, get_place) to delineate the boundary, so the agent must infer that filtering-by-facet is the differentiator.

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 context is implied by the filter list and the caveat that open_now currently matches nothing, which steers the agent away from that flag. There is no explicit when-to-use/when-not guidance and no routing to nearby_places or list_places, so the choice among siblings is left to inference.

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