Skip to main content
Glama

dayuan_read_result

Read-only

Fetches a submitted Dayuan query result by request_id, optionally waiting up to 30 seconds server-side and returning current status if the result is not ready yet.

Instructions

按 request_id 读取已提交的大渊查询结果,可用 wait_seconds 在服务端等待;结果为 Agent 生成内容。

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": {
      "request_id": "<request_id>"
    },
    "name": "dayuan_read_result"
  }
}

Input Schema

NameRequiredDescriptionDefault
request_idYes
wait_secondsNo服务端在本次调用内按同一 request_id 轮询结果的最长秒数(0–30);到时仍未完成则返回当前状态。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

The annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds the useful server-side wait/polling capability and that results are agent-generated content, but it does not say what is returned when the query is not yet complete (that is left to the schema's wait_seconds text) or how errors surface.

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?

A single compact sentence using semicolons; the primary action and identifier are front-loaded, and the optional wait behavior follows. Nothing is repeated from structured fields verbatim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should carry more of the return-value burden than the vague '结果为 Agent 生成内容'. It omits what a call returns when the query is still pending without wait_seconds, and how to obtain a request_id if absent.

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 50%: wait_seconds is fully documented in the schema, while request_id has only a pattern and no prose description. The description clarifies that request_id identifies a previously submitted query, which partially compensates, but adds no format, sourcing, or error semantics for it.

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?

The description states a specific verb-resource pair: it reads the results of an already-submitted Dayuan query, keyed by request_id. The qualifier '已提交的' (submitted) implicitly distinguishes it from dayuan_read_start, but it never names or contrasts with any sibling, so the distinction requires inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is only implied: an agent infers it should call this after a query has been submitted and it has a request_id. There is no explicit guidance on when to prefer dayuan_status vs this tool, or what to do if the request_id is unknown.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.