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." } ```
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HERDR_INBOX_DB | No | Overrides the location of the shared SQLite database used for questions and answers. Defaults to ${XDG_STATE_HOME:-~/.local/state}/herdr-inbox/inbox.db. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ask_operatorA | 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 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:
|
| alert_operatorA | Alert the human operator WITHOUT blocking and without expecting an answer: "please check X", "the deploy needs your eyes", "I hit something you should know about". Use it instead of writing the warning into chat (the operator may not be looking at this pane)
and instead of stopping to wait. It shows in the operator's inbox popup and as a herdr
notification, and counts in this tab's ❓ badge, until the operator acknowledges it.
Nothing is typed back; check_answers reports acknowledged alerts. Use ask_operator instead
when you need a decision or information. |
| withdraw_alertC | Withdraw one of your open alerts because the issue resolved itself. |
| check_answersA | Return operator answers to your questions that you have not seen yet, and mark them seen. Answers are normally delivered as |
| list_my_questionsA | List the questions this session has asked the operator, with their status and answers. Call this after compaction or resume BEFORE asking anything, so you do not re-ask a question that is already open or answered. |
| withdraw_questionB | Withdraw one of your open questions because you resolved it yourself. It is removed from the operator's inbox. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Most tools have clearly distinct purposes: ask_operator vs alert_operator (answer expected vs no answer), and withdraw_question vs withdraw_alert. check_answers and list_my_questions both retrieve question data, which could cause occasional misselection, but descriptions clarify their different scopes.
All tool names use consistent snake_case with a verb_noun pattern (withdraw_alert, check_answers, ask_operator, alert_operator, list_my_questions, withdraw_question). The only minor variation is the possessive 'my' in list_my_questions, but it still fits the pattern.
Six tools is well-scoped for the domain of asynchronous agent-operator communication. Each tool earns its place, covering asking, alerting, checking, listing, and withdrawing without redundancy.
The surface covers the full lifecycle: ask_operator/alert_operator to initiate, check_answers/list_my_questions to retrieve, and withdraw_question/withdraw_alert to cancel. Alerts are also tracked via check_answers for acknowledgments, leaving no obvious gaps.