Pinoyshki Bakery

Check an order

check_order

Read-onlyIdempotent

Check a basket against the bakery's ordering rules BEFORE any checkout. 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; same day = only today's counter items, up to 6 full-size, pickup, while open; catering = 3 days' notice for up to 24 full-size or 4 dozen bite-size (pickup), a week ahead (by Saturday) for anything larger, any delivery and custom cakes; delivery within 15 miles on orders over $100 or with a cake of $75 or more. Show the customer the lines and the subtotal, and never promise a date or time the result did not allow.

Input Schema

TableJSON Schema

Name	Required	Description
`zip`	No	Delivery ZIP code (delivery is within 15 miles).
`date`	No	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.
`time`	No	12-hour time like '1:00 pm'. Needed for catering.
`items`	Yes	What to order. Use item names exactly as get_menu or search_menu gave them.
`notes`	No	Optional note for the bakery.
`channel`	No	Optional. 'today' = same day from the counter menu, paid on Toast; 'catering' = ordered ahead, paid on Shopify. Left out, the basket decides.
`utensils`	No	Catering: include utensils. Default true.
`fulfillment`	No	Default pickup. Delivery is catering, week-ahead only.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	True when the order is allowed as asked.
`view`	Yes
`when`	No
`lines`	Yes
`title`	No
`today`	No	Today's date in Seattle, like 'Thursday, September 24'.
`channel`	No
`problems`	Yes
`lane_label`	No
`date_choices`	No	Present when the date asked for could mean either of these; ask the customer which.
`allowed_dates`	No
`allowed_times`	No
`earliest_date`	No
`subtotal_cents`	Yes	Before tax; the checkout page shows the final total.
`delivery_allowed`	No
`allowed_date_labels`	No	allowed_dates with weekdays, like 'Fri Oct 2'.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 25, 2026

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"
+}

First observedSep 25, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint:false, so the description need not restate safety. It adds valuable behavioral context: the exact rules applied (closed Mondays, same-day and catering constraints), the return of problems and available times, and the explicit directive to never promise a date/time the result did not allow. This goes beyond annotations and helps the agent set expectations and act on results correctly.

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 dense but highly structured: it leads with the core purpose and output, then lists the applied rules in a compact block, and closes with actionable guidance for customer interaction. Every sentence adds necessary information for correct tool usage—no filler. The logical flow (purpose → rules → usage instruction) makes it easy to parse even for a complex tool.

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 tool's complexity (8 parameters, intricate business rules), the description is remarkably complete. It specifies what rules are enforced, what the result contains, and how to use the result (show lines/subtotal, never promise disallowed times). With an output schema present, the description does not need to detail return formats. It covers all necessary guidance for an agent to invoke it correctly and interpret the outcome, leaving no critical gaps.

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?

Since schema coverage is 100%, the schema already explains each parameter's format and purpose. The description adds significant semantic value by linking parameters to business rules (e.g., delivery within 15 miles via zip, delivery is week-ahead only, same-day items are always full-size). This clarifies parameter interplay and helps the agent infer correct values (e.g., when to pass 'channel'). It enriches, rather than repeats, the schema information.

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 the exact purpose: 'Check a basket against the bakery's ordering rules BEFORE any checkout.' It also enumerates what it returns (lane, priced lines, subtotal, problems, available dates/times), clearly distinguishing itself from menu-lookup tools (get_menu, search_menu, show_item) and the actual checkout (start_checkout). The 'BEFORE' keyword explicitly positions it as a pre-check step, making its role unambiguous.

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?

The description explicitly directs 'BEFORE any checkout', implying it should be used prior to start_checkout. It also provides detailed business rules that dictate when each lane applies (same-day vs catering), giving the agent context to decide if this tool is appropriate. It does not explicitly name alternatives like 'use get_menu for menu items', but the sibling names and the clear scope make the appropriate use case evident. The instruction to 'show the customer the lines and the subtotal' also guides post-call behavior.

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

All Pinoyshki Bakery tools Inspect

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

Need Help?