Skip to main content
Glama
Sign In
ChatGPT–DSH Bridge

ChatGPT–DSH Bridge

by sho777564
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Get DSH task result

dsh_get_result
Read-onlyIdempotent

Retrieve the final answer, test-line summary, errors, usage, and timing for a terminal DSH task; wait up to 25 seconds if it is still running, then review results before claiming tests passed.

Instructions

Return the final answer, a bounded test-line summary, errors, usage, and timing for a terminal DSH task. If the task is still running, use wait_seconds (maximum 25s) rather than repeated immediate calls. Review the result before claiming that tests passed.

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": {
      "task_id": "<task_id>"
    },
    "name": "dsh_get_result"
  }
}

Input Schema

NameRequiredDescriptionDefault
task_idYesTask id returned by dsh_start_task.
max_charsNoMaximum characters of final result text to return.
include_logsNoInclude a short redacted stderr excerpt. Off by default.
wait_secondsNoWait up to this many seconds for a terminal state.

Output Schema

NameRequiredDescriptionDefault
okYes
nextNo
resultYes
statusYes
messageNo
task_idYes
terminalYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real behavior beyond that: the 25s wait cap, guidance against polling, and a caution to review results before asserting test success. It does not cover what happens for a non-terminal task with wait_seconds=0, or that log excerpts are redacted, which is left to 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.

Conciseness4/5

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

Three sentences, front-loaded with the payload of what is returned, then the polling caveat, then the verification warning. Every sentence carries operational weight with no filler, though the final verification sentence is a process instruction rather than tool behavior.

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?

An output schema exists, so the description need not enumerate return fields, yet it still summarizes them; combined with the polling and truncation guidance, an agent has enough to call this correctly. The only missing piece is an explicit pointer to dsh_get_status for checking whether a task is terminal, which the 'still running' clause presupposes.

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 coverage is 100%, so all four parameters already carry their own descriptions, setting the baseline at 3. The description reinforces wait_seconds with a usage norm not present in the schema and implies truncation via 'bounded', but says nothing about task_id, max_chars, or include_logs beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

A specific verb and resource: 'Return the final answer, a bounded test-line summary, errors, usage, and timing' names exactly what comes back, not just 'gets result'. The qualifier 'for a terminal DSH task' implicitly narrows it away from dsh_get_status, but never names that sibling, so differentiation requires inference from the task state wording.

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 an explicit when-not and the better alternative behavior: 'If the task is still running, use wait_seconds ... rather than repeated immediate calls.' It also sets a downstream norm: verify before claiming tests passed. The gap is that it never states the positive condition — call this once the task is terminal — or names dsh_get_status as the way to learn the task's state.

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