Skip to main content
Glama
Sign In
dsh-mcp-worker

dsh-mcp-worker

by tongsh6
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

批量提交 DSH 任务

dsh_batch_run
Destructive

Dispatch multiple independent work units in parallel and immediately return a batch ID, then aggregate outcomes with status and result queries. Not for serial steps in one workflow.

Instructions

一次并行派发多个彼此独立、各自可验收的工作单元（每个任务仍应覆盖「实现+自测+证据」），立即返回 batch_id；用 dsh_batch_status / dsh_batch_result 聚合查询。不要用它串行拆解同一工作流。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tasks": "<tasks>"
    },
    "name": "dsh_batch_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
tasksYes任务数组（1–8 个）

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.2

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare it as non-read-only, destructive and open-world, and the description adds the key behavioral fact not in them: dispatch is asynchronous and returns a batch_id immediately, with results retrieved later via the batch query tools. It also constrains task independence, which is a real behavioral precondition. It does not address permissions, cost, or what happens when a member task fails, so the destructiveHint implications stay unelaborated.

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

Conciseness5/5

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

Three compact clauses with no filler: what it does and returns, where to go next, and what not to use it for. The exclusions come last but the core action is front-loaded.

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 an async fan-out tool with no output schema, the description supplies the return handle (batch_id), the polling path, and the unit-independence precondition, which is enough to call it correctly. The gap is failure/permission behavior for member tasks, which an agent would need to reason about given destructiveHint=true.

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 the baseline is 3, but the description adds real meaning: the `task` string must be a full work unit covering implement + self-test + evidence rather than a single step, and units must be mutually independent — semantics the schema's "完整工作单元描述" only partly captures. It also implies the 1–8 concurrency ceiling that the schema itself does not enforce via maxItems.

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?

The description opens with a specific verb and scope: "一次并行派发多个彼此独立、各自可验收的工作单元" and states the immediate return value (batch_id). The clause "不要用它串行拆解同一工作流" carves out a boundary against the single-task siblings like dsh_run, so an agent can distinguish this from its twelve siblings without opening any schema.

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?

It gives a positive condition (multiple independent, individually acceptable units) and an explicit exclusion (do not use to serially decompose one workflow), plus the follow-up path via dsh_batch_status / dsh_batch_result. It never names dsh_run as the alternative for the single-unit case, leaving that inference to the agent.

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