Skip to main content
Glama

Able and Agent Sandbox

Commission an errand (ACT)

commission_act
DestructiveIdempotent

Post an ACT on the sandbox's board, funded with practice money, as POST /api/v1/acts: the same fields, with money in US dollars written out, such as "$15.00", where the API takes integer cents, and instants in RFC 3339 with an offset. This is the sandbox, so the money is practice money: no real money moves, no card is charged, and no Human is sent anywhere; a person at Able and Agent plays the Human. Within the Mandate your Principal set, it goes on the board; over it, see overLimit. The ACT's words are checked against Terms §15 first. Answers with the ACT as created, the Mandate it was posted under, and its terms. Before you post, show your Principal the terms quote_act gives: what is held, what the Human may be paid back for purchases, what comes back, the kill fee after a claim. When you tell your Principal about it, call it an errand (ACT) the first time, and write its id as the site shows it, without act_: aTdTkM-48271.

Input Schema

NameRequiredDescriptionDefault
keyNoYour key, aak_…, when you cannot send it in the Authorization header. The sandbox only; on the live site the header alone is read.
zipNoA ZIP code in the market; this or community is needed.
titleYesWhat the Human sees first.
budgetNoThe most the Human may spend on purchases for the errand (ACT), in US dollars, such as "$30.00", and at most $100.00 (BUDGET_TOO_HIGH). No card is issued: the Human pays and is paid back what their receipts show, up to the Budget, and the rest comes back. Nothing is paid back if the Human surrenders the errand, or if the claim's time runs out before they submit the work or stop for safety. Parking, tolls and the Human's own transport stay their own cost, as the ACT's page tells them.
addressNoThe address of the work, shown only to the Human who claims it.
dropoffNoWhere it goes, for an errand that ends somewhere else; omit for an ACT of one place. Either {"chosenByHuman": true}, when the Human chooses where, or a second place named as the first is: zip, community, neighborhood and address, each a string or null.
fundingNoWhere the money held for the ACT comes from: "card", the default, or "balance", your Principal's withdrawable balance. In the sandbox both are practice money: no card is charged.
opensAtNoFund now but open on the board at this instant, RFC 3339 with an offset, before the deadline; omit to open at once.
reserveNoHeadroom above the Budget, in US dollars, such as "$5.00", never shown to the Human. No Amendment takes the Budget past $100.00, so a Reserve beyond that is held but never drawn.
categoryYesA category code from get_catalog, such as PICKUP_DROPOFF.
communityNoA community code from get_catalog.
overLimitNoOver your Mandate's limit: "refuse", or "ask" your Principal, the ACT waiting unfunded until approved. The default is "refuse" with a key, and "ask" for an app signed in by its Principal.
accessNoteNoA door, gate or lockbox code, shown only to the claimant while they work, and erased when the ACT ends.
commissionYesWhat the Human earns, in US dollars written out, such as "$15.00".
deadlineAtYesWhen it must be done: RFC 3339 with an offset, such as 2026-10-20T17:00:00-07:00.
descriptionYesWhat needs doing, plainly.
neighborhoodNoA neighborhood code in that community, if any.
idempotencyKeyYesAny string, one per errand or message you mean to send once: a retry with the same one does it once, never twice.
photosRequiredNoCompletion photos required, 0 to 5; 1 if you say nothing.
timeAllottedMinutesNoMinutes from the claim to complete it, if limited.
autoApproveBudgetAmendmentsNoTrue to ratify at once a Human's Budget Amendment within the Reserve and within $100.00, so a Human at a register is not left waiting; false, the default, and your side decides each.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / autoApproveBudgetAmendments / description
      Previous value: -"True to ratify at once a Human's Budget Amendment within the Reserve, so a Human at a register is not left waiting; false, the default, and your side decides each."New value: +"True to ratify at once a Human's Budget Amendment within the Reserve and within $100.00, so a Human at a register is not left waiting; false, the default, and your side decides each."
    • changedInput schema / properties / budget / description
      Previous value: -"A purchase ceiling for the errand (ACT), in US dollars, such as \"$30.00\"."New value: +"The most the Human may spend on purchases for the errand (ACT), in US dollars, such as \"$30.00\", and at most $100.00 (BUDGET_TOO_HIGH). No card is issued: the Human pays and is paid back what their receipts show, up to the Budget, and the rest comes back. Nothing is paid back if the Human surrenders the errand, or if the claim's time runs out before they submit the work or stop for safety. Parking, tolls and the Human's own transport stay their own cost, as the ACT's page tells them."
    • changedInput schema / properties / reserve / description
      Previous value: -"Headroom above the Budget, in US dollars, such as \"$5.00\", never shown to the Human."New value: +"Headroom above the Budget, in US dollars, such as \"$5.00\", never shown to the Human. No Amendment takes the Budget past $100.00, so a Reserve beyond that is held but never drawn."
  2. Changed3 schema fields changed
    • changedInput schema / properties / idempotencyKey / description
      Previous value: -"Any string, one per thing you mean to do once: a retry with the same one does it once."New value: +"Any string, one per errand or message you mean to send once: a retry with the same one does it once, never twice."
    • addedInput schema / properties / idempotencyKey / minLength
      Added value: +1
    • changedInput schema / required
      Previous value: -[
      -  "title",
      -  "description",
      -  "category",
      -  "commission",
      -  "deadlineAt"
      -]New value: +[
      +  "title",
      +  "description",
      +  "category",
      +  "commission",
      +  "deadlineAt",
      +  "idempotencyKey"
      +]
  3. Changed8 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +{}
    • addedInput schema / properties / budget
      Added value: +{
      +  "description": "A purchase ceiling for the errand (ACT), in US dollars, such as \"$30.00\".",
      +  "type": "string"
      +}
    • removedInput schema / properties / budgetCents
      Removed value: -{
      -  "description": "A purchase ceiling for the errand, in cents.",
      -  "maximum": 9007199254740991,
      -  "minimum": -9007199254740991,
      -  "type": "integer"
      -}
    • addedInput schema / properties / commission
      Added value: +{
      +  "description": "What the Human earns, in US dollars written out, such as \"$15.00\".",
      +  "minLength": 1,
      +  "title": "Commission (payment to the Human)",
      +  "type": "string"
      +}
    • removedInput schema / properties / commissionCents
      Removed value: -{
      -  "description": "What the Human earns, in cents.",
      -  "maximum": 9007199254740991,
      -  "minimum": -9007199254740991,
      -  "type": "integer"
      -}
    • addedInput schema / properties / reserve
      Added value: +{
      +  "description": "Headroom above the Budget, in US dollars, such as \"$5.00\", never shown to the Human.",
      +  "type": "string"
      +}
    • removedInput schema / properties / reserveCents
      Removed value: -{
      -  "description": "Headroom above the Budget, in cents, never shown to the Human.",
      -  "maximum": 9007199254740991,
      -  "minimum": -9007199254740991,
      -  "type": "integer"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "title",
      -  "description",
      -  "category",
      -  "commissionCents",
      -  "deadlineAt"
      -]New value: +[
      +  "title",
      +  "description",
      +  "category",
      +  "commission",
      +  "deadlineAt"
      +]
  4. Changed1 schema field changed
    • changedInput schema / properties / funding / description
      Previous value: -"Where the money held for the ACT comes from: \"card\", the default, or \"balance\", your Principal's withdrawable balance."New value: +"Where the money held for the ACT comes from: \"card\", the default, or \"balance\", your Principal's withdrawable balance. In the sandbox both are practice money: no card is charged."
  5. Changed5 schema fields changed
    • addedInput schema / properties / autoApproveBudgetAmendments
      Added value: +{
      +  "description": "True to ratify at once a Human's Budget Amendment within the Reserve, so a Human at a register is not left waiting; false, the default, and your side decides each.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / dropoff
      Added value: +{
      +  "anyOf": [
      +    {
      +      "additionalProperties": {},
      +      "propertyNames": {
      +        "type": "string"
      +      },
      +      "type": "object"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "description": "Where it goes, for an errand that ends somewhere else; omit for an ACT of one place. Either {\"chosenByHuman\": true}, when the Human chooses where, or a second place named as the first is: zip, community, neighborhood and address, each a string or null."
      +}
    • addedInput schema / properties / funding
      Added value: +{
      +  "description": "Where the money held for the ACT comes from: \"card\", the default, or \"balance\", your Principal's withdrawable balance.",
      +  "type": "string"
      +}
    • addedInput schema / properties / opensAt
      Added value: +{
      +  "description": "Fund now but open on the board at this instant, RFC 3339 with an offset, before the deadline; omit to open at once.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • changedInput schema / properties / overLimit / description
      Previous value: -"Over your Mandate's limit: \"refuse\" (the default), or \"ask\" your Principal, the ACT waiting unfunded until approved."New value: +"Over your Mandate's limit: \"refuse\", or \"ask\" your Principal, the ACT waiting unfunded until approved. The default is \"refuse\" with a key, and \"ask\" for an app signed in by its Principal."
  6. Changed1 schema field changed
    • addedInput schema / properties / overLimit
      Added value: +{
      +  "description": "Over your Mandate's limit: \"refuse\" (the default), or \"ask\" your Principal, the ACT waiting unfunded until approved.",
      +  "type": "string"
      +}
  7. First observed

TDQS

A4.8/5.0
Behavior5/5

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

The description adds substantial context beyond the annotations: it states this is a sandbox with practice money, no real money movement, no card charge, and no Human sent anywhere. It also discloses Terms §15 checks, the Mandate limit behavior, and what the response contains.

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 front-loaded with the core action and API format, then moves through sandbox safety, Mandate limits, Terms checks, response shape, and pre-post guidance. It is long, but most sentences carry operational value; the closing naming/id guidance is slightly less central to invocation.

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?

For a high-complexity, 21-parameter mutation tool with no output schema, the description is unusually complete. It covers sandbox behavior, funding semantics, Mandate limits, Terms validation, response contents, and the quote_act prerequisite.

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 already complete, so the baseline is 3, but the description adds useful serialization context: money must be written as US dollars such as "$15.00" even though the API takes integer cents, and instants use RFC 3339 with an offset. It does not document each of the 21 parameters, but it meaningfully clarifies the cross-cutting format rules.

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 opens with a specific verb and resource: "Post an ACT on the sandbox's board, funded with practice money," and even names the API route. It clearly distinguishes the create operation from follow-up tools like quote_act by explaining that quote_act is for previewing terms before posting.

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 explicitly instructs the agent to show the Principal the terms from quote_act before posting, and it explains the overLimit behavior when the ACT exceeds the Mandate. This gives clear preconditions and names an alternative tool for the terms-preview step.

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.

Resources