Skip to main content
Glama

post_task

Create a real-world task and run the full screening cascade: policy_gate regex, task_shapes shape_match, a Claude LLM classifier when ANTHROPIC_API_KEY is set or SCREENING_LLM_FALLBACK when absent, then human_review parking when needed. Results in status open, rejected, or screening. Write instructions a stranger can execute. budget_max_minor is the all-in ceiling in integer minor units of currency; deadline is an ISO 8601 timestamp with a timezone. Latitude and longitude are decimal degrees.

The stored proof requirements are the union of each required capability's unwaivable floor, its default proof types, and your proof_requirements extras. proof_requirement_opt_outs waives a capability default where it isn't the product — e.g. ["geo_checkin"] on a photo task whose location doesn't matter. Waiving a capability floor (like geo check-in on an errand) returns a structured 422; floors are never waivable.

Set request_live_location=true only when the task genuinely needs it (e.g. meeting a courier, time-critical errands). Workers see the request before deciding; a worker who accepts the offer consents, live sharing turns on for the task's active window only, and you can poll the current point with get_worker_location. It cannot be added to a task later.

Set interactive=true to supervise the work live: find workers with interactive_ok=true, offer at least their interactive_rate_minor, then use start_interactive once they accept. Also creation-only.

Input Schema

NameRequiredDescriptionDefault
latYesLatitude where the work happens, decimal degrees.
lngYesLongitude where the work happens, decimal degrees.
titleYesShort summary a worker sees first, e.g. 'Photograph the storefront at 5th and Main'.
addressNoOptional street address shown to the worker alongside the map pin.
currencyNoISO-4217 currency code. USD is the only currency supported today.USD
deadlineYesWhen the work must be done, ISO-8601 UTC, e.g. '2026-06-21T18:00:00Z'.
interactiveNoMake this an interactive task: while the worker is live you can see stills from their phone camera, hear what they tell you, and guide them (start_interactive). Offered only to workers with interactive_ok, at their interactive_rate_minor. Cannot be added later.
instructionsYesWhat the worker must actually do, specific enough to finish without asking you. Screened before dispatch.
idempotency_keyNoOptional key of your own choosing so a retry does not post the task twice.
budget_max_minorYesMost you will pay for the work, integer minor units. Must sit within your per-task cap; see get_spend_status.
conclave_shareableNoLet this task's proof photos be shared in a Conclave finding (draft_conclave_post), never with the worker's name. The worker sees this on the offer before accepting. Cannot be added later.
proof_requirementsNoOptional proof types to require on top of whatever the capability already demands.
request_live_locationNoAsk the worker to share live location while working. They must consent; it is never automatic.
required_capabilitiesYesCapability slugs the worker must hold. Use exact slugs from list_capabilities -- an unknown slug is rejected.
proof_requirement_opt_outsNoOptional proof types to waive, where the capability permits waiving them.

Output Schema

NameRequiredDescriptionDefault
statusNo
task_idNo
screening_reasonNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / conclave_shareable
      Added value: +{
      +  "default": false,
      +  "description": "Let this task's proof photos be shared in a Conclave finding (draft_conclave_post), never with the worker's name. The worker sees this on the offer before accepting. Cannot be added later.",
      +  "title": "Conclave Shareable",
      +  "type": "boolean"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / interactive
      Added value: +{
      +  "default": false,
      +  "description": "Make this an interactive task: while the worker is live you can see stills from their phone camera, hear what they tell you, and guide them (start_interactive). Offered only to workers with interactive_ok, at their interactive_rate_minor. Cannot be added later.",
      +  "title": "Interactive",
      +  "type": "boolean"
      +}
  3. Changed14 schema fields changed
    • addedInput schema / properties / address / description
      Added value: +"Optional street address shown to the worker alongside the map pin."
    • addedInput schema / properties / budget_max_minor / description
      Added value: +"Most you will pay for the work, integer minor units. Must sit within your per-task cap; see get_spend_status."
    • addedInput schema / properties / currency / description
      Added value: +"ISO-4217 currency code. USD is the only currency supported today."
    • addedInput schema / properties / deadline / description
      Added value: +"When the work must be done, ISO-8601 UTC, e.g. '2026-06-21T18:00:00Z'."
    • addedInput schema / properties / idempotency_key / description
      Added value: +"Optional key of your own choosing so a retry does not post the task twice."
    • addedInput schema / properties / instructions / description
      Added value: +"What the worker must actually do, specific enough to finish without asking you. Screened before dispatch."
    • addedInput schema / properties / lat / description
      Added value: +"Latitude where the work happens, decimal degrees."
    • addedInput schema / properties / lng / description
      Added value: +"Longitude where the work happens, decimal degrees."
    • addedInput schema / properties / proof_requirement_opt_outs / description
      Added value: +"Optional proof types to waive, where the capability permits waiving them."
    • addedInput schema / properties / proof_requirements / description
      Added value: +"Optional proof types to require on top of whatever the capability already demands."
    • addedInput schema / properties / request_live_location / description
      Added value: +"Ask the worker to share live location while working. They must consent; it is never automatic."
    • addedInput schema / properties / required_capabilities / description
      Added value: +"Capability slugs the worker must hold. Use exact slugs from list_capabilities -- an unknown slug is rejected."
    • addedInput schema / properties / title / description
      Added value: +"Short summary a worker sees first, e.g. 'Photograph the storefront at 5th and Main'."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "screening_reason": {
      +      "anyOf": [
      +        {
      +          "type": "string"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "title": "Screening Reason"
      +    },
      +    "status": {
      +      "anyOf": [
      +        {
      +          "type": "string"
      +        },
      +        {
      +          "type": "integer"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "title": "Status"
      +    },
      +    "task_id": {
      +      "anyOf": [
      +        {
      +          "type": "string"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "title": "Task Id"
      +    }
      +  },
      +  "title": "TaskWriteOut",
      +  "type": "object"
      +}
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With annotations covering safety hints, the description still adds substantial behavioral context: the full screening cascade, the possible status outcomes (open/rejected/screening), consent semantics for live location, the structured 422 on unwaivable floors, and the irreversibility of request_live_location/interactive/conclave_shareable. This is rich disclosure beyond 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.

Conciseness4/5

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

Purpose and cascade are front-loaded, and each paragraph addresses a distinct parameter group. It is dense and mostly earns its length, though the lat/lng restatement and a few clauses are mildly redundant with the schema.

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 15-param, 7-required mutation tool with an output schema, the description covers the pipeline, the creation-only constraints, error behavior, and proof-requirement composition. An agent has enough to call it correctly without further docs.

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 100%, so the baseline is 3, but the description meaningfully enriches several params: budget_max_minor is the all-in ceiling in minor units, deadline is ISO 8601 with timezone, lat/lng are decimal degrees, and the union semantics of proof_requirements/opt_outs are explained. It stops short of documenting every field (e.g. idempotency_key, conclave_shareable are only in the schema).

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+resource ('Create a real-world task') and even names the internal pipeline it triggers (policy_gate, task_shapes, LLM classifier, human_review). It clearly distinguishes itself from siblings like update_task, create_task_chain, and make_offer.

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 context for the optional flags (when request_live_location or interactive is genuinely needed) and warns that both are creation-only. However, it never explicitly contrasts when to use this tool versus create_task_chain or make_offer, leaving that routing to inference.

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.