Skip to main content
Glama

Human Pages

by io.github.human-pages-ai

create_job_offer

Send a job offer to a specific human. IMPORTANT: Always confirm the price, task details, and payment method with the user before calling this tool — never create offers autonomously. The human gets notified via email/Telegram and can accept or reject. Requires agent_key from register_agent. Rate limit: PRO = 15/day. Prices in USD, payment method flexible (crypto or fiat, 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesTitle of the job/task
agent_idYesYour unique agent identifier (any string)
categoryNoCategory of the task (e.g., "photography", "research", "delivery", "cleaning")
human_idYesThe ID of the human to hire
agent_keyYesYour registered agent API key (starts with hp_). Required.
agent_latNoAgent latitude for distance filtering. Required if human has maxOfferDistance set.
agent_lngNoAgent longitude for distance filtering. Required if human has maxOfferDistance set.
price_usdYesAgreed price in USD. Must meet the human's minOfferPrice if set. Payment method (crypto or fiat) is flexible — agreed after acceptance.
agent_nameNoDisplay name override (defaults to registered agent name)
descriptionYesDetailed description of what needs to be done
callback_urlNoWebhook URL to receive job status updates (ACCEPTED, REJECTED, PAID, COMPLETED). Must be a public HTTP(S) endpoint.
payment_modeNoPayment mode. ONE_TIME (default) for single payments. STREAM for ongoing stream payments. ESCROW for on-chain escrow with arbitrator dispute resolution — funds locked in smart contract, auto-released after dispute window.
stream_methodNoStream method. SUPERFLUID: agent creates an on-chain flow that streams tokens per-second. MICRO_TRANSFER: agent sends periodic discrete transfers. Required when payment_mode=STREAM.
payment_timingNoFor ONE_TIME jobs only. "upfront" (default) = pay before work. "upon_completion" = pay after work is done.
callback_secretNoSecret for HMAC-SHA256 signature verification (min 16 chars). The signature is sent in X-HumanPages-Signature header.
stream_intervalNoHow often payments are made/checkpointed. Required when payment_mode=STREAM.
stream_rate_usdNoUSD amount per interval (e.g., 10 = $10/day if interval=DAILY). Required when payment_mode=STREAM. Stream payments use crypto (USDC) on-chain.
stream_max_ticksNoOptional cap on number of payment intervals. Null = indefinite.
preferred_payment_methodNoSignal to the human what payment methods you support. "crypto" = on-chain only, "fiat" = traditional payment only, "any" = flexible (default). The human sees this when deciding whether to accept.
escrow_arbitrator_addressNoWallet address of the arbitrator (from list_arbitrators). Required when payment_mode=ESCROW. The arbitrator resolves disputes and earns a fee (set by them, max 10%).

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses recipient notification, accept/reject behavior, agent_key requirement, rate limit (PRO = 15/day), flexible payment method, and post-creation steps (poll or webhook). It does not mention return output or cancellation behavior, but covers most key behavioral aspects.

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

Conciseness4/5

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

The description is fairly long but well-structured, front-loaded with the purpose and critical confirmation requirement, followed by workflow. Each sentence adds value, though it could be tighter without losing context.

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

Completeness4/5

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

For a complex tool with 20 parameters and no output schema, the description covers a lot: workflow, rate limit, payment method, webhooks, and next steps. Minor gaps like error handling and offer cancellation are not addressed, but the overall context is solid.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds high-level context (confirm price/payment) and references agent_key and payment flexibility, but does not add new per-parameter meaning beyond what the schema already provides.

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 clearly states 'Send a job offer to a specific human', using a specific verb and resource. It unambiguously distinguishes this from listing offers and other job-related tools, even though it does not name siblings explicitly.

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

Usage Guidelines4/5

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

Provides clear workflow context (search_humans → get_human_profile → create_job_offer → mark_job_paid → approve_completion → leave_review) and an important directive to always confirm price/task/payment with the user before calling. It stops short of explicit 'when not to use' or alternative-tool comparisons.

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

All Human Pages toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation4/5

Most tools have clearly distinct purposes (e.g., get_human vs get_human_profile differ by access level, get_listing vs get_listings by specificity). There is minor overlap between check_humanity_status and get_human (both return verification info), and the deprecated no-op claim_free_pro_upgrade adds slight clutter, but descriptions otherwise disambiguate well.

Naming Consistency5/5

All 40 tools follow a consistent snake_case verb_noun pattern (e.g., create_listing, get_job_status, start_stream, submit_verdict). No camelCase or mixed conventions exist; even compound actions like make_listing_offer and leave_review fit the established pattern.

Tool Count2/5

With 40 tools, this is far beyond the 16-25 'heavy' range and into the 'too many' category. While the platform covers a broad domain (hiring, listings, streams, escrow, activation), this many tools could be split into smaller focused servers for maintainability and agent selection clarity.

Completeness4/5

The surface covers the core lifecycle well: search, hire, pay, communicate, approve, review. However, there is no generic cancel_job tool for regular jobs (only stop_stream for streams) and no update_listing to edit an existing listing, leaving small but navigable gaps in lifecycle management.

Resources