Community Board

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

With no annotations, the description carries the full burden and does real work: it discloses the access-control model (active listings public; draft/sold/closed/expired restricted to owner) and the failure mode when the identity isn't configured (reported as not found). It omits rate limits and output shape, but the output schema covers the latter.

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 core action, then the visibility qualifier. No filler and no restating of the title.

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 single-record lookup with a full input schema and an output schema already published, the description supplies the one thing structured fields can't: the visibility/ownership rule and the not-found behavior. Little is missing, though a note on what the caller receives for an unauthorized-but-existing listing would close the loop.

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 is fully documented as the listing UUID, so the schema already does the work. The description's reference to "UUID" adds no syntax or format 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?

The description names a specific verb ("Retrieve") and resource ("one listing") and pins the lookup key to a UUID, which cleanly separates it from the search/list siblings. It stops short of naming those siblings explicitly, so the differentiation is inferred 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 – call this when you already have a listing UUID rather than search criteria – but there is no explicit when-to-use/when-not statement and no alternative tool is named. The visibility rules hint at edge cases but do not route the agent between tools.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the empty-result case ('An empty categories array means no categories are currently configured'), which is real behavioral context, but says nothing about auth requirements, caching, or whether results are stable across calls.

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 short sentences, each earning its place: what it returns, how to use the result, and how to interpret the empty case. Front-loaded and free of 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 no-param lookup with an output schema present, the description covers purpose, usage, and the empty-result edge case. The remaining gap is minor behavioral detail (auth/consistency) that a read-only vocabulary tool could arguably omit.

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 per the rubric the baseline is 4; there is nothing for the description to clarify. It stays silent on parameters, which is correct here.

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 ('Return the category slugs and display names') and scopes it to what is accepted by listing creation and search. It is trivially distinguishable from get_listing/search_listings/search_nearby, which operate on listings rather than the category vocabulary.

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 concrete usage context: 'Use a returned slug as the category parameter,' which tells the agent this is a prerequisite lookup for the sibling search/list tools. It stops short of naming alternatives or when-not-to-call, so it does not reach the explicit routing of a 5.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses that results are restricted to active listings and that an empty array means no matches, and it explains parameter interdependencies (lat/long pairing, radius_km dependency, distance-sort dependency). However it says nothing about result limits, pagination, or any auth/permission requirements for a search 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?

Three tightly packed sentences with zero filler; the core purpose is front-loaded and each following clause covers a distinct conditional rule rather than restating the schema.

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?

An output schema exists, so return-value explanation is not required, and the description still adds the empty-result semantics. It is complete enough to invoke correctly, with the only gap being result-limit/pagination behavior that neither the description nor the schema addresses.

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 every parameter is already documented in the schema and the baseline is 3. The description adds the cross-parameter constraint that distance sorting requires an origin and that radius_km requires both coordinates, but offers no syntax or format detail beyond what the schema provides.

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 with scope qualifier ('Search active Community Board listings') plus the filterable dimensions. It does not name or contrast with siblings like search_nearby, so an agent must infer the boundary from the geo-radius wording.

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 clear conditional guidance: supply both latitude and longitude to calculate distance, add radius_km to limit, use distance sorting only with an origin, relevance for title matches, newest for recency. It never states when to prefer this over search_nearby or get_listing, so it stops short of full when-to-use 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?

With no annotations provided, the description carries the full behavioral burden. It discloses active-listing filtering, default distance ordering, and that an empty array means no active matches within the radius, but it does not explicitly state read-only/side-effect-free behavior, permissions, or rate limits.

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 front-loaded with purpose and then briefly covers parameters, ordering, and empty-result behavior. It is tight, though 'using the existing PostGIS distance search' is implementation detail and 'distance ordering is the default' repeats the schema default.

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?

An output schema exists, so return-format details are not needed, and schema coverage is high. But with no annotations, the description should do more to establish when to use this tool versus search_listings and to disclose safety or permission context; those gaps keep it from being 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 description coverage is 100%, so the schema already documents latitude, longitude, radius_km, sort, and category. The description restates that latitude and longitude are separate decimal degrees, radius_km is required in kilometers, and category is optional, but adds little beyond the schema's own parameter descriptions.

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 gives a specific verb and resource: 'Find active listings near a geographic point', with a clear spatial scope and method. It does not differentiate from sibling tools like search_listings or explain when spatial search is preferable, but the core purpose 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?

The description implies use when a latitude, longitude, and radius are available, and notes optional category narrowing. However, it never mentions alternatives such as search_listings or when not to use this tool, leaving routing guidance absent.

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