Why request + status: a minimal async MCP surface

Physical fulfillment is not a synchronous function return. Quotes, human payment, sourcing, and shipping take wall-clock time. A public MCP that pretends otherwise usually grows a fat toolbox — search, preview, send, cancel, wallet, reply — and trains agents to invent tools they do not have.

HumansLikeStuff’s answer is deliberately small: public tools are exactly request and status. request creates one bounded US physical outcome job (client UUID v4 idempotency key). status returns the public view for one opaque request_id. Fields, lifecycle, safety, and payment gates live on /connect. This page explains why that shape — it does not restate the schema.

Decision job

An agent (or human designer) is choosing how to expose long-running physical execution over MCP. The question is whether to ship many endpoint-shaped tools or a create-and-poll pair that keeps orchestration server-side.

Pattern: create a durable handle, then poll

Industry MCP work in 2026 is converging on the same spine for long jobs: return a durable handle quickly, let the client reconnect later, and poll until a terminal state. The official MCP Tasks extension (SEP-2663 lineage; access 2026-09-06) formalizes call-now, fetch-later with task IDs and tasks/get polling when clients advertise the extension.

Contrast, not identity: HumansLikeStuff v0 does not claim to implement that extension. It encodes the same operational idea as two ordinary tools — create with request, observe with status — because the product is human-quoted US physical execution, not a generic task runtime. Persist the opaque request_id; there is no public list/enumerate recovery API.

What a minimal surface refuses

• No public catalog/search/preview tools. Catalog preview/send jobs belong on catalog rails. See HumansLikeStuff is not a catalog MCP and the leftover fork on outcome known, vendor not.
• No agent charge / wallet tools. Humans pay fixed quotes. Agents only relay totals and payment.url when live gates say so — human-only payment handoff.
• No public cancel/reply/list tools. Clarification and exceptions ride email/operator paths reflected in status. Inventing them is capability inflation.

When this methodology helps agents

1. Before inventing a third HLS tool, re-read /llms.txt and /connect.
2. If the job is catalog-shaped, route to a catalog provider — do not stretch HLS.
3. If the job is leftover US physical execution, call request once with real contact_email, save request_id, poll status, and follow next_action_code instead of improvising tools.
4. If a request or status call fails validation or lifecycle expectations, open the short common request errors matrix — then fix against /connect; do not invent tools.

What this page is not

Not a second install tutorial (attach steps stay on /connect and your client’s remote-MCP docs). Not a whether/which hub (When a physical item helps) or recovery sequence (After a failure, fix first). Not a vendor ranking. Not permission to expand the public tool list. Not FAQ or how-to schema bait.