deepseek-dsh

Overview Schema Source Related Servers Discussions Admin

deepseek_delegate

Destructive

Delegate bounded development execution to DeepSeek Harness: it reads and edits scoped code, runs authorized commands, and returns a structured handoff with evidence and blockers.

Instructions

Delegate bounded development execution to DeepSeek Harness. Astra plans and accepts; DeepSeek reads/searches code, implements changes and runs the specified checks when execution is supplied. Provide the project constraints, writable paths, exact authorized commands and acceptance criteria. DeepSeek cannot spawn agents, redelegate, escalate permissions or start background jobs. Commands run without network in a scoped filesystem sandbox. read, glob and grep are read-only; write and edit exist only when write_paths are granted; bash exists only for the exact authorized commands. The model-visible bash schema enumerates exactly those authorized command strings: choose one verbatim, use workdir equal to the assigned workspace or ".", set timeoutMs greater than 0 and at most 120000 ms, and do not send background or escalation parameters. A command absent from the enum is refused before execution and reported as not executed; dependency or environment probes belong inside an authorized implementation/check command, not as extra commands. Use read/glob/grep for exploration: granting a file read root does not grant its parent directory. A clearly denied, unexecuted exploratory ls/glob/grep becomes a non-blocking warning only when all required authorized commands actually exited 0 and the same target evidence was later obtained through an authorized read/glob/grep; every other denial remains a failure, and a missing necessary permission must be reported as a blocker. Model request budget: max_steps 1..64 (default 24); hard deadline: timeout_seconds 10..900 (default 600); each command has a hard 120000 ms limit. Commands are matched as exact strings and run one per call: do not concatenate them with &&, ; or |. About 20% of the request budget (at most 12 requests) is reserved for verification and handoff; the final request is summary-only with tools disabled, and no additional model requests are granted. Returns a stable structured handoff with observed writes, actual command results, missing checks, non-blocking warnings and blockers, plus the actual tool transcript and session. Astra reviews the diff and evidence without redoing the implementation or automatically auditing it again. One active task per server/workspace; identical requests share a result. Omit execution only for a backwards-compatible text-only answer.

Input Schema

TableJSON Schema

Name	Required	Description
`task`	Yes	One concrete deliverable owned by DeepSeek.
`context`	Yes	Task entry points, necessary context and applicable AGENTS/project constraints. Do not send credentials or unrelated private data.
`execution`	No	Astra assigns permissions within the current user authorization and sandbox. This object enables execution; it does not grant a new experiment or an approval bypass.
`acceptance`	Yes	Concrete deliverables and checks. Execution should report modified files, actual commands/results and any unresolved failures.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.2.2Oct 19, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Far exceeds what the annotations convey: no network, scoped filesystem sandbox, no agent spawning/redelegation/escalation/background jobs, exact-string command matching refused before execution if absent from the enum, read/glob/grep read-only, one active task per workspace, identical requests share a result. A denial/warning policy and the distinction between a non-blocking warning and a blocker are spelled out, which is exactly the behavioral disclosure agents need.

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

Conciseness3/5

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

The purpose is front-loaded, but the remainder is a dense multi-topic block that mixes policy, authorization mechanics and budget rules, and repeats constraints already in the schema (the 120000 ms limit appears three times, the verification handoff budget twice). Much of it earns its place, yet a trim would improve scanability without losing information.

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?

For a complex, nested, destructive-capable tool with no output schema, it closes every important gap: it describes the structured handoff return (observed writes, command results, missing checks, warnings, blockers, transcript, session), permissions implications of read roots and write paths, execution limits, and the review step Astra performs afterward.

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 cross-parameter meaning the schema cannot express: each command is matched verbatim and run one per call, workdir must equal the assigned workspace or ".", timeoutMs must be >0 and ≤120000, and shell composition is not authorized. This makes the invocation contract interpretable rather than merely restated.

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 first sentence names a specific verb+resource: "Delegate bounded development execution to DeepSeek Harness," and immediately splits responsibilities ("Astra plans and accepts; DeepSeek reads/searches code, implements changes and runs the specified checks"). An agent can tell exactly what this tool does and what it owns without opening the 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 strong invocation context ("Provide the project constraints, writable paths, exact authorized commands and acceptance criteria") and a clear when-not ("Omit execution only for a backwards-compatible text-only answer"). With no sibling tools there are no alternatives to name, so the only gap is the absence of comparative 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

Other Tools

deepseek_delegateA