List active promotions and deals available in this neighborhood directory. Returns discount label, promo code (if any), CTA link, validity window, and which business/place it belongs to. FLASH offers have a countdown deadline.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Filter by offer kind. FLASH = time-limited flash sale with countdown. Omit to return all active offers. | |
| limit | No | Max offers to return (default 20, max 60). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It does not explicitly state that the tool is read-only or non-destructive, though 'list' implies reading. It adds useful context about FLASH offers having countdown deadlines, but does not disclose error conditions, rate limits, or authentication requirements. This is adequate but not comprehensive.
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 sentences with zero wasted words. The first sentence covers purpose and return fields; the second adds a crucial detail about FLASH offers. Every sentence earns its place, and the structure 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?
Given no output schema, the description effectively lists all returned fields, and explains the distinction between STANDARD and FLASH offers. It omits details like pagination ordering or error handling, but for a simple list tool with known parameters, it is nearly 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 100% with both parameters fully described. The tool description adds a bit of context ('FLASH offers have a countdown deadline') that reinforces the schema's description of the 'kind' parameter, but does not significantly extend it. Baseline of 3 is appropriate as the schema already does heavy lifting.
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 verb 'List', the resource 'active promotions and deals', and the context 'neighborhood directory'. It enumerates returned fields (discount label, promo code, CTA link, validity window, business/place), providing a precise and distinct purpose. While it does not explicitly differentiate from sibling tools, the 'neighborhood directory' scope and specific fields make its purpose 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?
No explicit guidance on when to use this tool versus alternatives (e.g., list_products, list_events). There is no mention of when not to use it or prerequisites. The description implies usage for listing offers, but lacks comparative context among the many sibling list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource or action (booking, checkout, availability, events, reviews, etc.). Even similar-looking tools like create_booking, request_reservation, and rsvp_event are clearly differentiated by their descriptions and target systems.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_booking, get_availability, list_booking_services). No mixing of conventions or unclear verbs.
28 tools is on the higher end, but the server covers a wide domain (places, events, movies, booking, forms, loyalty, etc.). Each tool serves a clear purpose, so the count is justifiable, though minor trimming could be considered.
The tool set covers most workflows for a neighborhood directory: search, details, booking, events, reviews, etc. Some CRUD operations are missing (no update/delete for bookings), but these are consumer-facing actions where that is acceptable. The domain is well-covered.
