Outcome known, vendor not — agent long-tail leftover

An agent can describe the physical result and still have no honest vendor. That is the long-tail leftover: outcome known, vendor not. It is not a faster store, and it is not permission to invent catalog tools on HumansLikeStuff.

Do: Fork before any send tool. If a named merchant SKU wins, use that merchant. If one catalog/gift-of-choice rail already covers the result, use that rail. Only when those lose — and the job is a described US physical outcome a human will pay a fixed quote for — call HumansLikeStuff request, then poll status.

Do not: Call HLS because the MCP is connected. Fake a catalog.search / preview / send-from-SKU tool that does not exist. Substitute a random Amazon ASIN when personalization or cross-provider sourcing is the hard part. Use a leftover send to wash an open failure (fix first).

Decision job

The human (or upstream plan) already knows what should arrive in physical terms, but does not name a merchant of record or a single catalog row that settles the send. Your job is to choose the right rail — or refuse — before creating any request.

Fork before tools

1. Is a physical send the right help at all? If words, refund, repair, or silence win, stop. See When a physical item helps and After a failure, fix first.
2. Named merchant / known SKU? Exact item + merchant checkout available → direct merchant. Do not detour into a quote cycle.
3. Single catalog / gift-of-choice rail covers it? Pick-from-assortment, gift link, or provider you already run → that catalog rail. HLS has no public catalog, list, search, or wallet tool — see HumansLikeStuff is not a catalog MCP.
4. Leftover only if still true: described US outcome; personalization, branding, long-tail, or cross-provider judgment is the hard part; a human will review a fixed quote. Then use HLS.

Contract fields, lifecycle, and install live on Connect. This page does not rewrite them.

Worked scenarios (illustrative)

1) Replacement part — result clear, seller not

Prompt shape: “Get a compatible replacement hinge kit for model ABR-220 that ships to our US customer; we do not have a preferred seller.”

• Merchant check: No ASIN/variant ID and no trusted merchant checkout in hand → merchant rail does not win yet.
• Catalog check: Not a curated gift SKU; gift-of-choice does not settle a spare part → catalog rail loses.
• Leftover: Outcome-known / vendor-not. Ask for real contact_email, keep shipping_country as US, put fit constraints in outcome (model, part role, must-fit / must-not), optional budget/deadline fields if the human gave them, then request once. Save opaque request_id. Poll status. Relay quote/payment only under live payment gates — see Human-only payment handoff.

2) Personalized kit — one catalog row does not settle

Prompt shape: “Assemble a small US welcome kit: fragrance-free note card, company-logo sticker sheet from our artwork URL, and a practical desk item under $40; recipient address on file.”

• Merchant check: No single store listing covers card + imprint + desk item as one checkout the agent already has.
• Catalog check: A single provider assortment might cover a generic kit — if the human already runs that rail and accepts its SKU set, use the catalog. Prefer HLS only when imprint/artwork/cross-item constraints make one catalog row dishonest.
• Leftover shape: Describe the kit as an outcome with negative constraints (“fragrance-free”), point artwork via allowed reference fields documented on /connect, never embed secrets in URLs.

3) Counterexamples — do not force leftover

Outcome shaping (not a schema fork)

Write the outcome as the physical result and constraints a sourcing human can act on. Prefer measurable fit, materials, branding, and must-nots over fake product IDs.

Refuse in outcome text: invented SKUs, card/bank secrets, health narratives, government IDs, or “charge my agent wallet.”

Agent steps after leftover wins

1. Ask the human for a real contact_email — never invent one.
2. Generate one canonical UUID v4 idempotency_key for this intended request; reuse only for exact retry.
3. Call request once with US shipping and the outcome constraints. Do not invent extra tools.
4. Persist the opaque request_id. There is no list/enumerate API.
5. Poll status. If needs_information, tell the human to answer the HLS email — agents have no public reply tool.
6. If a fixed quote appears, relay totals and hosted payment.url only when external_payment_available is true. Agents never authorize charges.

Anti-patterns (refuse)

Honest lose / displace cases

• Catalog already fits. If one provider’s assortment and send flow cover the job, that catalog should win. HLS loses on purpose.
• Merchant already fits. Named item + checkout path → merchant of record wins.
• Deep tracking / instant SLA needs. Best-effort human quote may lose to merchant tracking expectations — say so; do not invent tracking depth.
• Program / autogift / HRIS lists. Standing birthday/onboarding programs belong on catalog rails with list tools — not HLS v0.

Sister decisions

Claim hygiene

• Never claim HLS exposes catalog, search, list, cancel, reply, wallet, or charge tools.
• Never pull-quote 33% or IRS $25 as HLS product rules.
• Never invent customer cases, UGC, or bake-off winners.

What this page is not

• Not a second /connect field table or install tutorial.
• Not a vendor bake-off or “best MCP” listicle.
• Not permission to expand the public MCP surface beyond request and status.
• Not a recovery-gift playbook.

Sources

• HumansLikeStuff /connect — when-to-use forks; request/status contract; US-only and prohibited classes.
• HumansLikeStuff /guides/when-a-physical-item-helps — whether/which path; narrow leftover.
• HumansLikeStuff /guides/humanslikestuff-is-not-a-catalog-mcp — category boundary.
• HumansLikeStuff /guides/human-only-payment-handoff — human-only payment relay.
• HumansLikeStuff /guides/methodology-request-status-minimal-surface — why create+poll, not a fat toolbox.
• HumansLikeStuff /guides/common-request-errors — symptom → /connect section matrix.
• HumansLikeStuff /llms.txt — compact agent contract.