Cleanor Tools is a zero-auth MCP server providing AI agents and builders with four core tools:
Optimize Images (optimize_image): Fetch an image from a public URL and re-encode it as WebP, AVIF, or JPEG with optional resizing by width, returning the optimized image along with before/after byte sizes.
Storage Capacity Lookup (storage_capacity): Calculate how many photos or minutes of video realistically fit in a given storage tier (e.g., 128 GB), corrected for real OS/filesystem overhead.
Image Format Savings Data (image_format_savings): Retrieve benchmark data on how much smaller WebP, AVIF, or JPEG XL are compared to JPEG at matched quality, including the "HEIC conversion tax" (how converting iPhone HEIC files to JPG/PNG increases file size).
QR Code Generation (qr_code): Encode any text or URL into a crisp, dependency-free SVG QR code with configurable error-correction level and size.
A hosted, zero-auth MCP server with 22 tools: optimize and convert images, generate QR codes, and run the deterministic dev utilities LLMs get wrong.
No API key. No signup. No OAuth. Point any Model Context Protocol client at one URL and 22 tools appear, all read-only and safe to hand to an autonomous agent.
Streamable HTTP endpoint |
|
npm package (stdio) | |
Official MCP Registry | |
Homepage | |
Auth | none |
Tools | 22 |
Version | 0.6.0 |
Pick your client. Every option below points at the same hosted server, so there is nothing to build, install or key.
claude mcp add --transport http cleanor https://mcp.cleanor.app/mcpThen run claude mcp list to confirm it connected. Full walkthrough: docs/add-an-mcp-server-to-claude-code.md.
Add to .cursor/mcp.json (per project) or ~/.cursor/mcp.json (global):
{
"mcpServers": {
"cleanor": {
"url": "https://mcp.cleanor.app/mcp"
}
}
}Run code --add-mcp '{"name":"cleanor","type":"http","url":"https://mcp.cleanor.app/mcp"}', or add the server to .vscode/mcp.json in the workspace:
{
"servers": {
"cleanor": {
"type": "http",
"url": "https://mcp.cleanor.app/mcp"
}
}
}Open Settings, then Connectors, then "Add custom connector", and paste the endpoint:
https://mcp.cleanor.app/mcpOr run the server locally over stdio from claude_desktop_config.json:
{
"mcpServers": {
"cleanor": {
"command": "npx",
"args": ["-y", "@cleanor/mcp"]
}
}
}The npm build is the same tool registry compiled for Node. It uses sharp (an optional dependency) for local image encoding; the other 21 tools need nothing.
The endpoint speaks the MCP Streamable HTTP transport, so you can drive it with curl or any HTTP client:
curl -s https://mcp.cleanor.app/mcp \
-H 'content-type: application/json' \
-H 'accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize",
"params":{"protocolVersion":"2025-06-18","capabilities":{},
"clientInfo":{"name":"curl","version":"1"}}}'There is also a plain REST surface for non-MCP callers: GET /v1/capabilities (feature detection, machine-readable tool list) and POST /v1/optimize (one image in, optimized bytes out).
Related MCP server: qr-maker
22 tools, every one of them carrying an input and an output schema, so a client gets typed structuredContent back and not just a wall of text.
Tool | What it does | Key params |
| Fetches an image from a public URL and re-encodes it smaller. Returns the optimized image plus before and after byte counts. Input capped at 25 MB. |
|
| Dependency-free SVG placeholder at any size, with a label and custom colors. |
|
| Encodes text or a URL as a crisp SVG QR code you can paste anywhere. |
|
Tool | What it does | Key params |
| How many photos or minutes of video actually fit in a storage tier, corrected for real OS and filesystem overhead. Returns a per-format breakdown. |
|
| How much smaller WebP, AVIF or JPEG XL are than JPEG at matched perceptual quality, from a controlled benchmark on the 24-image Kodak suite. Also reports the HEIC conversion tax. |
|
The operations an LLM is unreliable at: hashing, counting, radix math, timezones. Pure compute, no network, no state.
Tool | What it does | Key params |
| SHA-1/256/384/512 hex digest of text. MD5 is deliberately not offered. |
|
| Keyed HMAC signature, hex or Base64. For signing and verifying webhooks. |
|
| UUID v4 (random) or v7 (time-sortable, the better database key). |
|
| Base64 encode or decode, UTF-8 safe, optional URL-safe alphabet. |
|
| Validates JSON, then pretty-prints or minifies it, optionally deep-sorting keys. Returns a precise parse error if invalid. |
|
| Decodes a JWT header and payload and flags expiry. The signature is not verified and no secret is needed. |
|
| Runs a JavaScript regex against sample text and returns every match with its index and captured groups (first 100). |
|
| Explains a 5-field cron expression in plain English and lists the next 5 run times in UTC. |
|
| Exact conversion across length, mass, data size, time, speed and temperature. |
|
| The real current time, or any timestamp, rendered in an IANA timezone as ISO, Unix and human forms. |
|
| Splits a URL into scheme, host, port, path, decoded query params and fragment. |
|
| Integer conversion between bases 2 and 36, BigInt-exact so large values stay exact. |
|
| Line-by-line diff of two texts with an added and removed count. Up to 1000 lines per side. |
|
| Converts one color into hex, RGB and HSL at once. Accepts hex, |
|
| Derives a harmonious palette from one base color. |
|
| Clean, URL-safe slug from a title: lowercased, hyphenated, accents stripped. |
|
| Exact characters (code points), UTF-16 units, words, lines and UTF-8 bytes. |
|
Every tool is annotated readOnlyHint: true. Only optimize_image touches the network (openWorldHint: true); the other 21 are pure functions of their input.
Full input and output schemas: docs/mcp-tools-reference.md.
data/tools.csv is the same 22 tools as a flat, machine-readable table: name, title, category (image, data, dev), summary, required and optional parameters, and output fields. Handy for diffing releases, feeding an MCP directory, or comparing this server against another.
The file is generated, not hand-written: every value is read out of the tool's Zod schema in src/tools/. If you add or change a tool, regenerate it.
npm run tools:csv # rewrite data/tools.csv from src/tools/
npm run tools:csv:check # exit 1 if data/tools.csv is out of datePage | What it answers |
The | |
How to let an AI agent compress and convert images (WebP, AVIF, JPEG) through MCP, and the measured savings per format. | |
All 22 tools, one section each, with the complete input and output schema and an example call. |
Yes. It is free to use, with no account, no API key and no paid tier. The hosted endpoint is rate-limited per IP (120 requests per minute in general, 30 per minute for image optimization) so one client cannot starve the rest, and the source is MIT licensed if you would rather run it yourself.
No. Auth is none, which you can verify for yourself at GET https://mcp.cleanor.app/v1/capabilities. There is no signup, no OAuth flow and no token to rotate. Point your client at https://mcp.cleanor.app/mcp and start calling tools.
Only what you pass to a tool. 21 of the 22 tools are pure functions evaluated on the server, and optimize_image additionally fetches the public image URL you hand it. There is no account, no user identifier, and no database or object store in the server: it is a single Cloudflare Worker with no persistence binding for your inputs. If your data is sensitive, run the stdio build locally with npx -y @cleanor/mcp and nothing leaves your machine.
Yes, in two ways. Run it locally over stdio with npx -y @cleanor/mcp (the same tool registry, with sharp doing the image encoding instead of Cloudflare Images), or deploy this repo to your own Cloudflare account with wrangler deploy, since the Worker entry point and wrangler.jsonc are both in the tree. The Dockerfile builds the stdio server for registries and scanners that prefer to start it themselves.
A local (stdio) server is a process your client spawns on your machine: it can reach your filesystem, but you have to install it, keep it updated and carry its dependencies. A hosted (Streamable HTTP) server is just a URL: no install, no version drift, and the heavy work runs on someone else's CPU. Cleanor MCP is offered both ways, and the hosted endpoint is the one to prefer for image optimization, because Cloudflare Images does the encoding and you never install sharp.
Any MCP client that speaks Streamable HTTP: Claude Code, Claude Desktop (as a custom connector), Cursor, VS Code, and the agent frameworks with MCP support. Clients that only speak stdio can run the npm package instead. Both paths expose the identical 22 tools, because both register the same tool array from src/tools/.
storage_capacity and image_format_savings return numbers from Cleanor Labs' published studies, not from model memory. The format savings come from a controlled benchmark on the 24-image Kodak lossless suite at matched SSIM; the storage numbers come from measured per-item file sizes plus real OS overhead. Every response links its source page on cleanor.app/research.
Repo | What it is |
The in-browser image compression and conversion engine behind cleanor.app. | |
Chrome extension: compress, convert and capture images without leaving the page. | |
WordPress plugin that optimizes and converts your media library. | |
The open benchmarks behind the storage and image-format studies. | |
Open dataset of monthly search demand, the source for the Cleanor trends studies. |
Cleanor is a set of free, private browser tools (files never leave your device) plus original research on device storage and image formats. This MCP server is a thin front door to that toolset and that data, for AI agents.
Free browser tools: https://cleanor.app/tools
Research and studies: https://cleanor.app/research
MCP homepage: https://cleanor.app/mcp
MIT, Cleanor Labs.
If you use Cleanor MCP or its data, please cite it. Authored by Cleanor Labs, ORCID 0009-0005-4623-961X. The archived, citable version has DOI 10.5281/zenodo.21225551, a concept DOI that always resolves to the latest release. Machine-readable metadata lives in CITATION.cff.
How much smaller WebP, AVIF or JPEG XL are than JPEG at matched perceptual quality, from Cleanor Labs’ controlled benchmark. Also reports the "HEIC conversion tax" (converting an iPhone HEIC to JPG/PNG makes it bigger). Use to justify a format choice when building a site or app.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Target format to compare against JPEG. | avif |
| quality | No | web = typical web quality (SSIM 0.95); high = near-lossless (SSIM 0.98). | web |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully explains the tool's behavior: it reports benchmark-derived savings and the HEIC conversion tax. It is a read-only operation (consistent with readOnlyHint) and provides all key behavioral details beyond annotations, including the qualitative metric (SSIM) implicitly referenced.
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, efficiently delivering core purpose, bonus feature, and use case. No redundant or vague language; each 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 simple parameter set (2 optional enums with defaults) and no output schema, the description fully covers what the tool returns (savings numbers) and includes a notable extra detail (HEIC tax). It is complete and self-sufficient for agent 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?
Both parameters are fully described in the schema with enums and defaults. The description adds context by naming the target formats and quality levels, but does not significantly extend the meaning beyond the schema. Baseline 3 is appropriate given 100% schema coverage.
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 computes file size savings of WebP, AVIF, and JPEG XL over JPEG at matched perceptual quality, and mentions the HEIC conversion tax. It explicitly frames the tool for justifying format choices, distinguishing it from siblings like optimize_image and storage_capacity.
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 advises using the tool to justify format choices when building a site or app. It does not explicitly state when not to use or provide alternatives, but the context and sibling tools imply its comparative purpose. The guidance is clear but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch an image from a public URL and re-encode it smaller (WebP/AVIF/JPEG), optionally resizing to a target width. Returns the optimized image plus before/after byte sizes. Use this when an AI-generated or dropped-in asset (hero image, screenshot, illustration) is too large to ship.
| Name | Required | Description | Default |
|---|---|---|---|
| width | No | Resize to this width in px, preserving aspect ratio. Omit to keep original size. | |
| format | No | Output format. webp = best browser support; avif = smallest; jpeg = universal. | webp |
| quality | No | Encode quality 1-100 (80 is a good default). | |
| image_url | Yes | Public URL of the source image (PNG/JPEG/WebP/AVIF/GIF). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation 'readOnlyHint=true' is consistent with fetching and re-encoding without modifying the source. 'openWorldHint=true' aligns with fetching from a public URL. The description adds value beyond annotations by specifying the return of before/after sizes and the network access, providing helpful behavioral 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 extremely concise, using two sentences to convey purpose, output, and usage guidance. Every sentence adds value without 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?
Given the absence of an output schema, the description adequately explains the return value ('optimized image plus before/after byte sizes'). It covers the core functionality well, though it could briefly specify the return format (e.g., if it includes a URL or base64 data).
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 the baseline is 3. The description adds minimal extra meaning—only mentioning 'public URL' for 'image_url' and 'resizing to target width' for 'width'. The 'format' and 'quality' parameters are not elaborated beyond the schema, so no additional value is provided.
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 ('fetch', 're-encode', 'resize'), the resource ('image from a public URL'), and the output ('optimized image plus before/after byte sizes'). It effectively distinguishes the tool from siblings like 'image_format_savings' by focusing on optimization rather than comparison.
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 explicit usage context: 'Use this when an AI-generated or dropped-in asset... is too large to ship.' However, it does not mention when not to use it or reference alternatives, such as 'image_format_savings' for format selection without re-encoding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Encode text or a URL as a QR code and return a crisp, dependency-free SVG you can paste straight into a page, deck or doc.
| Name | Required | Description | Default |
|---|---|---|---|
| ecc | No | Error-correction level: L=7%, M=15%, Q=25%, H=30% recoverable. | M |
| size | No | SVG pixel size. | |
| text | Yes | Text or URL to encode. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, so agent already knows it's safe. Description adds that output is 'crisp, dependency-free SVG', clarifying the return format. No contradictions. Does not disclose additional traits like rate limits or auth needs, but given simplicity and annotations, it's sufficient.
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 that efficiently conveys purpose and output format. No wasted words. Front-loaded with key information.
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 what the tool does, the output format (SVG), and usage scenario. No output schema exists, but the description sufficiently describes the return. The 3 parameters are well-documented in schema. Minor gap: does not mention that text is required or max length, but that's in schema. Overall complete for a simple tool.
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 schema already explains all parameters (ecc, size, text). The tool description does not add any extra information about parameters beyond what's in the schema. Baseline 3 is appropriate.
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?
Description clearly states the tool's function: encoding text or URL into a QR code SVG. Uses specific verb 'Encode' and resource 'QR code SVG', and distinguishes from sibling tools which are unrelated (image_format_savings, optimize_image, storage_capacity).
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?
Provides context for use: 'paste straight into a page, deck or doc'. Does not explicitly exclude use cases or compare with siblings, but the sibling tools serve different purposes, so no exclusion is necessary. Lacks explicit 'when not to use'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How many photos or minutes of video actually fit in a given storage size, corrected for real OS/filesystem overhead. Backed by Cleanor Labs measured per-item sizes. Use for realistic sample copy, dashboards, or "how many photos fit in 128 GB" answers.
| Name | Required | Description | Default |
|---|---|---|---|
| content | No | What to count. | photos |
| storage_gb | Yes | Advertised storage size in GB (e.g. 64, 128, 256, 512). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, confirming it's a safe read. The description adds value by noting corrections for OS/filesystem overhead and that it is 'Backed by Cleanor Labs measured per-item sizes,' which provides transparency beyond annotations. No contradictions.
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?
Three sentences, front-loaded with the core purpose. Every sentence adds value: purpose, data source, and use cases. 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?
Given the tool's simplicity (2 parameters, no output schema) and three siblings, the description covers everything: what it does, how it works, and when to use it. No gaps.
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% with both parameters described. The description adds meaning by linking 'storage_gb' to 'advertised storage size' and 'content' to 'photos or minutes of video,' reinforcing the enum values. No additional schema is needed.
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: counting photos or video minutes that fit in a given storage size, with real OS/filesystem overhead. It uses specific verbs and resources (e.g., 'How many photos or minutes of video actually fit') and distinguishes from siblings like 'image_format_savings' and 'optimize_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 explicit use cases: 'Use for realistic sample copy, dashboards, or "how many photos fit in 128 GB" answers.' It does not explicitly state when not to use or mention alternatives, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: image format comparison, image optimization, QR code generation, and storage capacity estimation. There is no overlap or ambiguity.
All names use snake_case and are descriptive, but they mix verb starts (optimize_image, qr_code) with noun starts (image_format_savings, storage_capacity). While not perfectly consistent, the pattern is clear and predictable.
With 4 tools, the server is well-scoped for its purpose of providing image and storage utilities. Each tool earns its place without unnecessary bloat.
The tool set covers core image and storage needs, including format justification, optimization, QR generation, and capacity estimation. A minor gap like video format savings is absent, but the set feels complete for its stated domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate QR codes and create, edit and track dynamic (editable) QR codes with scan analytics, over a hosted MCP server plus a free REST API. Free, no watermark, no expiry. Every tool takes a free API key from https://openqr.uk/api.
Convert images to PNG, JPEG, WebP, or AVIF through one public remote MCP tool.
Generate QR codes for URLs, PIX, Wi-Fi, vCards, WhatsApp and more. For AI agents.
Hosts AI-generated web content (HTML, images, SVG, JSON) at a public URL, with custom domains.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cleanor-app/cleanor-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
