Skip to main content
Glama
Sign In
chrischall

OFW MCP

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

toast_find_restaurants

Read-onlyIdempotent

Locate Toast restaurants that accept takeout or delivery orders near a latitude/longitude point, returning each restaurant's GUID, ordering link, address, and distance, nearest first.

Instructions

Find restaurants that take orders through Toast near a point (latitude/longitude — this server has no geocoder, so convert an address or city first). Returns each restaurant's GUID (what toast_get_menu needs), shortUrl, ordering link, address and distance, nearest first. Toast's directory lists restaurants OPEN for the dining option at when (default now): an empty or short result late at night means closed, not absent — retry with a daytime when. Optional name filters the results. There is no paging: total is every match and limit (default 25, max 300) is how many come back.

Input Schema

NameRequiredDescriptionDefault
nameNoOnly restaurants whose name contains this (case/punctuation-insensitive).
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands. compact (default) returns the shaped result; "full" returns the Toast gateway's raw `data` object untouched.
whenNoISO-8601 date-time the order would be fulfilled at. Default: now.
limitNoMax restaurants to return (default 25).
latitudeYesLatitude of the search centre, decimal degrees.
longitudeYesLongitude of the search centre, decimal degrees.
radius_milesNoSearch radius in miles (0.1–25, default 2). Toast caps one answer at 300 restaurants.
dining_optionNoTAKE_OUT (default) or DELIVERY. DELIVERY lists only restaurants that deliver to the point.TAKE_OUT

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark this as read-only, open-world, and idempotent, but the description adds important behavior: the directory lists restaurants OPEN for the dining option at `when`, empty results may reflect closure, and there is no paging. These details materially affect how an agent interprets and retries calls.

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?

The description is front-loaded with the core purpose and then layers return format, prerequisites, caveats, and result limits in a logical order. Despite being dense, every sentence carries operational value and avoids repetition.

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?

For an eight-parameter, no-output-schema tool, the description is complete enough to call correctly: it explains required geocoding, return fields, nearest-first ordering, open-now filtering, empty-result interpretation, and paging behavior. No critical agent-facing behavior is missing.

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

Parameters4/5

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

Schema coverage is 100%, so parameter descriptions already carry most semantics. The description still adds useful meaning for `when` (default now and its effect on open restaurants), `limit`/`total` (no paging and `total` is every match), and the optional `name` filter, though it does not elaborate on `view`, `radius_miles`, or `dining_option` beyond the schema.

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 states a specific verb and resource: find restaurants that take orders through Toast near a latitude/longitude point. It also distinguishes the result's GUID as the input needed by toast_get_menu, making the tool's role clear against siblings.

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

Usage Guidelines5/5

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

It explicitly tells the agent to convert an address or city first because the server has no geocoder, and it explains that empty or short late-night results mean restaurants are closed rather than absent, recommending a daytime `when` retry. It also notes the optional `name` filter and the relationship between `total` and `limit` without paging.

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