Skip to main content
Glama

search_places

Search for places (restaurants, cafes, shops, etc.) in this neighborhood. The q match is accent-insensitive and typo-tolerant ("acai" finds "Açaí", "restaurnt" finds "Restaurante"), ranked by relevance. Compose filters for multi-condition queries: category, neighborhood, open_now (true = open at this exact moment), and attributes (amenity slugs, ALL must match). Each result includes a precomputed open_now boolean, an attributes array (amenity slugs), a delivery array of curated delivery-app deep-links (ifood, rappi, 99food, uber-eats — each { platform, url }), rating, and structured hours (Google Maps periods: day 0=Sun–6=Sat, time "HHMM"). Common amenity slugs: wifi, outdoor-seating, wheelchair, dog-friendly, delivery, takeaway, reservations, live-music, vegan, gluten-free (availability varies per place).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFree-text term matched against place name and address — accent-insensitive and typo-tolerant.
limitNoMax results to return (default 20, max 100).
categoryNoFilter by category label (e.g. "Café"). Case-insensitive substring match.
open_nowNoWhen true, return only places open at the current local time (computed server-side from their opening hours).
attributesNoAmenity slugs a place must ALL have, e.g. ["wifi","outdoor-seating"]. Common slugs: wifi, outdoor-seating, wheelchair, dog-friendly, delivery, takeaway, reservations, live-music, vegan, gluten-free.
neighborhoodNoFilter by neighborhood name. Case-insensitive substring match.

TDQS

A4.4/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It describes search behavior (accent-insensitive, typo-tolerant), result structure (open_now boolean, attributes, delivery, hours), and notes that open_now is computed server-side. It does not mention pagination details or rate limits, but the core behavioral traits are disclosed.

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

Conciseness4/5

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

The description is two paragraphs with clear structure: first sentence states purpose, second paragraph dives into details. Every sentence adds value, though some repetition exists (e.g., listing slugs again). It is front-loaded but could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but the description explains the result fields (open_now, attributes, delivery, hours, rating). It covers all 6 parameters adequately. Missing aspects like sorting/ordering or pagination beyond limit, but overall it is complete for a search tool.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds crucial context: for `q` it adds accent-insensitive and typo-tolerant; for `open_now` it clarifies 'at this exact moment'; for `attributes` it notes 'ALL must match' and lists common slugs; for `neighborhood` it specifies case-insensitive substring match. This goes well beyond the schema descriptions.

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

Purpose5/5

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

The description begins with a clear verb ('Search') and resource ('places'), listing examples (restaurants, cafes, shops). This distinguishes it from sibling tools like 'get_place' (single place) and 'search_dishes' (different resource).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains filter behavior (multi-condition queries with parameters like category, open_now, attributes) and gives details on match algorithm (accent-insensitive, typo-tolerant). However, it does not explicitly contrast with alternative tools for similar tasks (e.g., when to use 'get_place' instead).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool targets a distinct resource or action (e.g., bookings, events, places, menus, forms), with detailed descriptions that clearly differentiate even similar operations like create_booking vs. reserve_event_tickets. No two tools overlap in purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using lowercase and underscores (e.g., create_booking, get_availability, list_events). Verbs are semantically appropriate (create, get, list, search, submit) and predictable.

Tool Count4/5

28 tools is slightly above the typical 3-15 range, but the breadth of the neighborhood directory domain justifies each tool. The count feels dense but not excessive, with no redundant tools.

Completeness5/5

The tool set covers the full lifecycle of a neighborhood directory: place search, restaurant menus, events, movie showtimes, booking, reviews, blog, guides, offers, loyalty, forms, and profiles. Obvious gaps like review creation are absent but likely out of scope.

Resources