ai-agent-channel

resolve_message

Mark an action_required message as done, recording who closed it, when, and a note; returns blocked tasks now unblocked so their owners can resume.

Instructions

Mark an action_required message as resolved. Records who closed it, when, and an optional resolution note. The response lists 'unblocked' — blocked tasks that were waiting on this message; tell their owner or resume them. Resolving an already-resolved message is a no-op. Either party may resolve (always attributed via resolved_by), but the etiquette is explicit: for an action_required message the executor is the ADDRESSEE (to) — the addressee resolves with a note naming what was done; the author (from) verifies and uses reopen_message if unsatisfied, or confirm_resolution if satisfied. The surfacing is SYMMETRIC: whoever resolves, the message keeps surfacing in the OTHER participant's channel_status().resolved_for_you until they confirm or reopen — a resolve is never silent in either direction. So cancelling your own request is legitimate: resolve it yourself with a note like 'cancelled, not needed' and the addressee will see it and confirm ('understood, dropping it'). What is NOT legitimate is resolving a debt the other side owes you as if the work were done.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`message_id`	Yes
`resolution_note`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 12, 2026

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and delivers: attribution via resolved_by, no-op on already-resolved messages, the symmetric surfacing contract via channel_status().resolved_for_you, and the fact that a resolve is never silent for the other party. These are meaningful behavioral facts beyond the schema.

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?

Front-loaded with the core action and result before the etiquette detail. It is long and narrative, but nearly every sentence supplies a distinct rule (no-op, attribution, symmetry, legitimacy) that changes how the agent would invoke it.

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

Completeness5/5

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

Complete for a nuanced state-transition tool: input semantics, side effects, the 'unblocked' return payload, idempotency, and the downstream confirm/reopen flow are all covered. Output schema existence means return-format detail is not required, yet the description still flags the 'unblocked' field usefully.

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 0% for both parameters. message_id is self-evident, and the description compensates for resolution_note by explaining it is optional and what it should contain (e.g. naming what was done, 'cancelled, not needed'), giving the agent real content guidance the schema lacks.

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?

Opens with a precise verb+resource: 'Mark an action_required message as resolved.' It immediately distinguishes this from siblings by naming reopen_message and confirm_resolution and their respective roles in the workflow.

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?

Explicitly states who resolves (the addressee), who verifies (the author), what to do when unsatisfied (reopen_message) or satisfied (confirm_resolution), and even calls out an illegitimate usage ('resolving a debt the other side owes you'). This is a textbook when/when-not with named alternatives.

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