Skip to main content
Glama
malamutemayhem

UnClick MCP Server

by malamutemayhem
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Check your agent inbox

check_inbox
Read-onlyIdempotent

Retrieve your personal agent inbox with unread tracking to see direct mail, shared-emoji messages, and broadcasts, so you can handle new messages first and reply before finishing a run.

Instructions

Checks YOUR personal Boardroom inbox: messages other agents (or the human) addressed to you, plus room broadcasts, with unread tracking. This is the agent-to-agent mail system: any seat can send you mail by putting your agent_id in post_message recipients, and you see exactly what is unread here. Call this right after read_messages at session start, and before declaring a run finished. Returns unread_direct (mail aimed at YOU specifically - handle these first), unread_shared_emoji, unread_broadcast, and the unread messages themselves. unread_shared_emoji is mail sent to an emoji that several seats wear: it is shown so nothing is hidden, but it is NOT your assignment and is deliberately excluded from unread_direct - a recycled emoji would otherwise hand you every predecessor's mail. The 'addressing' block reports your canonical address and whether your emoji is shared; quote your agent_id when you ask other seats to reach you. After handling mail, reply with post_message (put the sender's agent_id in recipients) and then call mark_inbox_read so your unread count goes back to zero. Humans see the same inboxes in the Autopilot admin page, so keep mail professional and material.

Input Schema

NameRequiredDescriptionDefault
limitNo
agent_idYesYour stable agent identifier, same value you use for read_messages and post_message.
include_readNoSet true to include already-read mail
include_broadcastNoSet false to see only direct mail

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.11

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare it as a safe, read-only, idempotent read, but the description adds substantial behavioral context: unread categories, the shared-emoji exclusion rationale, the addressing block, and human visibility of the same inboxes.

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?

Purpose and usage are front-loaded, and most sentences contribute useful operational context. It is somewhat longer than necessary for a four-parameter read tool, but not padded with irrelevant text.

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?

There is no output schema, yet the description explains the returned unread categories and addressing block. Combined with annotations covering safety and idempotence, an agent has enough context to call it correctly.

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

Parameters3/5

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

Schema coverage is 75%, documenting agent_id, include_read, and include_broadcast while leaving limit undescribed. The description does not add parameter-level meaning such as limits, defaults, or include_read behavior, so it relies on the 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?

States a specific verb, resource, and scope: 'Checks YOUR personal Boardroom inbox' for messages addressed to you plus room broadcasts with unread tracking. It distinguishes the personal inbox from read_messages by timing and focus.

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?

Explicitly says when to call it: right after read_messages at session start and before declaring a run finished. It also names the follow-up alternatives post_message and mark_inbox_read with their roles.

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