Skip to main content
Glama
profilesearch

GoHireHumans

Official
by profilesearch
OverviewSchemaSourceRelated ServersDiscussionsAdmin

hire_worker

DestructiveIdempotent

Order a service listing to hire a provider and pay for the work, after the account owner approves the listing, price, and requirements.

Instructions

Order one service listing: hires its provider and pays for the work. Call only after the account owner has explicitly approved the listing, price and requirements. Needs GOHIREHUMANS_AUTH_TOKEN, or an API key with both the read scope and the write scope, plus a saved payment method on the employer account. Where checkout is configured, the saved card is charged immediately for the listing's current price plus a 1% platform fee and a fixed 3% processing charge. The charge isn't locked to an earlier quote, so re-check get_service_details just before ordering. The worker is paid only when the employer approves the delivered work with release_payment. A funded order has no self-serve cancel option. Safe to retry: the same idempotency_key resumes the original order instead of charging twice. Returns the order ID, amount and status for get_job_status(order_id).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
service_idYesNumeric ID of the service listing to order, from search_services, get_recommended or get_service_details
requirementsNoInstructions for the worker (what to deliver, details, deadline). Saved on the order.
budget_amountNoUSD amount with at most two decimal places, used only for custom-priced listings (required there). It is not a spending cap: fixed-price listings always charge the listed price, and hourly listings charge one hour at the listed rate.
idempotency_keyYesUnique key for this order (16-128 letters, digits, '.', '_', ':' or '-'). Reuse the exact same key when retrying an ambiguous or failed checkout; a different order with the same key is rejected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2.1.0
    • changedInput schema / properties / budget_amount / description
      Previous value: -"Canonical USD amount with at most two decimal places. Defaults to the service listing price if omitted."New value: +"USD amount with at most two decimal places, used only for custom-priced listings (required there). It is not a spending cap: fixed-price listings always charge the listed price, and hourly listings charge one hour at the listed rate."
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"Unique operation identity. Reuse this exact value when retrying an ambiguous or failed checkout."New value: +"Unique key for this order (16-128 letters, digits, '.', '_', ':' or '-'). Reuse the exact same key when retrying an ambiguous or failed checkout; a different order with the same key is rejected."
    • changedInput schema / properties / requirements / description
      Previous value: -"Specific requirements or instructions for the worker"New value: +"Instructions for the worker (what to deliver, details, deadline). Saved on the order."
    • changedInput schema / properties / service_id / description
      Previous value: -"The ID of the service listing to purchase"New value: +"Numeric ID of the service listing to order, from search_services, get_recommended or get_service_details"
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations declare destructiveHint/idempotentHint/openWorldHint, but the description goes further than they can: auth requirements (GOHIREHUMANS_AUTH_TOKEN or read+write scopes plus a saved payment method), immediate charge timing, the 1% platform fee and 3% processing charge, that the charge tracks the current price rather than an earlier quote, and that the worker is only paid via release_payment. It correctly explains the idempotency_key retry semantics that back the idempotentHint.

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

Conciseness5/5

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

Purpose, precondition, credentials, cost model, payment timing, irreversibility and retry safety are ordered by the sequence an agent would need them, and every sentence carries a distinct operational fact with no filler.

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

Completeness5/5

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 compensates by naming the return payload (order ID, amount, status) and the tool that consumes it. With auth, fees, charge timing, payout gating and cancel policy all covered, an agent has everything needed to invoke this safely.

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 schema already documents all four parameters including the budget_amount non-cap nuance and the key format. The description restates retry behavior for idempotency_key but adds no syntax or format detail beyond it, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Order one service listing: hires its provider and pays for the work" gives a specific verb, resource and the money-moving consequence in one line, and the closing sentence names the resulting artifact (order ID) routed to get_job_status. It does not explicitly say why an agent would pick this over the closest sibling create_job, so it falls short of full sibling differentiation.

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

Usage Guidelines5/5

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

It states a hard precondition ("Call only after the account owner has explicitly approved the listing, price and requirements") and names the sibling to consult first ("re-check get_service_details just before ordering"). It also flags the when-not case: a funded order has no self-serve cancel option, so the agent knows this is irreversible at order time.

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

Deploy Server

Other Tools