If you're referring to the MCP server published by this repository, it's herdr-inbox (the README calls it “herdr inbox”). Description: It lets Claude Code agents running in herdr ask a question once, get a receipt, and keep working instead of blocking, while the operator answers all open questions from a single popup and each answer is delivered back to the pane that asked. A couple of notes on the constraints you gave: - The name used is the repository's own project name, herdr-inbox, not a person or organization. - The description deliberately avoids repeating the name and focuses on what the server enables: asynchronous agent questions, non-blocking work, centralized answering, and delivery back to the originating agent. - If you want the answer as a strict JSON object only, it would be: ```json { "name": "herdr-inbox", "description": "Enables Claude Code agents running in herdr to ask a question once, receive a receipt, and continue working instead of blocking, while the operator answers all open questions from one popup and each answer is delivered back to the pane that asked." } ```

Official

Overview Schema Source Related Servers Discussions Admin

ask_operator

Ask the human operator a question without blocking: get a receipt, keep working, and receive the answer asynchronously in the same conversation.

Instructions

Ask the human operator a question WITHOUT blocking. Returns immediately with a receipt.

Use this instead of asking in chat whenever work can continue without the answer. The operator answers asynchronously; the answer will arrive in this conversation as a message starting with [inbox] that names the question id (Q). After calling it, continue with work that does not depend on the answer. Do not repeat the question in chat and do not call ask_operator for it again: a repeat is detected and only returns the existing receipt.

Keep the question self-contained: the operator reads it without your chat history, so name the repo/PR/file and what you need decided. The operator answers in a picker like AskUserQuestion's:

options: up to 9 choices, each a plain string or {"label", "description"} (label short, description says what picking it means). The operator can always type a free answer instead and attach a note to a choice.
header: a short chip shown above the question (max 12 chars), e.g. "DB choice".
multi_select: true when several options may be picked together.
preview (per option, optional): text shown beside the options while that option is highlighted (a code snippet, a config diff, an ASCII mock); monospace, no markup.
title: a short name for the whole call (≤60 chars), e.g. "Worker rollout settings". The operator's inbox lists calls by this name, so ALWAYS set it when you pass questions; optional for a single question (its header or text is used instead).
questions: instead of question, up to 4 related questions in one call, each {"question", "header"?, "options"?, "multi_select"?}. The operator answers them together; each gets its own Q id.
context: supporting detail; asked_by: who is asking (e.g. "reviewer PR 42") when you are a subagent or one of several roles. Each answer is one line: the picked label(s), notes in parentheses, or the free text. Answers the operator submits together arrive in one [inbox] message.

Input Schema

Name	Required	Description	Default
`title`	No
`header`	No
`context`	No
`options`	No
`asked_by`	No
`question`	No
`questions`	No
`multi_select`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.8.0Oct 16, 2026

TDQS

A4.8/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it delivers: non-blocking contract, immediate receipt return, async arrival format ('[inbox]' message naming Q<n>), duplicate detection behavior, and answer format. The only omitted bit is auth/permissions, which is not relevant here.

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?

Front-loaded with the core contract and scoping in the first two sentences, then structured bullets per parameter. It is long, but the length is justified by the zero-coverage schema; only the duplicated chat-vs-inbox explanation could be trimmed slightly.

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?

Covers behavior, param semantics, and follow-up handling for an 8-param, zero-schema-description tool. Output schema exists so return-value detail is legitimately omitted, but the description could note the receipt fields or clarify how single `question` vs `questions` interacts with max-count limits.

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?

Schema description coverage is 0%, so the description must supply param meaning, and it does: it documents options (up to 9, string or {label, description}), header (≤12 chars), multi_select, per-option preview, title (≤60 chars, emphasized for `questions`), questions (up to 4, shape given), context, and asked_by. This is a rare case where prose fully compensates for an empty 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 and resource ('Ask the human operator a question') and immediately distinguishes itself from siblings by naming the key behavioral constraint ('WITHOUT blocking'). The contrast with 'asking in chat' and the routing comment to check_answers/ask_operator-again makes it unmistakable which tool handles async questions.

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?

Explicit when-to-use ('Use this instead of asking in chat whenever work can continue without the answer') and when-not ('Do not repeat the question in chat and do not call ask_operator for it again'). It also tells the agent the follow-up action (continue with independent work) and that duplicate calls are deduped — full routing guidance.

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

Deploy Server