Production-ready images in one pass: resize, crop, compress, convert format, upscale, tag for SEO
Scored across 3 tools
The three tools serve clearly distinct purposes: optimizing images, checking account status, and upgrading the plan. There is no overlap or ambiguity between them.
The naming is mixed: optimize_image follows a verb_noun pattern, but status is a bare noun and upgrade is a bare verb. The names are readable but not stylistically consistent.
Three tools is reasonable for a focused image optimization API, but it feels slightly thin given the detailed credit and GIF handling logic described in optimize_image and references to missing tools.
The tool set references a login tool and a confirm_gif_cost tool that are not present, leaving authentication and GIF cost confirmation gaps. Core optimization is covered, but these referenced utilities are missing.
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. Guest (unregistered): 20 credits/day, no signup. Log in with the login tool for more credits — registered Free tier is 30/day. 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 | Absolute path where the optimized file was saved |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations: it discloses that compression is lossy, that upscaling can be triggered automatically even when not explicitly requested, that the server charges credits for this automatic behavior, and that SVG/ICO output has flat pricing that overrides the normal formula. It even describes GIF frame-based billing and the 100-frame cap. None of this contradicts the annotations; it substantially enriches 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 long, but almost every sentence carries operational or financial consequence. The most important information is front-loaded (what optimize does, input/output formats, credit costs). It is somewhat dense and could benefit from bullet separation, but it avoids fluff and redundancy aside from a minor repetition of the remote-URL mode caveat.
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 12 parameters, a complex credit model, format conversion rules, and GIF-specific behavior, the description covers the relevant context thoroughly: formats, size limits, file path semantics, automatic upscaling, credit calculation, quota limits, and where to check remaining credits. Since an output schema exists and the input schema details parameter defaults, nothing critical is left unexplained.
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 adds meaningful cross-parameter semantics not fully captured in the schema: the total credit formula, the automatic-upgrade cost condition, the SVG/ICO flat-rate override, GIF per-frame billing, and daily guest/free quotas. This helps an agent reason about combinations of parameters, not just individual ones.
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 opens with a specific verb and scope — 'Optimize an image: smart lossy compression... optional resize/upscale/format conversion, and AI-generated SEO metadata' — and enumerates supported input/output formats. This clearly distinguishes optimize_image from siblings like status and upgrade, which serve entirely different purposes.
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 strong contextual guidance: it explains when remote URLs are required, warns that animated GIF processing needs confirm_gif_cost, tells users to check credits via the status tool before batch processing, and points to the login tool for higher quotas. It does not explicitly state 'when not to use this tool,' but no competing image-optimization sibling exists, so the absent exclusion is not a meaningful gap.
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?
The annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is established. The description adds meaningful behavioral context by listing what the status check reveals and why it matters before batch processing. No contradiction with annotations.
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 sentences with no filler: the first sentence states the resource and expected output fields, and the second gives the recommended usage. The purpose is front-loaded and every phrase 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 no-parameter, read-only status tool, the description is complete: it names the operation, enumerates the returned information, and gives a concrete trigger for use. The rich annotations and absence of parameters mean there is no critical missing context.
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 input schema has zero parameters)Skip; with no parameters, the description cannot add parameter-level detail. The baseline of 4 is appropriate here because there is nothing to explain beyond what the empty schema already conveys.
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 ('Check'), names the resource ('GlassyPic account status'), and enumerates the exact fields returned: login state, tier, credits remaining, and credit reset time. This clearly separates it from the sibling tools 'optimize_image' and 'upgrade'.
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 an explicit use case: 'Use this before batch processing to verify sufficient credits.' This gives clear contextual guidance, though it does not explicitly state when not to use it or mention alternatives among the siblings.
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 declare openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the side-effect profile. The description adds context by specifying it opens the page in the user's browser and that the plan can be changed, which is useful beyond the raw annotations. It does not contradict any annotation, and the added detail (browser opening) is consistent with the openWorld hint. With annotations present, a 4 is fair.
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. The first sentence front-loads the primary action and resource, and the second gives the usage condition. There is no wasted wording, padding, or redundancy. Every sentence 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?
Given the tool has no parameters, no output schema, and simple side effects (opening a browser page), the description fully covers what an agent needs to call it correctly. It states the action, the resource, the purpose, and the trigger. Nothing essential 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?
The tool has zero parameters, so the schema covers everything. Per the rubric, a baseline of 4 is given when there are 0 params. The description does not need to add parameter meaning since none exist. It correctly makes no reference to parameters.
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 a specific verb ('Open'), a resource ('the GlassyPic pricing page'), and the purpose ('where the account's plan can be reviewed and changed'). It distinguishes the tool from its siblings (optimize_image, status) by its singular action of opening a pricing page, leaving no ambiguity about what it does.
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 explicitly states when to call the tool: 'Call this only when the user asks to change or review their plan.' This gives a clear condition for use. It does not mention when not to use it or alternative tools, but the condition is specific enough to guide an agent. The absence of exclusions is minor, so a 4 is appropriate.
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_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.
AI-native digital asset management: semantic search, generative image edits, and CDN delivery.
Image processing for AI agents: resize, convert, compress, crop, and web-ready AI-generated images.
Image toolkit: resize, convert, compress, crop, metadata, hashes, favicons, OCR, QR codes, barcodes.
Add one secure layer between your agents and this server.
