ai-agent-channel

get_acknowledgements

Read-only

Check a message's acknowledgement record to find which roles have not yet voted, including electorate counts and optional field projection to trim large histories.

Instructions

The consent state of a message: the acknowledgements on record AND 'missing' — the roles whose vote is still absent, which is what you actually need to know and what the collected votes alone cannot tell you. 'needed' counts the round's electorate: its declared 'voters' when it has them (listed under 'voters'), otherwise its recipients — never the channel roster, and never the author. Votes from roles outside the electorate are reported, not counted: under 'from_non_voters' when voters were declared, 'from_non_recipients' otherwise. Votes cast before the body was re-issued appear under 'quenched_by_revision'; voids under 'declared_dead_by'. 'fields' projects this answer (not a listing): use fields='headers' for the tally without the notes. Optional 'fields' projects the response: a list of field names, or the single value 'headers' for the usual listing set (everything except the bodies). Omit it and the full record comes back. Use it when a listing over a long history would otherwise be too large to return — bodies dominate the size, and a 'which messages' question rarely needs them; fetch the ones you want individually afterwards.

Input Schema

TableJSON Schema

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

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?

The description goes well beyond the readOnlyHint annotation, detailing how votes from non-voters are reported, how quenched_by_revision and declared_dead_by are handled, and how the fields parameter projects the response. It clarifies edge cases and response semantics, which is exactly what an agent needs to interpret results correctly.

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 lengthy but information-dense; every sentence contributes value, and it is front-loaded with the core purpose. It could be better structured with bullets or separators, but it is not verbose or redundant. The level of detail is justified given the tool's complexity.

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 output schema exists, the description does not need to enumerate return fields, but it explains the semantic meaning of the response (missing, needed, non-voters, etc.) and the projection behavior. It covers all essential aspects for correct invocation and interpretation, making it fully complete.

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?

With 0% schema description coverage, the description fully compensates by explaining the 'fields' parameter in detail: it can be a list of field names or 'headers' for the usual set, and omitting it returns the full record. The message_id parameter is implied by the context. The description adds substantial meaning beyond the raw schema.

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 clearly states the tool's function: returning the consent state of a message, including acknowledgements and missing votes. It specifies the exact resource (message) and the action (get acknowledgements) with enough detail to distinguish it from generic getters. It also explains the 'needed' count and the distinction between voters and non-voters, which adds specificity.

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 implies when to use it: when you need to know missing votes, which is what the collected votes alone cannot tell you. It explains the purpose and the fields projection for large listings. However, it does not explicitly name alternative tools or state when not to use it, though the context strongly suggests it's the right tool for consent-state queries.

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