Skip to main content
Glama
Sign In
dsh-any-agent

dsh-any-agent

by xmtlzzz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Submit review verdict

dsh_review

Record a pass, partial, or fail verdict on an ended agent turn after verifying changed files and tests, capturing review outcomes without blocking later sends.

Instructions

Record the caller's review verdict on the result of a turn that has ended (to allow or deny a permission request while a turn is running, use dsh_approval_decide). Results from dsh_send / dsh_interject and the sentinel carry a review ticket (checklist, evidence summary, review_id). Before treating a result as done, verify it yourself (read the changed files, look at git diff, run tests), then call this tool to record pass / partial / fail. Reviews are advisory by default: they do not block later dsh_send calls and are not fed back to DSH automatically; send another dsh_send if something needs fixing. A verdict can still be submitted after the run record was evicted from memory or the server restarted (the sentinel file is the reference).

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": {
      "conversation_id": "<conversation_id>",
      "run_id": "<run_id>",
      "verdict": "<verdict>"
    },
    "name": "dsh_review"
  }
}

Input Schema

NameRequiredDescriptionDefault
notesNoThe reason. Required for fail/partial (or use findings instead). Up to 8000 characters.
run_idYesThe dispatch being reviewed (the run_id on the review ticket).
verdictYespass = usable as is; partial = partly usable, needs more work; fail = unusable, redo. fail and partial require a reason.
findingsNoOptional itemised list of problems; up to 50 items of up to 2000 characters each.
conversation_idYesConversation id, from dsh_start or dsh_list.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.6.8
    • changedInput schema / properties / conversation_id / description
      Previous value: -"会话 id，来自 dsh_start 或 dsh_list。"New value: +"Conversation id, from dsh_start or dsh_list."
    • changedInput schema / properties / findings / description
      Previous value: -"逐条问题清单，可选；最多 50 条、每条 2000 字。"New value: +"Optional itemised list of problems; up to 50 items of up to 2000 characters each."
    • changedInput schema / properties / notes / description
      Previous value: -"审核理由。fail/partial 必填（或改用 findings），最多 8000 字。"New value: +"The reason. Required for fail/partial (or use findings instead). Up to 8000 characters."
    • changedInput schema / properties / run_id / description
      Previous value: -"要审核的那次派活（审核单里的 run_id）。"New value: +"The dispatch being reviewed (the run_id on the review ticket)."
    • changedInput schema / properties / verdict / description
      Previous value: -"pass=可直接采用；partial=部分可用、需补充；fail=不可用、需重做。fail/partial 必须说明理由。"New value: +"pass = usable as is; partial = partly usable, needs more work; fail = unusable, redo. fail and partial require a reason."
  2. Addedv0.5.1

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false): it discloses that reviews are advisory, do not block later dsh_send calls, and are not fed back to DSH automatically — the key consequence of a write-shaped tool that has destructiveHint=false. It also explains persistence behavior, noting a verdict can still be submitted after the run record was evicted or the server restarted, with the sentinel file as the source of truth.

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?

Purpose is front-loaded, followed by the exclusion, the verification prerequisite, and the advisory-behavior caveats in a logical order with no filler sentences. It is on the dense side — the parenthetical and the sentinel/eviction clause pack in a lot — but every sentence carries operational value.

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?

There is no output schema, yet the description covers what an agent needs: the ticket that identifies the run, the verification obligation before calling, the verdict semantics, and the post-call consequences and persistence guarantees. For a five-parameter recording tool this is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so run_id, conversation_id, verdict, notes and findings are already documented, including the fail/partial reason requirement. The description adds only modest orientation — that run_id comes from the review ticket (checklist, evidence summary, review_id) — which is useful for locating the id but does not extend parameter meaning much beyond the schema. Baseline 3 applies.

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 precise verb+resource ('Record the caller's review verdict on the result of a turn') and immediately scopes it against the closest sibling: approval during a running turn belongs to dsh_approval_decide, not here. An agent can distinguish this from dsh_send, dsh_interject and dsh_approval_decide 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use (a turn has ended and you have a review ticket), when-not-to-use plus the named alternative (dsh_approval_decide for in-flight permission requests), and a prerequisite workflow: verify the result yourself via changed files, git diff, tests, then record pass/partial/fail. It also states the follow-up path ('send another dsh_send if something needs fixing'), so nothing is left to inference.

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