Skip to main content
Glama
songzhifei512

multi-agent-bridge

task_fail

Mark a task as failed with a reason when an agent cannot complete it, enabling the multi-agent team to update task status and proceed accordingly.

Instructions

Mark a task failed with reason (e.g. could not complete).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultNo
task_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It states the core state change and that a reason can be provided, but it does not disclose whether the failure is reversible, whether dependent tasks are affected, or any side effects. This is thin for a mutation tool.

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?

A single sentence that is verb-first, informative, and includes an example. Every word earns its place; there is no redundant restatement.

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?

The tool mutates task state, has no annotations, no output schema, and an undocumented schema, yet the description only covers the basic action. Missing guidance on when to fail versus complete or escalate, and on the role of the result field, leaves the context incomplete for reliable selection and 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 0%, so the description must compensate. 'with reason (e.g. could not complete)' gives meaning to the optional result parameter, and 'task' implies task_id. However, it doesn't explicitly map these to the schema parameter names or discuss requiredness beyond what the schema already provides.

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?

The verb 'Mark' plus resource 'task failed' is specific and immediately distinguishes this from siblings like task_complete or task_escalate. The parenthetical reason adds useful context. However, it doesn't explicitly name an alternative tool, so it falls just short of the top score.

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

Usage Guidelines2/5

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

The description provides no when-to-use or when-not-to-use guidance. It does not mention alternatives such as task_complete, task_escalate, or task_interrupt, leaving the agent to infer selection solely from the tool name and sibling list.

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