Skip to main content
Glama

Pictomancer.ai

by ai.pictomancer.api

analyze_image

Analyze an image

Fetch an image from a URL or base64 and return its metadata: size in bytes, pixel dimensions, source format, and what it costs every supported vision model in tokens. Always free. Dimensions are omitted if the image header cannot be read. Also reports whether the input carries a C2PA (Content Credentials) manifest and in which container; the manifest is not validated.

Responses:

200: Successful Response (Success Response) Content-Type: application/json

Example Response:

{
  "size_bytes": 1,
  "c2pa_manifest": true
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceYesImage source: a public URL (https://...) or a base64-encoded string (optionally as a data URI like data:image/png;base64,...).

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral disclosure burden. It discloses that the operation is free, that dimensions are omitted if headers cannot be read, that C2PA manifests are reported but not validated, and shows a success response. It does not discuss failure modes or data handling, but the provided caveats are meaningful.

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

Conciseness5/5

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

The description is front-loaded with 'Analyze an image' and organized into a concise narrative followed by a response example. Every part earns its place: the output list, the free guarantee, the header caveat, and the C2PA note all add useful, non-redundant information.

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 single-parameter tool with no output schema, the description covers expected outputs, source requirements, caveats, and a partial JSON example. It is slightly incomplete in that the example does not illustrate all named response fields (e.g., dimensions, format, per-model costs), but it is still sufficient for basic invocation.

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?

Schema coverage is 100%: the source parameter's description already explains public URLs and base64 data URIs. The tool description mostly repeats this information, adding no new parameter constraints or format details, so the baseline score of 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 clearly states the tool's purpose: fetch an image and return its metadata (size, dimensions, format, per-model token costs, C2PA status). It distinguishes itself from transform-focused siblings like compress_image and resize_image, and the 'Always free' qualifier helps separate it from cost-related tools like estimate_cost.

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

Usage Guidelines3/5

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

It gives concrete input context by specifying public URL or base64 sources, and mentions the always-free nature. However, it does not explicitly state when to prefer this tool over siblings such as estimate_cost or get_format_info, nor does it mention exclusions or alternative tools.

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

All Pictomancer.ai toolsInspect
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