Skip to main content
Glama

Gracie Barra Jiu-Jitsu

by io.github.junoventures
OverviewDiscussionsAdmin

search_places

Read-onlyIdempotent

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"). Amenity slugs are listed on the attributes parameter.

Input 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. 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. Common slugs: wifi, outdoor-seating, wheelchair, dog-friendly, delivery, takeaway, reservations, live-music, vegan, gluten-free.
neighborhoodNoFilter by neighborhood name. Case-insensitive substring match.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / attributes / description
      Previous value: -"Amenity 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."New value: +"Amenity slugs a place must ALL have. Common slugs: wifi, outdoor-seating, wheelchair, dog-friendly, delivery, takeaway, reservations, live-music, vegan, gluten-free."
    • addedInput schema / properties / attributes / examples
      Added value: +[
+  [
+    "wifi",
+    "outdoor-seating"
+  ]
+]
    • changedInput schema / properties / category / description
      Previous value: -"Filter by category label (e.g. \"Café\"). Case-insensitive substring match."New value: +"Filter by category label. Case-insensitive substring match."
    • addedInput schema / properties / category / examples
      Added value: +[
+  "Café",
+  "Restaurante"
+]
  2. Changed2 schema fields changed
    • addedInput schema / properties / attributes
      Added value: +{
+  "description": "Amenity 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.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / open_now
      Added value: +{
+  "description": "When true, return only places open at the current local time (computed server-side from their opening hours).",
+  "type": "boolean"
+}
  3. First observed

TDQS

A4/5.0
Behavior5/5

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

With annotations already covering the safety profile (readOnly, idempotent, closed-world), the description still adds substantial behavior: accent-insensitive and typo-tolerant matching with worked examples, relevance ranking, and the ALL-must-match semantics for attributes. It also discloses the full result shape — precomputed open_now, attributes array, curated delivery deep-links per platform, rating, and Google Maps-style hours with day/time encoding — which is critical since no output schema exists.

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?

Front-loaded with purpose, then match semantics, then filter composition, then return shape — a sensible progression. The closing sentence is dense (six distinct return fields in one breath) but every clause carries information an agent needs given the absent output schema.

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

Completeness5/5

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

Six optional parameters with no output schema, so the description must carry the return-value burden — and it does, enumerating open_now, attributes, delivery links, rating, and hours structure. Combined with filter-composition guidance, nothing an agent needs to call this correctly is missing.

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

Parameters3/5

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 structured form, and the description largely restates it (open_now = open at this exact moment, attributes = ALL must match, accent/typo tolerance for q). The one addition — that amenity slugs are listed on the attributes parameter — is marginal. Baseline 3 is appropriate.

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

Purpose4/5

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

Opens with a specific verb+resource+scope: 'Search for places (restaurants, cafes, shops, etc.) in this neighborhood.' The parenthetical examples and neighborhood scoping make the domain unmistakable. It never names the adjacent siblings (get_place for a single place, search_dishes for menu items), so it falls short of a 5.

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

Usage Guidelines3/5

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

Offers one genuine usage cue — 'Compose filters for multi-condition queries' — which tells the agent how to combine parameters. But there is no when-to-use/when-not guidance and no mention of get_place or search_dishes as alternatives, so the agent must infer the routing itself.

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

All Gracie Barra Jiu-Jitsu toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources