Skip to main content
Glama

agents_task_complete

Report that an agent run handed to you by DialogBrain is over: a Claude Code agent task, or a run started in an external agent. Call this when you finish processing it.

Input Schema

NameRequiredDescriptionDefault
successNoWhether the task completed successfully (default true)
summaryNoBrief summary of what was done. When the task came from the AI panel (reply_to='panel'), this is your answer and is shown to the person there, in full; when it came from another agent's session (reply_to='agent'), it is delivered to that session as your answer.
trace_idYesTrace ID from the agent task event
in_workspaceNoRun this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / summary / description
      Previous value: -"Brief summary of what was done. When the task came from the AI panel (reply_to='panel'), this is your answer and is shown to the person there, in full."New value: +"Brief summary of what was done. When the task came from the AI panel (reply_to='panel'), this is your answer and is shown to the person there, in full; when it came from another agent's session (reply_to='agent'), it is delivered to that session as your answer."
  2. Changed3 schema fields changed
    • addedInput schema / properties / success / default
      Added value: +true
    • changedInput schema / properties / success / description
      Previous value: -"Whether the task completed successfully"New value: +"Whether the task completed successfully (default true)"
    • changedInput schema / required
      Previous value: -[
      -  "trace_id",
      -  "success"
      -]New value: +[
      +  "trace_id"
      +]
  3. Changed1 schema field changed
    • changedInput schema / properties / summary / description
      Previous value: -"Brief summary of what was done"New value: +"Brief summary of what was done. When the task came from the AI panel (reply_to='panel'), this is your answer and is shown to the person there, in full."
  4. Changed1 schema field changed
    • addedInput schema / properties / in_workspace
      Added value: +{
      +  "description": "Run this one call in this workspace id instead of the session's. Nothing is stored; other sessions are not affected.",
      +  "type": "integer"
      +}
  5. Added
  6. Removed
  7. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare this is a non-read-only, non-idempotent write. The description adds that the run may originate from an external agent, which is useful context, but it does not warn that duplicate calls are not idempotent or describe the effect on the receiving session.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Two sentences, front-loaded with the action, no filler. The clause listing run types is slightly clunky but earns its place by widening applicability.

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

Completeness2/5

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

This is a non-idempotent state-changing call (idempotentHint=false, readOnlyHint=false) with no output schema, yet the description never says what happens downstream: whether the trace is closed, whether the caller's session resumes, or what a repeat call does. It covers the what and the when, but leaves the consequences of the mutation entirely unstated.

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 100% and the schema itself documents the success default, the trace_id source, and the panel-vs-agent delivery semantics of summary. The description adds the framing that the run came 'from DialogBrain' and may be external, but contributes no parameter detail beyond the schema; baseline 4 applies since zero compensation is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and object ('Report that an agent run ... is over') and narrows the scope to runs handed over by DialogBrain, including Claude Code agent tasks and external agent runs. It does not distinguish itself from near-siblings such as job_complete or agent_handoff, so an agent still has to guess which completion path applies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The trigger is stated plainly ('Call this when you finish processing it'), which is enough to know the moment of use. There is no when-not guidance and no reference to alternatives like job_complete, so the routing decision is only implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources