atx-mcp

Overview Schema Source Related Servers Discussions Admin

inspect_image

Read-onlyIdempotent

Inspect an image revision for dimensions, MIME type, size, alpha/ICC flags, EXIF orientation/GPS, luma stats, sharpness, and perceptual hash for blur or duplicate checks.

Instructions

Inspect a revision: dimensions, MIME type, byte size, alpha/ICC presence, EXIF orientation and summary, whether GPS (PII) metadata is present, luma statistics, a sharpness score (variance of the Laplacian - relative, so compare it against a known-good capture rather than an absolute; for documents below ~30 usually means motion blur or defocus) and a perceptual_hash (dHash, 16 hex digits) for telling "is this the same picture?" without comparing pixels. Set include_exif=true to also get every EXIF field as {ifd, tag, value} entries; it is off by default because the full dump can carry GPS coordinates and names.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`revision_id`	Yes	対象 revision ID("rev_...")。
`include_exif`	No	EXIF 全フィールドを `info.exif` に載せるか。既定 false。既定で落としているのはプライバシーのため: 全量には GPS 座標や個人名が入りうるので、明示的に要求されたときだけ返す (`exif_summary` と `has_gps` は従来どおり常に載る)。

Output Schema

TableJSON Schema

Name	Required	Description	Default
`info`	Yes
`path`	Yes
`revision_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.6.4Sep 29, 2026

addedInput schema / properties / include_exif

Added value: +{
+  "default": false,
+  "description": "EXIF 全フィールドを `info.exif` に載せるか。既定 false。\n\n既定で落としているのはプライバシーのため: 全量には GPS 座標や\n個人名が入りうるので、明示的に要求されたときだけ返す\n(`exif_summary` と `has_gps` は従来どおり常に載る)。",
+  "type": "boolean"
+}

addedOutput schema / $defs / ExifEntry

Added value: +{
+  "description": "One EXIF field, rendered as text.",
+  "properties": {
+    "ifd": {
+      "description": "Which IFD the field came from: primary, exif, gps, interop or thumbnail.",
+      "type": "string"
+    },
+    "tag": {
+      "description": "Tag name, or `Tag(0x____)` when the tag is not in the standard set.",
+      "type": "string"
+    },
+    "value": {
+      "description": "Formatted value including its unit. Long values are cut to 256 characters\nfollowed by `...`; maker notes and binary blobs over 1 KiB read `<N bytes>`.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "ifd",
+    "tag",
+    "value"
+  ],
+  "type": "object"
+}

addedOutput schema / $defs / ImageInfo / properties / exif

Added value: +{
+  "description": "Every EXIF field found in the input, one entry per field. Present only when\nthe caller explicitly asks for it, because the full dump can include GPS\ncoordinates and other personal data.",
+  "items": {
+    "$ref": "#/$defs/ExifEntry"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}

addedOutput schema / $defs / ImageInfo / properties / perceptual_hash

Added value: +{
+  "description": "Perceptual hash (dHash) as 16 lowercase hex digits, or null when the pixels\ncould not be decoded. Compare two hashes bit by bit: a Hamming distance of\n5 or less usually means the same picture re-encoded or resized.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / $defs / ImageInfo / properties / stats / description

Previous value: -"輝度ヒストグラム統計(黒点 / 白点 / 中央値 / チャンネル平均)。\n\n**決定論的なサブサンプル**上で計算する(`crate::stats` 参照)。\n262144 画素(512x512 相当)以下の画像は全画素を使うため厳密値、\nそれより大きい画像はグリッド間引き(x, y とも k 刻み)による近似値。\nメタデータは読めたが画素デコードに失敗した場合は `None`(inspect 自体は成功させる)。"New value: +"輝度ヒストグラム統計(黒点 / 白点 / 中央値 / チャンネル平均)。\n\nヒストグラムとチャンネル平均は**決定論的なグリッド間引き**の上で計算する\n(`crate::stats` 参照。262144 画素以下は全画素なので厳密値)。`sharpness` だけは\n間引かず全画素を輝度化し、長辺 1024 へ縮小してから測る(隣接差分が要るため)。\nメタデータは読めたが画素デコードに失敗した場合は `None`(inspect 自体は成功させる)。"

addedOutput schema / $defs / ImageStats / properties / sharpness

Added value: +{
+  "description": "Variance of the 3x3 Laplacian response over the BT.709 luma, downscaled to a\nlong edge of at most 1024 px (higher = crisper edges; rounded to 1 decimal).\nScene-dependent, so treat it as a relative measure: for documents, below ~30\nusually means motion blur or defocus; compare against a known-good capture\nrather than an absolute.",
+  "format": "double",
+  "type": "number"
+}

changedOutput schema / $defs / ImageStats / required

Previous value: -[
-  "luma_p0_2",
-  "luma_p1",
-  "luma_p50",
-  "luma_p99",
-  "luma_p99_8",
-  "mean_r",
-  "mean_g",
-  "mean_b"
-]New value: +[
+  "luma_p0_2",
+  "luma_p1",
+  "luma_p50",
+  "luma_p99",
+  "luma_p99_8",
+  "mean_r",
+  "mean_g",
+  "mean_b",
+  "sharpness"
+]

First observedv0.5.2Sep 14, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's added value is the interpretation detail: sharpness is a relative Laplacian variance (below ~30 usually means motion blur or defocus), perceptual_hash is a dHash for identity checks, and include_exif is off by default because full EXIF can carry GPS coordinates and names. That privacy and interpretation context goes beyond the annotations.

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?

Two dense sentences that front-load the enumeration and end with the opt-in flag's rationale. Every clause carries information, though the output enumeration is long enough that it slightly blurs the primary purpose.

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, yet the description still adds interpretive value the schema cannot (sharpness scale, dHash semantics) and explains the include_exif default. For a read-only, non-destructive, idempotent inspection tool, an agent has everything needed to invoke and interpret it.

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 description coverage is 100%, so the schema already documents revision_id and include_exif including the privacy rationale. The description restates the include_exif default and its reason without adding syntax or format detail beyond the structured field, so the 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?

Names a concrete verb (Inspect) and resource (revision/image) and enumerates the exact attributes produced: dimensions, MIME type, byte size, alpha/ICC, EXIF orientation, GPS presence, luma stats, sharpness, perceptual_hash. This clearly separates it from siblings like compare_revisions, detect_text_blocks, and render_preview.

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?

Usage is implied by the listed outputs (image QA, blur detection, duplicate detection via perceptual_hash), and the sharpness note says to compare against a known-good capture. However, there is no explicit when-to-use/when-not guidance nor any reference to sibling tools such as compare_revisions for revision diffing.

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

Deploy Server