Skip to main content
Glama

Pinoyshki Bakery

by com.pinoyshki
OverviewDiscussionsAdmin

Server Details

Browse Pinoyshki Bakery's menu, check an order against its rules, and get the checkout link.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
100.0% over 28 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a distinct purpose: cake_options for custom cakes, get_menu for full menu, search_menu for keyword search, show_item for item details, check_order for basket validation, and start_checkout for payment link. The two-step ordering tools are clearly labeled as sequential, and no overlap causes confusion.

Naming Consistency4/5

Five of six tools follow a verb_noun pattern (check_order, get_menu, search_menu, show_item, start_checkout). Only cake_options deviates as a noun phrase, which is a minor inconsistency in an otherwise predictable scheme.

Tool Count5/5

Six tools are well-scoped for a bakery ordering server, covering menu browsing, custom cake information, order validation, and checkout link generation without redundancy. Each tool earns its place.

Completeness4/5

The surface covers menu display, search, item details, custom cake options, order checking, and checkout link generation, which are the core workflows. Minor gaps exist, such as no explicit tool for order modification or business information retrieval, but these are workable around.

Available Tools

6 tools
cake_optionsDesign a custom cakeA
Read-onlyIdempotent
Inspect

Custom decorated cakes for any occasion (a birthday, anniversary, graduation, baby shower, retirement, holiday or office party): the cake sizes and prices (with candles and a card), flavors, the earliest day, what the bakery does not make, photos of past cakes, and the design questions to settle. A cake is ordered through check_order with its cake details.

NameRequiredDescriptionDefault
guestsNoOptional: how many people, to suggest a size.

Output Schema

NameRequiredDescription
nameNo
noteNo
viewYes
sizesYes
titleNo
photosNo
flavorsNo
not_offeredNo
allowed_datesNo
earliest_dateNo
flavor_detailsNo

TDQS

A3.9/5.0
Behavior4/5

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

Annotations declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses the content the tool returns (sizes/prices with candles and card, flavors, earliest day, exclusions, photos, design questions) and the crucial behavioral fact that ordering is a separate step via check_order. A minor gap: it doesn't explicitly say the output is informational rather than action-taking, but the combination of annotations and content list makes it clear.

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

Conciseness3/5

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

The first sentence is a long comma-separated list that is somewhat dense and front-loaded with the resource but not the core action. It could be tightened; however, every item in the list corresponds to distinct content the tool provides, so most of it earns its place. The second sentence is an effective redirect sentence.

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 an output schema present, the description needn't explain return values, and it doesn't (though it does list content categories). Annotations cover safety. The agent knows what the tool provides, that ordering goes elsewhere, and that 'guests' is optional. One small gap: it doesn't state whether the tool is a static reference or dynamically personalized by the guests parameter, but that's a minor omission given full schema coverage and a simple read-only tool.

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 the single optional 'guests' parameter is fully documented in the schema. The description does not mention 'guests' directly but says sizes are covered and '(with candles and a card)'. Baseline 3 for full schema coverage; slight uplift because the description lists that sizes/prices are returned, which helps the agent know why guests matters. Still doesn't add syntax beyond the schema.

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 the resource (custom decorated cakes) and enumerates what it covers: sizes, prices, flavors, lead time, exclusions, photos, design questions. It's clearly a reference/consultation tool, not an ordering tool. However, the core action verb is vague ('options' serves as a noun list) and the title 'Design a custom cake' is somewhat misleading since the actual ordering is routed to check_order.

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?

Explicitly says 'A cake is ordered through check_order with its cake details,' which is strong routing to the sibling. It also implies when to use (any occasion, to explore options) but does not state when NOT to use it (e.g., for non-cake items) or which sibling handles general menu queries.

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

check_orderCheck an orderA
Read-onlyIdempotent
Inspect

Step 1 of 2 to order: checks a basket of one or more menu items against the bakery's ordering rules. Saves nothing and makes no link. Returns the lane (same day on Toast, or catering on Shopify), the priced lines, the subtotal, any problems, and the dates and times the bakery can serve. Rules it applies: closed Mondays and blocked dates; Toast = only counter-menu items, up to 6 piroshki and pinoyshki (other items not limited), pickup, today while open or scheduled up to 14 days ahead with a time in that day's hours; catering = 3 days' notice for up to 24 full-size or 4 dozen bite-size piroshki and pinoyshki (other items not limited, pickup), a week ahead (by Saturday) for more, any delivery and custom cakes; delivery within 15 miles on orders over $100 or with a cake of $75 or more. The result may list 'Still needed' questions: combo_offer (a combo, in combo hours), sold_out_choice (what to do if a piroshki is sold out, for a later day) and cake_details (what is still undecided about a custom cake).

NameRequiredDescriptionDefault
zipNoDelivery ZIP code (delivery is within 15 miles).
dateNoThe date as YYYY-MM-DD ('today' also works). Work it out from the customer's words using today's date in Seattle (Pacific time). If their words could mean two dates, like 'next Friday' said earlier in the same week, ask them which before calling. Needed for catering and for a Toast pickup on a later day.
timeNo12-hour time like '1:00 pm'. Needed for catering and for a Toast pickup on a later day.
itemsYesWhat to order. Use item names exactly as get_menu or search_menu gave them.
notesNoOptional note for the bakery.
channelNoOptional. 'today' = the counter menu on Toast: same day, or a scheduled pickup up to 14 days ahead (up to 6 full-size, pickup only, paid on Toast); 'catering' = ordered 3 or more days ahead, paid on Shopify. Left out, the basket and date decide: catering is preferred from 3 days out when every item is on the catering menu.
utensilsNoCatering: include utensils. Default true.
staff_tipNoToast orders: the tip for the bakery staff in whole dollars, shared by the staff who bake, pack and hand over the order. 0 (the default) unless the customer picks one; offer $1, $3 or $5 or any whole amount.
fulfillmentNoDefault pickup. Delivery is catering, week-ahead only.

Output Schema

NameRequiredDescription
okYesTrue when the order is allowed as asked.
viewYes
whenNo
linesYes
titleNo
todayNoToday's date in Seattle, like 'Thursday, September 24'.
channelNo
problemsYes
tip_offerNoToast orders: the staff tip choices in whole dollars and the suggested one.
lane_labelNo
date_choicesNoPresent when the date asked for could mean either of these; ask the customer which.
allowed_datesNo
allowed_timesNo
earliest_dateNo
subtotal_centsYesBefore tax, with the staff tip; the checkout page shows the final total.
staff_tip_centsNoThe tip for the bakery staff, 0 when none.
delivery_allowedNo
allowed_date_labelsNoallowed_dates with weekdays, like 'Fri Oct 2'.

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent/non-destructive annotations by disclosing the actual rules engine: closed Mondays, quantity caps, notice windows, delivery radius, and the 'Still needed' questions the result may raise. That rule context is not derivable from annotations and materially changes how the agent plans a call.

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

Conciseness3/5

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

The lead sentence is well front-loaded, but the rules dump is a single sprawling sentence that repeats constraints already documented in the schema (combo hours, 14-day window, 15-mile delivery). It is dense rather than wasteful, but the duplication costs it.

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 a 9-parameter tool with two lanes and conditional branch rules, the description supplies the decision logic, sequencing and the semantics of the 'Still needed' responses; with an output schema present it need not spell out return formatting. Nothing an agent needs to call it correctly 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 the baseline is 3, but the description adds genuine meaning by linking behavior to parameters: the combo_offer, sold_out_choice and cake_details questions it may return map directly onto the combo, if_unavailable and cake inputs. It explains why those fields exist rather than merely restating them.

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?

States a specific verb (checks) and resource (a basket of one or more menu items), and positions itself as 'Step 1 of 2 to order', which cleanly distinguishes it from the step-2 sibling start_checkout. An agent can tell exactly what this does and where it sits in the flow without opening any schema.

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?

Explicitly frames the ordering sequence ('Step 1 of 2'), states the key non-action ('Saves nothing and makes no link'), and names the conditions that select a lane (same-day Toast vs catering Shopify). This is enough for an agent to know when to call it and what it must do next.

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

get_menuBrowse the Pinoyshki menuA
Read-onlyIdempotent
Inspect

Pinoyshki Bakery's menu with prices and photos, from the bakery's live data. lane 'today' is today's counter menu (what can be ordered on Toast for pickup today or a later day; sold-out items are left off); lane 'catering' is the catalogue for ordering 3 days to a week ahead, with sizes (full-size, bite-size dozen, half dozen).

NameRequiredDescriptionDefault
laneNoDefault 'today'.
sectionNoOptional section filter, like 'Pastries' or 'Vegan'. 'Piroshki' and 'Pinoyshki' both show the whole family (pinoyshki are piroshki with Filipino fillings); customers asking for either nearly always want both.
only_this_familyNoOnly when the customer asked for just piroshki or just pinoyshki: keep the section filter to that word.

Output Schema

NameRequiredDescription
laneNo
noteNo
viewYes
hoursNo
titleYes
sectionsYes
closed_weekdaysNo

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: data is live, sold-out items are omitted from the 'today' lane, and catering carries size variants.

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?

A single dense sentence with the resource and data source front-loaded, followed by lane semantics. Every clause carries information, though the parenthetical detail in the lane clause makes it slightly heavy.

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?

An output schema exists, so return values need no description, and annotations cover the safety profile. The description closes the remaining gaps (lane selection, section filtering, family merging), leaving only sibling-level routing unaddressed.

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 the baseline is 3. The description goes further by explaining what each lane actually returns and the rationale for the Piroshki/Pinoyshki family merge, adding meaning beyond the schema's terse field descriptions (though only_this_family guidance largely restates the schema).

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+resource ('Pinoyshki Bakery's menu with prices and photos, from the bakery's live data') and defines the two lanes precisely. It is clear on its own, but does not explicitly differentiate itself from siblings like search_menu or show_item, 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 Guidelines4/5

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

Gives explicit when-to-use conditions for the two lanes: 'today' for counter pickup today or later, 'catering' for ordering 3 days to a week ahead. No sibling alternatives or exclusions are named, so it stops 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.

search_menuSearch the Pinoyshki menuA
Read-onlyIdempotent
Inspect

Find menu items by a few words (a filling, a pastry, 'vegan', 'ube'), across today's counter menu and catering. Each match comes with its price, a short description, a photo URL and the allergens the bakery lists. Custom cakes are not in it; they are designed with cake_options.

NameRequiredDescriptionDefault
laneNoDefault 'all'.
queryYesA few words to look for.

Output Schema

NameRequiredDescription
laneNo
noteNo
viewYes
hoursNo
titleYes
sectionsYes
closed_weekdaysNo

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds behavioral context beyond that: what each match includes (price, short description, photo URL, listed allergens) and the categorical exclusion of custom cakes, which changes how an agent interprets results.

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?

Two sentences, no filler, with the core action and scope front-loaded and the exclusion routed to the sibling in the second sentence. Every clause earns its place.

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?

Complete for a small two-parameter read tool: the action, scope, result contents, and the custom-cake exclusion are all present, and an output schema exists so return values needn't be detailed. Minor gap is that the lane parameter isn't echoed in prose, though the schema fully documents it.

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 the baseline is 3. The description goes beyond the schema by giving concrete example query terms (filling, pastry, 'vegan', 'ube'), which sharpens how to construct the free-text query and complements the enum-documented lane parameter.

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?

States a specific verb (find) and resource (menu items) plus the scope: today's counter menu and catering. It explicitly names the sibling cake_options as out of scope, so an agent can distinguish it from cake_options and get_menu without opening a schema.

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 context ('a few words – a filling, a pastry, vegan, ube') and an explicit exclusion with the alternative named ('Custom cakes are not in it; they are designed with cake_options'). It doesn't contrast against get_menu or show_item, but the routing to the key sibling is explicit.

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

show_itemShow a menu itemB
Read-onlyIdempotent
Inspect

One menu item with its photo, description, sizes and prices, and the allergens the bakery lists. The photo is included in the result.

NameRequiredDescriptionDefault
laneNoOptional: only this menu.
nameYesThe item's name.

Output Schema

NameRequiredDescription
alsoNo
itemYes
viewYes

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful fact that the photo is returned in the result, but with an output schema present it carries little additional behavioral burden.

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?

Two short sentences with no filler. It front-loads the core resource and follows with the payload contents, so an agent can skim it in one pass.

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 annotations covering safety and an output schema covering the return shape, the description only needs to establish scope, which it does. The one real gap is routing to sibling tools and behavior on a failed lookup, but for a low-complexity two-parameter read tool this is close to complete.

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 both the name field and the lane enum are already documented in the schema. The description adds no lookup semantics (e.g. exact match vs partial, case sensitivity, behavior when the name is not found), 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 (show) and resource (one menu item) and enumerates what the item carries: photo, description, sizes/prices, allergens. It never distinguishes itself from the sibling get_menu or search_menu, so an agent cannot tell from the text alone why it should pick this over those.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no named alternative. The lane enum implies a menu-selection context, but the description never says to use this for a single named item versus get_menu or search_menu for browsing.

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

start_checkoutGet the checkout linkA
Destructive
Inspect

Step 2 of 2 to order, for a basket check_order has allowed: checks the same order again and returns the link the customer pays on, on the bakery's own domain. The same order sent again within 15 minutes gets the same link back; an empty basket gets no link. Toast: a Pinoyshki page that shows the order while it finishes the cart on Toast (with the staff tip and the pickup day and time), then takes them to Toast's checkout (good for a week; opened after its pickup time it remakes the cart for the next pickup time). Catering: it checks the order again and opens Shopify's checkout with the date, time and pickup or delivery filled in (good for a week). No payment happens here. If a rule is broken it returns the problems instead of a link.

NameRequiredDescriptionDefault
zipNoDelivery ZIP code (delivery is within 15 miles).
dateNoThe date as YYYY-MM-DD ('today' also works). Work it out from the customer's words using today's date in Seattle (Pacific time). If their words could mean two dates, like 'next Friday' said earlier in the same week, ask them which before calling. Needed for catering and for a Toast pickup on a later day.
timeNo12-hour time like '1:00 pm'. Needed for catering and for a Toast pickup on a later day.
itemsYesWhat to order. Use item names exactly as get_menu or search_menu gave them.
notesNoOptional note for the bakery.
channelNoOptional. 'today' = the counter menu on Toast: same day, or a scheduled pickup up to 14 days ahead (up to 6 full-size, pickup only, paid on Toast); 'catering' = ordered 3 or more days ahead, paid on Shopify. Left out, the basket and date decide: catering is preferred from 3 days out when every item is on the catering menu.
utensilsNoCatering: include utensils. Default true.
staff_tipNoToast orders: the tip for the bakery staff in whole dollars, shared by the staff who bake, pack and hand over the order. 0 (the default) unless the customer picks one; offer $1, $3 or $5 or any whole amount.
fulfillmentNoDefault pickup. Delivery is catering, week-ahead only.
customer_nameNoOptional: the name the order is for.
customer_emailNoOptional: an email for the bakery.
customer_phoneNoOptional: a phone number for the bakery.

Output Schema

NameRequiredDescription
okYesTrue when the order is allowed as asked.
urlNoThe link the customer opens to pay. Give it to them as-is.
viewYes
whenNo
linesYes
titleNo
todayNoToday's date in Seattle, like 'Thursday, September 24'.
buttonNo
channelNo
pays_onNo
problemsNo
tip_offerNoToast orders: the staff tip choices in whole dollars and the suggested one.
lane_labelNo
date_choicesNoPresent when the date asked for could mean either of these; ask the customer which.
allowed_datesNo
allowed_timesNo
earliest_dateNo
subtotal_centsYesBefore tax, with the staff tip; the checkout page shows the final total.
staff_tip_centsNoThe tip for the bakery staff, 0 when none.
delivery_allowedNo
allowed_date_labelsNoallowed_dates with weekdays, like 'Fri Oct 2'.

TDQS

A4.4/5.0
Behavior5/5

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

Adds substantial behavior beyond annotations: same-order idempotency within 15 minutes, empty-basket behavior, Toast vs. Catering flows, link validity windows, staff tip and pickup-time handling, no payment, and rule-violation error returns. With annotations already covering the safety profile, this is rich, useful context.

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-loads the key purpose and prerequisite, and every sentence carries useful information. It is long, but the length is justified by the tool's complexity and branching fulfillment flows.

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?

Given the rich input schema and the existence of an output schema, the description covers the essential behavior an agent needs: prerequisite, checkout flows, idempotency, error behavior, and payment boundary. Nothing critical 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 description coverage is 100%, so parameter meaning is already well documented. The description adds scenario context for channel choices but does not add syntax or constraints beyond the schema, so baseline 3 is appropriate.

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?

States a specific verb and resource—checks the allowed basket again and returns the checkout link—and frames itself as step 2 of 2 relative to check_order. An agent can distinguish it from check_order, get_menu, and search_menu without opening another schema.

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?

Explicitly says this is for a basket that check_order has already allowed, making the prerequisite clear. It does not add explicit when-not-to-use guidance beyond that prerequisite, but the usage context is strong.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updates
    • Changedcake_options1 field changed
      • addedOutput schema / properties / flavor_details
        Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • Changedcheck_order1 field changed
      • changedInput schema / properties / items / items / properties / cake / properties / flavor / description
        Previous value: -"Vanilla, Chocolate, Red Velvet, or the custom flavor asked for (an ube cake is a custom request)."New value: +"One of cake_options' premade flavors, or the custom flavor asked for (vanilla, red velvet, ube...), which goes to the bakery to confirm."
    • Changedstart_checkout1 field changed
      • changedInput schema / properties / items / items / properties / cake / properties / flavor / description
        Previous value: -"Vanilla, Chocolate, Red Velvet, or the custom flavor asked for (an ube cake is a custom request)."New value: +"One of cake_options' premade flavors, or the custom flavor asked for (vanilla, red velvet, ube...), which goes to the bakery to confirm."
  2. 2 tool updates
    • Changedcheck_order1 field changed
      • changedInput schema / properties / items / items / properties / cake / properties / flavor / description
        Previous value: -"Vanilla, Chocolate, Red Velvet, Ube, or the custom flavor asked for."New value: +"Vanilla, Chocolate, Red Velvet, or the custom flavor asked for (an ube cake is a custom request)."
    • Changedstart_checkout1 field changed
      • changedInput schema / properties / items / items / properties / cake / properties / flavor / description
        Previous value: -"Vanilla, Chocolate, Red Velvet, Ube, or the custom flavor asked for."New value: +"Vanilla, Chocolate, Red Velvet, or the custom flavor asked for (an ube cake is a custom request)."
  3. 1 tool update
    • Changedstart_checkout5 fields changed
      • addedOutput schema / if
        Added value: +{
+  "properties": {
+    "view": {
+      "const": "checkout"
+    }
+  }
+}
      • removedOutput schema / properties / view / const
        Removed value: -"checkout"
      • addedOutput schema / properties / view / enum
        Added value: +[
+  "checkout",
+  "quote"
+]
      • changedOutput schema / required
        Previous value: -[
-  "view",
-  "ok",
-  "lines",
-  "subtotal_cents",
-  "url"
-]New value: +[
+  "view",
+  "ok",
+  "lines",
+  "subtotal_cents"
+]
      • addedOutput schema / then
        Added value: +{
+  "required": [
+    "url"
+  ]
+}
  4. 2 tool updates
    • Changedcheck_order1 field changed
      • changedInput schema / properties / items / items / properties / cake / properties / card / description
        Previous value: -"A birthday card."New value: +"A card to go with the cake."
    • Changedstart_checkout1 field changed
      • changedInput schema / properties / items / items / properties / cake / properties / card / description
        Previous value: -"A birthday card."New value: +"A card to go with the cake."
  5. 2 tool updates
    • Changedcheck_order1 field changed
      • changedInput schema / properties / items / items / properties / cake / properties / recipient / description
        Previous value: -"Who it is for, with their age."New value: +"Who it is for (with their age, for a birthday)."
    • Changedstart_checkout1 field changed
      • changedInput schema / properties / items / items / properties / cake / properties / recipient / description
        Previous value: -"Who it is for, with their age."New value: +"Who it is for (with their age, for a birthday)."
  6. 4 tool updates
    • Addedcake_options
    • Changedcheck_order6 fields changed
      • addedInput schema / properties / items / items / properties / cake
        Added value: +{
+  "additionalProperties": false,
+  "description": "Only on the decorated cake (see cake_options): what was decided with the customer. Leave out what is not decided yet.",
+  "properties": {
+    "allergens": {
+      "description": "Allergies or dietary needs, or 'none'.",
+      "type": "string"
+    },
+    "candles": {
+      "type": "boolean"
+    },
+    "card": {
+      "description": "A birthday card.",
+      "type": "boolean"
+    },
+    "design": {
+      "description": "The design concept the customer agreed to.",
+      "type": "string"
+    },
+    "flavor": {
+      "description": "Vanilla, Chocolate, Red Velvet, Ube, or the custom flavor asked for.",
+      "type": "string"
+    },
+    "guests": {
+      "description": "How many people; picks the size.",
+      "minimum": 1,
+      "type": "integer"
+    },
+    "inscription": {
+      "description": "What it says, or 'none'.",
+      "type": "string"
+    },
+    "occasion": {
+      "type": "string"
+    },
+    "recipient": {
+      "description": "Who it is for, with their age.",
+      "type": "string"
+    },
+    "size": {
+      "description": "A size from cake_options, like '10-15'.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
      • addedInput schema / properties / staff_tip
        Added value: +{
+  "description": "Toast orders: the tip for the bakery staff in whole dollars, shared by the staff who bake, pack and hand over the order. 0 (the default) unless the customer picks one; offer $1, $3 or $5 or any whole amount.",
+  "maximum": 50,
+  "minimum": 0,
+  "type": "integer"
+}
      • addedOutput schema / properties / lines / items / properties / cake
        Added value: +{
+  "description": "The cake's flavor, message and design, in words, or empty.",
+  "type": "string"
+}
      • addedOutput schema / properties / staff_tip_cents
        Added value: +{
+  "description": "The tip for the bakery staff, 0 when none.",
+  "type": "integer"
+}
      • changedOutput schema / properties / subtotal_cents / description
        Previous value: -"Before tax; the checkout page shows the final total."New value: +"Before tax, with the staff tip; the checkout page shows the final total."
      • addedOutput schema / properties / tip_offer
        Added value: +{
+  "description": "Toast orders: the staff tip choices in whole dollars and the suggested one.",
+  "type": "object"
+}
    • Changedget_menu2 fields changed
      • addedInput schema / properties / only_this_family
        Added value: +{
+  "description": "Only when the customer asked for just piroshki or just pinoyshki: keep the section filter to that word.",
+  "type": "boolean"
+}
      • changedInput schema / properties / section / description
        Previous value: -"Optional section filter, like 'Pastries' or 'Piroshki'."New value: +"Optional section filter, like 'Pastries' or 'Vegan'. 'Piroshki' and 'Pinoyshki' both show the whole family (pinoyshki are piroshki with Filipino fillings); customers asking for either nearly always want both."
    • Changedstart_checkout6 fields changed
      • addedInput schema / properties / items / items / properties / cake
        Added value: +{
+  "additionalProperties": false,
+  "description": "Only on the decorated cake (see cake_options): what was decided with the customer. Leave out what is not decided yet.",
+  "properties": {
+    "allergens": {
+      "description": "Allergies or dietary needs, or 'none'.",
+      "type": "string"
+    },
+    "candles": {
+      "type": "boolean"
+    },
+    "card": {
+      "description": "A birthday card.",
+      "type": "boolean"
+    },
+    "design": {
+      "description": "The design concept the customer agreed to.",
+      "type": "string"
+    },
+    "flavor": {
+      "description": "Vanilla, Chocolate, Red Velvet, Ube, or the custom flavor asked for.",
+      "type": "string"
+    },
+    "guests": {
+      "description": "How many people; picks the size.",
+      "minimum": 1,
+      "type": "integer"
+    },
+    "inscription": {
+      "description": "What it says, or 'none'.",
+      "type": "string"
+    },
+    "occasion": {
+      "type": "string"
+    },
+    "recipient": {
+      "description": "Who it is for, with their age.",
+      "type": "string"
+    },
+    "size": {
+      "description": "A size from cake_options, like '10-15'.",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
      • addedInput schema / properties / staff_tip
        Added value: +{
+  "description": "Toast orders: the tip for the bakery staff in whole dollars, shared by the staff who bake, pack and hand over the order. 0 (the default) unless the customer picks one; offer $1, $3 or $5 or any whole amount.",
+  "maximum": 50,
+  "minimum": 0,
+  "type": "integer"
+}
      • addedOutput schema / properties / lines / items / properties / cake
        Added value: +{
+  "description": "The cake's flavor, message and design, in words, or empty.",
+  "type": "string"
+}
      • addedOutput schema / properties / staff_tip_cents
        Added value: +{
+  "description": "The tip for the bakery staff, 0 when none.",
+  "type": "integer"
+}
      • changedOutput schema / properties / subtotal_cents / description
        Previous value: -"Before tax; the checkout page shows the final total."New value: +"Before tax, with the staff tip; the checkout page shows the final total."
      • addedOutput schema / properties / tip_offer
        Added value: +{
+  "description": "Toast orders: the staff tip choices in whole dollars and the suggested one.",
+  "type": "object"
+}
  7. 2 tool updates
    • Changedcheck_order3 fields changed
      • addedInput schema / properties / items / items / properties / combo
        Added value: +{
+  "description": "Toast orders, piroshki and pinoyshki, when the pickup time is in combo hours (Tue to Fri, 11 am to 4 pm): 'small' = fries + a 12oz drink, 'large' = large fries, borscht + a drink, 'none' = the customer said no. check_order offers it (combo_offer) with each item's prices and drinks.",
+  "enum": [
+    "small",
+    "large",
+    "none"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / items / items / properties / combo_drink
        Added value: +{
+  "description": "The combo's drink, as check_order listed it (like '12oz Coke' or 'Small Juice'). Default: any 12oz soda.",
+  "type": "string"
+}
      • addedOutput schema / properties / lines / items / properties / combo
        Added value: +{
+  "description": "The line's combo upgrade, in words, or empty.",
+  "type": "string"
+}
    • Changedstart_checkout3 fields changed
      • addedInput schema / properties / items / items / properties / combo
        Added value: +{
+  "description": "Toast orders, piroshki and pinoyshki, when the pickup time is in combo hours (Tue to Fri, 11 am to 4 pm): 'small' = fries + a 12oz drink, 'large' = large fries, borscht + a drink, 'none' = the customer said no. check_order offers it (combo_offer) with each item's prices and drinks.",
+  "enum": [
+    "small",
+    "large",
+    "none"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / items / items / properties / combo_drink
        Added value: +{
+  "description": "The combo's drink, as check_order listed it (like '12oz Coke' or 'Small Juice'). Default: any 12oz soda.",
+  "type": "string"
+}
      • addedOutput schema / properties / lines / items / properties / combo
        Added value: +{
+  "description": "The line's combo upgrade, in words, or empty.",
+  "type": "string"
+}
  8. 2 tool updates
    • Changedcheck_order6 fields changed
      • changedInput schema / properties / channel / description
        Previous value: -"Optional. 'today' = same day from the counter menu, paid on Toast; 'catering' = ordered ahead, paid on Shopify. Left out, the basket decides."New value: +"Optional. 'today' = the counter menu on Toast: same day, or a scheduled pickup up to 14 days ahead (up to 6 full-size, pickup only, paid on Toast); 'catering' = ordered 3 or more days ahead, paid on Shopify. Left out, the basket and date decide: catering is preferred from 3 days out when every item is on the catering menu."
      • changedInput schema / properties / date / description
        Previous value: -"The date as YYYY-MM-DD ('today' also works). Work it out from the customer's words using today's date in Seattle (Pacific time). If their words could mean two dates, like 'next Friday' said earlier in the same week, ask them which before calling. Needed for catering."New value: +"The date as YYYY-MM-DD ('today' also works). Work it out from the customer's words using today's date in Seattle (Pacific time). If their words could mean two dates, like 'next Friday' said earlier in the same week, ask them which before calling. Needed for catering and for a Toast pickup on a later day."
      • addedInput schema / properties / items / items / properties / backups
        Added value: +{
+  "description": "Toast orders, with if_unavailable 'closest': up to 3 counter-menu piroshki or pinoyshki the customer would take instead, in order of preference.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 3,
+  "type": "array"
+}
      • addedInput schema / properties / items / items / properties / if_unavailable
        Added value: +{
+  "description": "Toast orders, piroshki and pinoyshki only: what the bakery does if this one is sold out when the order is made. 'closest' (default) swaps in the closest piroshki, 'remove' leaves it out, 'cancel' cancels the order. Worth asking for a scheduled day, since the counter menu changes.",
+  "enum": [
+    "closest",
+    "remove",
+    "cancel"
+  ],
+  "type": "string"
+}
      • changedInput schema / properties / time / description
        Previous value: -"12-hour time like '1:00 pm'. Needed for catering."New value: +"12-hour time like '1:00 pm'. Needed for catering and for a Toast pickup on a later day."
      • addedOutput schema / properties / lines / items / properties / if_unavailable
        Added value: +{
+  "description": "The line's backup choice on Toast, in words.",
+  "type": "string"
+}
    • Changedstart_checkout6 fields changed
      • changedInput schema / properties / channel / description
        Previous value: -"Optional. 'today' = same day from the counter menu, paid on Toast; 'catering' = ordered ahead, paid on Shopify. Left out, the basket decides."New value: +"Optional. 'today' = the counter menu on Toast: same day, or a scheduled pickup up to 14 days ahead (up to 6 full-size, pickup only, paid on Toast); 'catering' = ordered 3 or more days ahead, paid on Shopify. Left out, the basket and date decide: catering is preferred from 3 days out when every item is on the catering menu."
      • changedInput schema / properties / date / description
        Previous value: -"The date as YYYY-MM-DD ('today' also works). Work it out from the customer's words using today's date in Seattle (Pacific time). If their words could mean two dates, like 'next Friday' said earlier in the same week, ask them which before calling. Needed for catering."New value: +"The date as YYYY-MM-DD ('today' also works). Work it out from the customer's words using today's date in Seattle (Pacific time). If their words could mean two dates, like 'next Friday' said earlier in the same week, ask them which before calling. Needed for catering and for a Toast pickup on a later day."
      • addedInput schema / properties / items / items / properties / backups
        Added value: +{
+  "description": "Toast orders, with if_unavailable 'closest': up to 3 counter-menu piroshki or pinoyshki the customer would take instead, in order of preference.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 3,
+  "type": "array"
+}
      • addedInput schema / properties / items / items / properties / if_unavailable
        Added value: +{
+  "description": "Toast orders, piroshki and pinoyshki only: what the bakery does if this one is sold out when the order is made. 'closest' (default) swaps in the closest piroshki, 'remove' leaves it out, 'cancel' cancels the order. Worth asking for a scheduled day, since the counter menu changes.",
+  "enum": [
+    "closest",
+    "remove",
+    "cancel"
+  ],
+  "type": "string"
+}
      • changedInput schema / properties / time / description
        Previous value: -"12-hour time like '1:00 pm'. Needed for catering."New value: +"12-hour time like '1:00 pm'. Needed for catering and for a Toast pickup on a later day."
      • addedOutput schema / properties / lines / items / properties / if_unavailable
        Added value: +{
+  "description": "The line's backup choice on Toast, in words.",
+  "type": "string"
+}
  9. 2 tool updates
    • Changedcheck_order4 fields changed
      • changedInput schema / properties / date / description
        Previous value: -"YYYY-MM-DD, 'today', or plain words like 'next Friday'. Needed for catering."New value: +"The date as YYYY-MM-DD ('today' also works). Work it out from the customer's words using today's date in Seattle (Pacific time). If their words could mean two dates, like 'next Friday' said earlier in the same week, ask them which before calling. Needed for catering."
      • addedOutput schema / properties / allowed_date_labels
        Added value: +{
+  "description": "allowed_dates with weekdays, like 'Fri Oct 2'.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • addedOutput schema / properties / date_choices
        Added value: +{
+  "description": "Present when the date asked for could mean either of these; ask the customer which.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • addedOutput schema / properties / today
        Added value: +{
+  "description": "Today's date in Seattle, like 'Thursday, September 24'.",
+  "type": "string"
+}
    • Changedstart_checkout4 fields changed
      • changedInput schema / properties / date / description
        Previous value: -"YYYY-MM-DD, 'today', or plain words like 'next Friday'. Needed for catering."New value: +"The date as YYYY-MM-DD ('today' also works). Work it out from the customer's words using today's date in Seattle (Pacific time). If their words could mean two dates, like 'next Friday' said earlier in the same week, ask them which before calling. Needed for catering."
      • addedOutput schema / properties / allowed_date_labels
        Added value: +{
+  "description": "allowed_dates with weekdays, like 'Fri Oct 2'.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • addedOutput schema / properties / date_choices
        Added value: +{
+  "description": "Present when the date asked for could mean either of these; ask the customer which.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
      • addedOutput schema / properties / today
        Added value: +{
+  "description": "Today's date in Seattle, like 'Thursday, September 24'.",
+  "type": "string"
+}
  10. 5 tool updates
    • First observedcheck_order
    • First observedget_menu
    • First observedsearch_menu
    • First observedshow_item
    • First observedstart_checkout

Related MCP Connectors

Related MCP Servers

  • ijburgeats-mcp

    jspuij
    A
    license
    A
    quality
    C
    maintenance
    Enables an AI assistant to browse restaurants and menus, manage a cart, reorder past orders, review checkout details, and place food delivery orders, returning a payment link to complete payment.
    13
    MIT

  • 小葵 × 麦当劳中国 MCP

    AriaEternity
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables ChatGPT to query stores, menus, meal details, and coupons, calculate official prices, prepare orders for per-order owner approval, submit approved intents, and check order status with duplicate-submission and UNKNOWN safeguards.
    2
    MIT

  • mcd-order

    ruixingshi
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables ordering from McDonald's through an interactive UI: selecting stores, browsing menus, managing a cart, applying coupons, placing orders, paying, and tracking orders.
    19 npm
    MIT
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