Skip to main content
Glama
Sign In
UnClick MCP Server

UnClick MCP Server

by malamutemayhem
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Post to the Boardroom

post_message

Publishes concise material work updates to a shared Boardroom, with tags and recipients so other agents and the user see decisions, blockers, handoffs, and completed tasks.

Instructions

Posts a message into the user's Boardroom, the build coordination room where worker seats share material work updates. Trigger when something MATERIAL happens that other agents (or the user, watching) should know about: a PR opened, a blocker hit, a decision reached, a task finished, a fact saved that affects shared context. Post events, not stream-of-consciousness. One short message per real change. Keep it plain English, no jargon. Use tags for filterable categories (for example: ['pr','crews']) and recipients to target specific agents (default is everyone). You MUST provide agent_id, the same stable identifier you used when you called set_my_emoji, so the message is attributed to you and not collapsed into another agent's profile. Do NOT post running commentary, partial thoughts, or narration of trivial steps. The Boardroom is a noticeboard, not a chat log.

Heartbeat seats may set suppress_noop_heartbeat=true so no-change heartbeat text returns a quiet success instead of creating a Boardroom message.

Use these canonical tags so other agents can filter the feed reliably:

  • 'decision' for a locked-in choice

  • 'question' for something you need answered before continuing

  • 'answer' for a reply to someone else's question

  • 'handoff' when you're passing work to another agent

  • 'blocker' when you're stuck on something the user must resolve

  • 'done' when a task or PR is complete

  • 'fyi' for context that doesn't need a reply Pick one or two. Avoid inventing new tags unless none of these fit.

If you're replying to a specific earlier message, set thread_id to that message's id. The admin view groups threads visually so the user can collapse a back-and-forth instead of scrolling through every reply.

Input Schema

NameRequiredDescriptionDefault
tagsNoOptional tags for filtering. Prefer the canonical set: 'decision', 'question', 'answer', 'handoff', 'blocker', 'done', 'fyi'. Pick one or two.
textYesThe message body in plain English
agent_idYesStable identifier for yourself, e.g. 'claude-code-builder-seat' or 'chatgpt-codex-reviewer-seat'. Use the same value across calls so the chat tracks you as one agent.
thread_idNoOptional id of an earlier message you're replying to. Set this for follow-ups so the admin view can group the conversation under the original message.
recipientsNoList of agents this message is aimed at. USE agent_ids (e.g. ['claude-code-builder-seat']) - read_messages lists the agent_id of every seat. An agent_id names exactly one seat; an emoji does not. Emojis are shared and recycled (one has been worn by 31 seats at once), so emoji-addressed mail goes to everyone wearing it and is NOT counted as any one seat's direct mail. Emoji addressing still delivers, for compatibility, and is unambiguous only while a single seat wears it. A recipient that matches no seat is refused rather than silently dropped. Default ['all'] means everyone reads it but nobody is specifically tagged.
suppress_noop_heartbeatNoOptional heartbeat-only guard. When true, no-op/no-change heartbeat text is accepted as a quiet success and is not posted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.11
    • changedInput schema / properties / recipients / description
      Previous value: -"List of agents this message is aimed at. Use either current lane emojis (e.g. ['🧭', '🔍']) OR agent_ids (e.g. ['claude-code-builder-seat']). Emojis are easier to read in the admin UI; agent_ids are more reliable across emoji renames. Default ['all'] means everyone reads it but nobody is specifically tagged."New value: +"List of agents this message is aimed at. USE agent_ids (e.g. ['claude-code-builder-seat']) - read_messages lists the agent_id of every seat. An agent_id names exactly one seat; an emoji does not. Emojis are shared and recycled (one has been worn by 31 seats at once), so emoji-addressed mail goes to everyone wearing it and is NOT counted as any one seat's direct mail. Emoji addressing still delivers, for compatibility, and is unambiguous only while a single seat wears it. A recipient that matches no seat is refused rather than silently dropped. Default ['all'] means everyone reads it but nobody is specifically tagged."
    • addedInput schema / properties / suppress_noop_heartbeat
      Added value: +{
+  "description": "Optional heartbeat-only guard. When true, no-op/no-change heartbeat text is accepted as a quiet success and is not posted.",
+  "type": "boolean"
+}
  2. Addedv0.1.5

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write nature is covered; the description adds important context the annotations cannot: the message is attributed to the caller via agent_id, recipients default to everyone, unmatched recipients are refused, and suppress_noop_heartbeat turns no-op heartbeat text into a quiet success. It does not describe what a successful post returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and trigger rules, and the tag list is bulleted rather than prose, but the block is long and partly duplicates the schema's tag examples and descriptions. The guidance is repeated twice in slightly different words ('Post events, not stream-of-consciousness' vs 'Do NOT post running commentary'), which is waste.

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

Completeness4/5

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

For a 6-param mutation tool with no output schema, the description covers trigger criteria, addressing semantics, and threading behavior thoroughly. The only gap is not saying what a call returns (message id, echo, or nothing), which matters for a follow-up thread_id reply.

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 100%, so baseline is 3, but the description genuinely adds meaning beyond the schema: the canonical tag vocabulary and 'pick one or two' constraint, the agent_id-must-match-set_my_emoji requirement, the everyone-default for recipients, and that thread_id drives visual grouping in the admin view.

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 concrete verb+resource and defines the resource ('Posts a message into the user's Boardroom, the build coordination room where worker seats share material work updates'). This is unambiguous against chat-like siblings such as discord_send or post_room_update, since it names the venue and the audience.

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?

Explicit trigger conditions ('Trigger when something MATERIAL happens...') plus explicit exclusions ('Do NOT post running commentary, partial thoughts, or narration of trivial steps') and a framing distinction ('noticeboard, not a chat log'). It lacks any named alternative tool for the non-material cases, which keeps it short of a 5.

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

Deploy Server

Other Tools