WhizzyCommerce

pickup_set_location

Add or change a collection point. Money is integer minor units (cents). Calling this changes nothing: it returns a preview of what would change and a confirmation link. Only the merchant, on that page, can make it happen.

Input Schema

TableJSON Schema

Name	Required	Description
`city`	No	Required for a new place.
`name`	Yes	The place's name as shoppers pick it, like Baixa shop. Names an existing place (case does not matter) to change it, or a new one to add.
`line1`	No	Street and number. Required for a new place.
`line2`	No	Floor, unit, building. Empty clears it.
`phone`	No	A number shoppers can call about their order. Empty clears it.
`slots`	No	Collection windows within a day as HH:MM pairs, replacing the current list. Empty means any time the place is open.
`country`	No	ISO 3166-1 alpha-2, like PT. Required for a new place.
`province`	No	Region or state. Empty clears it.
`renameTo`	No	A new name for an existing place. Up to 60 characters.
`isEnabled`	No	Whether checkout offers it. A place closed for a while is switched off, not removed. New places are on unless said.
`readyTime`	No	The promise shown to shoppers, a sentence like 'after 3pm today'. Empty puts back 'Usually ready in 24 hours'.
`pickupDays`	No	Weekdays collections are accepted, 0 Sunday through 6 Saturday. New places default to Monday to Friday. A place that is on needs at least one.
`postalCode`	No	Empty clears it.
`closedDates`	No	Dates the place is shut whatever the weekday, each YYYY-MM-DD, replacing the current list. Ones that do not read as a date are dropped.
`instructions`	No	Extra lines for the confirmation email: door codes, opening hours. Empty clears it.
`leadTimeHours`	No	Notice needed before the first day offered, in hours: 24 means tomorrow at the earliest. 0 to 1440.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 15, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false, idempotentHint=false and destructiveHint=false but say nothing about the deferred-confirmation mechanic. The description adds genuinely valuable behavior beyond the annotations: the call is non-mutating, it yields a preview and a confirmation link, and execution requires the merchant on that page. The 'Money is integer minor units (cents)' sentence is irrelevant to this schema and reads as template leakage.

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?

Purpose is front-loaded and the confirmation-flow sentences are tight and useful. However, the money/cents sentence serves no parameter here and appears to be copied from a sibling tool, so not every sentence 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?

For a 16-parameter tool with no output schema, the description covers the two things an agent most needs and cannot get elsewhere: that the call is a preview and that a confirmation link gates the real change, which effectively describes the return value. The omission of any parameter-level color is acceptable given 100% schema coverage.

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% across all 16 parameters, so the schema already carries the semantics (required-for-new-place fields, empty-clears behavior, list replacement). The description adds no parameter detail at all, and its one numeric remark about cents refers to no parameter in the schema, 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?

The opening sentence states a specific verb and resource ('Add or change a collection point'), which cleanly separates it from the only close sibling, pickup_remove_location. It does not explicitly name that sibling, but the add/change vs. remove distinction is inferable from the verb alone.

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?

The description supplies essential workflow context: it returns a preview plus a confirmation link and nothing happens until the merchant acts on that page. That tells the agent how the tool is used, but there is no guidance on when to prefer it over pickup_remove_location or how to react to the returned link, so usage remains implied rather than prescribed.

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

All WhizzyCommerce 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?