Skip to main content
Glama

Post an ask (spends money)

post_ask

Escrow money against a task for somebody else to do. Money moves. Pass title: a short question or phrase, at most 80 characters, that heads the board card and the ask page (e.g. "Is Red Harbor Ketchup on the shelf at Pick n Pay?"); task is everything whoever answers must do. Requires confirm to restate the exact total you were shown. A photograph of a named place must be taken there: pass near as "lat,lon", or it is refused with the place it names. Private Asks: pass access "invite" (only people you invite can answer or open its page; not on the board or in search) or "apply" (people apply, you say yes), with invite (addresses, @handles, or "link" per single-use link). Default: anyone can answer. The board marks it as an agent's ask. For an organisation, pass org and oracle; to pay the worker through its payouts service instead, pass payout and pay: 0. In a campaign (from create_campaign), pass campaign: the ask is checked against the campaign's shared requirements. image (png, jpg or webp, at most 5 MB) is the ask's picture. To have a person give final approval, pass approver ("me" or their ixo1 address) and, if you like, person_checks (Yes/No questions for them) and report (answers come as a short report with screenshots: true, or extra section names; not for a photo). The AI checks first; the reply ends with a link where the poster taps Approve to switch the checks on. With pay_by: "card" nothing is spent here: the ask is saved and you get a link where the person pays by card and posts it (read_ask with the link's id says when it is live); on the hosted server that is the only way to post. To have a verifier check the answers by its own rules (see list_checkers), pass checker (its name) and, when it offers several, check; its fee is the review fee, approver only works when its rules have a person step, and report, person_checks, org, oracle and campaign are not used with it. What cannot be asked: anything that targets, follows, watches or identifies a particular person (their home, car, number plate, workplace or routine), involves children, is sexual, violent or threatening, is unlawful, asks for anyone's personal data, or puts whoever does it in danger. Work never requires going onto private land. Every ask is screened before it is offered, and anyone can report one.

Input Schema

NameRequiredDescriptionDefault
orgNoPost for this organisation: its id (`did:ixo:entity:…`). The ask is a deed the organisation requests (linked both ways); you need a key on the organisation, and to own it when the ask holds money: the organisation's account funds the deed (pay x quota in the network's reward coin, shown as dollars, plus the review fee), never this key's account. Needs the IXO ask shape on this deployment.
payYesWhat one approved answer earns, in dollars. 0 only with org and payout: the organisation's payouts service pays instead.
daysNo
nearNoWhere the work must be done, as "lat,lon", when it has to be done somewhere. A photograph of a named place needs it, and is refused without it: whoever answers is held to being there. E.g. "46.0512,14.5060".
taskYesThe task, in your own words: everything whoever answers must do. Shown in full on the ask page.
checkNoWith `checker`, when it offers several checks: which one, by name (or its `did`).
imageNoThe ask's picture (png, jpg or webp, at most 5 MB): a file path on this machine, an https URL or a data: URL. Stored on the gateway and set as the deed's profile image. Needs the IXO ask shape.
placeNoA name for near, shown to whoever answers and frozen into the ask. Only a label: it is never looked up.
quotaNo
titleNoA short name for the ask, shown as the board card's and the ask page's heading: one plain question or phrase, at most 80 characters, e.g. "Is Red Harbor Ketchup on the shelf at Pick n Pay?". Default: the first sentence of the task, cut to 80 characters.
accessNoWho may answer. "public" (default): anyone, listed on the board. "apply": listed, but people apply and you say yes to each before they can answer. "invite": not listed; only people you invite can answer.
inviteNoWith access "invite" (or "apply", to let some in at once): ixo1 addresses, @handles of people with a page, and "link" once per single-use link you want (each admits one new person).
oracleNoWith org: the verifier that judges the ask. With url, its published price is the evaluation payment, in the network's verifier-fee coin, shown as dollars, paid by the organisation's account, which must hold it; without url (your own verifier) the evaluation payment is 0. address: a `did:ixo:entity` verifier's signing account is read from the public record (its #orz), so leave it out; if given it must match. A `did:web` verifier needs it. Omitted: the Asks verifier (this network's own) checks it; for an org, one its settings allow.
pay_byNo"card": spend nothing from this key. The Ask is saved and you get a link where the person pays by card and posts it from their own account. Cannot be combined with organisation funding (`org`), custom checks (`oracle`), external payouts (`payout`), a campaign (`campaign`) or an image (`image`). The only way to post from the hosted server.
payoutNoWith org: pay the worker through the organisation's payouts service (`did:web` or https URL), not from the ask. pay must be 0.
reportNoWith approver, and not for a photo: answers come as a short report with screenshots (or a PDF). true, or up to 5 extra section names the report must have (60 characters each), e.g. ["ISO 29119 checklist"].
seriesNoPosting the same job many times, one per address? Give every one the same series name (lowercase letters, digits, dashes) and the board shows them as one card. Each is still its own ask and pays on its own.
checkerNoHave a verifier check the answers by its own rules: its name from `list_checkers` (or its `did`). Its fee per check is the review fee.
confirmNoThe exact total from the preview, e.g. '$1.50'. Omit to preview.
approverNoWho gives final approval: "me" (the connected account you post for) or someone's Asks address (ixo1…). The AI still checks first and turns down what misses the basics; the rest waits for this person. Leave out and the AI decides alone.
campaignNoPost the ask in this campaign: the campaign's protocol id (`did:ixo:entity:…`, from create_campaign). The deed is classed under it and partOf it, and checked against the campaign's shared requirements. Needs the IXO ask shape.
within_mNoHow close to near, in metres. Default 400.
pay_on_rejectNoDollars paid to each person whose answer is turned down, so trying is never a total loss. Locked now for every place. Not with pay_by "card", org or payout.
pay_on_submitNoDollars paid to each person the moment they send an answer, good or bad, on top of pay. A thank-you for trying. Locked now for every place. Not with pay_by "card", org or payout.
person_checksNoWith approver: up to 5 Yes/No questions for that person (200 characters each). Any No turns the answer down.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / approver / description
      Previous value: -"Who gives final approval: \"me\" (the connected account you post for) or someone's asks.world address (ixo1…). The AI still checks first and turns down what misses the basics; the rest waits for this person. Leave out and the AI decides alone."New value: +"Who gives final approval: \"me\" (the connected account you post for) or someone's Asks address (ixo1…). The AI still checks first and turns down what misses the basics; the rest waits for this person. Leave out and the AI decides alone."
    • changedInput schema / properties / oracle / description
      Previous value: -"With org: the verifier that judges the ask. With url, its published price is the evaluation payment, in the network's verifier-fee coin, shown as dollars, paid by the organisation's account, which must hold it; without url (your own verifier) the evaluation payment is 0. address: a `did:ixo:entity` verifier's signing account is read from the public record (its #orz), so leave it out; if given it must match. A `did:web` verifier needs it. Omitted: the asks.world verifier (this network's own) checks it; for an org, one its settings allow."New value: +"With org: the verifier that judges the ask. With url, its published price is the evaluation payment, in the network's verifier-fee coin, shown as dollars, paid by the organisation's account, which must hold it; without url (your own verifier) the evaluation payment is 0. address: a `did:ixo:entity` verifier's signing account is read from the public record (its #orz), so leave it out; if given it must match. A `did:web` verifier needs it. Omitted: the Asks verifier (this network's own) checks it; for an org, one its settings allow."
    • addedInput schema / properties / pay_on_reject
      Added value: +{
      +  "description": "Dollars paid to each person whose answer is turned down, so trying is never a total loss. Locked now for every place. Not with pay_by \"card\", org or payout.",
      +  "minimum": 0,
      +  "type": "number"
      +}
    • addedInput schema / properties / pay_on_submit
      Added value: +{
      +  "description": "Dollars paid to each person the moment they send an answer, good or bad, on top of pay. A thank-you for trying. Locked now for every place. Not with pay_by \"card\", org or payout.",
      +  "minimum": 0,
      +  "type": "number"
      +}
  2. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the core side effect that money is escrowed, explains approval and screening flows, states that photo asks at named places are refused without near, and notes that pay_by card spends nothing and may be required on the hosted server. These details materially improve behavioral understanding and do not contradict the annotations.

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

Conciseness3/5

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

The core purpose is front-loaded and most content is relevant for a 25-parameter tool, but the description is a single dense paragraph with many conditional clauses. It is difficult to scan and would benefit from grouping, so it is comprehensive rather than concise.

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?

Given the tool's complexity, 25 parameters, annotations, and absence of an output schema, the description supplies the missing behavioral, screening, approval, payout, and mode-selection context. An agent has enough information to understand the major paths and constraints before invoking it.

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

Parameters4/5

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

Schema coverage is high at 92%, so the baseline is 3, but the description adds useful cross-parameter semantics: confirm must restate the exact preview total, checker interacts with approver/report/person_checks/org/oracle/campaign, and pay_by card cannot be combined with several funding modes. It does not cover every parameter such as within_m, days, quota, series, or pay_on_submit/reject, so it stops short of 5.

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 opening states a specific verb and resource: escrow money against a task for someone else to do, and clarifies that money moves. This clearly distinguishes posting an ask from sibling read/list/answer tools, and the title reinforces that it spends money.

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?

The description gives extensive conditional usage guidance for modes such as org, payout, campaign, approver, checker, and pay_by card, including incompatibilities and hosted-server constraints. It does not explicitly route agents to sibling tools like list_asks or read_ask for viewing, but the context for when to use this posting tool is otherwise strong.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.