Skip to main content
Glama
gridhra

atx-mcp

by gridhra
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

render_preview

Idempotent

Generate a small JPEG preview of a recipe, preset, or current revision to check composition, guides, or mask coverage before applying transformations.

Instructions

Render a recipe as a small JPEG preview (long edge <= 768 by default) and return it inline plus a file path, so the composition can be checked before committing to apply_transform. Takes either recipe or preset, exactly like apply_transform - or NEITHER, which previews the revision as it is (use this with overlay="grid" to read crop coordinates off an image before writing a recipe). Optional long_edge (256..=1568) sets the preview size: raise it to 1568 when the point of the preview is to READ text in the image; 768 is too small for that. Optional overlay ("grid" | "thirds" | "horizon") draws semi-transparent composition guide lines on the returned preview only (never on the apply_transform output). overlay="mask" instead visualises a mask: pass mask_revision_id (required for this overlay and rejected for the others) and the preview is tinted red where the mask weight exceeds 0.5 and dimmed elsewhere, so the coverage can be eyeballed. Note: if the recipe's encode format is png, webp, or avif, any ICC color profile on the source is dropped (embedding is only supported for jpeg output); this is reported as a warning, not an error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
presetNoビルトインプリセット名。`recipe` とは排他。
recipeNo変換レシピ。`{"operations": [...]}`。`preset` とはどちらか一方のみ指定する。
overlayNo構図確認用のガイド線。`"grid"`(1/8 刻みの格子)| `"thirds"`(三分割法)| `"horizon"`(1/12 刻みの水平線のみ、傾き目視用)| `"mask"`(マスクの被覆可視化。 `mask_revision_id` が必須)。省略時はオーバレイなし。
long_edgeNoプレビューの長辺(256..=1568)。省略時は 768。 文字を読む用途では 1568 まで上げる(DESIGN.md §9.12)。
revision_idYes入力 revision ID("rev_...")。
mask_revision_idNo`overlay: "mask"` で可視化するマスク画像 revision ID。 `overlay` が `"mask"` のときのみ指定でき、そのときは必須。

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
widthYes
heightYes
overlayNo適用した overlay。未指定なら null。
warningsYes
byte_sizeYes
mime_typeYes
recipe_hashYes
preview_pathYesプレビュー画像の絶対パス。
engine_versionYes
mask_revision_idNo`overlay: "mask"` で可視化したマスクの revision ID。それ以外では null。
source_revision_idYes
estimated_vision_tokensYesRough token cost of reading this preview inline: a rule of thumb for Anthropic vision models (pixels / 750, rounded up); other hosts differ. Use it to decide whether a larger `long_edge` (or reading a long document in bands) is worth it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.6.4
    • addedOutput schema / properties / estimated_vision_tokens
      Added value: +{
+  "description": "Rough token cost of reading this preview inline: a rule of thumb for Anthropic\nvision models (pixels / 750, rounded up); other hosts differ. Use it to decide\nwhether a larger `long_edge` (or reading a long document in bands) is worth it.",
+  "format": "uint32",
+  "minimum": 0,
+  "type": "integer"
+}
    • changedOutput schema / required
      Previous value: -[
-  "source_revision_id",
-  "recipe_hash",
-  "engine_version",
-  "preview_path",
-  "width",
-  "height",
-  "byte_size",
-  "mime_type",
-  "warnings"
-]New value: +[
+  "source_revision_id",
+  "recipe_hash",
+  "engine_version",
+  "preview_path",
+  "width",
+  "height",
+  "byte_size",
+  "mime_type",
+  "estimated_vision_tokens",
+  "warnings"
+]
  2. First observedv0.5.2

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only cover safety hints (readOnly=false, idempotent, non-destructive); the description adds genuinely non-derivable behavior: overlay lines appear only on the preview and never on apply_transform output, mask overlay tints pixels red above 0.5 weight, and ICC profiles are silently dropped for png/webp/avif with a warning. It stops short of saying the preview file is written to disk (implied by readOnlyHint=false) or describing rate/size limits.

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 the core purpose and output in the first sentence, then layers parameter guidance. Every sentence carries actionable information, though the dense multi-topic prose (overlay modes, ICC caveat, size rationale) makes it longer than the minimum.

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?

An output schema exists, so return-format detail is not required, and the description still names the inline image plus path. Combined with the parameter guidance and the ICC warning, nothing an agent needs to call it correctly or interpret the result is missing.

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?

Schema coverage is 100% (descriptions in Japanese), so the baseline is 3. The description nevertheless adds decision-relevant meaning beyond the schema: raise long_edge to 1568 specifically to read text because 768 is too small, and mask_revision_id is required for overlay="mask" and rejected otherwise. It does not restate enums redundantly, which is a plus.

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 (render) and resource (a recipe as a small JPEG preview), names the exact output (inline image plus file path), and explicitly frames its role relative to the sibling apply_transform. An agent can distinguish it from apply_transform without opening either schema.

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?

Explicitly says when to use it (to check composition before committing to apply_transform), how it relates to alternatives (takes recipe or preset exactly like apply_transform), and even covers the 'neither' case with a concrete use case (overlay="grid" to read crop coordinates). No inference required.

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

Deploy Server

Other Tools