Skip to main content
Glama

Able and Agent

Commission an errand (ACT)

commission_act
DestructiveIdempotent

Create an ACT and fund it, 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. Within the Mandate your Principal set, it is funded and 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
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). The Human pays for the purchases and is paid back what's on the receipts, 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.
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. Changed1 schema field changed
    • changedInput schema / properties / budget / description
      Previous 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."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). The Human pays for the purchases and is paid back what's on the receipts, 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."
  2. 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."
  3. 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"
      +]
  4. 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"
      +]
  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.2/5.0
Behavior4/5

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

The annotations already mark this as destructive, open-world, and idempotent, and the description adds meaningful behavior: funding under the Mandate, board posting, Terms §15 checking, and the returned ACT/Mandate/terms. It does not fully spell out reversibility or cancellation implications, so it is strong but not exhaustive.

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 main action and constraints are front-loaded, which suits a complex 20-parameter financial tool. Some sentences are dense and the Principal-facing ID instruction is not strictly needed for invocation, but most content earns its place.

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 complex destructive financial tool with no output schema, the description covers the essential context: creation and funding, Mandate enforcement, over-limit behavior, terms checking, response contents, and money/time formatting. The detailed schema fills in parameter-level specifics.

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 carries most parameter meaning. The description adds cross-cutting formatting notes about dollar strings, integer cents, and RFC 3339 instants, but it does not materially explain the 20 individual parameters 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 states a specific verb and resource: 'Create an ACT and fund it, as POST /api/v1/acts.' It also distinguishes this creation/funding action from quote_act, which is named for pre-posting terms review.

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?

It gives clear sequencing guidance, including showing the Principal the terms from quote_act before posting. It also explains Mandate-limit handling through overLimit, but does not explicitly state when not to use this tool or name other creation alternatives beyond quote_act.

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