pipeline_run

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

Goes well beyond the annotations by disclosing that the response is fast with a short handshake wait limit, that a timeout must not be treated as failure and must not trigger a restart, that launch.handshake can be "not_confirmed" and is trackable via pipeline_status, and that the launch key is present only when launched=true. These are exactly the operational behaviors an agent cannot infer from readOnlyHint/idempotentHint alone.

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?

Front-loaded with purpose, then the usage decision path, then return/behavioral details; each block earns its place. It is dense but somewhat long, and the argument-equivalence note is buried at the end of the second paragraph rather than near the parameter discussion.

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?

With no output schema, the description does the work of explaining pipeline_path, launched, launch, and launch.handshake outcomes, including the reuse-existing-run case. The remaining gap is the input contract (request/request_id), which is left to a cross-reference.

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%, so the description carries the full burden, but it only says the arguments are the same as pipeline_plan. It never explains dataset_root, request, or request_id semantics, nor what shape `request` should take or how request_id affects behavior.

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?

States a specific compound action (計画と起動を一括実行) and frames itself as the entry point of the auxiliary path for running MS-DIAL Console from raw data. It immediately distinguishes itself from the main path (load_dataset), the preview tool (pipeline_plan), and the continue-existing-run tool (pipeline_resume).

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?

Gives an explicit precondition sequence: first check for .arf traces, and if found use load_dataset instead; only when no traces exist, obtain user consent and then call this tool. It also names pipeline_plan for pre-launch inspection and pipeline_resume for advancing an existing run, so both when-to-use and when-not-to-use are covered.

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