MCP field guide / Square
// mcp field guide · fintech
A payments surface — an agent can process a payment, issue a refund, or create a payout on a live merchant account. But Square's design makes it the sharpest illustration of a rule this whole guide keeps hitting: it exposes just three generic tools, so a payment and a harmless list arrive under the same name. Classify by the tool name and you're blind.
GUARD FIT · READ SERVICES
PASS-THROUGHList/get payments, orders, customers, catalog, inventory. Low-risk — auto-allow by the resolved service+method.
GUARD FIT · MONEY MOVEMENT
STRONGpayments, refunds, payouts move real, settled money — effectively irreversible. One hallucinated argument from an unrecoverable transfer.
Overall fit: STRONG — for a payments surface, unambiguously so.
Square does not expose one MCP tool per operation. It exposes exactly three generic meta-tools: get_service_info, get_type_info, and make_api_request(service, method, request). All real work — reads and money movement — flows through that single call, where service selects a Square API domain (payments, refunds, payouts, orders, catalog, customers, inventory, invoices…) and method selects the operation.12
Processing a payment and listing a catalog both arrive as make_api_request.
The consequence is decisive for any safety layer: name-based classification is blind here. A guard MUST inspect the service + method arguments — auto-allow *.list/*.get, hard-gate the payments/refunds/payouts writes. (The three tool names are verified; the exact per-service method strings are auto-generated from Square's OpenAPI spec and unverified here — verify via get_service_info at integration time.)
| Tier | Services (via make_api_request) |
|---|---|
| read-only | read ops on payments, orders, customers, catalog, inventory, refunds, payouts, disputes, invoices, locations, merchants (list/get/retrieve/search) |
| mutating | catalog upsert/delete item, customers create/update, orders create/update (draft), inventory adjust counts, invoices create/publish, cards store-on-file, bookings create/update |
| money moves | payments (charge/capture), refunds (issue refund), payouts (move funds to a bank); adjacent: disputes responses, giftcardactivities (load/redeem value), invoices publish (triggers a real charge request) |
Merchant back-office. "How much did we take yesterday and which orders are unfulfilled?" — chained reads across payments/orders/inventory.
Catalog & inventory ops. "Create these 12 products and set stock" — catalog upserts + inventory adjustments (recoverable).
Payments/refunds automation. "Refund order #123" — the sharp edge: real money movement a compliance team needs gated.
For a payments surface this is unambiguously strong, with two nuances specific to Square:
make_api_request, the guard's classification must key on service+method: auto-allow *.list/*.get; hard-gate payments/refunds/payouts writes. A name-only allowlist would block everything or nothing.Honest caveat: a guard cannot make a settled payout or refund reversible — its value is prevention (stop the bad transfer before it fires) plus a provable record, not rollback of money already moved. And reads should pass ungated to keep the agent useful. This is compensation-is-not-undo plus classify by the arguments, not the tool name — Square makes both unavoidable.
ChronoMCP classifies make_api_request by its resolved service+method — holding payments/refunds/payouts for a human while reads flow.
Profiles describe third-party software from its public sources; ChronoMCP is not affiliated with Square/Block. The three tool names and service domains are verified; per-service method strings are auto-generated from Square's OpenAPI spec and vary — verify at integration time. Beta status; surface subject to change. Risk groupings are our classification. Sources current as of Aug 2026. Nothing here is financial or compliance advice.