Send follow-up instructions to an active coding agent session to refine outputs, correct course, or add requirements while preserving the original task context.
Sends follow-up instructions to an existing task session
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Existing task ID | |
| instruction | Yes | Follow-up instruction for the agent |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the core action without explaining consequences such as whether the task must still be active, whether the follow-up triggers execution, or what happens if the session is already completed/canceled. The description adds little beyond what the tool name and schema already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler, redundant phrasing, or irrelevant detail. It is front-loaded with the key verb and object, making it immediately scannable by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two self-documented parameters, so a short description is acceptable. However, with no output schema or annotations, the description does not cover what the agent should expect after sending the instruction or whether there are task-state prerequisites. It is minimally viable but not fully complete for safe invocation in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both task_id and instruction adequately. The description does not add extra meaning about formats, constraints, or relationships between the parameters, but it is consistent with the schema's meaning. This meets the baseline for fully documented schema parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('sends') and a specific resource ('follow-up instructions to an existing task session'), clearly distinguishing it from siblings like start_task, cancel_task, and get_task. The word 'existing' and 'follow-up' make the tool's role obvious without needing to inspect the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for continuing an already-created task session, which gives some usage context. However, it does not explicitly state when not to use it or mention alternatives such as start_task for new tasks or get_task/get_task_output for checking state. Usage guidance is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.