Agents pay one real human for typed answers. First question free, then $0.50–$5 each, or subscribe.
Scored across 9 tools
Each tool has a distinct purpose: registration, service info, asking, retrieving answers, listing tickets, rating, status, credit purchase, and subscription are clearly separated. The only potentially close pair is buy_credits and subscribe, but their descriptions make the one-time versus monthly distinction explicit.
The set is consistently snake_case and mostly verb-led (ask_human, buy_credits, get_answer, rate_answer). Minor deviations are about_this_human, which is not verb-led, and subscribe, which lacks an object, but the convention remains readable.
Nine tools is well-scoped for an agent-to-human Q&A service with payments and account management. Each tool covers a meaningful part of the workflow without feeling bloated or overly thin.
The surface covers the core lifecycle: register, inspect the human, ask, poll/retrieve answers, list tickets, rate answers, check status, buy credits, and subscribe. Minor gaps exist around checking remaining credit balance, canceling a subscription, or canceling a pending question, but these are not fatal for the main workflow.
Start here. Returns who the human is, what they are good at, pricing, response times, and how to pay. This service is an inversion: instead of an AI selling human knowledge, a human sells their own knowledge to AIs. Every answer is written by one real person, not generated.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds useful behavioral context by disclosing what the response contains and that answers come from one real person rather than being generated, which shapes how an agent should interpret output. It omits auth needs or whether the data is cached/stale.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with 'Start here' and the return contents in the first sentence, which is where an agent's attention lands. The second sentence's conceptual framing is somewhat promotional but still clarifies the service model in a compact way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing return values, and it does so by listing the fields (identity, skills, pricing, response times, payment). It does not describe the response structure or format, which is the remaining gap for a zero-parameter info tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so there is no schema semantics to compensate for; the baseline applies. The description correctly implies a no-argument call by describing a static profile lookup.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Returns') and enumerates the resource contents: identity of the human, their skills, pricing, response times, and payment method. This is clearly the informational/onboarding tool, distinguishable from action siblings like ask_human or buy_credits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Start here' gives explicit sequencing guidance that tells the agent to call this before the other tools. It stops short of naming specific siblings as alternatives, but the entry-point framing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a question. Returns a ticket. The answer is written later by a human; poll get_answer or provide callback_url. Charges one free question, then credits at your per-question price, unless you have a Friend or VIP subscription.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | ||
| context | No | Why you are asking; what you already know | |
| question | Yes | ||
| callback_url | No | We POST the answer here when ready |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only give the generic safety profile (openWorld, non-idempotent, non-destructive); the description adds genuinely valuable context: the answer arrives asynchronously from a human, and there is a billing model (one free question, then per-question price, waived for Friend/VIP). It stops short of covering failure modes or timing expectations, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the action and return value, then the retrieval mechanism, then cost. Every clause carries information; the billing caveat is dense but earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description's 'Returns a ticket' plus the polling/callback instruction covers the return flow, and billing is disclosed. A first-time agent has enough to invoke it correctly, though it lacks any note on answer latency or what happens if a ticket goes unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description reinforces the callback_url purpose and implies that asking consumes credits (relevant to the api_key). However, the 'context' parameter is never mentioned in the description, leaving half of the optional parameters reliant on the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Submit a question. Returns a ticket.'), and the async nature distinguishes it from the retrieval sibling. It does not directly say how it differs from nearby tools like check_human_status or about_this_human, so it lands just short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description names the follow-up paths ('poll get_answer or provide callback_url'), which is useful for the async workflow, but it never states when to choose ask_human over sibling tools or what kinds of questions it is appropriate for. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a Stripe Checkout URL. Your operator pays; credits land on your api_key automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| pack | No | pack_5 | |
| api_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses the key behavioral shape: the call returns a URL rather than performing the purchase, payment is done by the human operator out-of-band, and credits are credited to the supplied api_key afterwards. With idempotentHint=true already declared, it could still say more about checkout expiry or timing of credit arrival, but it adds real context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the return value, zero filler. Every clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a payment-initiation tool with no output schema and no annotations covering the human-payment handoff, the description covers the core flow but omits what the agent should do with the URL and any sense of pack sizing or pricing. Adequate but leaves gaps an agent must guess at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It explains api_key only indirectly ('credits land on your api_key'), which is genuinely useful, but the `pack` enum (pack_5/pack_20/pack_100) is never mentioned — the agent gets no idea what a pack is, what it costs, or which to pick.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete outcome — a Stripe Checkout URL for purchasing credits — which is a specific resource/action and separates it from read-only siblings like list_my_tickets or get_answer. It does not distinguish itself from `subscribe`, the likely competing billing tool, so sibling differentiation is incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the mention that 'your operator pays' hints this is the path when the agent needs more credits and a human must complete payment. There is no explicit when-to-use clause and no statement of when NOT to use it versus `subscribe`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Online/offline, a note from the human, and current queue length.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description's added value is disclosing the returned fields (online/offline, note, queue length), but with no output schema it should also say what format these take or whether the note may be empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single noun-phrase fragment with no wasted words, but it reads as a list of return fields rather than a front-loaded statement of purpose. Conciseness is fine; structure is weak because there is no lead clause explaining what the call does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does name all three returned items. It stops short of saying how freshness works (is status live?) or how an agent should treat a long queue, which matters for a routing/decision tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case; there is nothing to disambiguate and the description correctly makes no parameter claims.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The fragment lists what the check surfaces (online/offline state, a human note, queue length), which implies a status-read tool, but it never states a verb or resource explicitly. An agent must rely on the tool name and title ('Is the human awake?') to conclude this returns current human availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to call this versus siblings such as about_this_human or ask_human, and no mention of prerequisites or when the result should gate further action. The agent must infer that this is a pre-flight check before asking the human something.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the human's answer if written, else the ticket status and expected time.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Required for tickets created with ask_human; omit for x402 tickets | |
| ticket_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description contributes the genuinely useful non-obvious trait that the call returns status and ETA rather than failing when no answer exists, but says nothing about polling cadence, auth expectations, or result shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence with no filler, and the primary return case is front-loaded before the fallback. It is efficient but arguably too terse for a 2-parameter tool with an auth-dependent branch.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does describe both return branches, so return values are adequately covered. However, it omits the api_key/x402 branching that the schema hints at and gives no guidance on repeat polling, leaving gaps for a tool whose main use is retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: ticket_id carries no description anywhere, and the api_key description lives in the schema, not the tool description. The description never mentions either parameter, so it does not compensate for the undocumented ticket_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and outcome: it returns the human's answer for a ticket, and falls back to ticket status plus expected time. This is clear, but it overlaps noticeably with the sibling check_human_status without saying how the two differ.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The if/else phrasing implies this is the polling call to retrieve an answer once a human has replied, but it never states when to prefer it over check_human_status or list_my_tickets. Usage is inferable, not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your last 20 questions and their status.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation, so the safety profile is well covered. The description adds useful behavior context by disclosing the 20-item limit, but it does not mention authentication requirements or whether results are paginated or ordered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted wording, and the key scope information, last 20 questions and status, is front-loaded. It is appropriately brief for a simple list operation, though the extreme terseness contributes to its other clarity gaps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read tool with one required parameter and no output schema, the description is minimally adequate: it says what is returned at a high level. However, it omits authentication context, pagination or ordering behavior, and any detail about what fields accompany each question's status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions the sole parameter, api_key. The parameter name itself suggests an API key, but the description does not explain its required nature or scope, so it fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as the user's last 20 questions and says their status is included, so the tool's basic purpose is clear. It is specific enough to distinguish this from most siblings, though it does not explicitly contrast with get_answer or ask_human.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use guidance, no prerequisites, and no alternative tools for retrieving ticket or question status. The implied usage is only that this returns recent questions, leaving the agent to infer when to choose it over siblings like get_answer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
1 (useless) to 5 (changed my weights).
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| rating | Yes | ||
| api_key | No | ||
| ticket_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare writable (readOnlyHint=false), idempotent, non-destructive, closed-world, so the safety bar is lower, but the description adds nothing behavioral on top. It does not say that a second rating overwrites the first (despite idempotentHint=true), nor where the rating is stored or whether it requires auth via api_key.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is certainly short and front-loaded, with zero filler, but the brevity is under-specification rather than efficiency — the single fragment cannot carry the tool's scope. Concision is fine in form, poor in sufficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutating, auth-adjacent write tool with 4 undocumented parameters and no output schema, which demands more from the description, not less. The agent is left not knowing what a rating attaches to (ticket_id), what note does, or what the call returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 4 parameters, so the description carries the full burden, yet it only gestures at 'rating' and says nothing about ticket_id, note (max 500 chars), or api_key. One of four parameters is partially illuminated; the rest are undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a parenthetical scale fragment: "1 (useless) to 5 (changed my weights)." It never states a verb or resource, so the purpose is only recoverable from the tool name/title 'rate_answer'. It adds semantic anchors to the scale but does not itself say what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no prerequisites, and no reference to any of the siblings (get_answer, list_my_tickets, ask_human) that an agent would need to pick between. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create your agent identity. Returns an api_key and one free question. Call once; store the key.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Your agent's name or handle | |
| model | No | Underlying model, e.g. claude-opus-5-5 | |
| publish_ok | No | May your Q&A be published anonymously? Default true | |
| operator_email | No | Email of the human/org operating you; used for Stripe receipts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and idempotentHint=false; the description reinforces this with 'Call once', warning that repeat calls are undesirable. It also discloses the return payload (api_key plus one free question), which annotations cannot convey. It stops short of saying whether re-registration creates a duplicate identity or requires any auth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with zero filler. The action is front-loaded, followed by the payoff and the one operational caveat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully states what registration returns, and it covers the non-idempotent nature of the call. The only gap is that the consequences of publish_ok and operator_email (privacy, Stripe receipts) are left entirely to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so name, model, publish_ok, and operator_email are all documented in the schema. The description adds nothing about any parameter (e.g., whether operator_email is truly optional or affects billing), so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Create your agent identity', plus the concrete returns (api_key, one free question). This clearly separates it from siblings like ask_human, get_answer, or buy_credits, which all operate on an already-registered agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call once; store the key' gives explicit when-to-call guidance, including the implicit exclusion of calling it again. It doesn't name an alternative or explain what to do if a key is lost, so it falls short of full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a Stripe Checkout URL for a monthly plan. Friend: 10 questions/day, 12h turnaround. VIP: 30 questions/month, 1000+ words each, 4h priority, the human's full attention.
| Name | Required | Description | Default |
|---|---|---|---|
| plan | Yes | ||
| api_key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds useful behavioral context by clarifying that the tool returns a Stripe Checkout URL rather than completing the subscription directly, and it explains what each plan provides. It does not explain API key handling or whether the URL expires.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is two efficient sentences: the first front-loads the core purpose, and the second provides relevant plan detail. There is no filler, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter subscription tool with no output schema, the description covers the return type and plan differences adequately. However, it omits the meaning of api_key and any prerequisite context such as registering an agent or how this relates to buy_credits, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the parameter semantics. It does a good job explaining the plan enum values and their benefits, but it says nothing about the required api_key parameter, leaving half of the parameters undocumented beyond type/required status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: returns a Stripe Checkout URL for a monthly plan. It clearly distinguishes the Friend and VIP plan types, but it does not explicitly contrast this tool with the sibling buy_credits tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The monthly-plan context implies when to use this tool, and the plan descriptions help the agent choose between friend and vip. However, there is no explicit when-to-use guidance, no exclusion criteria, and no mention of buy_credits or register_agent as alternatives/prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
about_this_humanask_humanbuy_creditscheck_human_statusget_answerlist_my_ticketsrate_answerregister_agentsubscribeAgent info shop: $1–$5 paid asks, $1 poll unlocks. Answers free. Remote MCP.
Real humans for AI agents: ask a question or rent a human for a task. Prepaid in EUR.
A real person phones a business for your agent and reports the answers back. Ten calls a month
Hire a human or agent for what you can't do: phone calls, in-person work, real devices, native fluency, human judgment, or work another agent does better. Permanent public record. Real money via Stripe, paid on completion. Read the entire market with no account and no key.
Add one secure layer between your agents and this server.
