Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

resy_search

Search Resy restaurants near a location by name, cuisine, or neighborhood, and optionally include live bookable timeslots for a date and party size.

Instructions

Search Resy restaurants near a location. Searches restaurants by free-text term (name, cuisine, or neighborhood) near a latitude/longitude, optionally including live bookable-timeslot availability for a given date and party size.

Input Schema

NameRequiredDescriptionDefault
dateNoReservation date, YYYY-MM-DD; when set, results include live timeslots
sizeNoMax results, default 10
termNoFree-text search term (name, cuisine, or neighborhood)
latitudeYesSearch center latitude
longitudeYesSearch center longitude
party_sizeNoParty size, default 2

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses that setting a date triggers live bookable-timeslot availability — a real behavioral trait — but says nothing about auth requirements, rate limits, result ordering, or pagination.

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?

Two sentences, front-loaded with the action and the search scope. Slight redundancy between 'Search Resy restaurants near a location' and the following sentence, but no wasted padding.

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

Completeness3/5

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

For a six-parameter, no-annotation, no-output-schema tool, the description covers what it searches and the optional availability mode, but omits what a result contains, default result count behavior, and any pagination/limit semantics.

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%, so the schema already documents all six parameters (term, date, size, lat/long, party_size). The description restates term semantics and the date→timeslot coupling, adding marginal value beyond the schema; 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 and resource ('Search Resy restaurants') plus the search modality (free-text term, lat/long center, optional availability). Clear enough to distinguish from resy_restaurant/resy_locations, though it never names those siblings to sharpen the boundary.

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?

Usage is implied by the parameters: supply lat/long to search, add a date to get live timeslots. However no explicit when-to-use vs alternatives (resy_locations, resy_availability, resy_restaurant) or preconditions are given.

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

Deploy Server

Other Tools