What the agent does
No repository is attached. Square is an MCP connection. Rush's connector catalog points at the remote server https://mcp.squareup.com/mcp, OAuth, described as orders, catalog, inventory, customers and sales data. Square's own docs say that remote server reads production resources, and that a sandbox seller is a local server started with SANDBOX=true. This page's request names the remote connection, so it reads the production merchant the sign-in covers. Connect it with POST /me/connections as type mcp and auth mode oauth, finish authorize_url in the console as the key's creator, and put the connection's name on the session. The run receives only that connection.
The Square MCP server does not expose one tool per REST method. Its README documents three tools: get_service_info, get_type_info and make_api_request, in that order. The agent starts with get_service_info on orders, refunds, locations and catalog. It does not guess method names. get_type_info then supplies the request shape for the list or search method that service actually publishes. make_api_request runs it. Yesterday's window and the comparison window (the same weekday seven days earlier) are computed in the sandbox and sent as the time filters that tool's schema requires. Locations come from the locations service so each order is tied to a location id rather than mixed into one pile when the merchant has more than one.
Gross sales, refunds, net sales, order count and average ticket are computed from the order and refund payloads, and the report shows the formula. Sales by hour use the order's closed or created time, whichever field the payload uses for when the sale counted, and the file names that field. The ten best-selling items need the catalog service, because an order line carries a catalog object id and the item name lives on the catalog. Each of those figures is repeated for the comparison day, with the difference beside it. A day with no orders is written as a zero day, not omitted, so a closed Monday is visible next to the Monday before.
The prompt is read-only. Square's local server has a DISALLOW_WRITES environment variable; the remote server does not, so the constraint is the prompt plus a pass over the transcript. The agent may call make_api_request only for methods get_type_info described as reads. It does not create orders, issue refunds, or adjust inventory. The file is sales-summary.md, one page: totals, hourly rows, top ten items, and a line on which location ids were included.
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 before make_api_request. Read yesterday's orders, refunds against those orders, locations, and the catalog objects those orders reference. Write sales-summary.md with gross sales, refunds, net sales, order count, average ticket, sales by hour and the 10 best-selling items, each compared with the same weekday one week earlier. Show the formula for net sales. If a day has no orders, say so. Read only: do not create orders, refunds, payments or inventory changes.",
"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
sales-summary.md comes back as a session artifact. The session read returns a url that downloads that file with no key for an hour, and a later read returns a new url. GET /o/{org}/sessions/{id}/artifacts/sales-summary.md with the key also returns it. The final answer in result is a few sentences naming the two dates and the net-sales pair, short enough to sit in the webhook payload.
The transcript lists every make_api_request with the service, method and request body, and the tool_result that came back, matched by call_id. A reviewer picks one hourly bucket, finds the orders whose timestamp fell in it, and checks the sum. They also confirm no write method appears. Square's tool catalog includes payments, refunds and inventory as services the server can call; the absence of those writes is a property of this transcript, which is why it is kept.
Before the summary is posted to a shop channel, someone checks that yesterday was the merchant's local date rather than UTC midnight, that refunds were subtracted once, and that the top ten names came from the catalog rather than raw ids. A wrong date is a follow-up message on the same session, which wakes the parked sandbox, instead of a second cold start.
Run it on every each morning before open
A scheduler you already run (cron, a worker, the thing that opens the shop checklist) POSTs this body to /o/{org}/sessions each morning. The Idempotency-Key is the location id plus the local date. A retry with that key returns the original run; it does not summarize the day twice. Change the prompt's word yesterday if you need a named date after a holiday closure.
PATCH the key with a public https webhook_url. On completion Rush sends run.completed, including session_url, within about 30 seconds, and retries a non-2xx three more times at 2, 4 and 6 minutes with the same webhook-id. Your receiver verifies the signature, downloads sales-summary.md, and drops duplicate webhook-ids. A failed run is run.failed, which should page a person rather than post an empty summary.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
The numbers a shop wants before the door opens are a filter across orders, refunds and the catalog. Doing that in the Square dashboard every morning is a person clicking. Doing it with an access token in a spreadsheet is a token on a laptop. This run's only Square access is the connection named on the request, and the prompt bars writes. Square's remote MCP server is production, so the sandbox is where the reading happens, not a second copy of the merchant account.
Each morning is its own session, so a slow Tuesday does not block Wednesday, up to max_concurrent (default 4) before the API answers 429. The transcript is the audit: which Search-or-list method was called, which location ids, which two dates. When the summary disagrees with the Square dashboard, that is the record you compare, not a recollection of which export was downloaded.
Frequently asked questions
Does the remote Square connection see a sandbox merchant?
Square's documentation says the remote server at https://mcp.squareup.com/mcp reads production, and that sandbox access is a local server with SANDBOX=true. The connector catalog ships the remote URL. Try the prompt against a merchant you can afford to read, or against the local server, before you point the connection at the live seller. This request does not set SANDBOX.
Will it refund an order or change a count?
The prompt forbids create and update calls on orders, refunds, payments and inventory. The server itself can reach those services, which is why the transcript matters: look for make_api_request methods that are not reads. The file is a summary, not a write-back into Square.
How are item names resolved?
Order lines refer to catalog objects. The agent calls get_service_info on the catalog service and then make_api_request for the read that returns the item name. If a line's catalog object is missing, the row keeps the id and says the name was not returned, rather than labeling it Unknown Item.
What timezone is yesterday?
The prompt says yesterday and does not name a zone. Put the merchant's zone in the prompt, and ask for the two window start and end timestamps in the first lines of sales-summary.md, so a reviewer can see whether the cut was local midnight or UTC. Locations from the locations service are the place those timestamps should agree with.