KnowKensington

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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by describing output as 'side-by-side sourced records' and mentioning 'tags they share,' though it does not elaborate on response structure or error handling.

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 that covers the comparison scope, resource, input key, and notable output. Every clause adds information with no waste.

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?

The tool is simple with one parameter and rich annotations. The description explains the comparison operation and hints at return content, but without an output schema it could say more about the returned record structure. It is still sufficient for 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?

The input schema has 100% description coverage, including minItems, maxItems, uniqueItems, and an example. The description restates the 2-to-4 range and slug usage but adds no syntax or format details beyond the schema; baseline 3 is appropriate.

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

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

The description clearly states the tool compares 2 to 4 Kensington places by slug and returns side-by-side sourced records plus shared tags. It distinguishes itself from single-place or list/search tools through the comparison scope, though it does not explicitly name 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?

The description implies usage by specifying a comparison of 2 to 4 places, but it does not explicitly say when to use this instead of get_place, search_places, or nearby_places. No exclusions or alternatives are named.

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 this as read-only, idempotent, non-destructive, and closed-world, so the description need not repeat safety traits. It adds useful behavioral context by stating that the response includes the introduction, ranked places, and sourced fields. It does not mention error behavior when a slug is unknown, so it falls short of full transparency.

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 efficient sentence with the key information front-loaded: one published guide by slug, plus the response contents. Every phrase contributes to identifying the resource or clarifying its payload.

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 no output schema, the description is largely complete: it identifies the input scope and summarizes the return contents. The main remaining gap is that it does not explain what happens when the requested slug does not exist.

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 both slug and limit in detail. The description adds no additional parameter semantics beyond implying that the guide is selected by slug.

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: fetching one published Kensington guide by slug, scoped as the introduction plus ranked places. This distinguishes it from list_guides, though it does not explicitly contrast with the sibling tools.

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 phrase 'by slug' implies the tool is used when a slug is already known, which is enough to suggest usage. However, there is no explicit when-to-use guidance, no exclusions, and no reference to alternatives such as list_guides.

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, closed-world), so the description's job is lighter. It adds useful substance by disclosing what the record contains—the editorial description and a public /place URL—which is the main behavioral unknown here.

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

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

A single front-loaded sentence with no filler; the lookup key and the payload contents both appear immediately.

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 in outline ('full editorial record', description, public URL). It remains slightly underspecified—address, category, or related-place fields are not mentioned, and slug miss behavior is unstated—but it is adequate for a one-parameter read 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?

There is one parameter with 100% schema coverage and a concrete example ('artisan-coffee'), so the schema already does the work. The description only restates 'by slug' and adds no format, normalization, or not-found behavior beyond the schema.

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

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

The description names a specific verb and resource ('Full editorial record for one Kensington place') and the lookup key ('by slug'), which implicitly separates it from the list/search siblings. It stops short of naming an alternative like search_places or get_guide, so it is clear but not fully differentiated.

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: 'one ... place by slug' suggests this is the single-record fetch rather than a listing. There is no explicit when-to-use or when-not-to-use guidance (e.g. use search_places when you only have a name, not a slug), so the agent has to infer the 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 read-only, idempotent, closed-world behavior, so the description focuses on what is returned: sourced titles, summaries, and place counts. That return-content disclosure is genuinely useful since no output schema exists, though pagination or result-size behavior is not mentioned.

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 sentence front-loads the resource, embeds the URL pattern, and lists the returned fields with no 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 zero-parameter list tool with no output schema, the description covers purpose and returned fields adequately. Minor omission is result volume/pagination, which matters little given the closed-world, idempotent annotation profile.

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 document; baseline 4 applies. The description correctly implies no filtering arguments are available.

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 ('published Kensington themed guides') and includes the URL pattern, making the scope concrete. It doesn't explicitly contrast with the sibling get_guide (single guide) or search_places, but 'list' vs 'get' makes the distinction reasonably clear.

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 listing scope; the description never says when to call this versus get_guide or search_places, nor any prerequisites. An agent can infer it's the enumeration entry point, but nothing is stated explicitly.

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 read-only, idempotent, closed-world behavior, so the description is free to add the genuinely new information: each result carries a knowkensington.com/place/{slug} link and ranked lists live under /best/{category}. That return-shape and provenance detail is not derivable from annotations or schema.

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

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

Two sentences: the first defines scope and filters, the second defines result linking. Nothing is repeated from the schema or title, and the essential scope is front-loaded.

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

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

With no output schema, the description usefully covers what a caller gets back (slug URLs, ranked best-of pages) and that zero filters are required. Minor gaps remain on ordering and on the default-vs-explicit limit behavior, but the omission is small for a simple read tool.

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

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

Schema description coverage is 100%, with enums fully spelled out, so the baseline is 3. The description adds only that the filters are optional and combinable, without clarifying how tag, category, and featured interact when used together.

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 ('curated places in Kensington') plus the available filter axes, so an agent knows exactly what comes back. It never names a sibling, though, so the boundary with search_places, nearby_places, and compare_places must be inferred.

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?

'optionally filtered by category, use-case tag or featured picks' implies the browse-enumeration use case, but there is no explicit when-to-use versus search_places (free text) or nearby_places (proximity). The agent has to guess which listing tool fits a given query.

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 openWorld=false, so the safety profile is covered. The description adds genuinely useful context beyond that: results are distance-annotated in metres and come from a curated (closed) dataset, consistent with openWorldHint. It does not say how results are ordered, what an empty radius returns, or whether there is any cap beyond the schema's limit.

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 sentence with no filler, and the resource and unit of measurement are front-loaded. Slightly awkward phrasing ('to a WGS84 coordinate supplied in the request') is the only blemish.

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 full burden of describing returns, and it only gives the distance field and unit; ordering (nearest-first is implied but unstated), result shape, and behaviour on empty results are missing. For a five-parameter read tool this is adequate but not 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 40%: limit and radius are documented in the schema, while latitude, longitude and category are bare. The description compensates partially by specifying the coordinate reference system (WGS84), which is real added meaning for the two undocumented required params. However, it says nothing about the category enum's filtering behaviour or its default.

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 (find nearest), resource (curated Kensington places) and the key input (WGS84 coordinate) plus the unit returned (metres). It clearly reads as a proximity lookup, which implicitly separates it from search_places or list_places, but no sibling is named, so differentiation requires 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?

There is no explicit when-to-use, when-not-to-use, or named alternative among the six siblings. The phrase 'to a coordinate supplied in the request' hints that coordinates are the precondition, but the agent must infer why it would pick this over search_places or get_place.

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?

Beyond annotations, the description discloses important behavior: results are ranked like the referenced best-of pages, every field carries a source, and key fields such as addresses, coordinates, hours, websites, and photos are intentionally omitted. It also warns that open_now depends on owner-supplied or official-site hours and that none are recorded yet, which is critical behavioral context for an agent.

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 three focused sentences, front-loads the core filtering purpose, then adds return-content exclusions and the open_now caveat. There is no obvious wasted text, and the structure supports quick scanning.

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 search tool with complete schema coverage and annotations covering safety and idempotency, the description supplies what the schema does not: ranking behavior, field sourcing, excluded fields, URL-based next steps, and the open_now limitation. No output schema exists, but the description sufficiently explains what is and is not returned.

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 schema already has 100% parameter description coverage, so the baseline is 3. The description adds meaningful parameter-related context by warning that open_now has no currently recorded hours, which materially affects how an agent should use that flag. It otherwise mostly restates the filter dimensions already documented in 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: filtering Andrew's Kensington places by category, sub-zone, tags, featured picks, or text. It also clarifies that detail fields are excluded and should be fetched via each place URL, which helps distinguish it from a detail-fetch tool. However, it does not explicitly differentiate itself from siblings like nearby_places, list_places, or compare_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?

Usage is implied through the filtering dimensions and the note to follow each place URL for addresses, hours, and photos, but there is no explicit guidance on when to prefer this tool over sibling tools such as get_place or nearby_places. The open_now caveat is useful but does not establish broader when-to-use or when-not-to-use rules.

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