Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dsh-inbox-mcp deliver a task message to the current dsh session"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
DSH inbox MCP（stdio）：外部 agent 向运行中的 dsh web 投递 queue/steer/task ——
dsh-boss 的 delegate_task 依赖的配套 transport。
npm install -g dsh-inbox-mcp # 或 npx dsh-inbox-mcpmcp.json（客户端配置）:
{
"mcpServers": {
"dsh-inbox": {
"command": "dsh-inbox-mcp",
"env": {
"DSH_INBOX_URL": "http://127.0.0.1:3080",
"DSH_INBOX_HOUSE": "dsh-local",
"DSH_INBOX_TRUST": "与 dsh web 端一致的 trust_id（可选，设了才校验）"
}
}
}
}Related MCP server: dsh-agent-mailbox
dsh_inbox_deliver — 向指定/最近 session 投递消息（kind: auto | steer | task）
dsh_inbox_status — 查询 session 运行状态 / title / house / trust_required
门牌 + trust：DSH_INBOX_HOUSE/DSH_INBOX_TRUST（env）——本地共享信任串，
不是完整鉴权；未设 trust 时 gate 关闭（dev open）
危险命令拦截：rm -rf / curl|sh / powershell -enc / 私钥头 / api-key 模式
等默认 deny 列表，投递前拒绝（DSH_INBOX_DENY 可追加）
回环默认：127.0.0.1:3080，仅供本机/内网 MCP
npm install
npm run build # tsc → dist + node shebang
npm test # 信任/deny 逻辑 7 用例MIT
Deliver a message into a DeepSeek Harness (DSH) Web session via session.prompt. kind=auto (default): busy → steer, idle → queue. kind=steer forces mid-turn inject; kind=task always queues. Requires matching house_id + trust_id when DSH_INBOX_TRUST is set; pass from_id so DSH can see which agent sent this. Dangerous shell/exfil patterns are blocked. Requires local dsh web (default http://127.0.0.1:3080).
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Message text to queue or steer into the session | |
| kind | No | auto | steer | task (default auto) | |
| from_id | No | Sender agent id for attribution (default env INBOX_FROM=unknown) | |
| house_id | No | Doorplate (default house-test-001) | |
| trust_id | No | Trust id when DSH_INBOX_TRUST is set | |
| session_id | No | Target DSH sessionId; omit = most recently updated non-blank |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains trust/auth requirements, the need for from_id attribution, blocking of dangerous shell/exfil patterns, and the local service dependency. It does not describe return values or error behavior, but it provides substantial transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense, with the core action front-loaded and supporting details (mode semantics, auth, safety, local requirement) following. Each sentence contributes useful information. Some acronyms and DSH-specific terms are used without expansion, which slightly reduces accessibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no annotations and no output schema, the description covers the key operational context: delivery modes, trust pairing, attribution, safety blocking, local endpoint, and session targeting. It lacks an example body and does not tell the agent how to confirm delivery via the sibling status tool, but the core calling context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema: it explains how kind affects delivery routing, why trust_id/house_id matter, why from_id should be passed, and the fallback behavior of session_id. This gives an agent practical guidance for choosing and filling parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action with a concrete target: 'Deliver a message into a DeepSeek Harness (DSH) Web session via session.prompt.' It also explains the meaning of the three delivery modes, so an agent can understand what the tool does without opening the schema. This clearly distinguishes it from the sibling dsh_inbox_status, which presumably reports status rather than delivering messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear mode-selection context: kind=auto routes based on busy/idle state, steer forces mid-turn inject, and task always queues. It also lists prerequisites such as matching house_id/trust_id when DSH_INBOX_TRUST is set and the need for a local dsh web instance. However, it does not explicitly state when to prefer dsh_inbox_status or mention alternatives/exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll DSH session status via session.list (running, title, updatedAt). Omit session_id to inspect the most recently updated non-blank session.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | Session to inspect; omit = latest non-blank |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure, and it does so reasonably well by naming the API method, the returned status fields, and the non-blank default selection behavior. It does not cover error behavior, authentication, or rate limits, but for a simple polling operation the disclosed behavior is sufficient for an agent to form accurate expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one efficient sentence that front-loads the action and resource, then supplies the key parameter behavior. Every phrase earns its place, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single optional parameter and no output schema, the description names the underlying endpoint, the fields returned, and the default selection rule, which is enough to invoke it correctly. It does not enumerate possible return shapes or error cases, but those are less critical for a simple status-polling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single parameter with 100% coverage and even says 'omit = latest non-blank.' The description repeats this nuance but adds no new format, constraints, or example beyond what the schema provides, so it meets the baseline for schema-heavy parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Poll') and names the exact resource ('DSH session status') and underlying method ('session.list'), plus the fields it returns (running, title, updatedAt). This makes its purpose unmistakable and distinguishes it from the sibling dsh_inbox_deliver, which clearly handles delivery rather than status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear operational guidance: omit session_id to target the most recently updated non-blank session, which tells an agent exactly when the optional parameter should be left out. It does not explicitly state 'use this instead of dsh_inbox_deliver,' but the contrasting verb/resource makes the usage context clear enough without an explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0dsh_inbox_deliverdsh_inbox_statusScored across 2 tools
dsh_inbox_status reads/polls session state while dsh_inbox_deliver writes/sends a prompt; there is no overlap in their actions. An agent can easily choose the right tool based on whether it needs to observe or act.
Both tools share the clear dsh_inbox_ prefix and use snake_case, so they are instantly recognizable as part of one server. The minor deviation is that one name uses a noun (status) and the other uses a verb (deliver), rather than a uniform verb_noun pattern.
Two tools is at the low end of the acceptable range and feels thin for a general MCP surface. For the narrow status-and-deliver purpose the count is reasonable, but it is borderline rather than solidly well-scoped.
The core poll-and-deliver loop is covered: status tells whether the session is ready or busy, and deliver handles the different queueing modes. Mino gaps exist around inspecting queued messages or listing multiple sessions, but agents can generally work around these.
Authenticated async Opus 4.8 Agent agent with status polling and artifact results.
Agent-to-agent messaging: directory, public lobby, DMs, channels, search. Stateless MCP + REST.
Hosted MCP server for task-first delegation to remote workstations and workers.
Run and manage H Company's Computer-Use Agents from any MCP client.