get_workflow_detail

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

With no annotations, the description carries the behavioral burden. It discloses that the operation returns a JSON string containing form field values, approval opinions, and routing logs, and it explains what the two boolean flags toggle. It does not mention error cases, permissions, or side effects, but the read-only nature is clearly indicated by '获取'.

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

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

The description is well structured: a purpose statement, an Args block, and a Returns block. Information is front-loaded and each section has a clear role. The first line merely repeats the tool name and the 'core interface' sentence is mildly promotional, but the overall density is good.

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

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

Given 3 parameters, no annotations, and the presence of an output schema, the description is largely complete: it covers parameter semantics, the source of request_id, and the general return content. It could add guidance on when to set the booleans false or how to handle errors, but those are minor gaps for a read-only detail lookup.

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

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

Schema description coverage is 0%, and the description compensates in the Args section. It explains that request_id comes from the workflow list's requestid field and clarifies the meaning and defaults of is_get_form_data and is_get_request_log. Some details, like the booleans' defaults, are redundant with the schema, but the added semantics are non-obvious and useful.

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

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

The description states a specific verb and resource: '获取流程详情' and '根据流程请求ID获取流程的详细信息，包括表单数据、审批记录等'. It also identifies itself as the core interface for getting program modification content. However, it does not explicitly disambiguate from the sibling get_program_modification_details, so it stops short of a 5.

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

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

The description implies usage context well: the request_id should come from the workflow list's requestid field, and this tool is the core way to get the actual modification content. But it never explicitly states when not to use it, what conditions select this tool over sibling list/detail tools, or any exclusions.

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