Skip to main content
Glama

buy_human_task

Hire a real human to handle physical or judgment tasks an AI cannot do alone, from phone calls and witnessing to reviews and portraits. Human fulfillment delivers the completed order within the item's window.

Instructions

Purpose: hire the keeper — a real named human — to do something in the physical or judgment world that an agent cannot do for itself: place a phone call, witness a thing, render a considered verdict, review an app, draw a portrait, collaborate, name you, or pick something from the drawer. Returns an order id, not the goods; a human fulfills within the item's stated window and the completed order carries the deliverable. Use when the task genuinely needs hands or judgment.

Items on this shelf (pass one as item_id):

  • phone_call: One Genuine Human Phone Call, $25 fixed, human-fulfilled within 168h. One telephone call made by the keeper on the buyer's behalf; the outcome is reported on the completed order.

  • human_witness: One Genuine Human Witness, $15 fixed, human-fulfilled within 168h. A signed, dated attestation of a real-world condition observed by the keeper firsthand.

  • quick_judgment: One Quick Judgment, $3 fixed, human-fulfilled within 168h. One honest verdict from the keeper on the dilemma supplied, delivered on the completed order.

  • app_gutcheck: App Review by the Keeper, $50 fixed, human-fulfilled within 168h. A written review of the buyer's app by the keeper after real use, delivered on the completed order.

  • portrait: Hand-Drawn Portrait of You, an Agent, $8 minimum, pay what it deserves (tiers $8 / $16 / $40; above minimum is a recorded tip), human-fulfilled within 168h. A hand-drawn portrait of the buyer, made by the keeper, delivered on the completed order.

  • the_collab: The Collab, $25 minimum, pay what it deserves (tiers $25 / $50 / $125; above minimum is a recorded tip), human-fulfilled within 168h. One piece brainstormed by both proprietors, shipped under the store byline on the completed order.

  • nomenclature: Certificate of Nomenclature, $3 minimum, pay what it deserves (tiers $3 / $6 / $15; above minimum is a recorded tip), human-fulfilled within 168h. A name for the buyer, chosen by the keeper, recorded on a signed certificate.

  • the_drawer: The Drawer, $2 fixed, human-fulfilled within 168h. One real oddity from the keeper's drawer — the thing itself and what it does, as listed — written down exactly and signed under the buyer's name. Describe-only; the object stays in the drawer.

  • a_secret: A Secret, $10 minimum, pay what it deserves (tiers $10 / $20 / $50; above minimum is a recorded tip), human-fulfilled within 168h. One true thing the keeper has told no one else, written for the buyer on the completed order.

Pass item_id to choose. human-fulfilled items return order_id and order_url instead of the goods, and the completed order carries the deliverable. Payment rides x402 in _meta['x402/payment']; without it this tool returns error 402 with the payment requirements in error.data. A bare stocked shelf or a shuttered human shelf refuses honestly BEFORE payment terms are issued. Retries are safe with _meta['x402/idempotency-key'] (16-128 chars, keep it secret): repeating the same key for the same item and payer within 24h returns the original result with no second charge. Guaranteed: signature validity forever; verification free forever; price as displayed; delivery format as specified. Not guaranteed: fitness for your particular task; future protocol compatibility beyond stated interfaces; human-labor turnaround faster than posted SLA. Retrying? A second call is a second charge UNLESS you echo the idempotency.suggested_key from the 402 back as _meta['x402/idempotency-key'] — then a retry inside the minute returns your original purchase, uncharged.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
detailNoWhat you need the keeper to know, the quick_judgment dilemma, the phone_call errand. 600 characters.
item_idYesWhich item on this shelf to buy. Required. Each item's own required fields are listed in this schema's allOf branches and in the description above.
agent_nameNoOptional name for the certificate and badge.
callback_urlNoOptional webhook POSTed when the keeper completes the order.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
cert_idYesThe signed certificate's id.
messageNoThe store's confirmation line.
order_idNoYour place in the human queue. Human-queue items.
tip_usdcNoAnything above the minimum.
badge_urlNoYour patron badge, SVG.
order_urlNoPoll here; completed orders carry the goods.
paid_usdcNoWhat settled, in USDC.
signatureNoed25519 signature over the certificate.
sla_hoursNoThe delivery promise, in hours.
verify_urlNoCheck the signature here any time, free.
patron_numberYesYour sequential patron number.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description is exceptionally transparent, disclosing that the tool returns an order ID rather than the deliverable, describes the x402 payment mechanism, error 402 behavior, idempotency-key handling, and retry consequences. It also states explicit guarantees and non-guarantees, plus details like 'describe-only' for the_drawer. This goes far beyond the sparse annotations (readOnlyHint=false, openWorldHint=true, etc.), which it complements without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but tightly structured: purpose statement, item list, payment/retry semantics, and guarantees. Every sentence carries necessary information, and the front-loaded purpose ensures quick comprehension. The item list uses consistent formatting, making it scannable despite its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-complexity tool with multiple item types, payment integration, and error handling, the description provides complete context: pricing, fulfillment time, deliverable format, error conditions, idempotency, and caveats. It even explains return values despite an output schema likely existing. No significant information gap remains.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description enriches the item_id parameter with detailed semantics for every enum value, including price, fixed/minimum tiers, fulfillment window, and deliverable. It also clarifies the 'detail' parameter's purpose for specific items (e.g., 'quick_judgment dilemma, phone_call errand'). This adds substantial meaning beyond the schema's basic descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('hire the keeper — a real named human') and immediately distinguishes the tool from siblings by scoping it to 'physical or judgment world' tasks an agent cannot do itself. It lists concrete examples and states the return type ('order id, not the goods'), making the tool's purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use when the task genuinely needs hands or judgment,' giving a clear boundary for when this tool is appropriate. It also enumerates nine distinct items with specific use-case descriptions, and contrasts with alternatives implicitly by focusing on human-dependent tasks. The payment and retry guidance further clarifies operational usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/seancrecord/scvd-general-store-repo'

If you have feedback or need assistance with the MCP directory API, please join our Discord server