share_fileShares one image (PNG, JPEG, GIF, WebP, AVIF; not SVG) or PDF as a new site with a viewer and Download button: without content, a link where the user drops their file; with name and content (base64, up to 10 MB), published at once.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | With content: e.g. menu.pdf | |
| content | No | The file, base64-encoded (no data: prefix) |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / properties / name / descriptionPrevious value: -"With content: file name with extension, e.g. menu.pdf"New value: +"With content: e.g. menu.pdf"Output schema / (root)Previous value: -nullNew value: +{
+ "type": "object"
+}Input schema / properties / name / maxLengthRemoved value: -255Output schema / (root)Previous value: -{
- "additionalProperties": {},
- "properties": {
- "agent_message": {
- "type": "string"
- },
- "confirm_token": {
- "type": "string"
- },
- "error": {
- "description": "On failure (isError): {code, message}"
- }
- },
- "type": "object"
-}New value: +nullDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare non-read-only, non-destructive, open-world and non-idempotent, and the description stays consistent with them while adding substantive context: a 10 MB ceiling, base64 without data: prefix, and the fact that the result is a site with a viewer and Download button. It does not address whether repeating a publish creates a duplicate site (relevant given idempotentHint=false), which is the one behavioral gap.
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 dense sentence with the core action and format constraints front-loaded, followed by the two-mode behavior. Nothing is filler, though the packing of formats, size limit and both modes into one sentence makes it slightly harder to scan.
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 only two optional parameters, full schema coverage, an output schema to carry return values, and annotations covering the safety profile, the description supplies everything an agent needs: accepted types, the SVG exclusion, the size cap, encoding, and what gets created in each mode.
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 100%, so the baseline is 3, but the description goes beyond it by explaining that 'name' only matters when content is supplied and that content is capped at 10 MB and must be bare base64. That mode-dependency is not obvious from the schema alone.
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 names a specific verb and resource ('Shares one image ... or PDF as a new site') and enumerates supported formats plus an explicit exclusion (not SVG), so the agent knows exactly what the tool produces. It stops short of naming the closest sibling (create_upload_link) whose territory the 'link where the user drops their file' mode arguably overlaps, so sibling differentiation is implied rather than stated.
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?
It clearly lays out the two invocation modes: omit content to get a drop-link, or supply name+content to publish immediately. That is actionable conditional guidance, but there is no statement of when to prefer this over create_upload_link or other site-creating siblings.
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.