Uploads a local PNG, JPEG, or WebP image under 3 MiB as a temporary IMA file and returns an accessible temporary download URL for sharing or referencing.
把本地图片（PNG/JPEG/WebP，严格小于 3MiB）上传为 IMA 临时文件，返回可访问的临时 download_url。
| Name | Required | Description | Default |
|---|---|---|---|
| image_path | Yes |
Changes observed during successful MCP inspections.
v1.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and it does disclose real behavior: mutations happen (upload), accepted formats are PNG/JPEG/WebP, there is a hard size cap of strictly under 3MiB, and the returned URL is explicitly temporary. It omits lifetime/expiry semantics for the temporary file and whether cleanup is required.
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?
A single front-loaded sentence that names the action, the input constraints, and the return value with no filler or redundancy.
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 mutation tool with no annotations and no output schema, the description should explain the returned value more fully. It states a temporary download_url is returned but not how long it stays valid or what an agent should do with it, leaving a notable gap for an upload operation.
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% and image_path is completely undocumented in the schema, so the description must compensate. It does add meaningful constraints on what image_path must point to: a local file in one of three formats, under 3MiB. It still doesn't clarify path semantics (absolute vs relative, whether directories or URLs are rejected).
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: uploads a local image (PNG/JPEG/WebP, strictly under 3MiB) as an IMA temporary file and returns a temporary download_url. This is clear and even corrects the misleading tool name 'get_image_url', which implies retrieval rather than upload. It does not distinguish itself from siblings such as ima_insert_images_to_note or ima_upload_file_to_knowledge.
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?
Use is only implied: you need a local image file of the listed formats. The description never says when to choose this over ima_insert_images_to_note or ima_upload_file_to_knowledge, nor does it state prerequisites or what the returned URL is used for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.