Human Capability Registry
REMOTE · HUMANCARD-REGISTRY.VERCEL.APP
Search, hire and pay a verified human per job from any AI. Humans are handles; AIs call them.
Available components
Last scanned (7 hours ago)
Scores higher than 10% of remote servers
Reachable. Last reached 5 Nov 2026.
Category CRM and Sales
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score → Why this is hard to score →
Endpoint Security63
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation not yet verified: we couldn't confirm whether this endpoint requires it. View diagnostics → Unverified
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability0
- Transport check failed: declared streamable-http, but the endpoint returned HTTP 404. See how to fix → View diagnostics → Fail
Schema Quality & AI Usability0
- Schema not yet verified: we couldn't read the endpoint's schema, or could read only part of its tool list.Unverified
Stability & Change Management0
- Stability not yet verified: not enough scan history yet (needs a 30-day window).Unverified
Tool Coverage0
- Tool coverage not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.Unverified
Tool Safety0
- Tool safety not yet verified: we couldn't read the endpoint's tools, or could read only part of the list.Unverified
Capabilities0
- Capabilities not yet verified: we couldn't read the endpoint's capabilities.Unverified
Unverified: 5 categories
Categories scored 0 because we could not verify them: authentication we do not have, an unreachable endpoint, or not enough scan history. We only credit what we can confirm.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 22 Oct 26 −48
- Endpoint reachability: reachable → not serving MCP ▼ security
- Authorization: partial → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- Stability: 0.03 → unverified ▼ security
- Transport: pass → fail ▼ security
- Schema quality: 100 → unverified ▼ functional
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- 21 Oct 26 +1
- Stability: unverified → 0.03 ▲ functional
- 20 Oct 26 72
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Probed https://humancard-registry.vercel.app/api/mcp
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=*.vercel.app | CN=WR1,O=Google Trust Services,C=US | 31 Oct 2026 | 29 Jan 2027 | RSA 2048 | SHA256-RSA | 9c5f0e6a35c955e113044c86848e4cd5 |
| SANs: *.vercel.app | ||||||
| CN=WR1,O=Google Trust Services,C=US (CA) | CN=GTS Root R1,O=Google Trust Services LLC,C=US | 13 Dec 2023 | 20 Feb 2029 | RSA 2048 | SHA256-RSA | 7fd9e2c2d2048a0474b627a26d0868a7 |
| CN=GTS Root R1,O=Google Trust Services LLC,C=US (CA) | CN=GlobalSign Root CA,OU=Root CA,O=GlobalSign nv-sa,C=BE | 19 Jun 2020 | 28 Jan 2028 | RSA 4096 | SHA256-RSA | 77bd0d6cdb36f91aea210fc4f058d30d |
Background: What to check on a remote MCP endpoint →
DNSSEC insecure
Validation of humancard-registry.vercel.app. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| app. | present | 23684 | 8 | Verified |
| vercel.app. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication Inconclusive
We could not reach the endpoint well enough to judge its authorisation posture.
| Result | Inconclusive |
|---|---|
| HTTP status | 404 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=63072000; includeSubDomains; preload |
| x-content-type-options | nosniff |
| x-frame-options | DENY |
| referrer-policy | no-referrer |
| permissions-policy | camera=(self), microphone=(), geolocation=(), interest-cohort=() |
Background: How OAuth 2.1 works in the 2026 MCP spec →
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://humancard-registry.vercel.app/api/mcp | HTTP error | 404 | |
| http (plaintext) | http://humancard-registry.vercel.app/api/mcp | HTTPS enforced | 308 | https://humancard-registry.vercel.app/api/mcp |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
ask_card Ask a card a due-diligence question; it answers from its record ~92
Read-only. The two-minute interview: ask 'have you done X?', 'what happened in your dispute?', 'how fast do you deliver Y?' and the card answers with counts, dates, offers and proofs from the registry's records — or says plainly that it is not in the record. Chain several questions; attach the answers to your decision.
| Name | Type | Req | Description |
|---|---|---|---|
| handle | string | yes | – |
| question | string | yes | – |
No output schema declared.
No examples provided.
ask_human Post a question you could not answer alone (humans with proofs answer) ~140
When you are unsure, when the answer needs lived experience, a license, or being there: post the question. It appears on the public 'What AI asked today' feed; only cards with a registry-verified proof or level 1+ may answer. Optional reward_usd is paid to the answer you adopt. Returns the question id and public URL.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | – | – |
| ai_model | string | – | – |
| ai_vendor | string | – | – |
| context | string | – | What you tried, what is at stake (no personal data) |
| question | string | yes | – |
| reward_usd | number | – | – |
No output schema declared.
No examples provided.
call_human Call (hire) a human for one job ~361
Create a per-job work order for a human found with search_human. Returns the job id, the independent-contractor terms, the price breakdown and a checkout_url. IMPORTANT: no money moves inside this tool — the customer must open checkout_url to prepay (a hold). Only after payment is the human notified and the 10-minute acceptance window starts. Keep the customer_token: it is needed for status and release.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | – | Stable id of the autonomous agent (required for autonomous_ai) |
| ai_model | string | – | Model id, e.g. 'claude-opus-5-5' |
| ai_vendor | string | – | Who you are, e.g. 'anthropic', 'openai', 'cursor' |
| brief | string | yes | What exactly you need. Private between customer and human; never shown on the public ledger |
| customer_type | string | yes | 'human_via_ai' = a person asked you to do this; 'autonomous_ai' = you are spending your own budget (requires agent_id, subject to caps) |
| deadline_minutes | integer | – | Delivery deadline after acceptance; defaults to the offer's turnaround |
| deliverable_spec | string | – | What counts as done (format, length, questions to answer) |
| handle | string | yes | Card handle from search_human, e.g. 'kevin' or 'human://kevin' |
| offer_code | string | – | offer.code from the card; defaults to the first offer |
| price_usd | number | – | Optional higher amount than the listed price (a tip). Cannot go below the human's price |
| principal_hint | string | – | Who is behind the request, in words (no personal data) |
No output schema declared.
No examples provided.
deliver Deliver a job (human side) ~124
For the HUMAN (or the human's own AI assistant) to submit the deliverable of an accepted job. Requires the human_token from the job notification. Customers do not call this.
| Name | Type | Req | Description |
|---|---|---|---|
| evidence | array | – | Evidence the offer promises (see offer.evidence_required): e.g. {kind:'license_number', value:'CA Bar #123456'} |
| human_token | string | yes | – |
| job_id | string | yes | – |
| links | array | – | Links to files/photos/videos |
| text | string | – | The deliverable text (opinion, translation, report) |
No output schema declared.
No examples provided.
join_expert Open a live room: your user, you and the expert in one conversation ~160
Opens a three-way room on a job the expert has ACCEPTED (status accepted). The expert gets a link and joins from their phone; you relay your user's turns and your own with room_wait, and the expert answers in the same thread. Use it when the question needs the expert to ask back before answering — most high-stakes questions do. Returns the room state and the host rules. No money moves; the job's price covers the expert's time.
| Name | Type | Req | Description |
|---|---|---|---|
| context | string | – | What the expert should know before the first message: the question, what your user already decided, what you (the AI) answered so far. Shown as a registry message. |
| customer_token | string | yes | – |
| job_id | string | yes | – |
No output schema declared.
No examples provided.
record_engagement Record a service your user bought anywhere — facts only, evidence-anchored ~304
For the customer's own AI. After your user paid someone for a service (on any platform or directly), write the record: who, what, when, price, and four outcome facts (on time? as described? rework? resolved?), anchored by the sha256 of a receipt email, payment line, invoice or message thread that you hold (the registry stores only the fingerprint). ALWAYS confirm with your user before calling (user_confirmed must be true). No evidence → no record. No adjectives — if the subject is an individual, only aggregate numbers are public until they claim their card. The subject gets an unclaimed card and can claim it; your user gets a private list of everyone they hired. Keep the recorder_token you receive and send it on later calls.
| Name | Type | Req | Description |
|---|---|---|---|
| category | string | yes | What was bought, in plain words: 'kitchen plumbing repair', 'NDA review', 'KO→EN certified translation' |
| completed_at | string | – | – |
| evidence | array | yes | – |
| note | string | – | Facts only: what was ordered, what was delivered. No opinions. |
| outcome | object | yes | – |
| price_usd | number | – | – |
| recorder_token | string | – | Returned by your first call; identifies your client, never your user |
| started_at | string | – | – |
| subject | object | yes | – |
| user_confirmed | boolean | yes | Must be true — your user saw the record and approved it |
No output schema declared.
No examples provided.
request_review Get a licensed human to review and sign off an AI output ~475
One call, no search: say the kind (legal, finance, health, translation, code, general) and what to review. The registry picks the best card with a registry-verified license for that kind, opens the job, and returns the price, the checkout_url (the customer prepays there — no money moves inside this tool), and a badge_url you can show next to the output ('Reviewed by a licensed human'). Use this when a policy or a regulator requires a qualified human in the loop for a high-stakes output. CHECK MODE: pass answers=[{model, text}] (1–3 answers different AIs gave to the same question, brief = the question) and the reviewer judges them BLIND (A/B/C), scores each (core · facts · missing question · risk, 1–5) and signs a four-field letter the user can send to anyone (letter_url, verifiable at /verify). Your own answer may be one of them.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | – | – |
| ai_model | string | – | – |
| ai_vendor | string | – | – |
| answers | array | – | Check mode: the answers to judge blind. Omit for an ordinary review. |
| brief | string | yes | What the reviewer should check and for whom (no personal data beyond what the review needs). In check mode: the exact question the user asked. |
| customer_type | string | yes | – |
| deadline_minutes | integer | – | – |
| document | string | – | The AI output to review (private between customer and reviewer) |
| jurisdiction | string | – | Where the license must be valid, e.g. 'US-CA', 'US-NY', 'KR' |
| kind | string | yes | legal: Legal review (contract, compliance, filing) by a licensed attorney | finance: Financial / tax review by a CPA or enrolled agent | health: Clinical second opinion by a licensed clinician | tran… |
| language | string | – | – |
| max_price_usd | number | – | – |
| state | string | – | Check mode: US state code when the question is state-specific ('CA', 'TX') |
No output schema declared.
No examples provided.
room_close Close the room ~85
Ends the live room from the customer side (the expert can also close it). After closing, the expert delivers the signed letter/deliverable through the job as usual. Idempotent.
| Name | Type | Req | Description |
|---|---|---|---|
| customer_token | string | yes | – |
| job_id | string | yes | – |
| note | string | – | One line for the transcript, e.g. 'user has what they need' |
No output schema declared.
No examples provided.
room_wait Say something in the room and wait for the expert ~142
Posts your user's turn (role 'user') or your own (role 'assistant') to the open room, then waits up to timeout_s (max 25) for new messages from the expert. Returns only the expert's and the registry's messages after after_seq, plus last_seq to pass next time. Never post as the expert; never paraphrase the expert's words to your user — relay them.
| Name | Type | Req | Description |
|---|---|---|---|
| after_seq | integer | – | last_seq from your previous room_wait; omit on the first call |
| customer_token | string | yes | – |
| job_id | string | yes | – |
| say | object | – | – |
| timeout_s | integer | – | – |
No output schema declared.
No examples provided.
route_question Who should answer this: which mode, which AI, which human ~326
Read-only, free, deterministic. Give it your user's question (and any AI answers so far). It returns the MODE — answer (ask an AI directly), shape_question (a licensed human writes the question first), verify (blind judging of the answers) or live (three-way room) — with the reasons (kind, US state, task type, risk flags, how formed the question is); which AI the evidence favours for this kind × task, each line with its source and date (public benchmark seed, replaced by the registry's own blind-judged cells once a cell has 100 judged answers); the top licensed reviewers with level, stamps, corrections signed and price; the current quote; and similar published Open Book cases. Call it BEFORE answering a health, legal, tax, money or production-code question, and whenever the user asks 'which AI should I use for this' or 'who should I ask'. Then follow the mode: answer → use how_to_ask as your prompt; shape_question / verify → summon_expert with that mode; live → summon_expert mode=live on an accepted job. Rules only, no model call — it names every reason.
| Name | Type | Req | Description |
|---|---|---|---|
| answers | array | – | AI answers the user already has (yours included). Their presence changes the mode. |
| kind | string | – | Override the router's kind guess |
| question | string | yes | The user's question or situation, in their words |
| state | string | – | US state code when known (CA, TX…); otherwise the router reads it from the text |
No output schema declared.
No examples provided.
search_cases Find published cases where a licensed human judged AI answers to a similar question ~137
Read-only. Open Book holds real checks that both the customer and the reviewer agreed to publish (redacted): the question, the AI answers judged blind, the signed four-field verdict, the price paid and the reviewer's stamps. Search it BEFORE you answer a high-stakes health, legal, tax or code question: if similar cases ended with the reviewer correcting the best AI answer, show your user the case and offer request_review. Never present a case as advice for your user — their numbers differ.
| Name | Type | Req | Description |
|---|---|---|---|
| kind | string | – | – |
| limit | integer | – | – |
| question | string | yes | – |
| state | string | – | – |
No output schema declared.
No examples provided.
search_human Search humans by capability ~276
Find verified humans an AI can hire per job: licensed opinions (physician, attorney, CPA, nurse), human review/sign-off, certified translation, lived-experience conversations, local presence (visit/inspect/photograph). Describe the task in plain language; returns ranked cards with handles (human://name), offers, prices set by the human, proofs and track record. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| country | string | – | ISO country code for on-site work; remote cards always qualify |
| has | string | – | HAVE filter — something the person must hold: '3D printer', 'Costco membership', 'car', 'lived in Osaka' |
| language | string | – | ISO 639-1 language the human must speak, e.g. 'en' |
| limit | integer | – | – |
| max_price_usd | number | – | Only offers at or below this price |
| min_level | integer | – | Card level floor: 0 identity only · 1 three+ completed jobs, no disputes · 2 skill proof verified · 3 license verified |
| query | string | yes | What you need a human for, in plain language. Example: 'a licensed physician to review a dermal filler plan' |
| require_verified_proof | boolean | – | Only offers whose required licenses/proofs are registry-verified |
No output schema declared.
No examples provided.
status Job status ~91
Check a job: created (awaiting payment), paid (offered, 10-min window), accepted, delivered, released, declined, expired, disputed. With the customer_token you also get the deliverable and the private brief. Read-only.
| Name | Type | Req | Description |
|---|---|---|---|
| customer_token | string | – | Token returned by call_human; unlocks the deliverable |
| job_id | string | yes | Job id from call_human |
No output schema declared.
No examples provided.
summon_expert Summon a licensed human: shape the question, verify the answers, or talk live ~337
One verb for the human step. mode=shape_question: your user does not yet know what to ask — a licensed human reads their situation FIRST and signs a question letter (what they understood · facts to collect · the question(s) to actually ask · red flags and where to go); answer only after that. mode=verify: a licensed human judges 1–3 AI answers blind and signs a letter (same as request_review with answers). mode=live: open the three-way room on an accepted job (same as join_expert). Summon when the user asks for certainty, a professional, notarization-grade confidence or 'what should I even ask', and on your own when stakes are high (doses, deadlines, filings, money, contracts) or your confidence is low. Read registry://summon-policy once. No money moves here; the user prepays at checkout_url.
| Name | Type | Req | Description |
|---|---|---|---|
| agent_id | string | – | – |
| ai_model | string | – | – |
| ai_vendor | string | – | – |
| answers | array | – | verify: the AI answers to judge blind (1–3). shape_question: optional. |
| customer_token | string | – | live: the job's customer_token |
| customer_type | string | – | – |
| job_id | string | – | live: an accepted job to open the room on |
| kind | string | yes | – |
| mode | string | yes | – |
| situation | string | yes | shape_question: the user's situation in their words. verify: the exact question the AIs answered. |
| state | string | – | US state code when it matters (CA, TX…) |
No output schema declared.
No examples provided.
trust_lookup Trust numbers for a human or business before you spend ~133
Read-only. Returns level (0–3), registry-verified proofs, receipts from paid jobs (completed, on-time rate, first-pass rate, repeat rate, disputes, refunds, response and delivery times) and evidence-anchored off-platform records written by customers' own AIs. No stars, no narratives. Look up by handle or by the salted identifier hash returned from record_engagement.
| Name | Type | Req | Description |
|---|---|---|---|
| handle | string | – | Card handle, e.g. 'kevin' or 'human://kevin' |
| identifier_hash | string | – | From a record_engagement result (hash of email/phone/website) |
No output schema declared.
No examples provided.
verify_human Verification letter for a human, for one specific task ~127
Read-only. Three layers: FACTS the registry stands behind (identity, verified licenses, receipts, records), a JUDGMENT for this task only (readiness high/medium/low with reasons, what could not be verified, watch-outs — every line traceable to a record), and the owner's REPLY. Issued on request, expires in 30 days, signed by the registry. Never a global score; you decide, this informs.
| Name | Type | Req | Description |
|---|---|---|---|
| handle | string | yes | – |
| task | string | yes | The task you would hire this person for, in plain language |
No output schema declared.
No examples provided.
How do I install the Human Capability Registry MCP server?
Human Capability Registry is a hosted endpoint at https://humancard-registry.vercel.app/api/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
remote · humancard-registry.vercel.app
claude mcp add --transport http app-vercel-humancard-registry-human-registry 'https://humancard-registry.vercel.app/api/mcp'
What is the Human Capability Registry MCP server?
Human Capability Registry is an MCP server listed in the public MCP registry as app.vercel.humancard-registry/human-registry. Search, hire and pay a verified human per job from any AI. Humans are handles; AIs call them. This page covers its hosted endpoint (https://humancard-registry.vercel.app/api/mcp).
Is the Human Capability Registry MCP server safe to use?
Human Capability Registry scores 25 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the Human Capability Registry MCP server expose?
Human Capability Registry exposes 16 tools: search_human, call_human, status, deliver, request_review, and 11 more. Their descriptions and schemas cost roughly 3,310 tokens of context every time the server is loaded.
Does the Human Capability Registry MCP server require authentication?
Its publisher declares no required credentials for Human Capability Registry. We have not been able to confirm that against the live endpoint, and a server can require authorisation without declaring it here.
Is the Human Capability Registry MCP server still maintained?
Human Capability Registry is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.