What the agent does
There is no repository. Square is the MCP connection at https://mcp.squareup.com/mcp in Rush's connector catalog. Square's docs say that remote server reads production, while a sandbox merchant is the local server with SANDBOX=true. This request names the remote connection, so the counts it reads are the production seller behind the OAuth sign-in. Connect with POST /me/connections, finish authorize_url as the key's creator, and pass the connection name on the session. The run is given no other connection.
Square's MCP README exposes get_service_info, get_type_info and make_api_request, and a service catalog that includes inventory, catalog, orders and locations. The agent calls get_service_info on inventory, catalog and orders before any make_api_request, then get_type_info for the read methods those services list. Inventory counts and catalog item names are separate reads: a count refers to a catalog object, and the name and the variation come from the catalog service. Orders for the last 30 days supply units sold. The agent uses the location id from the locations service when counts are per location, and it does not add two locations' stock into one row unless the prompt is changed to say so.
For each variation it computes average daily units as units sold in the window divided by 30, and days of stock left as on-hand count divided by that average. An item with no sales in the window is not given an infinite days-left; the row says no sales in 30 days and is kept out of the under-14 list. Items under 14 days of stock are sorted by days left, smallest first. The suggested reorder quantity is enough units to cover 30 days at that average, minus what is on hand, and the file shows that subtraction. Counts are not written back. Square's local server has DISALLOW_WRITES; the remote server does not, so the prompt forbids inventory adjustments and the transcript is how you check.
reorder.md is a table: location, item name, variation, catalog id, on-hand, units sold in 30 days, average daily units, days left, suggested reorder. A short head lists the window timestamps and the location ids included. Items at or above 14 days are omitted from the table and counted in one line, so the file stays a reorder list.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Use the Square connection. Call get_service_info and get_type_info on the inventory, catalog, orders and locations services before make_api_request. Read current inventory counts and orders from the last 30 days. For each item variation compute average daily units sold (units sold divided by 30) and days of stock left. Write reorder.md listing items with under 14 days of stock, sorted by days left, with a suggested reorder quantity for 30 days at that average minus on-hand. Show the arithmetic. If an item had no sales, say no sales in 30 days and leave it off the reorder list. Do not adjust inventory, do not create orders, and do not call any write method.",
"connections": [
"square"
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
reorder.md comes back as an artifact. The url on the session downloads it with no key for an hour; read the session again for a fresh url, or GET /o/{org}/sessions/{id}/artifacts/reorder.md with the key. result summarizes how many variations fell under 14 days and names the location ids, which fits in the webhook result cap of 16 KiB. The table itself is the file.
A reviewer recomputes one row: on-hand from the inventory read, units sold from the orders in the transcript, days left as the quotient, reorder as 30 times the average minus on-hand. They confirm the catalog name matches the id. They confirm make_api_request was not used to adjust counts. Square's service list includes inventory as a service that can change stock; the prompt's value is that the transcript shows only reads.
The file does not place a purchase order. Someone buys from it, or a later message on this session asks for a CSV of the same rows. The sandbox stays parked, with the counts it already fetched, for follow-ups within the idle window of 7 days.
Run it on every weekday inventory check
Each weekday your server POSTs this body. The Idempotency-Key is the date plus the location id, so a retry does not start a second count of the same morning, and two locations are two runs rather than one blended table. The 30-day window and the 14-day threshold are in the prompt; change them there if a category needs a different cover.
Set webhook_url on the API key. run.completed posts session_url within about 30 seconds. Verify the Standard Webhooks signature, download reorder.md, and send it to whoever orders stock. If the run is run.failed, do not reuse yesterday's file without saying it is stale. A 429 from max_concurrent (default 4) means the location waits and retries; it does not mean the count was zero.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
Days of cover is on-hand divided by recent sales, which Square keeps on different services (inventory, orders, catalog). A person can click through those. An access token in a sheet can too, and that token can also adjust counts. This run is a sandbox plus one connection, and the prompt bars write methods. Square's remote server is production, so the read is the live counts, and the sandbox is not a place those counts get edited.
Each row shows the arithmetic, and the transcript shows the reads, so a surprising reorder quantity can be checked against the orders that produced it. Locations stay in separate runs when you key them that way, which keeps one shop's stock from being averaged with another's. Concurrent mornings stop at the key's max_concurrent and then 429.
Frequently asked questions
Will it change on-hand counts in Square?
No. The prompt forbids inventory adjustments and any write method. The local Square server can set DISALLOW_WRITES; the remote server at https://mcp.squareup.com/mcp does not use that variable, so the check is the transcript. Search it for make_api_request calls that are not reads before you order from the file.
Does this hit the Square sandbox?
The catalog connection is the remote server, and Square's docs say remote access is production. Sandbox is a local process with SANDBOX=true. Do not expect this request to read a sandbox merchant. Connect a seller you intend to read, or test the prompt against the local server first.
How is the reorder quantity calculated?
Average daily units are units sold over the last 30 days, divided by 30. Days left are on-hand divided by that average. Suggested reorder is 30 days of that average, minus on-hand. The file shows those three numbers per row. An item with no sales is excluded from the under-14 list and labeled, because days left would otherwise have no value.
What about items stocked at two locations?
Rows keep the location id from the locations and inventory reads. They are not summed across locations unless you change the prompt. Starting one session per location, with the location id in the Idempotency-Key, keeps the reorder lists separate. A single session can still list every location as its own section if you say that in the prompt.