Pictomancer.ai

optimize_for_vision

Resize an image for a vision model

Resize an image to the largest size a given vision model still benefits from, and report what it costs that model in tokens before and after. Every provider downscales oversized input before counting tokens, so this alone saves bytes and upload latency rather than tokens. Pass max_tokens to trade resolution for tokens: that lever is continuous on Claude, unavailable on OpenAI (cost follows the aspect ratio alone), and on Gemini reaches only a flat 258. An image already within budget is returned untouched and free (X-Pig-Billed: 0).

Responses:

200: Processed image binary (Success Response) Content-Type: application/json Content-Type: image/jpeg

Example Response:

"string"

Content-Type: image/png

Example Response:

"string"

Content-Type: image/webp

Example Response:

"string"

Input Schema

TableJSON Schema

Name	Required	Description
`q`	No	Quality (1-100). Maps to libvips Q parameter.
`format`	No	Output format: jpeg, png, webp, tiff, gif, or avif. If omitted, the original format is preserved.
`source`	Yes	Image source: a public URL (https://...) or a base64-encoded string (optionally as a data URI like data:image/png;base64,...).
`delivery`	No
`max_tokens`	No	Optional cap on what the image may cost the target model. Without it the image is resized to the model's own ceiling, which saves bytes and upload latency but no tokens, because every provider already downscales oversized input before counting. Set a budget to trade resolution for tokens. The response reports the cost actually achieved: on OpenAI it cannot be lowered by resizing at all, and on Gemini only down to a flat 258.
`target_model`	Yes	Vision model the image is being prepared for, e.g. claude-opus-5, gpt-4o, gemini-2.5-pro. Unknown ids are rejected rather than guessed: the wrong limits would silently resize to the wrong size.

TDQS

A4.2/5.0

Behavior5/5

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

With no annotations, the description carries full behavioral disclosure. It states that without max_tokens no tokens are saved, explains per-provider differences, and discloses that in-budget images are returned untouched and free (X-Pig-Billed: 0). It also documents the binary response shape, providing transparency beyond a simple resize action.

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

Conciseness3/5

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

The core prose is front-loaded and well-structured, with clear paragraphs for behavior and provider nuances. However, the Responses section is bloated with repetitive Content-Type examples and placeholder 'string' responses that add noise and reduce conciseness.

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

Completeness4/5

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

For a tool with no annotations and no true output schema, the description covers the optimization logic, provider-specific token tradeoffs, the free/in-budget case, and the binary response. It does not explicitly address delivery modes, but those are well documented in the input schema, so overall completeness is strong.

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

Parameters3/5

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

The schema already covers 83% of parameters with detailed descriptions, including max_tokens and target_model. The description reinforces max_tokens semantics but adds little that isn't already in the schema; q, format, source, and delivery rely on schema descriptions. Baseline 3 is appropriate.

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?

The description opens with a specific verb and resource: 'Resize an image to the largest size a given vision model still benefits from' and adds reporting of token cost before/after. This clearly differentiates it from the sibling resize/compress/convert tools by tying the action to vision-model token optimization.

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

Usage Guidelines4/5

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

It gives actionable usage guidance: 'Pass max_tokens to trade resolution for tokens' and explains provider-specific behavior (continuous on Claude, unavailable on OpenAI, flat 258 on Gemini). It also notes that without max_tokens only bytes/latency are saved, which helps decide when the tool is useful. It does not explicitly name sibling alternatives but the context is clear.

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

All Pictomancer.ai tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Most tools have clearly distinct purposes (analyze, compress, convert, crop, resize, pipeline, optimize_for_vision, optimize_generated_image). However, there is some overlap between compress_image and convert_image (both deal with quality settings and can change format), and between resize_image and crop_image (resize's fill mode with smart-crop overlaps crop's smart crop). The pipeline tool could theoretically subsume any of the single-operation tools, which introduces a slight ambiguity in when to use pipeline vs. individual tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (analyze_image, compress_image, convert_image, crop_image, get_format_info, image_pipeline, optimize_for_vision, optimize_generated_image, resize_image). The naming is predictable and self-documenting, with no mixing of camelCase or other conventions.

Tool Count5/5

With 9 tools, the server is well-scoped for an image processing domain. Each tool covers a core operation (analyze, compress, convert, crop, resize, pipeline, format info, and two optimization tools). The count feels appropriate—not too few to limit usefulness, not too many to be overwhelming.

Completeness5/5

The tool set provides comprehensive coverage for common image manipulation tasks: analysis, compression, format conversion, cropping, resizing, optimization for both general and AI-generated images, and a pipeline for chaining operations. Missing features like rotation, flipping, or color adjustments are minor but the core CRUD-like operations (read/analyze, write/convert, resize/crop) are well-represented, and the pipeline tool mitigates gaps by allowing combinations.

Resources

Need Help?