Localstreet

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

Annotations already declare a safe read operation, and the description adds useful behavioral context by stating the returned content types (line disruption and flood warnings) and that freshness is included for each. It does not cover pagination or edge cases, but that is minor for this simple read tool.

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 zero waste. It communicates the subject, scope, and key return detail 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?

For a one-parameter read tool with no output schema, the description does enough: it says what is returned and with what freshness. The only notable omission is what happens when the optional area parameter is omitted, but the core behavior is otherwise clear.

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 area parameter is fully documented with examples in the schema. The description does not add meaning beyond the schema, so the baseline score 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 names a specific resource and scope: current local incidents (line disruption and flood warnings) with freshness metadata. It is clear enough to distinguish from siblings like events_on and noticeboard_search, though it does not explicitly name alternatives.

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 'right now' implies this is for real-time incident checks rather than historical or scheduled events, but there is no explicit when-to-use guidance or exclusion against sibling tools such as noticeboard_search or events_on.

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?

The annotations already establish that this is a read-only, idempotent, closed-world lookup. The description adds useful behavioral context by listing the returned fields, including dynamic information such as 'open now' and callback-request status. It does not cover not-found behavior or other failure cases.

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 compact sentence fragment that front-loads the key distinction ('One listed business') and then lists the most relevant returned fields. There is no wasted text.

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?

Because there is no output schema, the description usefully enumerates what details are returned. Combined with the annotations and fully documented parameters, this is nearly complete for a simple read-only detail lookup, though it lacks guidance on lookup preconditions or failure behavior.

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 `area` and `path` are already well documented in the schema. The description does not add meaning beyond the schema, which is acceptable given the high coverage but not exceptional.

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 as a single listed business and enumerates the details returned. It distinguishes itself implicitly from `search_businesses` by specifying 'One listed business', though it does not explicitly name the sibling or use a direct retrieval verb.

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: look up details for one known business. However, the description does not state when to use this instead of `search_businesses`, nor does it explain that a path is required or that search should precede lookup.

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, closed-world), so the bar is lower. The description adds one genuinely useful behavioral note — that the tool reports when admissions-distance data is not yet available — but says nothing about what the result looks like or how partial data is signalled.

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, front-loaded with the core check. Minor waste in the vague phrasing 'Says when that data is not available yet', but nothing is padded.

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 zero required parameters, the description should clarify what happens when only some of area/school/postcode are supplied and what a 'not available' response looks like. It hints at the failure mode but leaves the calling contract underspecified.

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 three parameters (area, school, postcode) are already well documented in the schema. The description adds no syntax, format, or combination guidance beyond what the schema provides, 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?

The description states a specific check (was a postcode inside a school's last admissions distance) with both the resource and the returned judgement, which is enough to separate it from siblings like schools_near or area_now. It is terse and slightly telegraphic, but the operation is unambiguous.

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 guidance and no routing to alternatives such as schools_near for broader school discovery. The agent must infer that this is the narrow 'am I in catchment' path from the description 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 readOnly, idempotent, and openWorldHint=false, so the safety profile is covered. The description adds the meaningful behavioral detail that results are scoped to the visitor's borough, but says nothing about result cap (max 10), pagination, or what a result contains.

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 time-format detail is parenthetical and compact. Slightly informal ("What's on") but it earns its space.

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 four-parameter, zero-required read tool with annotations and no output schema, the description covers intent and time scope. It omits what happens when `area` and `limit` are omitted (implied default of the visitor's borough, but unstated) and gives no sense of the returned 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 description coverage is 100%, so all four parameters are fully documented in the schema, including the `when` enumeration and the area examples. The description's parenthetical ("today, tomorrow, weekend, week, or yyyy-mm-dd") merely restates the `when` 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?

States a specific verb+resource ("what's on" = list events) and scopes it to the visitor's borough and a day. It's clear what the tool returns, but it never distinguishes itself from siblings like area_now or noticeboard_search, so an agent must infer the split.

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 "in the visitor's borough" and "on a day" – the agent can guess this is a visitor-oriented events lookup. There is no explicit when-to-use/when-not-to-use statement and no named alternative among the six siblings.

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 openWorldHint=false, so the safety and side-effect profile is covered. The description adds one useful behavioral fact — results are "live" posts, implying only currently active listings rather than historical/expired ones — but says nothing about result ordering, pagination beyond the schema's limit, or coverage boundaries of the dataset.

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 short sentence with the content scope front-loaded and zero filler. It is efficient, though its brevity edges into under-specification rather than crisp 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?

With three optional parameters, a fully documented schema, and no output schema, the description is minimally adequate. It never indicates what a returned post looks like or whether empty results are common, which is the main gap for a search tool with no declared response shape.

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 q, area, and limit all documented including examples and the default of 5, so the schema carries parameter meaning fully. The description adds no syntax, matching behavior (e.g. whether q is free text or AND/OR), or guidance on combining q with area, 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?

The description identifies the resource ("posts on the borough's noticeboard") and the listing categories (for sale, free, wanted, local help), which helps an agent understand the content domain. However, it never states the action — the search/retrieve verb exists only in the tool name — and it does not distinguish this from siblings such as search_businesses or area_now.

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 when-to-use guidance, no mention of alternatives, and no prerequisites. An agent deciding between noticeboard_search, search_businesses, and events_on gets no routing signal from the description at all.

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, so the description only needs to add context, and it does: the data provenance ("our hub data") and the result ordering ("nearest first"), the latter being especially valuable with no output schema. It stops short of stating the nearest metric or whether results are truncated by the default 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 front-loaded sentence that packs resource, data source, returned fields and sort order with zero filler. Nothing could be removed without losing 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?

With no output schema, the description does useful work by naming the returned attributes and ordering, but it never explains how `area` and `district` interact, what "nearest" is measured from (the visitor's location presumably, unstated), or the default result count. For a discovery tool those are real gaps.

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 and the description adds nothing parameter-specific. It notably leaves the overlap between `area` (which already accepts a postcode district) and the separate `district` parameter unresolved, an ambiguity the agent must guess at.

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 schools in an area) plus the returned attributes (Ofsted, phase, faith character, address) and ordering (nearest first), which is more than the title conveys. It does not differentiate itself from the sibling catchment_check, which is the obvious source of confusion for an agent choosing between the two.

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?

"In the visitor's area" implies a location-scoped lookup, so the intended usage is inferable, but there is no explicit when-to-use or when-not statement. The sibling catchment_check plausibly overlaps (distance-to-school questions) and the description gives no rule for choosing between them.

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 openWorldHint=false, so safety and determinism are covered. The description adds only that results come from a curated Localstreet directory, without saying how area/district interact, whether results are paged, or what shape they take. With annotations carrying the behavioral burden this is adequate but thin.

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 action and source are stated up front. It is efficient but so terse that it omits the one routing detail (when to prefer it over business_details) that would have earned 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 four-parameter discovery tool with no output schema, the description covers the core intent but never explains how area and district combine to narrow results or how many results to expect. Annotations cover safety, so the gap is in filtering semantics rather than risk.

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 (q, area, limit, district) are already documented with examples and defaults. The description echoes only the 'trade or name' meaning of q and adds nothing about area/district overlap or the limit cap, 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 ('Search') and resource ('the businesses listed on Localstreet') plus the query dimension (trade or name), so the agent knows exactly what it retrieves. It does not distinguish itself from the sibling business_details, which could also be used to look up a business, leaving a small ambiguity.

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 instead of business_details, nor any mention of prerequisites or exclusions. The agent must infer that this is for discovery and business_details for a known record.

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