Mundane

update_task

DestructiveIdempotent

Amend an unassigned task instead of cancel-and-repost. Supply only the fields to change; at least one is required. Material changes (title, instructions, location, capabilities, proof requirements) re-run the FULL screening cascade — the response's status may come back rejected — and withdraw any pending offer with an automatic escrow refund. Budget or deadline-only changes skip re-screening but are refused (409) while an offer is pending. Accepted, in-progress, and rejected tasks are immutable; editing them returns 409, as does editing a step of a task chain.

Input Schema

Name	Required	Description
`lat`	No	New latitude, or omit to leave it unchanged.
`lng`	No	New longitude, or omit to leave it unchanged.
`title`	No	New title, or omit to leave it unchanged.
`address`	No	New street address, or omit to leave it unchanged.
`task_id`	Yes	The task to amend. It must not have been accepted by a worker yet.
`deadline`	No	New deadline, ISO-8601 UTC, or omit to leave it unchanged.
`instructions`	No	New instructions, or omit to leave them unchanged. Re-screened if supplied.
`budget_max_minor`	No	New maximum spend in integer minor units, or omit to leave it unchanged.
`proof_requirements`	No	Replacement proof requirements, or omit to leave them unchanged.
`required_capabilities`	No	Replacement capability slugs, or omit to leave them unchanged.

Output Schema

Name	Required	Description	Default
`status`	No
`task_id`	No
`screening_reason`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed11 schema fields changedSep 22, 2026

addedInput schema / properties / address / description

Added value: +"New street address, or omit to leave it unchanged."

addedInput schema / properties / budget_max_minor / description

Added value: +"New maximum spend in integer minor units, or omit to leave it unchanged."

addedInput schema / properties / deadline / description

Added value: +"New deadline, ISO-8601 UTC, or omit to leave it unchanged."

addedInput schema / properties / instructions / description

Added value: +"New instructions, or omit to leave them unchanged. Re-screened if supplied."

addedInput schema / properties / lat / description

Added value: +"New latitude, or omit to leave it unchanged."

addedInput schema / properties / lng / description

Added value: +"New longitude, or omit to leave it unchanged."

addedInput schema / properties / proof_requirements / description

Added value: +"Replacement proof requirements, or omit to leave them unchanged."

addedInput schema / properties / required_capabilities / description

Added value: +"Replacement capability slugs, or omit to leave them unchanged."

addedInput schema / properties / task_id / description

Added value: +"The task to amend. It must not have been accepted by a worker yet."

addedInput schema / properties / title / description

Added value: +"New title, or omit to leave it unchanged."

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"
+}

First observedSep 22, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations (destructiveHint, idempotentHint, openWorldHint) by disclosing that material changes re-run the FULL screening cascade, that the response status may return 'rejected', that pending offers are withdrawn with an automatic escrow refund, and which edits return 409 and why. These are exactly the side effects and failure modes an agent cannot infer from structured fields.

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?

Front-loads the purpose and the alternative, then layers behavioral consequences. Though long, every clause carries distinct information (screening cascade, 409 conditions, escrow refund, immutability) with no padding or repetition.

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?

An output schema exists, so return values need not be enumerated, yet the description still flags the one response field that matters (`status` can come back `rejected`). Combined with the immutability rules, 409 cases, and screening/refund behavior, an agent has everything needed to call this mutation safely.

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 100%, so the per-field descriptions ('or omit to leave it unchanged') carry the baseline. The description adds real meaning on top by partitioning the fields into material changes (title, instructions, location, capabilities, proof requirements) versus budget/deadline-only changes, which is what determines whether re-screening occurs.

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?

States a specific verb and resource (amend a task) and immediately distinguishes it from the obvious alternative workflow by naming 'cancel-and-repost'. It also scopes the target precisely as an 'unassigned task', so an agent can separate it from cancel_task/post_task without opening any schema.

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?

Gives explicit when-to-use (amend an unassigned task), when-not (accepted, in-progress and rejected tasks are immutable; chain steps are refused), and the alternative it replaces (cancel-and-repost). It also spells out the partial-update contract ('supply only the fields to change; at least one is required') and the pending-offer condition that governs budget/deadline edits.

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

All Mundane tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.