Get full details for a specific place by its URL slug, including opening hours, a precomputed open_now boolean, amenity attributes (slugs), a delivery array of curated delivery-app deep-links (ifood, rappi, uber-eats — each { platform, url }), ratings, address, and neighborhood.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | URL slug of the place, e.g. "cafe-example". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It transparently lists the exact response components, including the structure of the delivery array and the open_now boolean, which is valuable. However, it does not mention potential errors (e.g., invalid slug) or any side effects, though for a read-only get operation this is acceptable.
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, information-dense sentence that leads with the primary purpose and then enumerates key response fields. While long, every phrase contributes value (e.g., specifics about delivery platforms and the 'precomputed open_now boolean'). It is well-structured and 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 the tool's moderate complexity (one parameter, no output schema), the description effectively covers what the caller can expect, including the structure of nested arrays. It does not explain error handling or null cases, but for a simple get-detail tool the provided information is largely 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 a clear schema description for 'slug'. The tool description adds minimal extra meaning beyond restating 'by its URL slug', essentially echoing the schema. Thus the baseline of 3 applies, as the schema already does the 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 identifies the tool's action ('Get full details') and resource ('a specific place'), with the unique identifier ('URL slug') and the exact data returned (opening hours, open_now, attributes, delivery, ratings, address, neighborhood). This distinguishes it from sibling tools like search_places (searching) and get_reviews (reviews only).
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 clear usage: use this when you have a place's URL slug and need full details. It does not explicitly mention when not to use it or name alternative tools, but the context ('by its URL slug') and the list of sibling tools provide enough situational clarity.
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 services, restaurant reservations, event tickets, and RSVPs are all clearly separated by domain and described with explicit use cases. Similarly, search_places, search_dishes, and get_restaurant_menus cover different granularities of place/menu lookup. The descriptions include guidance on when to use each tool, eliminating ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_*, get_*, create_*, search_*). While a few verbs like 'request' and 'rsvp' differ, they accurately reflect the action's semantics and do not break the overall consistency. The naming makes the tool's purpose predictable from its name.
At 28 tools, this is a large set, but it serves a broad multi-domain directory (places, events, movies, store, bookings, content, etc.). Each tool covers a distinct feature or resource, and there are no redundant tools. The count is at the upper boundary but appropriate for the server's comprehensive scope.
The tool surface covers the full lifecycle for the directory's main domains: search/discover places, view details, menus, reviews, book services, reserve/RSVP events, browse movies/showtimes, list products, access content (blog, guides, FAQs), submit forms, and check loyalty. There are no obvious dead ends or missing operations for the stated purpose. The inclusion of pairing tools like list_forms→submit_form and get_availability→create_booking shows deliberate workflow completeness.