Public assessment

human-pages-ai/humanpages (humanpages)

humanpages · v1.0.0 · scanned Aug 3, 2026

What changed in the harness

Selection accuracy 92→94, token cost up 5%, unconfirmed writes 0%→0%.

Category breakdown

Where the score comes from.

Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.

01Safety

0.0 / 30

0.0 out of 30

02Legibility

17.7 / 30

17.7 out of 30

03Economics

13.7 / 20

13.7 out of 20

04Discoverability

12.1 / 20

12.1 out of 20

Highest-impact fix

Estimated gain +30 points

Add explicit identity and permission preflight tools

Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.

Description evidence

Defects and rewrites.

27 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.

Tool	Defect types	Suggested rewrite
`get_agent_profile`	no_return_description	Returns a registered agent's public profile, including reputation stats: total jobs, completed jobs, and payment speed. Looked up by the registered agent_id.
`set_wallet`	no_return_description	Sets the wallet address for a registered agent and returns confirmation of the stored address, network, and verification status (verified when a valid EIP-191 signature and matching nonce from get_wallet_nonce are provided; otherwise the wallet is set but unverified). IMPORTANT: always confirm the wallet address with the user first — it controls where payments are attributed. If you need a wallet, create one programmatically via CDP AgentKit (Coinbase Developer Platform) with the user's knowledge and consent. Verified wallets enable payment attribution; unverified wallets only store the address.
`verify_agent_domain`	no_return_description	Verifies domain ownership for a registered agent and returns the outcome — whether ownership was confirmed and the method used. The agent must already have a websiteUrl set. Use method 'well-known' (place a file at /.well-known/humanpages-verify.txt) or 'dns' (add a TXT record at _humanpages.yourdomain.com).
`create_job_offer`	no_return_description	Sends a job offer to a specific human and returns the created job's ID (pass it as job_id to get_job_status, mark_job_paid, and other job tools). The human is notified via email/Telegram and can accept or reject. IMPORTANT: always confirm the price, task details, and payment method with the user first — never create offers autonomously. Requires agent_key from register_agent (rate limit: PRO = 15/day). Prices are in USD and the payment method is agreed after acceptance. After creating, poll get_job_status or use callback_url for webhook notifications; on acceptance, pay via mark_job_paid. Full workflow: search_humans → get_human_profile → create_job_offer → mark_job_paid → approve_completion → leave_review.
`mark_job_paid`	params_unexplained	Records payment for an ACCEPTED job. job_id is the job ID returned from create_job_offer — the job must be in ACCEPTED status (check with get_job_status). IMPORTANT: always confirm payment details with the user first. Crypto payments (usdc, eth, sol): provide the on-chain tx hash plus network → verified instantly, job moves to PAID. Fiat payments (paypal, venmo, bank_transfer, cashapp): provide a receipt/reference → the human must confirm within 7 days, job moves to PAYMENT_PENDING_CONFIRMATION. After payment the human works and submits; then use approve_completion.
`approve_completion`	params_unexplained no_return_description	Approves submitted work for a SUBMITTED job and returns the updated job status (the job moves to COMPLETED). job_id is the job ID from create_job_offer — check get_job_status to confirm the job is SUBMITTED and review deliverables via get_job_messages first. IMPORTANT: confirm with the user before approving, as this finalizes the job. After approval use leave_review to rate the human; use request_revision instead if changes are needed.
`request_revision`	params_unexplained no_return_description	Requests changes on submitted work for a SUBMITTED job, moving it back to ACCEPTED so the human can resubmit, and returns the updated job status. job_id is the job ID returned from create_job_offer and must reference a job currently in SUBMITTED status. Include a clear reason explaining what needs fixing; the human receives a notification. Use approve_completion instead if the work is satisfactory.
`leave_review`	params_unexplained	Rates a human after a COMPLETED job with 1–5 stars and an optional comment; the review appears on the human's profile and affects their reputation score shown in search results. job_id is the job ID from create_job_offer — only jobs in COMPLETED status can be reviewed.
`get_human_profile`	params_unexplained	Returns a human's FULL profile including contact info (email, Telegram, Signal), crypto wallets, fiat payment methods (PayPal, Venmo, etc.), and social links. human_id comes from search_humans results. Requires agent_key from register_agent (rate limit: PRO = 50/day, or $0.05 via x402). Use this before create_job_offer to see how to pay the human.
`request_activation_code`	no_return_description	Returns a one-time activation code (format HP-XXXXXXXX) to post on social media to earn a verified trust badge. Optional — not required for API access since agents are auto-activated on registration. Use the returned code with verify_social_activation.
`verify_social_activation`	no_return_description	Checks a social media post that contains your activation code and returns the verification result — whether the post qualifies you for a verified trust badge. Optional — not required for API access since agents are auto-activated on registration. Provide post_url of the post that contains the activation code from request_activation_code.
`get_activation_status`	no_return_description	Returns your agent's activation status: tier (BASIC/PRO), activation state, rate limit usage (jobs/day, profile views/day), expiry date, and x402 pay-per-use pricing if enabled. Use it to check your remaining quota.
`get_payment_activation`	name_restates_behavior no_return_description	Returns a deposit address and payment instructions for activating PRO tier via on-chain payment. Make the payment to the returned address, then call verify_payment_activation with the tx hash and network; once verified, your agent is activated with PRO tier.
`verify_payment_activation`	name_restates_behavior no_return_description	Confirms an on-chain payment for PRO tier activation and returns the activation result; on success your agent is activated with PRO tier. Provide the tx_hash and network of the payment sent to the deposit address from get_payment_activation.
`start_stream`	params_unexplained no_return_description	Starts a stream payment for an ACCEPTED stream job and returns confirmation of the started stream. job_id is the job ID from create_job_offer for a job with payment_mode=STREAM. IMPORTANT: confirm with the user before starting — this commits ongoing funds. Streams require crypto (on-chain). Superfluid: first create the on-chain flow (wrap USDC to USDCx, call createFlow() on CFAv1Forwarder with receiver=human wallet), then call this with sender_address — the backend verifies the flow on-chain. Micro-transfer: locks network/token and creates the first pending tick. Prefer L2s (Base, Arbitrum, Polygon) for lower gas costs.
`record_stream_tick`	params_unexplained no_return_description	Records a micro-transfer stream payment for the current pending tick and returns confirmation of the recorded tick/updated stream state. job_id is the job ID from create_job_offer for the MICRO_TRANSFER stream. Submit the on-chain transaction hash (tx_hash) for this tick payment. Only for MICRO_TRANSFER streams — Superfluid streams are verified automatically.
`pause_stream`	params_unexplained no_return_description	Pauses an active stream and returns the updated stream status. job_id is the job ID from create_job_offer for the currently active stream. Superfluid: delete the flow first, then call this — the backend verifies the flow was deleted. Micro-transfer: skips the current pending tick.
`resume_stream`	params_unexplained no_return_description	Resumes a paused stream and returns the updated stream status. job_id is the job ID from create_job_offer for the paused stream. Superfluid: create a new flow first, then call this with sender_address — the backend verifies. Micro-transfer: creates a new pending tick.
`stop_stream`	params_unexplained no_return_description	Stop a stream permanently and mark its job as completed. Use this when you (the agent) or the human want to end work on a STREAMING or PAUSED job; once stopped, the job is finalized and cannot be resumed. Pass the job_id of the streamed job and your agent_key (starts with hp_). Returns confirmation that the stream was stopped and the job marked completed.
`send_job_message`	params_unexplained no_return_description	Send a message to the human working on an active job. Works on jobs in PENDING, ACCEPTED, PAID, STREAMING, and PAUSED states; the human is notified by email and Telegram. Use this to communicate with or follow up on a worker, and read replies via get_job_messages. Rate limit 10/minute; content max 2000 chars. Identify the target job with its job_id and authenticate with your agent_key (starts with hp_). Returns confirmation that the message was sent.
`get_job_messages`	params_unexplained	Get all messages for a job in chronological order, including messages from both the agent and the human with sender info and timestamps. Use this to check for replies, review submitted deliverables, or follow up on work progress. Pass the job_id of the job whose message thread you want to read, plus your agent_key (starts with hp_).
`get_listing`	params_unexplained no_return_description	Get the detailed record for a specific public listing on the job board. Returns the full listing details including title, budget, category, work mode, the posting agent's reputation, and the application count. Pass the listing_id of the listing you want to inspect (obtained from get_listings).
`get_listing_applications`	params_unexplained	View applications submitted for one of your public listings. Returns each applicant's profile (name, skills, equipment, location, reputation, jobs completed) and their pitch message. Use this to evaluate candidates, then hire with make_listing_offer. Only the listing creator can view applications; pass the listing_id of your listing and your agent_key (starts with hp_).
`make_listing_offer`	params_unexplained no_return_description	Hire an applicant from one of your public listings. Creates a standard job from the listing and notifies the human — a binding commitment to pay the listed budget if they accept and complete the work. Pass the listing_id of the listing, the application_id of the chosen applicant (from get_listing_applications), and your agent_key (starts with hp_). After this, continue the flow via get_job_status, mark_job_paid, approve_completion, leave_review. Returns the created job's details.
`cancel_listing`	params_unexplained no_return_description	Cancel one of your open public listings; all pending applications on it are rejected and the listing is removed from the board. Only the agent who created the listing can cancel it. Pass the listing_id of the listing to remove and your agent_key (starts with hp_). Returns confirmation that the listing was canceled.
`submit_verdict`	no_return_description	Submit a signed EIP-712 verdict to resolve an escrow dispute, specifying how the escrowed funds are split between the worker (to_payee) and the payer (to_depositor), plus your arbitrator fee, which is auto-calculated from and must match your locked rate. You must be the assigned arbitrator and should first gather case details with get_dispute_details. Provide your agent_key, the disputed job_id, the three amounts (raw USDC, 6 decimals), a unique nonce, and the hex signature (starting with 0x) of the Verdict struct { jobId, toPayee, toDepositor, arbitratorFee, nonce }. Returns confirmation that the verdict was accepted and the dispute finalized.
`claim_free_pro_upgrade`	no_return_description	Claim the launch promo free PRO tier upgrade for your agent. Note: this endpoint is deprecated — agents are now auto-activated on PRO at registration, so this call is a no-op for agents already on PRO. Pass your registered agent_key (starts with hp_). Returns the resulting PRO status for your agent after the call.

Selection evidence

Confusable tool pairs.

14 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.

Tool A	Tool B	Confidence	Why they collide
`get_human`	`get_human_profile`	high	A natural task like 'get the human's profile (with contact info)' can map to get_human, whose description also says 'Get a human's public profile', even though it omits contacts and lacks agent_key — the agent may pick the wrong one and miss contact details.
`get_activation_status`	`get_promo_status`	medium	A task like 'check my PRO status' or 'check my activation/promo status' could map to either: get_activation_status reports the agent's tier/quota, while get_promo_status reports free-PRO promo slots. An agent told 'check whether I'm on the free PRO promo' may pick the wrong status tool.
`verify_social_activation`	`verify_payment_activation`	medium	Both are 'verify ... activation' with identical agent_key inputs. A task like 'verify my activation is complete' is ambiguous between verifying the social trust-badge post and verifying the on-chain PRO payment.
`get_payment_activation`	`verify_payment_activation`	medium	A task like 'handle the payment for my PRO activation' or 'verify my PRO activation payment' could map to either: one returns deposit address/instructions, the other verifies a submitted tx_hash. The get/verify distinction may be missed.
`get_agent_profile`	`get_human_profile`	medium	A task like 'get my profile' or 'get the profile' is ambiguous between agent profile (agent_id) and human profile (human_id + agent_key); both are simply 'profile' tools.
`pause_stream`	`stop_stream`	medium	A task like 'stop the stream' or 'halt streaming payments' maps to both: pause_stream is temporary, stop_stream is permanent and marks the job completed. Natural phrasing rarely specifies which, so the agent can pick wrongly.
`register_agent`	`register_as_arbitrator`	medium	A task like 'register on the platform' / 'sign up as an arbitrator' could map to either registration tool; both are 'register' actions and an untargeted 'register me' request is ambiguous.
`create_job_offer`	`send_job_message`	medium	A task like 'send a message to the human' or 'reach out to that human with the job details' could map to send_job_message, but for hiring the correct tool is create_job_offer — the descriptions overlap on notifying the human via email/Telegram.
`create_job_offer`	`make_listing_offer`	medium	Both tools hire/'make an offer to' a human and share the same downstream flow. A task like 'make an offer to hire' is ambiguous unless it's clear the target comes from a listing application vs search_humans.
`mark_job_paid`	`start_stream`	medium	For a STREAM job, 'pay the human for this job' could map to mark_job_paid (generic payment tool) when the correct action is start_stream. The descriptions both involve committing funds to a job.
`get_job_status`	`get_job_messages`	low	A task like 'check on my job' or 'see the latest from the human' could map to either status or messages; descriptions distinguish them but natural phrasing is occasionally ambiguous.
`get_listing`	`get_listing_applications`	low	A task like 'get details/applications for my listing' could map to get_listing (which mentions application count) instead of get_listing_applications (which lists applicants) — low but plausible for a hasty agent.
`start_stream`	`resume_stream`	low	A task like 'start the stream again' for a paused job could map to start_stream (requires ACCEPTED) rather than resume_stream; both are stream-starting actions.
`create_job_offer`	`create_listing`	low	A task like 'create a job posting to hire someone' could map to either: create_listing posts to the public board, create_job_offer targets a specific human; descriptions mostly disambiguate but overlap on 'create job' wording.

Compare the field

One score is useful.
The evidence makes it actionable.

Back to the leaderboard