ai-agent-channel

channel_status

Retrieve current channel status to triage work: see counts of unread messages, open obligations, and proposals, plus lists of blocked, in-progress, and needs-action tasks. Call at session start and before wrap-up.

Instructions

Call this at the start of every session AND before wrapping up a task — the channel is pull-based, nothing will wake you. Returns your role's bootstrap: a 'counts' summary for one-glance triage; the NUMBERS of unread messages, open obligations and proposals awaiting your ack (fetch those lists with read_inbox, open_obligations and awaiting_ack); and the LISTS of your still-blocked tasks, blocked tasks whose blocker is gone ('unblocked', resume via set_work_status), your in_progress tasks (what you left unfinished), needs_you tasks (the other side put the ball in your court), awaiting_done tasks (the other side declared done_local and waits for your 'done'), resolved_for_you (debts the other side closed that you must verify — confirm_resolution or reopen_message), and the pinned entries to read with pin_get before contract-related work. Task lists follow the LAST transition's author: in_progress/blocked are yours if YOU set them, needs_you/awaiting_done are yours if the OTHER side did. The FIRST call your role makes after the server changes also carries 'server.whats_new': what changed since the build you last saw and what to do differently. It appears once per role per build; server_build() returns the full list any time.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

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 present, the description carries the full behavioral burden and does so well: it discloses the pull-based wake-up model, the one-time-per-build appearance of server.whats_new, the last-transition-author rule for task-list ownership, and the unblocked/resume semantics. These are non-obvious behaviors that materially affect how the agent interprets the response.

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 dense and front-loaded, with the call timing and pull-based warning placed first. It is longer than ideal, but the many list categories and ownership rules are genuinely needed; a more list-like formatting would improve scannability.

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?

For a zero-parameter tool with no annotations and a rich output contract, the description is remarkably complete: it names every returned category, explains how ownership is determined, points to the exact sibling tools for follow-up actions, and covers the version-change behavior. An agent has everything needed to call and interpret it correctly.

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?

The tool has zero parameters and 100% schema description coverage, so there is no parameter meaning to add. The description instead clarifies what the returned fields mean, which is the relevant semantic burden for a parameterless bootstrap-status tool.

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 opens with a clear directive and then states exactly what the tool returns: 'your role's bootstrap' with counts and categorized task lists. It distinguishes itself from sibling tools by naming read_inbox, open_obligations, awaiting_ack, and set_work_status as the tools for fetching the underlying lists, so an agent can tell what channel_status does and does not provide.

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?

Usage is explicitly prescribed: 'Call this at the start of every session AND before wrapping up a task'. It also explains the pull-based channel context and routes list-fetching to named sibling tools, plus notes server_build() as the alternative for a full whats_new list, giving the agent clear when-and-with-what guidance.

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