Fetch a material resource's latest preview by resourceId; returns a WebP thumbnail, an inline file stream, or 404 when unavailable.
预览资源最新版本。项目成员且通过可见范围校验。取最新版本——有缩略预览时返回 image/webp；无预览但文件 mime 命中内联白名单（位图、PDF、Markdown、常见音视频）时返回原始文件流；否则 404。 GET /api/projects/{id}/materials/{resourceId}/preview 项目由当前 API 密钥自动确定，无需传 projectId。
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond them: the auth/visibility requirement, the content-negotiation outcome (image/webp when a thumbnail exists, raw stream for whitelisted inline MIME types, 404 otherwise). That tells the agent exactly what it will get back and when it fails.
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 the action and the fallback chain, then auth, then the route. Every clause carries information. The raw 'GET /api/projects/...' line is the one mildly redundant element given the tool name already encodes the path.
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?
No output schema exists, and the description fully compensates by enumerating the three possible response outcomes and the 404 case. Combined with the stated authorization precondition, an agent has everything needed to call and interpret the result.
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 nested resourceId parameter, so the description must carry the load. It clarifies that the project is derived from the API key and that projectId must not be passed — useful — but gives no format or semantics for resourceId itself beyond the URL template. Partial compensation only.
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+resource: 'preview the latest version of a resource'. The 'latest version' scoping distinguishes it from the sibling anon_get_materials_resource_id_versions_version_preview, which targets a specified version. An agent can select correctly without opening the schema.
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 clear usage conditions: project membership plus visibility-scope check, and 'takes the latest version' which implicitly routes away from the version-specific preview sibling. It never explicitly names that alternative or states exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.