Progress of a regime analysis or pairs check started with start_regime_analysis.
Returns `{task_id, status, progress, message, dashboard_url}`. When the
analysis has finished, the answer also carries `result`, the same
summary `summarize_workflow` gives (for a pair, the pairs check), and
`report_url`, the report, which the run's card in the chat shows.| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint/destructiveHint already declaring a safe read, the description still adds real value: it discloses the exact return keys, the terminal-state behavior ('when the analysis has finished, the answer also carries `result`'), and that `result` mirrors `summarize_workflow` while `report_url` matches the chat card. It does not cover polling cadence, status value semantics, or behavior on a stale/invalid task_id.
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?
Three tight sentences: purpose and origin first, then the return payload, then the terminal-state additions. No filler, and the most decision-relevant information is front-loaded.
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?
There is no output schema, so the description must enumerate return values — it does so thoroughly, including the conditional `result` and `report_url`. Combined with annotations covering the safety profile, an agent has what it needs; only error/edge-case behavior is missing.
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 coverage is 0% for the single `task_id` property, so the description carries the burden and does so partially by tying the id to a run created via `start_regime_analysis`. It never says explicitly that `task_id` is that tool's returned identifier, nor what happens if it is unknown, so a little meaning is left implicit.
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 the specific verb and resource ('Progress of a regime analysis or pairs check') and names the originating tool `start_regime_analysis`, which separates it from the many other *_progress siblings. It stops short of explicitly contrasting with sibling progress tools like `get_regime_optimization_progress` or `list_my_running_tasks`, so it lands just under the top mark.
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?
Clearly frames the usage context: call this after starting a run with `start_regime_analysis` to poll its state. No when-not guidance or alternative routing (e.g., for already-finished runs or for enumerating tasks) is offered, which keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.