Mundane

update_task

Idempotent

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.

Input Schema

TableJSON 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

TableJSON 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?

The description goes far beyond the annotations, disclosing material side effects: the full screening cascade, possible rejection, pending-offer withdrawal, automatic escrow refund, and immutability of certain task states. These behavioral traits are not visible in the annotations, which only include generic read-only/destructive/idempotent flags. No contradiction with annotations.

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?

The description is dense but well-structured, front-loading the core purpose, then layer-by-layer constraints, side effects, and error conditions. Every sentence contributes new information without redundancy or filler.

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 mutation tool, the description covers the critical behavioral nuances an agent needs: the re-screening cascade, offer/escrow implications, when changes are skipped, and immutable states. With an output schema present, return-value details are not required, and the provided description is fully adequate for safe invocation.

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?

The schema already has 100% parameter coverage, so the baseline is 3. The description adds value beyond the schema by grouping parameters into material (title, instructions, location, capabilities, proof requirements) versus budget/deadline-only, and clarifies the 'at least one field required' constraint that the schema's required list implies but does not state.

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: 'Amend an unassigned task,' immediately distinguishing it from cancel/post operations. It states the precise operational scope (unassigned tasks only) and the action it performs, so an agent knows exactly what invoking this tool does.

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?

Explicitly tells when to use this tool instead of cancel-and-repost, and details when it is refused ('409') or when different behavior applies (material changes re-screening vs budget/deadline-only changes). This is model usage guidance with clear exclusions.

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.