KnowFulham

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description adds value beyond them by disclosing the return shape ('sourced records ... with the tags they share'), which matters because no output schema exists.

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

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

A single front-loaded sentence with no filler; the comparison scope and cardinality come first. 'Sourced records' is slightly opaque wording but costs only a few words.

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, fully described schema with annotations covering safety and no output schema, the description supplies the essential result character (records plus shared tags). Only edge behavior for invalid or unknown slugs is left unstated.

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 already enforces minItems 2, maxItems 4, and uniqueItems, so the description's '2 to 4 ... by slug' restates structured constraints rather than adding new meaning. 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 concrete operation and resource: a side-by-side comparison of Fulham places, bounded to 2–4 slugs, returning shared tags. The cardinality and 'side-by-side' framing separate it from get_place without naming the sibling 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?

The comparison intent implies when to use it (multiple places at once rather than one), but there is no explicit statement of when to prefer this over get_place or nearby_places, and no mention of preconditions such as slugs needing to exist or be distinct.

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, closed-world behavior, so the safety profile is covered. The description adds that only published guides are returned and that every field is sourced, but it is silent on what happens for an unknown or unpublished slug and never mentions that the 'limit' parameter can truncate the ranked places.

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 clause identifies resource, selector, and payload with no filler. 'Every field sourced' is compact to the point of being cryptic about what provenance data actually appears.

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 sketches the return shape (introduction plus ranked places), which is the main thing an agent needs. Gaps remain around error/not-found behavior and whether ranking order is guaranteed.

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

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

Schema coverage is 100%, so both parameters are already documented including the slug example and the limit default/max. The description reinforces slug-based selection and the published-only constraint but adds no syntax, format, or behavior 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?

Names a single, specific resource ('One published Fulham guide by slug') and states what comes back (introduction and ranked places). The singular 'one' plus 'by slug' implicitly separates it from list_guides, though it never names that sibling 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: 'by slug' signals it is the follow-up to a list_guides lookup, but there is no explicit when-to-use, when-not-to-use, or named alternative such as get_place for individual items.

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 a read-only, idempotent, closed-world, non-destructive call, so the safety profile is covered. The description adds value by disclosing what the payload contains – the guide's description and the public /place URL – which matters given there is no output schema. It omits error behavior for missing slugs, keeping it from 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?

One sentence, front-loaded with the resource and keyed lookup, then the payload contents. Nothing redundant and 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 simple single-parameter read tool with full annotation coverage and a documented parameter, the description supplies the missing piece – what the response contains. Only edge-case behavior for nonexistent or non-public slugs is 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 the single slug parameter includes a concrete example. The description's 'by slug' restates the schema rather than adding format, validation, or lookup semantics 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 and resource: 'Full editorial record for one Fulham place by slug.' The phrase 'one ... by slug' implicitly contrasts with the list/search siblings, and 'full editorial record' signals the depth of payload. It stops short of naming which sibling to use instead, so not a 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: you need a slug and want the complete record rather than a listing or search result. There is no explicit when-to-use clause, no mention of when to prefer search_places or nearby_places, and no note on what happens for an unknown or unpublished slug.

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 safety (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add substance — and it does, disclosing the returned fields (titles, summaries, place counts) despite there being no output schema. It omits ordering, pagination, and roughly how many guides exist, which are the remaining 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?

A single front-loaded sentence with the resource, its 'Published' scope, and the URL pattern packed into a parenthetical that earns its place. Nothing is redundant.

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 and no output schema, the description carries the return-value burden and does so by naming the fields returned. For a simple catalogue listing it is close to complete, though a note on result size or ordering would fully close it.

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

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

The tool takes zero parameters, so the schema baseline applies and no parameter explanation is needed. The description wisely spends its words on scope and return content instead.

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 identifies the resource precisely: published Fulham-themed guides, with the URL pattern showing a {slug} identity. It is clearly distinct from get_guide (single guide) by being a listing, though it never states that distinction 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 by the resource being a collection; there is no explicit 'use this when you want the catalogue' statement and no mention of get_guide or search_places as alternatives. The 'Published' qualifier hints that unpublished guides are excluded, which is a small piece of scoping 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 establish that this is a read-only, idempotent, non-destructive operation. The description adds useful context by explaining that each result links to a /place/{slug} page and that ranked pages use /best/{category}, but it does not describe ordering, pagination behavior, or the returned fields.

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 concise sentences with no unnecessary wording. It is front-loaded with the core purpose and follows with useful output URL context.

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 has no required parameters, full schema description coverage, and annotations covering safety and idempotency. The description supplies additional URL context for results, though it could say more about result ordering or what fields each place includes.

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 schema already documents all four parameters including enums and the limit default. The description mentions category, tag, and featured filtering but adds little beyond what the schema provides, so the baseline score of 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 uses a specific verb and resource: 'List' curated places in Fulham, with optional filtering by category, tag, or featured status. It is clear what the tool does, but it does not explicitly distinguish itself 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 implies browsing curated places and mentions the available filters, but it does not state when to use this tool instead of search_places, nearby_places, or get_place. Usage is only minimally 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 declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds dataset scope (curated Fulham only) and measurement units (metres), which is useful, but says nothing about result ordering, radius-overflow behavior, or what happens when nothing is found.

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 naming resource, coordinate system and unit – no filler. It is efficient, though at the cost of the guidance and parameter context noted above rather than as a deliberate compression of richer 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 read-only geo lookup with full safety annotations and no output schema, the essentials are present: what is searched, where, and in what unit results are measured. Missing are result ordering/shape and any guidance on choosing radius or category, which an agent would want before iterating.

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?

Coverage is 40%, so the description must compensate and it only partly does: it establishes WGS84 for the coordinates and metres for radius, aligning with the schema's units. It never mentions the category filter, the limit cap, or defaults, leaving the enum parameter documented only by its type.

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 operation: returns nearest curated Fulham places to a WGS84 coordinate, with distance in metres. The proximity framing implicitly distinguishes it from search_places and list_places, but no sibling is named, so an agent must infer the boundary itself.

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 'nearest ... to a WGS84 coordinate' – an agent can infer this is the proximity query. There is no explicit when-to-use, when-not-to-use, or steering toward search_places/list_places when proximity is not the goal.

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?

Goes well beyond the readOnly/idempotent annotations: it discloses that every field carries its source, that addresses, coordinates, hours, websites and photos are deliberately absent so callers must follow the place url, and that ranking mirrors a known site pattern. The open_now caveat — that only owner/official-site hours count and none are recorded yet — is a critical disclosure that the filter currently matches nothing.

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, front-loaded with the filtering capability, then data-availability limits, then the open_now caveat. Dense and purposeful, though the middle sentence is a run-on that bundles several exclusions together.

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 optional parameters and no output schema, the description does the needed extra work: it states the ranking model, warns that most contact/location fields are omitted, and flags the open_now dead end. Only minor gaps remain, such as result ordering when no query is supplied and whether any facets combine conjunctively beyond tags.

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 tags (all-must-match), limit, query, category, featured, open_now and sub_zone. The description adds meaning only for open_now (its data-source restriction and current emptiness) and for result ordering; the remaining parameters get no extra semantics beyond the schema.

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

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

Opens with a specific verb and resource — 'Filter curated Fulham places' — and enumerates the exact facets (category, sub-zone, tags, featured, text), which tells an agent precisely what this tool does. It does not name any sibling (list_places, nearby_places, get_place), so differentiation from those must be inferred from the facet list rather than stated.

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 filter list plus the instruction to 'follow each place url' for addresses/hours/photos, which hints that this tool is an index rather than a detail lookup. However, no alternative tool is named and no when-not-to-use condition is given (e.g. when to prefer nearby_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.