Extract an intensity profile along a line between two image pixel centers, with optional width, and return the calibrated distance.
沿两点取强度剖面：直接传 x0/y0/x1/y1 原图像素中心坐标（不是 start/end；只有 dm_2d_preview 的 profile 对象用 start/end）。可指定 width，按标定返回距离。
| Name | Required | Description | Default |
|---|---|---|---|
| x0 | Yes | ||
| x1 | Yes | ||
| y0 | Yes | ||
| y1 | Yes | ||
| width | No | 沿线垂直方向的剖面宽度（像素），默认 1；算法与边界策略随结果返回 | |
| image_id | No | 图像 id（来自 dm_datasets），或 "front" 表示前台窗口 |
Changes observed during successful MCP inspections.
v0.6.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It does disclose that the result reports distance according to calibration and that the width algorithm/boundary strategy are returned with the result, which implies a non-destructive read. It does not state permissions, whether the image must be open, or the overall shape of the response.
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?
Two compact sentences with the core action front-loaded and no filler. The parenthetical mixes parameter guidance with sibling disambiguation, which is dense but still earns its place.
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?
For a six-parameter tool with no annotations and no output schema, the description covers coordinates, width, and calibrated distance output. It omits whether the intensity profile itself is returned and what happens when image_id is absent (e.g., defaulting to the front window), leaving real gaps.
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 only 33%, and the four undocumented required parameters (x0/y0/x1/y1) are exactly what the description explains: raw pixel-center coordinates rather than start/end labels. It also mentions width's effect; only image_id semantics are left entirely to the schema.
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 verb and resource: take an intensity profile along two points, using raw image pixel-center coordinates. It also explicitly separates itself from sibling dm_2d_preview's profile object, so an agent can distinguish the two calling conventions.
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 parenthetical about start/end applies to dm_2d_preview's profile object, which is a useful disambiguation against that alternative. However, it never states when to prefer this tool over siblings like dm_2d_analyze or dm_2d_preview, nor any prerequisites such as needing an open image.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.