Fold Laundry

Schedule residential pickup

book_residential_pickup

Destructive

Schedule a laundry pickup at a residential address. For any non-hotel address in the service area, including Airbnb and other vacation rentals (the rental address is the pickup address). Creates a guest customer account (no password needed — they can claim it later by signing up with the same email). Returns an order code (FOLD-XXXXX) and a Stripe payment-setup URL. The card is NOT charged until after intake. $39.99 order minimum applies. Only ZIPs served by Fold are accepted (see check_service_zip).

Input Schema

Name	Required	Description
`city`	Yes	City, e.g. "Los Angeles"
`email`	Yes	Customer email (used for tracking + receipts)
`line1`	Yes	Street address line 1, e.g. "123 Main St"
`line2`	No	Apartment / suite / unit (optional)
`notes`	No	Optional special instructions about the laundry (e.g. "no fabric softener").
`phone`	Yes	Customer phone in E.164 format (+1XXXXXXXXXX) or US 10-digit
`state`	Yes	US state code, e.g. "CA"
`zipCode`	Yes	5-digit ZIP. Must be in service area (use check_service_zip first).
`lastName`	Yes	Customer last name
`services`	Yes	What services to perform.
`firstName`	Yes	Customer first name
`pickupDate`	Yes	YYYY-MM-DD date for pickup. Must be today or in the future.
`deliveryDate`	No	YYYY-MM-DD delivery date. Defaults to pickup date + 1 day if omitted.
`pickupWindow`	Yes	Pickup time window label from check_service_zip.pickupWindows, e.g. "9-11 AM".
`deliveryNotes`	No	How to find / deliver to the address (gate code, doorman, leave at door, etc.).
`deliveryWindow`	No	Delivery time window label from check_service_zip.deliveryWindows. EVENING ONLY — Fold does not deliver in the morning. Defaults to the evening window if omitted.
`idempotencyKey`	No	OPTIONAL — pass a unique identifier (UUID recommended) to make this call safe to retry. If we have already seen this key, we return the EXISTING order code instead of creating a duplicate. Highly recommended for production agents that may retry on network errors.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations (destructiveHint=true, idempotentHint=false) by disclosing that a guest account is created without a password, that the card is not charged until after intake, the $39.99 minimum, and the exact return payload (FOLD-XXXXX order code plus Stripe setup URL). It also explains the retry-safe idempotencyKey behavior, which materially refines the idempotentHint=false signal.

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?

Front-loaded with purpose and eligibility, then behavior, then return values and cost. Every sentence carries distinct information — no repetition of the title or restatement of schema fields.

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 17-parameter mutation with no output schema, the description supplies the missing pieces an agent needs: what is created (guest account), what is returned (order code + Stripe URL), when money moves, the order minimum, and the service-area gate. Nothing critical to a correct first call is absent.

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 adds real meaning on top by clarifying that zipCode must be a Fold-served ZIP (check_service_zip first) and that pickupWindow labels come from that tool. It does not add guidance for the many optional fields (notes, deliveryNotes, line2), leaving those to 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?

States the specific verb and resource (schedule a laundry pickup) and immediately scopes it to residential/non-hotel addresses, explicitly including Airbnb and vacation rentals. This cleanly separates it from the hotel-pickup siblings without needing the 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?

"For any non-hotel address in the service area" is an explicit when-to-use plus an implicit when-not (hotels), and it routes the agent to check_service_zip for ZIP validation and to pickupWindows/deliveryWindows as the source of window labels. Alternatives and preconditions are both named.

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

All Fold Laundry 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?