Production-ready images in one pass: resize, crop, compress, convert format, upscale, tag for SEO
Scored across 3 tools
The three tools have clearly distinct purposes: optimize_image processes images, status reports account/credit state, and upgrade opens the pricing page. An agent can easily pick the right tool with no overlap.
All names are lowercase snake_case, but the pattern is mixed: optimize_image is verb_noun while status (a noun) and upgrade (a verb) are single words. Still readable and predictable enough overall.
Three tools is a tight, focused set for an image-optimization service, with one core action plus two account utilities. It is slightly thin, especially since the descriptions reference tools that are not present.
The optimize_image description references a login tool and a confirm_gif_cost tool that do not exist in the set, and there is no separate batch tool despite heavy batch-processing guidance. Core optimization plus account status/upgrade is covered, but these notable gaps will cause dead ends.
Optimize an image: smart lossy compression (typically 60-80% size reduction), optional resize/upscale/format conversion, and AI-generated SEO metadata. Accepts absolute local file paths or remote URLs. In remote/API mode, only remote URLs are supported. Supported input formats: JPG, PNG, WebP, AVIF, GIF, SVG, ICO, HEIC, TIFF, BMP (max 50 MB). Supported output formats: JPG, PNG, WebP, AVIF, GIF, SVG, ICO. Credits: 3 to compress (always), +1 if width or height is set, +2 to upscale, +1 for SEO tags (on by default). A full pipeline is 7 credits. Upscale is charged whether you request it or the server adds it automatically — it does so whenever a resize target exceeds the source by more than 1.2x, so a resize-only call on a small image also costs 7. SVG or ICO output is a flat 1 credit, overriding everything above. Animated GIFs are billed per frame: (per-frame operations x frames) + 1 if tags, up to 601 credits at the 100-frame limit — confirm_gif_cost gates that path. GIFs are excluded from automatic upscaling. Works as a guest with no signup. Log in with the login tool for more credits. Use status tool to check remaining credits before batch processing.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Absolute local file path or remote URL of the image to optimize. Note: in remote/API mode, only remote URLs are supported (no local file paths). Supported inputs: JPG, PNG, WebP, AVIF, GIF (animated supported), HEIC, TIFF, BMP (max 50 MB). GlassyPic supports high-quality conversion between any input and output format. | |
| output_path | No | Where to save. Accepts a file path (/tmp/out.webp) or directory ending in / (/tmp/images/). If omitted: saves next to original, named with SEO slug when SEO is enabled or .polished suffix otherwise. URLs save to current working directory. | |
| output_format | No | Output format. Defaults to 'original' (keep input format). Animated GIFs stay animated when output is 'gif'; converting to other formats preserves only the first frame. SVG output from raster input uses vector tracing. ICO output generates a favicon set (16, 24, 32, 48, 256px) unless a specific size is given. | |
| gif_frame_limit | No | Maximum frames to process for animated GIFs (1-100, default 100). Reduces cost by sampling fewer frames while preserving animation. | |
| output_width_px | No | Target width in pixels. Set only width for proportional resize. Set both width and height for exact output dimensions (see output_resize_behavior). Costs 1 credit. If the target exceeds the source by more than 1.2x, the server also adds an AI upscale for a further 2 credits. | |
| confirm_gif_cost | No | Set to true to proceed with animated GIF processing after seeing cost warning. Required for animated GIFs to prevent unexpected credit consumption. | |
| output_height_px | No | Target height in pixels. Set only height for proportional resize. Set both width and height for exact output dimensions (see output_resize_behavior). Costs 1 credit. If the target exceeds the source by more than 1.2x, the server also adds an AI upscale for a further 2 credits. | |
| _gif_temp_file_id | No | Internal: temp file ID from a previous GIF cost warning. Skips re-upload. | |
| output_seo_tag_gen | No | Generate SEO metadata (alt text, keywords, filename) and rename output file to SEO slug. Costs 1 extra credit. Default: true. | |
| output_upscale_factor | No | AI upscale factor: 2 (2×) or 4 (4×). Uses Real-ESRGAN for high-quality upscaling. Costs 2 credits. Note that upscaling also triggers automatically, without this parameter, whenever a resize target exceeds the source by more than 1.2x — the same 2 credits are charged either way. | |
| output_file_size_limit | No | Target maximum output file size in bytes. The server will attempt to meet this limit through additional compression. Not guaranteed. | |
| output_resize_behavior | No | When both width and height are set and aspect ratio differs: 'pad' adds white padding (default), 'crop' smart-crops to fill exact dimensions |
| Name | Required | Description |
|---|---|---|
| output_path | Yes | Local server: absolute path where the optimized file was saved. Remote server: an https download URL that works without credentials until it expires (see download_expires_in_seconds); download it promptly. |
| seo_alt_text | Yes | AI-generated image alt text for accessibility and SEO |
| seo_filename | Yes | AI-generated SEO filename slug without extension |
| seo_keywords | Yes | AI-generated keywords describing the image |
| output_format | Yes | Output format: jpg, png, webp, avif, gif, svg, or ico |
| output_width_px | Yes | Width of the output image in pixels |
| output_height_px | Yes | Height of the output image in pixels |
| compression_ratio | Yes | Output-to-input size ratio, e.g. 0.35 means 65% smaller |
| output_size_bytes | Yes | File size of the optimized image in bytes |
| download_expires_in_seconds | No | Remote server only: seconds until the output_path download URL expires |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare write/non-idempotent/open-world; the description adds substantial behavior: the automatic upscale trigger (target >1.2x source, charged even if unrequested), per-frame animated-GIF billing up to 601 credits, GIF exclusion from auto-upscaling, flat SVG/ICO credit override, the remote-mode URL-only restriction, and the 50 MB cap. This is exactly the beyond-annotation context the dimension rewards.
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?
Purpose is front-loaded and the format/limit facts are efficient, but the middle billing paragraph is a dense run-on ('A full pipeline is 7 credits... up to 601 credits at the 100-frame limit') that is hard to parse and partially duplicates cost notes already in the schema's parameter descriptions.
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 12-parameter mutation tool, the description covers modes, formats, size limits, cost model, GIF edge cases, and guest/auth behavior. An output schema exists, so return values need no explanation, and nothing an agent needs to invoke it correctly 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 100%, so the baseline is 3; the description earns above that by explaining cross-parameter cost interactions (width/height +1, upscale +2, SEO +1) and the resize-triggers-upscale rule that ties output_width_px/output_height_px to output_upscale_factor. It clarifies parameter economics rather than merely restating field names.
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 ('Optimize an image') and enumerates the concrete operations (smart lossy compression, resize/upscale/format conversion, AI SEO metadata). It is trivially distinguishable from the sibling tools (login/status/logout/upgrade), which handle account/credits rather than image work.
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?
Routes the agent to siblings: 'Log in with the login tool for more credits' and 'Use status tool to check remaining credits before batch processing,' plus the guest-mode note and the confirm_gif_cost gate. It gives clear usage context but no explicit when-not-to-use guidance (there is no competing image tool, so that omission is minor).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check your GlassyPic account status: login state, tier, credits remaining, and credit reset time. Use this before batch processing to verify sufficient credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, covering the safety profile. The description adds the specific status fields and a use-case tip, but does not disclose additional behavioral traits such as authentication requirements or rate limits. With annotations present, this is adequate but not rich.
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?
The description is two concise sentences, front-loaded with the purpose and followed by actionable usage advice. No unnecessary words or repetition.
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 simple status-check tool with no parameters, the description is complete. It explicitly lists the return fields, compensating for the lack of an output schema, and provides a clear usage scenario.
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?
The tool has zero parameters, so the input schema covers everything trivially. The description adds no parameter details, which is appropriate. Per the rubric, a 0-parameter tool gets a baseline of 4.
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 clearly states the tool's function with a specific verb ('Check') and resource ('GlassyPic account status'), and enumerates the exact data returned (login state, tier, credits remaining, credit reset time). It distinguishes itself from sibling tools like login/logout/upgrade by being the read-only status checker.
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 description provides a concrete usage context: 'Use this before batch processing to verify sufficient credits.' It does not explicitly mention when not to use or name alternatives, but the guidance is clear and practical for the intended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open the GlassyPic pricing page in the user's browser, where the account's plan can be reviewed and changed. Call this only when the user asks to change or review their plan.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is open-world, idempotent, and non-destructive. The description adds valuable context that it opens a page (not directly modifying the plan) and that the plan can be changed from that page. This goes beyond the annotations without contradicting them.
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?
The description is a single, well-structured sentence that front-loads the core action and then provides the usage condition. Every word earns its place with no 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 tool with no parameters and no output schema, the description is completely sufficient: it explains what the tool does, what page it opens, and when to call it. There are no gaps in understanding.
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?
The tool has zero parameters, and the schema covers everything (100% coverage). The description still contributes by clarifying the action's intent, though no parameter details are needed. This aligns with the baseline for parameterless tools.
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 uses a specific verb ('Open') and specifies the resource ('GlassyPic pricing page'), clearly distinguishing this from sibling tools like login, logout, status, and optimize_image. It states exactly what the tool does and why it exists.
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 description gives explicit when-to-use guidance: 'Call this only when the user asks to change or review their plan.' This is a clear directive that also implies when not to use it, making it easy for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
optimize_image2 fields changedOutput schema / properties / download_expires_in_secondsAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "description": "Remote server only: seconds until the output_path download URL expires"
+}Output schema / properties / output_path / descriptionPrevious value: -"Absolute path where the optimized file was saved"New value: +"Local server: absolute path where the optimized file was saved. Remote server: an https download URL that works without credentials until it expires (see download_expires_in_seconds); download it promptly."status1 field changedInput schema / additionalPropertiesRemoved value: -falseupgrade1 field changedInput schema / additionalPropertiesRemoved value: -falseoptimize_image17 fields changedInput schema / properties / output_height_px / descriptionPrevious value: -"Target height in pixels. Set only height for proportional resize. Set both width and height for exact output dimensions (see output_resize_behavior)."New value: +"Target height in pixels. Set only height for proportional resize. Set both width and height for exact output dimensions (see output_resize_behavior). Costs 1 credit. If the target exceeds the source by more than 1.2x, the server also adds an AI upscale for a further 2 credits."Input schema / properties / output_path / descriptionPrevious value: -"Where to save. Accepts a file path (/tmp/out.webp) or directory ending in / (/tmp/images/). If omitted: saves next to original, named with SEO slug when SEO is enabled or .tinified suffix otherwise. URLs save to current working directory."New value: +"Where to save. Accepts a file path (/tmp/out.webp) or directory ending in / (/tmp/images/). If omitted: saves next to original, named with SEO slug when SEO is enabled or .polished suffix otherwise. URLs save to current working directory."Input schema / properties / output_upscale_factor / descriptionPrevious value: -"AI upscale factor: 2 (2×) or 4 (4×). Uses Real-ESRGAN for high-quality upscaling."New value: +"AI upscale factor: 2 (2×) or 4 (4×). Uses Real-ESRGAN for high-quality upscaling. Costs 2 credits. Note that upscaling also triggers automatically, without this parameter, whenever a resize target exceeds the source by more than 1.2x — the same 2 credits are charged either way."Input schema / properties / output_width_px / descriptionPrevious value: -"Target width in pixels. Set only width for proportional resize. Set both width and height for exact output dimensions (see output_resize_behavior)."New value: +"Target width in pixels. Set only width for proportional resize. Set both width and height for exact output dimensions (see output_resize_behavior). Costs 1 credit. If the target exceeds the source by more than 1.2x, the server also adds an AI upscale for a further 2 credits."Output schema / properties / compression_ratio / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / compression_ratio / typeRemoved value: -[
- "number",
- "null"
-]Output schema / properties / output_format / anyOfAdded value: +[
+ {
+ "minLength": 0,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / output_format / descriptionPrevious value: -"Output format: jpg, png, webp, avif, or gif"New value: +"Output format: jpg, png, webp, avif, gif, svg, or ico"Output schema / properties / output_format / typeRemoved value: -[
- "string",
- "null"
-]Output schema / properties / output_height_px / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / output_height_px / typeRemoved value: -[
- "number",
- "null"
-]Output schema / properties / output_width_px / anyOfAdded value: +[
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / output_width_px / typeRemoved value: -[
- "number",
- "null"
-]Output schema / properties / seo_alt_text / anyOfAdded value: +[
+ {
+ "minLength": 0,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / seo_alt_text / typeRemoved value: -[
- "string",
- "null"
-]Output schema / properties / seo_filename / anyOfAdded value: +[
+ {
+ "minLength": 0,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / seo_filename / typeRemoved value: -[
- "string",
- "null"
-]optimize_imagestatusupgradeResize, compress, convert, watermark and SEO-tag e-commerce product images from a public URL.
Resize, convert to WebP, compress, crop, rotate and strip EXIF from images
AI-native digital asset management: semantic search, generative image edits, and CDN delivery.
Resize, compress, convert, crop, rotate and watermark images, one at a time or in a zip.
Add one secure layer between your agents and this server.
