ai-agent-channel

acknowledge

Record your decision on a message—agree, reject, needs_changes, or void—with an optional note; a proposal is agreed when every role has a fresh 'agree'.

Instructions

Record your role's decision on a message: agree, reject, needs_changes, or void, with an optional note (at most 4000 characters). 'void' means 'the subject of this decision no longer exists'. It clears the record from your awaiting_ack and never counts towards 'agreed'. A void from a voter of the round (its declared 'voters', or its recipients when none were declared), cast after the last revision of the body, closes a pin round: the key is free for a new round and the proposal can no longer approve pin_set. A void from anyone else is recorded but closes nothing. 'expect_body_sha256': pass the digest of the body you read and the vote is refused if the author has re-issued it since. Works on any message kind (only kind='proc' surfaces in awaiting_ack). One acknowledgement per (message, role) — repeating overwrites it. You cannot acknowledge your own message. A proposal is agreed when every role of its electorate — the declared 'voters', or else its recipients — has a fresh 'agree' (see get_acknowledgements). Acking also retires your outstanding nudges about this message (sent with about_message_id= and addressed to you); they are returned as 'superseded'.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`note`	No
`decision`	Yes
`message_id`	Yes
`expect_body_sha256`	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.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains side effects: clearing awaiting_ack, closing pin rounds, refusal conditions with expect_body_sha256, one-per-(message, role) overwriting, prohibition on self-acknowledgement, and retirement of nudges. This is exceptionally transparent.

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?

The description is long but dense with critical information, structured logically from core action to edge cases. It front-loads the primary purpose and then details nuances. While not minimal, every sentence contributes to correct usage, making it efficient for the complexity involved.

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?

Given the tool's complexity, the description is remarkably complete. It covers all major behaviors: decision semantics, pin round closure rules, agreement conditions, nudge retirement, and cross-references get_acknowledgements. An agent can call it correctly without additional external knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero descriptions (coverage 0%), so the description must compensate. It explains the meaning of decision values, the 4000-character limit on note, the purpose of expect_body_sha256 (digest verification), and implies message_id context. This fully compensates for the schema's lack of documentation.

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 explicitly states the tool records a role's decision on a message, enumerating the four decision values and the optional note. It clearly identifies the resource (message) and the action (acknowledgement), distinguishing it from sibling tools like mark_read or resolve_message by its unique purpose.

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

Usage Guidelines4/5

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

The description provides rich context on when to use the tool, including conditions for void closing a pin round and the effect on awaiting_ack. It also references get_acknowledgements for checking agreement. However, it does not explicitly state when NOT to use it or compare with alternative tools, though the behavior is so specific that the intended use is unambiguous.

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