mFlow

update_standalone_status

Rename, recategorize, or assign a coding-agent role (agentRole) to an existing custom status on a standalone project. Use create_standalone_status instead to add a new one, or reorder_standalone_statuses to change column order without altering name/category.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	New display name for the status.
`color`	No	New display color for the status.
`category`	No	New rollup category: "todo", "in_progress", or "done".
`statusId`	Yes	The status to update — an id from that project's statuses list (see get_standalone_project).
`agentRole`	No	Set which coding-agent role this status plays: "working" (a linked task is moved here when the coding agent starts it) or "review" (moved here when it finishes). Assigning a role takes it off the status that had it; pass null to remove the role from this status. Only in_progress statuses can hold a role.
`projectId`	Yes	The project the status belongs to.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 24, 2026

addedInput schema / properties / agentRole

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "working",
+        "review"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Set which coding-agent role this status plays: \"working\" (a linked task is moved here when the coding agent starts it) or \"review\" (moved here when it finishes). Assigning a role takes it off the status that had it; pass null to remove the role from this status. Only in_progress statuses can hold a role."
+}

Changed5 schema fields changedSep 18, 2026

addedInput schema / properties / category / description

Added value: +"New rollup category: \"todo\", \"in_progress\", or \"done\"."

addedInput schema / properties / color / description

Added value: +"New display color for the status."

addedInput schema / properties / name / description

Added value: +"New display name for the status."

addedInput schema / properties / projectId / description
```
Added value: +"The project the status belongs to."
```

addedInput schema / properties / statusId / description

Added value: +"The status to update — an id from that project's statuses list (see get_standalone_project)."

First observedSep 18, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows it's a non-destructive mutation. The description adds that it modifies an existing status (not create/delete) but does not disclose side effects like role reassignment implications or permission requirements. Some context is present in the schema (e.g., agentRole behavior), but the description itself adds limited behavioral nuance 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.

Conciseness5/5

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

Two concise sentences: the first states the core purpose, the second provides alternatives and exclusions. No filler, and the key action is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with 100% schema parameter coverage and no output schema, the description gives sufficient orientation: what it updates, on what resource, and how it differs from siblings. It doesn't mention edge cases like agentRole only applying to in_progress statuses, but the schema covers that. Overall complete enough for correct invocation.

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 input schema fully documents all six parameters. The description adds a grouping of actions (rename, recategorize, assign role) that maps to parameters, but doesn't offer extra detail beyond what the schema provides. Baseline of 3 is appropriate.

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 specific verbs (rename, recategorize, assign role) acting on a specific resource (existing custom status on a standalone project). It explicitly distinguishes from siblings by naming create_standalone_status and reorder_standalone_statuses, making the tool's scope unambiguous.

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?

The description gives explicit when-to-use guidance and names alternatives: 'Use create_standalone_status instead to add a new one, or reorder_standalone_statuses to change column order without altering name/category.' This directly tells the agent when not to use this tool and what to use instead.

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

All mFlow tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?