Tanod MCP server

imagepeek: convert an image to another format

image_convert

Idempotent

Convert images between PNG, JPEG, WebP, GIF, TIFF, BMP, ICO, and AVIF formats, with quality, transparency, and optimization settings.

Instructions

imagepeek: Convert an image to PNG, JPEG, WebP, GIF, TIFF, BMP, ICO or AVIF. To shrink the file use image_compress. Returns the image converted to png, jpeg, webp, gif, tiff, bmp, ico (16-256 px icon sizes) or avif, with quality, progressive JPEG, optimized PNG or lossless WebP; transparency is flattened onto background (default white) for jpeg and bmp. Reads PNG, JPEG, WebP, GIF, TIFF, BMP, ICO and AVIF; other formats and images over 40 megapixels are refused (not charged). Output: base64 data_base64, without EXIF, GPS, XMP or IPTC; over 15 MB or 50 megapixels is a 413 (not charged). Images are not logged; a result is kept only with output "url" (24 h). Typically 0.5-2 s. Price: USD 0.002. Free: 3 imagepeek calls per IP per UTC day. Docs: https://tanod.dev/learn/image-convert-api.html

Input Schema

TableJSON Schema

Name	Required	Description	Default
`to`	Yes	png, jpeg, webp, gif, tiff, bmp, ico or avif.
`url`	No	Public http(s) URL of the image (at most 10 MB; private, internal and IP-literal hosts are refused); or use image_base64.
`output`	No	base64 (default): the file comes back inline as base64. url: the file is stored for 24 hours and the reply carries a download link (url, expires_at, bytes, content_type, sha256) instead of the base64, which keeps the file out of your context window.	base64
`quality`	No	Encoder quality 1-100 for lossy formats (default: per format).
`lossless`	No	webp only.
`optimize`	No	png only.
`background`	No	Alpha is flattened onto this for jpeg/bmp (#ffffff).
`auto_orient`	No	Apply the EXIF orientation first (default true).
`progressive`	No	jpeg only.
`image_base64`	No	The image as standard or url-safe base64 (at most 10 MB decoded; a data:image/...;base64, prefix is fine); or use url.

Output Schema

TableJSON Schema

Name	Required	Description
`url`	No
`bytes`	No
`error`	No	Only on an error result: an object {code, message}, or the reason string of an x402 PaymentRequired object.
`input`	No
`notes`	No
`width`	No
`format`	No
`height`	No
`sha256`	No
`source`	No
`final_url`	No
`operation`	No
`expires_at`	No
`source_url`	No
`data_base64`	No
`content_type`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 15, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond annotations (readOnly/idempotent/destructive) by disclosing accepted input formats, a 40 MP refusal threshold, a 15 MB / 50 MP 413 cap, that refusals are not charged, that metadata (EXIF/GPS/XMP/IPTC) is stripped, privacy ('images are not logged'), the 24 h retention only for output=url, typical latency, price, and the free tier.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose and the sibling alternative, and every clause carries information. The middle 'Returns...' sentence is a long run-on stacking many facts, so it is dense rather than effortless to scan, but nothing is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-param conversion tool with an output schema, all an agent needs is present: inputs accepted, output modes and their retention/response shape, format-specific flags, limits with exemption-from-charge, cost, and docs link.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage the baseline is 3, but the description adds real semantics: quality and progressive apply to JPEG, optimize to PNG, lossless to WebP, transparency is flattened onto background (default white) for JPEG/BMP, and ICO supports 16-256 px icon sizes.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Convert an image to PNG, JPEG, WebP...') and is explicitly distinguished from the sibling image_compress. The agent can tell exactly what this does versus the other image tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names the alternative and the condition that selects it: 'To shrink the file use image_compress.' It also implicitly scopes itself to format conversion rather than resizing/cropping, which are separate nearby siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server