Myrtle Beach food trucks, restaurants, shops and HOAs: live menus, stops, pickup times, order links.
Scored across 6 tools
Each tool targets a distinct resource: business profile, menu, city-wide truck stops, per-business events/stops, search, and cart creation. The main potential confusion is between get_trucks_tonight (city-scoped) and get_upcoming_events (business-scoped), since both surface food truck stops, but the descriptions clearly separate the two contexts.
Names follow a mostly consistent snake_case verb_noun pattern (get_business, get_menu, get_upcoming_events, search_businesses, start_order). get_trucks_tonight is slightly more idiomatic/descriptive than the others but still fits the verb_noun convention, so the deviation is minor.
Six tools is well-scoped for a local business discovery and ordering surface, with no obvious redundancy. Search, detail, menu, events, trucks, and ordering each earn a distinct place in the workflow.
The surface covers discovery (search), inspection (business, menu, events, trucks), and order initiation (start_order) end-to-end, with payment handled off-server. Minor gaps exist, such as no tool to retrieve/check an order's status or to enumerate categories/towns, but agents can work around these via search filters.
Returns the public profile of one Shortlist business: name, type, description, town, phone, website, page URL, hours (fixed locations only), whether online ordering is open, and the order page URL when it is. Mobile businesses (food trucks) have no fixed address; their locations are the upcoming stops in the upcoming-events data.
| Name | Required | Description | Default |
|---|---|---|---|
| subdomain | Yes | The business subdomain, e.g. "nitos" for nitos.shortlistpass.com |
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 — and the description still adds real behavioral context: hours exist for fixed locations only, whether online ordering is open, the conditional presence of an order page URL, and the mobile-business caveat. It stops short of describing error behavior for a bad subdomain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the identity of the returned resource, followed by the field inventory and then the mobile-business caveat. Two sentences, both earning their place, though the opening sentence is a long comma-separated run-on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does so by enumerating the fields, including conditional ones (hours, order page URL) and the mobile-business exception. Only failure/empty-result behavior for an unknown subdomain is left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents the sole subdomain parameter with a concrete example ('nitos' for nitos.shortlistpass.com). The description adds no parameter-level detail beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource ('Returns the public profile of one Shortlist business') with an enumerated field list, and the singular 'one business' implicitly contrasts with the plural sibling search_businesses. It never names a sibling explicitly, so the differentiation is inferential rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied only: you must already hold a subdomain, and the note that mobile business locations live in 'upcoming-events data' hints at redirection to get_upcoming_events. There is no explicit when-to-use/when-not statement or named alternative for get_menu or search_businesses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Food trucks in one city today (local time), in two lists. "tonight" (status "out_tonight"): trucks with a stop confirmed for today — truck name, park if it is at one, address, start and end time, open_now, the truck page link, and order_url only when that truck is taking preorders for that stop. "usually_here" (status "usually_here"): trucks that regularly park at a listed park but have NO stop confirmed for today — say "usually here", never "out tonight". Also lists the parks with today's and usual truck counts. Optional "days" (1-7, default 1): also returns "days", the posted stops for today and the next days grouped by date (truck, where, start, end, open_now, page link); a day with no posted stop is left out. Test pages, private events and cancelled or hidden stops are never included. Cities: Myrtle Beach, Austin.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City name or slug, e.g. "Austin" or "myrtle-beach" | |
| days | No | How many days from today, 1-7 (default 1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description still adds substantial behavior: excluded record classes (test pages, private events, cancelled or hidden stops), conditional field presence (order_url only when preorders are open for that stop), and the fact that days with no posted stop are omitted entirely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first clause, and each following sentence adds distinct information (list semantics, days behavior, exclusions, cities) rather than padding. It is dense and slightly run-on with heavy quoting of field names, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the full burden of describing return shape, and it does so thoroughly: per-list field inventories, the parks counts, the optional date-grouped 'days' structure, and the exclusion rules. An agent can call and interpret this tool correctly from the definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description goes beyond it by explaining what 'days' actually does (returns a date-grouped 'days' list covering today plus the next N days) and that empty days are dropped, which is behavior the schema cannot express. City semantics are left to the schema's example values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (get food trucks in one city today) and immediately partitions the output into two named lists with their status values, so an agent knows exactly what it returns. No sibling tool (get_business, get_menu, get_upcoming_events, search_businesses, start_order) covers trucks, so differentiation is inherent and reinforced by the explicit scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for use: single-city, today local time, with the supported city list (Myrtle Beach, Austin) acting as a usable precondition. It also sets semantic rules ('usually_here' must never be called 'out tonight'), but it never names an alternative tool or states a when-not-to-use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the upcoming published events and stops for one business; for a food truck these are its locations. Each has a name, ISO start and end with the local offset, location name and address, whether pre-orders are open for that stop, the pickup time slots still available with remaining capacity (null means no cap), and a menu with menu_status: "set" means the items listed are what is sold at that stop and their offering ids are accepted by start_order for that stop; "not_live" means the business has not put a menu on that stop yet, the menu is empty, menu_note carries the explanation, and start_order does not accept the stop; "catalog" means a fixed business whose standing menu applies. Recurring events carry a recurrence description and the next date. Cancelled and test events are not included.
| Name | Required | Description | Default |
|---|---|---|---|
| subdomain | Yes | The business subdomain, e.g. "nitos" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, read-only, idempotent operation, and the description goes well beyond that with real behavioral rules: cancelled/test events are excluded, 'null' means no capacity cap, and the three menu_status values define what start_order will accept. This is exactly the extra context an agent needs to act on the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long and dense, but it is front-loaded with the core purpose before diving into return-field semantics. Every clause carries concrete information (capacity, menu status, recurrence, exclusions), though the single paragraph could be broken up for scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the full burden of describing the return payload, and it does so thoroughly: event fields, capacity semantics, menu_status meanings, recurrence, and exclusions. An agent has enough to interpret results and chain into start_order correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter with 100% schema coverage, and the schema already documents 'subdomain' with an example. The description adds no additional meaning about the parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
It states a specific verb and resource ('Returns the upcoming published events and stops for one business') and clarifies the food-truck case ('these are its locations'). It also implicitly distinguishes itself from siblings by explaining that the offering ids it returns are what start_order accepts, so an agent can tell it apart from get_menu and start_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by tying returned offering ids to start_order and by noting what is excluded (cancelled and test events), but it never explicitly states when to call this versus get_menu or how it complements get_business. Guidance is present but inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches real local businesses on Shortlist Pass (food trucks, restaurants, shops, HOAs and more). Optional filters: a town slug (e.g. "myrtle-beach"), a business category key (e.g. "food_truck", "restaurant", "bakery"), and a free-text query. The query matches every word, in any order, against the business name, headline and type, and also against its active menu items (name, description, tags, category); a business found through its menu carries matched_items (id, name, price, up to 5). For food trucks, matched items come from the full catalog and menu_note says so; what is sold on a given day is per stop. Businesses with a menu match rank first. Returns up to 25 matches, each with its subdomain, which is the identifier the other tools take. Demo and test pages are not included.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | Town slug, e.g. "myrtle-beach" | |
| query | No | Free-text query, e.g. "empanadas" or "buffalo chicken fries"; matched word-by-word against the business and its menu items | |
| category | No | Business category key, e.g. "food_truck" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safe-read profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: menu-match ranking puts menu matches first, results cap at 25, demo/test pages are excluded, matched_items carries up to 5 items with id/name/price, and food-truck matches come from the full catalog with a menu_note caveat plus the per-stop caveat. These are behavioral traits an agent could not infer from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but dense and front-loaded: purpose first, then filters, then matching/ranking behavior, then return shape. Every sentence carries information, though the middle menu-matching clause is run-on and could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the full burden and does so: it explains the result shape (up to 25 matches, subdomain as the cross-tool identifier, matched_items fields) plus edge cases (demo/test exclusion, food-truck catalog vs. per-stop menus). Nothing an agent needs to call this correctly appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real semantics the schema lacks: the query is matched word-by-word in any order against business name, headline, type, and active menu items (name, description, tags, category). That goes meaningfully beyond the per-parameter examples in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ("Searches real local businesses on Shortlist Pass") and enumerates the concrete domain (food trucks, restaurants, shops, HOAs). It also distinguishes this discovery tool from the sibling get_business/get_menu tools by noting the returned subdomain is the identifier the other tools take, so an agent can tell where this fits in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states the optional filter dimensions (town, category, query) and what the query matches, and it links results to downstream tools via the subdomain identifier. It does not, however, name an alternative tool or state when NOT to use this search (e.g., when you already have a subdomain, use get_business instead), so the routing guidance is clear but not exclusionary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a short-lived cart for a customer at one Shortlist business and returns a cart_url on the business's own page, where the customer reviews the order and pays through the business's checkout. Input is offering ids (preferred) or item names, and quantities; prices are not accepted. Order by id from get_menu or the stop's menu. If you only have a name, send it as name: when it is unclear or not on the menu, no cart is made and the reply (error "needs_choice") lists each line as matched, choose (options with ids) or not_found (genuinely close items with ids, or none) with a message to read to your user; ask them and resend with the offering_id. The server prices every line from the menu, applies the business's deals and tax, and returns the resulting quote. For businesses with menu_source "event" (food trucks), event_id is required and identifies one upcoming stop; the offering ids accepted are those listed in that stop's menu in the upcoming-events data, and pickup_time is one of that stop's open pickup_slots. A stop whose menu_status is "not_live" is refused. The cart expires in 30 minutes. This tool does not accept payment details or addresses; payment happens on the business's page at the returned cart_url. In the quote, total_before_tip excludes the optional tip, which the customer chooses on the checkout page; quote.tip.note states the business's suggested percentage. agent.name is recorded on the cart and the order so the business can see which assistant helped.
| Name | Required | Description | Default |
|---|---|---|---|
| agent | No | The name of the assistant placing the order, e.g. { "name": "Claude" }. Optional; defaults to "AI assistant". | |
| items | Yes | ||
| customer | No | Customer details, if provided; pre-filled on the order sheet | |
| event_id | No | A stop id from the upcoming-events results. Required for businesses with menu_source "event". | |
| subdomain | Yes | The business subdomain, e.g. "nitos" | |
| pickup_time | No | One of the stop's open pickup_slots, "HH:MM" 24-hour |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare a non-idempotent, non-destructive open-world write, and the description adds substantial context beyond them: 30-minute cart expiry, prices not accepted, no payment details/addresses, the needs_choice error shape (matched/choose/not_found), not_live refusal, and how agent.name is recorded. This is far richer than the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and return value, but the body is a dense run-on covering error handling, event flow, and tip semantics; every point is relevant yet the lack of structure makes it harder to scan than it needs to be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still explains the returned quote (total_before_tip excludes tip, quote.tip.note suggests a percentage) and cart_url, and covers required prerequisites (event_id, pickup_time) and failure modes. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83% (baseline 3), and the description adds real meaning: offering_id is preferred over name, quantities are supplied not prices, event_id identifies one upcoming stop's menu, pickup_time maps to open pickup_slots, and agent.name is recorded on the order. It goes meaningfully beyond the schema for the trickiest parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('Creates a short-lived cart for a customer at one Shortlist business') and names the concrete return value (cart_url), clearly distinguishing it from siblings like get_menu and get_business.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It routes the agent explicitly: order by offering_id from get_menu or the stop's menu, else send name:. It states the event-business precondition (event_id required, pickup_time must be an open slot, not_live stops refused) and the recovery path on needs_choice, so the when/when-not is fully covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
start_order3 fields changedInput schema / properties / items / items / properties / nameAdded value: +{
+ "description": "Only when you have no id: the item's name as your user said it. If it is unclear the reply is error \"needs_choice\" with options (ids) per line; ask your user and resend with the offering_id.",
+ "maxLength": 120,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / items / items / properties / offering_id / descriptionPrevious value: -"An offering id from the stop's menu (or from the menu results for a fixed business)"New value: +"An offering id from the stop's menu (or from get_menu for a fixed business). Preferred."Input schema / properties / items / items / requiredPrevious value: -[
- "offering_id",
- "quantity"
-]New value: +[
+ "quantity"
+]get_trucks_tonightstart_order2 fields changedInput schema / properties / agent / descriptionPrevious value: -"The name of the assistant placing the order, e.g. { \"name\": \"Claude\" }"New value: +"The name of the assistant placing the order, e.g. { \"name\": \"Claude\" }. Optional; defaults to \"AI assistant\"."Input schema / requiredPrevious value: -[
- "subdomain",
- "items",
- "agent"
-]New value: +[
+ "subdomain",
+ "items"
+]search_businesses1 field changedInput schema / properties / query / descriptionPrevious value: -"Free-text query, e.g. \"empanadas\""New value: +"Free-text query, e.g. \"empanadas\" or \"buffalo chicken fries\"; matched word-by-word against the business and its menu items"search_businesses1 field changedInput schema / properties / query / descriptionPrevious value: -"Free text, e.g. \"empanadas\""New value: +"Free-text query, e.g. \"empanadas\""start_order7 fields changedInput schema / properties / agent / descriptionPrevious value: -"Who you are, e.g. { \"name\": \"Claude\" }"New value: +"The name of the assistant placing the order, e.g. { \"name\": \"Claude\" }"Input schema / properties / customer / descriptionPrevious value: -"What the customer told you; pre-fills the order sheet"New value: +"Customer details, if provided; pre-filled on the order sheet"Input schema / properties / event_id / descriptionPrevious value: -"The stop's id from get_upcoming_events. Required for businesses that sell per stop."New value: +"A stop id from the upcoming-events results. Required for businesses with menu_source \"event\"."Input schema / properties / items / items / properties / offering_id / descriptionPrevious value: -"An id from the stop's menu (or get_menu for a fixed business)"New value: +"An offering id from the stop's menu (or from the menu results for a fixed business)"Input schema / properties / items / items / properties / options / descriptionPrevious value: -"Only the offering's own variant/modifier choices, by value or label"New value: +"The offering's own variant or modifier choices, by option value or label"Input schema / properties / items / items / properties / quantity / descriptionAdded value: +"Whole number, 1 to 100"Input schema / properties / pickup_time / descriptionPrevious value: -"A pickup slot from the stop's pickup_slots, \"HH:MM\" 24h"New value: +"One of the stop's open pickup_slots, \"HH:MM\" 24-hour"start_orderget_businessget_menuget_upcoming_eventssearch_businessesVerified food truck marketplace for Southwest Florida. Search trucks and browse listings.
Booking decisions, scorecards, and self-checks for Florida food vendors over live DBPR data.
Per-restaurant MCP servers: menu, hours, delivery terms; live example below
Read-only US food license data: verified state rules, Florida license lookup, renewal dates.
Add one secure layer between your agents and this server.
