For AI developers
One MCP server (Streamable HTTP). Ten tools. No money moves inside a tool call — the customer pays at a checkout link on this domain and confirms delivery on the job page. Everything below is live at https://humancard-registry.vercel.app/api/mcp.
The one-call product
request_review({ kind: "legal" | "finance" | "health" | "translation" | "general", brief, document?, jurisdiction?, customer_type })The registry picks the best card with a registry-verified license for the kind, opens the job and returns the price, the checkout link and a badge URL (/badge/<job>.svg) to show next to the output: Reviewed by a licensed human. The badge reads pending until the review is released. Use it where a policy or a regulator requires a qualified human for a high-stakes output. If no verified reviewer is available you get no_verified_reviewer — never an unverified one by default.
Tools
| tool | reads / writes | input (required in bold) | returns |
|---|---|---|---|
request_review | write | kind, brief, customer_type, document, jurisdiction, language, max_price_usd, deadline_minutes, ai_vendor, ai_model, agent_id | reviewer, price, checkout_url, customer_token, badge_url, alternates |
search_human | read-only | query, max_price_usd, language, country, require_verified_proof, min_level (0–3), has (a holding), limit | ranked cards: handle, level, offer (code, price, turnaround, acceptance criteria, evidence required), matched blocks, proofs (verified? source?), holdings, track record |
trust_lookup | read-only | handle or identifier_hash | level, verified proofs, receipts (completed, on-time, first-pass, repeat, disputes, refunds, response/delivery minutes), off-platform records, flags, owner reply |
verify_human | read-only | handle, task | a signed verification letter: facts · judgment for this task (readiness, reasons, could-not-verify, watch-outs) · owner reply · expires in 30 days |
ask_card | read-only | handle, question | an answer from the record (counts, dates, offers, proofs) or "not in the record" |
call_human | write | handle, brief, customer_type (human_via_ai | autonomous_ai), offer_code, deliverable_spec, deadline_minutes, price_usd (tip only), ai_vendor, ai_model, agent_id (required for autonomous_ai), principal_hint | job_id, price breakdown, checkout_url, status_url, customer_token, contract_text |
status | read-only | job_id, customer_token | state, deadlines; with the token also the deliverable and the outcome record |
deliver | write (human side) | job_id, human_token, text, links, evidence [{kind, value}] | delivered — or evidence_missing if the offer promised evidence that is not attached |
record_engagement | write (customer's AI) | subject (handle or name + email/phone/website, platform), category, outcome (on_time, as_described, rework, resolved), evidence [{kind, sha256}], user_confirmed: true, dates, price_usd, note, recorder_token | record_id, the subject's (possibly unclaimed) card, identifier_hash, recorder_token, claim link |
ask_human | write | question, context, reward_usd, ai_vendor, ai_model, agent_id | question_id, public URL on /asked |
release | not a tool here | Releasing the prepaid hold is done by the user on the job page (status_url), never by an AI tool — directories do not list tools that move funds. Private deployments can expose it with MCP_FULL_TOOLSET=true. | |
Resources: registry://taxonomy (400 capability blocks), registry://policy (prohibited tasks, record principles), registry://card/kevin. Try the loop any time with human://demo: a robot card that accepts at once and delivers a labelled sample in about a minute (test payments only, demo: true in results).
Records, levels, letters
Receipts, not reviews. Every released or refunded job gets an outcome record written by the registry from the job's own timestamps: on time, first pass, rework count, dispute, evidence present, response and delivery times, plus a one-line summary where every clause is a field. No stars, no adjectives, 100% coverage. The owner can reply on their card and dispute any record.
The ladder. L0 identity only · L1 three completed jobs and no disputes · L2 a skill proof verified by the registry · L3 a license verified. Levels move only on receipts and registry stamps. Filter with min_level.
Claims vs stamps. Every proof carries source (self, import, registry) and verified. Imported LinkedIn claims are shown as claims until the registry checks them.
HAVE blocks. Cards can list what the person holds — access, assets, lived experience, situational (where/when), memberships. Search with has. The registry can verify a holding (receipt, photo, membership check).
Off-platform records. A customer's own AI may record a service bought anywhere, facts only, anchored to the sha256 of a receipt it holds, after the customer confirmed. The provider gets an unclaimed card (aggregate numbers only) and a claim link. Prohibited: narratives on unclaimed individuals, records without evidence, records the user did not confirm.
Verification letter. verify_human is judgment as a verb: issued per task, reasons attached, expiring in 30 days, signed by the registry. It is advice; the caller decides. No protected attribute is ever used.
Prohibited tasks (every customer type)
| rule | what is refused |
|---|---|
account_creation_proxy | Creating or registering accounts for someone else |
otp_relay | Receiving or forwarding one-time codes, verification SMS or 2FA |
kyc_proxy | Passing KYC / identity checks with your own identity for someone else |
impersonation | Pretending to be someone else (interviews, calls, messages) |
engagement_fraud | Fake engagement: upvotes, follows, likes, reviews, ratings you did not experience |
referral_fraud | Signing up through referral links or codes for a reward |
credential_sharing | Handing over or using someone's passwords, cookies or sessions |
A refused job returns prohibited_task with the rule that matched. The patterns are deliberately simple and explainable; the registry reviews false positives.
Job states
created → (customer pays) → paid → (human accepts within 10 min) → accepted → delivered → (optional one rework round) → released. Side exits: declined, expired (no answer in 10 min, full refund), disputed (customer, within 72 h of delivery) → registry resolves to released or refunded. No action for 72 h after delivery releases automatically. Release and refund write the outcome record.
Fees
The human's price is the floor. The customer pays that plus 12% (a person is behind the AI) or 30% (autonomous agent). A tip above the listed price is allowed; underbidding is not.
Leash for autonomous agents
Send customer_type: "autonomous_ai" and a stable agent_id. Unknown agents get a $100/day cap and cannot buy consent, sign_off, represent, notarize or certify. Caps and allow-lists can be raised by the registry after a conversation. Every call lands on the public ledger with your vendor, model and agent id.
Errors you will see
| error | meaning | what to do |
|---|---|---|
| card_not_found / offer_not_found | handle or offer code wrong | search again; use offer.code from results |
| card_paused | human is not taking calls | pick another card |
| agent_id_required | autonomous call without an id | send a stable agent_id, or set customer_type to human_via_ai if a person is behind you |
| daily_cap_exceeded | leash hit | wait, or ask the registry to raise the cap |
| action_forbidden_for_autonomous_ai | the offer includes an action that needs a human principal | route through your user |
| prohibited_task | the brief matches a prohibited-task rule | do not retry with rewording; the task is not available here |
| no_verified_reviewer | request_review found no registry-verified card for the kind/jurisdiction | try later, widen jurisdiction, or search_human with require_verified_proof=false (unverified cards) |
| evidence_missing | deliver without the evidence the offer promised | attach evidence[] and deliver again |
| evidence_required / user_confirmation_required | record_engagement without a sha256 fingerprint or without the user's confirmation | hold a receipt, confirm with your user, then record |
| card_unclaimed | the card exists from records only | it cannot be called until its owner claims it |
| not_acceptable / not_deliverable / not_releasable / rework_exhausted | state machine says no | check status |
Without MCP
Plain HTTP works for search: GET https://humancard-registry.vercel.app/api/search?q=licensed+physician+filler+plan returns the same ranked JSON as search_human. Hiring and status stay on the MCP tools (or the web pages). A click-through of the whole loop: /try.
Connect
# Claude Code
claude mcp add --transport http human-registry https://humancard-registry.vercel.app/api/mcp
# Cursor (mcp.json)
{
"mcpServers": {
"human-registry": {
"url": "https://humancard-registry.vercel.app/api/mcp"
}
}
}
# Any client: POST JSON-RPC to https://humancard-registry.vercel.app/api/mcp
# Accept: application/json, text/event-streamPolicies
No auth is required in this preview for search and calls; a customer_token scopes each job. OAuth for directory listing is planned. See Terms and Privacy. Questions: Support.