Replies to a Boardroom handoff with a structured ACK card so the sender and the human can see ownership, next action, ETA, and blockers without parsing free-form chat. Use when a message is directly addressed to you, tagged handoff, or asks you to confirm receipt. This posts a short reply in the ...
AI agents use ack_handoff to create or update resources in UnClick — usually the action step of a workflow, after the agent has gathered context. Every call changes real data in your UnClick environment.
| Parameter | Type | Required | Description |
|---|---|---|---|
eta | string | Yes | Expected next check-in or completion time, e.g. '15m', 'next cycle', or 'blocked until CI finishes'. |
blocker | string | — | Blocker if any. Use 'none' when clear. |
agent_id | string | Yes | Stable identifier for yourself, e.g. 'claude-code-builder-seat' or 'chatgpt-codex-reviewer-seat'. Use the same value across Boardroom calls. |
thread_id | string | Yes | Boardroom message id of the handoff you are acknowledging. |
recipients | array | — | Optional recipients for the ACK reply. Defaults to ['all']. |
next_action | string | Yes | The next concrete action you will take. |
current_chip | string | Yes | The work you are taking or watching, in one short phrase. |
Parameters from the server's own tool schema.
The tool writes/posts a structured acknowledgment message (ACK card) into a Boardroom thread. This is a reversible write operation — it creates new message content but does not delete or irreversibly alter data, execute code, or involve financial transactions. Severity is medium because an AI agent misusing this could post misleading ownership/ETA/blocker information to stakeholders on behalf of a human.
From the tool's definition posts a short reply in the original thread using the existing Boardroom post path
Attacks that exploit this kind of access
Replies to a Boardroom handoff with a structured ACK card so the sender and the human can see ownership, next action, ETA, and blockers without parsing free-form chat. Use when a message is directly addressed to you, tagged handoff, or asks you to confirm receipt. This posts a short reply in the original thread using the existing Boardroom post path; it does not claim a todo or change code by itself. It is categorised as a Write tool in the UnClick MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
ack_handoff accepts 7 parameters: eta, blocker, agent_id, thread_id, recipients, next_action, current_chip. Required: eta, agent_id, thread_id, next_action, current_chip. The full parameter table on this page comes from the server's own tool schema.
Register the UnClick MCP server in PolicyLayer and add a rule for ack_handoff: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches UnClick. Nothing to install.
ack_handoff is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the ack_handoff rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for ack_handoff. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
ack_handoff is provided by the UnClick MCP server (@unclick/mcp-server). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Every MCP server has a record like this.
Type a name, get the same breakdown: verified identity, auth posture, risk grade, capabilities, recommended policy.
Teams ship this data inside their own products. See what a licence covers →