Skip to main content
Glama
Sign In

mFlow

by io.m-flow
OverviewDiscussionsAdmin

get_coding_agent_status

Read-only

Get the current execution status of a coding agent task by codeAgentTaskId, or by the linked standalone task's taskId/taskKey. Use this to check progress or completion after assign_to_coding_agent; it does not block or wait, so poll it rather than expecting a final result in one call. While status is queued the task is waiting for a free sandbox and queuePosition is its place in line (1 = next); it is null once the task has started.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_coding_agent_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
taskIdNoInternal standalone task ID linked to the coding agent task (the same id passed to assign_to_coding_agent).
taskKeyNoHuman-readable standalone task key linked to the coding agent task, e.g. "MVPB-120".
codeAgentTaskIdNoCodeAgent task ID returned by assign_to_coding_agent. Provide this, or taskId, or taskKey — whichever you have on hand.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / codeAgentTaskId / description
      Previous value: -"CodeAgent task ID returned by assign_to_coding_agent"New value: +"CodeAgent task ID returned by assign_to_coding_agent. Provide this, or taskId, or taskKey — whichever you have on hand."
    • changedInput schema / properties / taskId / description
      Previous value: -"Internal standalone task ID linked to the coding agent task"New value: +"Internal standalone task ID linked to the coding agent task (the same id passed to assign_to_coding_agent)."
    • changedInput schema / properties / taskKey / description
      Previous value: -"Human-readable standalone task key, e.g. \"MVPB-120\""New value: +"Human-readable standalone task key linked to the coding agent task, e.g. \"MVPB-120\"."
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds valuable non-blocking behavior and the queuePosition semantics (1 = next, null once started), which go beyond the annotations. It could mention additional status values beyond 'queued', but the provided context is strong.

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 sentences with no filler. The core purpose is stated first, followed by essential usage nuance (non-blocking, polling) and queue detail. Every sentence contributes to the agent's correct invocation.

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?

The description covers the essential invocation details: how to identify the task, when to poll, and what queuePosition means. With no output schema, it could have briefly noted the possible status values (e.g., queued, running, completed) to set expectations, but the provided guidance is sufficient for an agent to call it correctly.

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 each parameter is already fully documented. The description adds the alternative usage pattern (any of the three identifiers) and the linkage to assign_to_coding_agent, but this is largely redundant with the schema text for codeAgentTaskId and taskId. No meaningful extra value beyond 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 clearly states the verb 'Get' and the resource 'current execution status of a coding agent task', with explicit lookup keys (codeAgentTaskId, taskId, taskKey). It distinguishes itself from siblings like assign_to_coding_agent by being the status getter, leaving no ambiguity about its role.

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?

It explicitly tells the agent to use this after assign_to_coding_agent, clarifies it is non-blocking and should be polled, and provides context on queue behavior. This gives clear when-to-use guidance and sets expectations for repeated calls, differentiating it from a one-shot operation.

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

All mFlow toolsInspect
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.

Resources