This server provides image optimization and manipulation via the Tinify.dev API, allowing you to compress, resize, crop, convert formats, and check usage.
Compress images: Reduce file size of PNG, JPEG, WebP, and AVIF files with optional quality modes (balanced, best_quality, lossless) and target size. Honestly reports when optimization isn't possible and skips saving in that case.
Resize images: Change dimensions by width, height, or scale, with aspect ratio preservation.
Crop images: Extract a rectangular region using coordinates and dimensions.
Convert image formats: Convert between AVIF, WebP, JPEG, and PNG.
Get usage: Retrieve account plan, billing period, and operations usage statistics.
All tools require absolute file paths, enforce a 40 MB file size limit, save to a new file by default (e.g., <name>.min.<ext>) unless explicitly overwritten, and return byte metrics (original_bytes, result_bytes, saved_bytes, change_percent) for programmatic evaluation.
MCP (Model Context Protocol) server for the Tinify.dev image API. Lets ChatGPT, Claude, Cursor, and other MCP clients compress, resize, crop, and convert images — with honest results.
You: compress the screenshots in ~/Desktop/launch/
Claude: 312.4 KB → 97.1 KB (-68.9%), wrote /Users/you/Desktop/launch/hero.min.png
84.2 KB → 84.2 KB — logo.png is already as small as Tinify.dev can make it
(optimized: false), so no file was written.Never lies about savings — when the API cannot shrink a file it says so (optimized: false) instead of writing a byte-identical "optimized" copy.
Never overwrites your originals silently — results go to <name>.min.<ext> beside the input, or to an explicit output_path. Replacing a file requires overwrite: true.
Raw numbers in structuredContent on every call, so agents can do math instead of parsing prose.
Not affiliated with TinyPNG. This server talks to the Tinify.dev API.
Node.js >= 20
A Tinify.dev API key from tinify.dev/developers — free tier is 500 operations/month, no card required.
Related MCP server: tinypng-mcp-server
Add to claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"tinify": {
"command": "npx",
"args": ["-y", "@tinify-dev/mcp"],
"env": { "TINIFY_API_KEY": "tnf_live_..." }
}
}
}claude mcp add tinify -e TINIFY_API_KEY=tnf_live_... -- npx -y @tinify-dev/mcpCreate .cursor/mcp.json in your project (or ~/.cursor/mcp.json globally):
{
"mcpServers": {
"tinify": {
"command": "npx",
"args": ["-y", "@tinify-dev/mcp"],
"env": { "TINIFY_API_KEY": "tnf_live_..." }
}
}
}The same five tools are available as a hosted streamable-HTTP MCP server - no install, works from ChatGPT connectors, the claude.ai directory, and any registry that expects a URL:
Endpoint: https://api.tinify.dev/mcp
Auth: OAuth 2.1 (PKCE + dynamic client registration), or
Authorization: Bearer tnf_live_... (or tnf_test_...)Two ways to authenticate:
OAuth (for connectors) - ChatGPT connectors and the claude.ai directory only speak "OAuth" or "no auth". Add the server by its URL (https://api.tinify.dev/mcp) and pick OAuth; the client discovers the authorization and token endpoints automatically from the server's .well-known metadata, registers itself, and opens a Connect Tinify page where you paste your Tinify API key. Your key stays the credential - the client only ever holds an opaque token that maps back to it server-side.
Direct bearer (for scripts/CLIs) - send Authorization: Bearer tnf_live_... (or tnf_test_...) and skip OAuth entirely. Unchanged.
In ChatGPT, open Settings → Security and login and enable Developer mode.
Open ChatGPT Plugins, select the plus button, and add https://api.tinify.dev/mcp.
Complete Connect Tinify with a Tinify API key.
Add the connection from the conversation's tools menu, attach a PNG/JPEG/WebP/AVIF, and ask:
Use Tinify to compress this image for the web. Show the original size,
result size, and percentage saved.The hosted server cannot access local paths, so each image tool accepts exactly one of:
image — the ChatGPT attachment object. ChatGPT fills this automatically because the descriptor advertises openai/fileParams.
image_base64 — a portable fallback for other MCP clients, capped at ~28 MB decoded.
ChatGPT attachment downloads are HTTPS-only, reject private/reserved network targets and redirects, time out after 30 seconds, and are capped at the Tinify API's 40 MB limit. Successful operations return exact byte metrics and a temporary MCP result link. Existing base64 callers also receive structuredContent.image_base64 for backwards compatibility. get_usage is identical to the local version. Nothing is written to the user's filesystem.
Try it with curl:
curl -s https://api.tinify.dev/mcp \
-H "Authorization: Bearer tnf_live_..." \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"curl","version":"0"}}}'For local files, prefer the stdio server above - it reads and writes them directly with no base64 round-trip and no 28 MB cap.
This repository intentionally supports both OpenAI and Claude:
The shared tool names, Tinify client, result metrics, errors, and annotations are platform-neutral.
The stdio adapter uses absolute local paths and writes files for desktop/CLI clients such as Claude, Cursor, and Codex.
The hosted adapter uses ChatGPT file attachments or base64 and returns temporary result links because hosted servers cannot read a user's filesystem.
An OpenAI-only repository would duplicate the Tinify logic and make behavior drift more likely. OpenAI-specific descriptor metadata stays as a small additive layer in the hosted adapter; a separate repository is not needed.
For public OpenAI submission, set the portal-provided domain token as
OPENAI_APPS_CHALLENGE_TOKEN in /etc/tinify/mcp-http.env and deploy the
matching nginx location from deploy/nginx-location.conf. The endpoint returns
only that token at /.well-known/openai-apps-challenge; do not commit the real
portal token.
Tool | Arguments | Does |
|
| Compresses PNG/JPEG/WebP/AVIF. Writes |
|
| Resizes and writes the result. |
|
| Crops to a rectangle and writes the result. |
|
| Converts formats (beta — the endpoint is rolling out server-side). Default output: |
| — | Plan, billing period, operations used and remaining. |
All image tools require absolute paths (MCP servers run with an unpredictable working directory) and pre-check the 40 MB API limit locally. API errors come back as readable tool errors with the error code and request_id to quote to support.
"Compress every PNG in /Users/me/site/static/img"
"Resize /Users/me/photo.jpg to 1200px wide and tell me how many bytes it saved"
"Convert /Users/me/hero.png to webp with best quality"
"How many Tinify operations do I have left this month?"
Max 40 MB / 50 MP per image; PNG, JPEG, WebP, AVIF.
Uploaded images and results are deleted from Tinify.dev servers after 2 hours.
The server only reads the files you point it at and only writes where it tells you it wrote.
"TINIFY_API_KEY is not set" — the server exits at startup with the exact config snippet to fix it. Add the key to the env block of your MCP config.
invalid_api_key — the key is wrong or revoked; create a new one at tinify.dev/developers.
quota_exhausted (429) — the monthly quota is used up; run get_usage to see the period end.
"path must be absolute" — pass full paths like /Users/you/img.png, not ./img.png.
Logs go to stderr; in Claude Desktop see ~/Library/Logs/Claude/mcp-server-tinify.log.
Batch tools (create/commit/wait/download) on top of the durable batch API — not in v1.
MIT © Stian Larsen
Cursor: Add to Cursor - then set your real key in Cursor's MCP settings.
VS Code:
code --add-mcp '{"name":"tinify","command":"npx","args":["-y","@tinify-dev/mcp"],"env":{"TINIFY_API_KEY":"tnf_live_..."}}'Codex CLI:
codex mcp add tinify --env TINIFY_API_KEY=tnf_live_... -- npx -y @tinify-dev/mcpor in ~/.codex/config.toml:
[mcp_servers.tinify]
command = "npx"
args = ["-y", "@tinify-dev/mcp"]
[mcp_servers.tinify.env]
TINIFY_API_KEY = "tnf_live_..."Claude Code plugin (MCP + image-optimization skill):
/plugin marketplace add Stianlars1/tinify-claude-plugin
/plugin install tinify@tinifyMore: https://tinify.dev/mcp
Compress a PNG, JPEG, WebP, or AVIF image with Tinify.dev and write the smaller file next to the original (or to output_path). The API never returns more bytes than it received; when it cannot shrink the file the tool says so honestly (optimized: false) instead of pretending.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the image (png, jpg, jpeg, webp, avif; max 40 MB). | |
| overwrite | No | Allow replacing an existing file at the output path. Default false. | |
| output_path | No | Absolute path to write the result. Default: <name>.min.<ext> next to the input. The source image is never overwritten unless output_path points at it AND overwrite is true. | |
| quality_mode | No | balanced (default), best_quality, or lossless. lossless is rejected for JPEG inputs. | |
| target_size_kb | No | Aim for a result at or below this many kilobytes (beta; server rollout). |
| Name | Required | Description |
|---|---|---|
| width | Yes | |
| wrote | Yes | Whether a file was written. |
| height | Yes | |
| optimized | Yes | false when the API could not shrink the file and returned the original bytes; null when the concept does not apply (resize/crop). |
| request_id | Yes | Quote this when contacting support. |
| output_path | Yes | Where the result was written, or null when nothing was written. |
| saved_bytes | Yes | original_bytes - result_bytes. |
| result_bytes | Yes | Result size in bytes. |
| change_percent | Yes | Byte change in percent; negative means smaller. |
| original_bytes | Yes | Input size in bytes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations: it explains that the API never returns more bytes, honestly reports if it cannot shrink (optimized: false), and clarifies that the source image is never overwritten unless output_path points at it and overwrite is true. No contradiction with annotations (readOnlyHint=false, destructiveHint=false is consistent with writing a new file).
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?
Two sentences, front-loaded with the main action and key formats. Every sentence provides essential information with no wasted words.
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 presence of an output schema (not shown but mentioned), the description covers the core behaviors: input formats, output behavior, and honesty flag. It is complete for a compression tool, including edge cases like inability to shrink.
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 baseline is 3. The description adds value by explaining the default output path naming ('<name>.min.<ext>') and the key behavior of the API (honest failure reporting), which reinforces parameter constraints without repeating schema details.
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 compresses PNG, JPEG, WebP, or AVIF images using Tinify.dev and writes the smaller file. The verb 'compress' and explicit format list make the purpose unambiguous, and it is distinct from siblings like resize, crop, or convert.
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 does not explicitly state when to use this tool versus alternatives. Usage is implied (when you need to reduce file size), but no exclusion criteria or comparison to siblings like resize_image is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert an image to AVIF, WebP, JPEG, or PNG with Tinify.dev (beta endpoint; may not be enabled on every account yet). Writes .min. next to the original unless output_path is given. Converting to the same format is rejected by the API (same_format_conversion).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the image (png, jpg, jpeg, webp, avif; max 40 MB). | |
| format | Yes | Target format. | |
| overwrite | No | Allow replacing an existing file at the output path. Default false. | |
| output_path | No | Absolute path to write the result. Default: <name>.min.<ext> next to the input. The source image is never overwritten unless output_path points at it AND overwrite is true. | |
| quality_mode | No |
| Name | Required | Description |
|---|---|---|
| width | Yes | |
| wrote | Yes | Whether a file was written. |
| height | Yes | |
| optimized | Yes | false when the API could not shrink the file and returned the original bytes; null when the concept does not apply (resize/crop). |
| request_id | Yes | Quote this when contacting support. |
| output_path | Yes | Where the result was written, or null when nothing was written. |
| saved_bytes | Yes | original_bytes - result_bytes. |
| result_bytes | Yes | Result size in bytes. |
| change_percent | Yes | Byte change in percent; negative means smaller. |
| original_bytes | Yes | Input size in bytes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral details beyond annotations: uses Tinify.dev, beta endpoint, file naming convention, and same-format rejection. However, it doesn't cover all traits like idempotency or rate limits.
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?
Two sentences, no fluff, front-loaded with key information. Every sentence adds value.
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?
Covers main purpose, side effects, and key constraint. However, it omits explanation of the quality_mode parameter, which is not described in the schema either. Output schema exists, reducing need to describe return values.
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 high (80%), so baseline is 3. The description adds context for output_path default behavior and same-format error, but does not explain the quality_mode parameter, leaving a gap.
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 converts images to specific formats (AVIF, WebP, JPEG, PNG) and distinguishes it from siblings like compress_image and resize_image by focusing on format conversion.
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 implies use for format conversion but does not explicitly compare to alternatives or state when not to use it. It mentions beta status and same-format rejection, but lacks guidance on choosing this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crop a PNG, JPEG, WebP, or AVIF image with Tinify.dev to the given rectangle and write the result next to the original (or to output_path). The source image is never overwritten silently.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | Left edge of the crop rectangle in pixels. | |
| y | Yes | Top edge of the crop rectangle in pixels. | |
| path | Yes | Absolute path to the image (png, jpg, jpeg, webp, avif; max 40 MB). | |
| width | Yes | Crop width in pixels. | |
| height | Yes | Crop height in pixels. | |
| overwrite | No | Allow replacing an existing file at the output path. Default false. | |
| output_path | No | Absolute path to write the result. Default: <name>.min.<ext> next to the input. The source image is never overwritten unless output_path points at it AND overwrite is true. |
| Name | Required | Description |
|---|---|---|
| width | Yes | |
| wrote | Yes | Whether a file was written. |
| height | Yes | |
| optimized | Yes | false when the API could not shrink the file and returned the original bytes; null when the concept does not apply (resize/crop). |
| request_id | Yes | Quote this when contacting support. |
| output_path | Yes | Where the result was written, or null when nothing was written. |
| saved_bytes | Yes | original_bytes - result_bytes. |
| result_bytes | Yes | Result size in bytes. |
| change_percent | Yes | Byte change in percent; negative means smaller. |
| original_bytes | Yes | Input size in bytes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by stating 'The source image is never overwritten silently', clarifying the non-destructive default behavior. Annotations show destructiveHint=false, so there is no contradiction. The description also mentions the max file size from schema, providing context.
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 only two sentences, no unnecessary words, and front-loaded with the verb and resource. 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?
The description covers purpose, input formats, output location, and overwrite safety. Given that an output schema exists (though not shown), the description does not need to explain return values. It is complete enough for an agent to use correctly.
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 description coverage is 100%, so baseline is 3. The description does not add extra meaning to parameters beyond what the schema provides. It mentions 'to the given rectangle' but does not elaborate on x, y, width, height specifics.
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 verb 'crop', the resource 'image', and specifies supported formats (PNG, JPEG, WebP, AVIF). It also explains the output behavior (writes next to original or to output_path). This clearly distinguishes from sibling tools like compress, resize, and convert.
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 does not explicitly state when to use this tool versus alternatives like resize_image or convert_image. It implies cropping by providing a rectangle, but lacks exclusionary guidance or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the Tinify.dev account's current billing-period usage: plan, period, operations included, used, and remaining.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| plan | Yes | |
| used | Yes | |
| included | Yes | |
| reserved | Yes | |
| remaining | Yes | |
| period_end | Yes | |
| request_id | Yes | |
| period_start | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already indicate a safe read operation. The description adds context about the specific data returned (plan, period, operations used). No contradictions exist.
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?
Single sentence, 12 words, front-loaded with the verb and resource. Every word earns its place. 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?
With an output schema present, the description needn't detail return structure. It covers the key categories of usage information. Given the tool's simplicity, it is fully complete.
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?
There are no parameters, so the description does not need to add parameter meaning. Per rules, baseline is 4 for 0-param tools. The description focuses on output, which is acceptable.
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 the specific verb 'Show' and clearly identifies the resource as 'Tinify.dev account's current billing-period usage', listing key fields (plan, period, operations included, used, remaining). This distinguishes it from sibling image processing tools.
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 does not explicitly state when to use or not use the tool, but sibling tools are all image manipulation, so usage context is clear by contrast. A note on when it is appropriate would improve clarity, but the current level is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resize a PNG, JPEG, WebP, or AVIF image with Tinify.dev by width, height, or scale, and write the result next to the original (or to output_path). At least one of width, height, or scale is required. The source image is never overwritten silently.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the image (png, jpg, jpeg, webp, avif; max 40 MB). | |
| scale | No | Scale factor, e.g. 0.5 halves both dimensions. | |
| width | No | Target width in pixels. | |
| height | No | Target height in pixels. | |
| overwrite | No | Allow replacing an existing file at the output path. Default false. | |
| output_path | No | Absolute path to write the result. Default: <name>.min.<ext> next to the input. The source image is never overwritten unless output_path points at it AND overwrite is true. | |
| keep_aspect_ratio | No |
| Name | Required | Description |
|---|---|---|
| width | Yes | |
| wrote | Yes | Whether a file was written. |
| height | Yes | |
| optimized | Yes | false when the API could not shrink the file and returned the original bytes; null when the concept does not apply (resize/crop). |
| request_id | Yes | Quote this when contacting support. |
| output_path | Yes | Where the result was written, or null when nothing was written. |
| saved_bytes | Yes | original_bytes - result_bytes. |
| result_bytes | Yes | Result size in bytes. |
| change_percent | Yes | Byte change in percent; negative means smaller. |
| original_bytes | Yes | Input size in bytes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description adds important safety context: the source image is never overwritten silently, and details output path behavior. This clarifies mutation safety.
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, front-loaded with the main purpose, and includes critical constraints without unnecessary words.
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 7 parameters, high schema coverage, and an output schema (not shown), the description adequately covers output path defaults and safety. It is sufficient for an agent to understand the tool's behavior.
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 description coverage is 86%, so parameters are well-documented. The description adds minor value by reinforcing the requirement for at least one of width/height/scale and the overwrite behavior, but does not significantly deepen parameter understanding.
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 resizes images (PNG, JPEG, WebP, AVIF) using Tinify.dev by width, height, or scale, and specifies output behavior. It differentiates from sibling tools like compress_image and crop_image.
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 clear context on when to use the tool (resizing images) but does not explicitly exclude scenarios or mention alternatives. It states the requirement for at least one dimension parameter.
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. Dates show when Glama detected each change.
v0.1.5compress_imageconvert_imagecrop_imageget_usageresize_imageScored across 5 tools
Each tool has a unique purpose: get_usage shows account usage, compress_image reduces file size, resize_image changes dimensions, crop_image extracts a region, and convert_image changes format. No overlapping functionality.
All tool names follow a consistent verb_noun snake_case pattern: get_usage, compress_image, resize_image, crop_image, convert_image. Predictable and easy to understand.
With 5 tools, the server covers essential image operations (compression, resizing, cropping, format conversion) plus usage monitoring. The count is appropriate for a focused image optimization service.
The tool set provides a complete workflow for image optimization: usage checks, compression, resizing, cropping, and format conversion. No obvious gaps for the intended domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Image toolkit: resize, compress, crop, watermark, convert, rotate, EXIF read/strip.
Resize, compress, convert, watermark and SEO-tag e-commerce product images from a public URL.
Resize, convert, compress, crop, thumbnail and watermark images from your AI chat.
Convert images to PNG, JPEG, WebP, or AVIF through one public remote MCP tool.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Stianlars1/tinify-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
