Skip to main content
Glama

Asian Recs

by com.asianrecs
OverviewDiscussionsAdmin

Search Asian Recs

search_places
Read-onlyIdempotent

Find places in San Francisco or New York ranked by how Asian diners rate them. Each result has the Asian diners' rating, everyone else's rating, the gap between them, how many Asian diners reviewed it, top dishes, neighborhood and a link to its page. Use when someone asks where to eat or drink in San Francisco or New York, or for restaurant, dessert, cafe or bar recommendations there. When nothing matches, message says why.

Input Schema

NameRequiredDescriptionDefault
cityYessf = San Francisco, nyc = New York
nearNoA point to measure distance from; adds distance_mi to results.
sortNoasian_rating: Asian diners' rating, highest first; loved_more: Biggest gap above everyone else; most_asian_diners: Most Asian diners; share_asian: Highest share of Asian reviewers; distance: Closest first (needs near). Default asian_rating.
typeNoKind of place. Default restaurants. Boba, coffee, tea and bakeries are cafes; ice cream and dessert shops are desserts.
limitNoDefault 10.
queryNoFree text matched against name, cuisine, neighborhood and dishes, e.g. a dish like "soup dumplings".
cuisineNoCuisine or drink category, e.g. "ramen", "sichuan", "korean", "dim sum", or "boba" with type cafes.
locationNoNeighborhood or area, e.g. "Mission", "East Village", "Flushing", "Manhattan — Downtown". list_filters has the exact names.
radius_miNoWith near: only places within this many miles.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / cuisine / description
      Previous value: -"Cuisine or drink category, e.g. \"ramen\", \"sichuan\", \"korean\", \"boba\", \"dim sum\"."New value: +"Cuisine or drink category, e.g. \"ramen\", \"sichuan\", \"korean\", \"dim sum\", or \"boba\" with type cafes."
    • changedInput schema / properties / location / description
      Previous value: -"Neighborhood or area, e.g. \"Mission\", \"East Village\", \"Flushing\", \"Manhattan — Downtown\"."New value: +"Neighborhood or area, e.g. \"Mission\", \"East Village\", \"Flushing\", \"Manhattan — Downtown\". list_filters has the exact names."
    • changedInput schema / properties / type / description
      Previous value: -"Kind of place. Default restaurants."New value: +"Kind of place. Default restaurants. Boba, coffee, tea and bakeries are cafes; ice cream and dessert shops are desserts."
  2. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real value by enumerating the returned fields (both ratings, the gap, review counts, top dishes, neighborhood, link) and by disclosing empty-result behavior ('message says why').

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

Conciseness5/5

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

Three tight sentences, none of them filler: capability and ranking first, usage triggers second, empty-state behavior last. Nothing is repeated and nothing is buried.

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?

With no output schema, the description correctly compensates by listing the result fields, and the nine params are fully covered by the schema. Only minor gaps remain, such as pagination or how limit interacts with ranking, which are not addressed anywhere.

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 description coverage is 100% and every parameter, including the enums and the near/radius interaction, is documented in the schema itself. The description adds no syntax, format, or default information beyond what the schema provides, so the baseline 3 applies.

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?

States a specific verb (find), resource (places), geography (San Francisco or New York), and the distinctive ranking signal (how Asian diners rate them). It does not, however, differentiate itself from siblings get_place or list_filters, leaving the agent to infer that get_place is for detail lookups.

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?

Gives clear triggering contexts: 'when someone asks where to eat or drink' and 'restaurant, dessert, cafe or bar recommendations' in the two supported cities. No explicit when-not-to-use or named alternatives, which keeps it short of a 5.

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

All Asian Recs 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