Editmamei

Overview Schema Source Related Servers Discussions Admin

ps_get_histogram

Read-onlyIdempotent

Read image histograms to detect clipped shadows/highlights, verify exposure shifts, check color neutrality, and confirm edits took effect.

Instructions

Whole-image (or per-channel) histogram — the quantitative answer to questions get_preview can't reliably answer by eye. Returns 256 bin counts plus mean / stdev / median. Cheap (~50ms), read-only. Reach for this when: (a) clipping detection — bins 0 and 255 carry the count of crushed shadows / blown highlights; you can't see clipping reliably in a downsampled JPEG preview; (b) exposure verification after a levels/curves/exposure adjustment — confirm the histogram actually shifted; (c) "is this image neutral-gray?" — compare R / G / B channel means; (d) confirming a destructive op did anything (two identical histograms = no-op regardless of the tool's success message). Composite reads the visible flattened image (any color mode). Per-channel reads require the document have that channel.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`channel`	No	Which channel to read. "composite" (default) is the visible flattened image; if the active layer is an adjustment/fill/shape layer the tool transparently switches to a pixel layer to read it. "red"/"green"/"blue" require an RGB doc; "gray" a grayscale doc. "luminosity" dispatches per doc mode — Lab uses the Lightness channel (exact), Grayscale uses Gray (exact), and RGB reads the per-pixel luminance Photoshop reports, weighted 0.30/0.59/0.11, so its shape and any clipping or percentile read taken from it are sound. Note that weighting is not Rec.709, so a luminosity mean will not match one computed as 0.2126/0.7152/0.0722. A channel value naming a marginal mixture means the document histogram was unavailable and the read fell back to combining the channel histograms: that mean is still sound, its shape is not. The result's `channel` field annotates which path landed when a fallback was used.	composite

Output Schema

TableJSON Schema

Name	Required	Description	Default
`bins`	No
`mean`	No
`stdev`	No
`median`	No
`channel`	No
`context`	No
`bin_count`	No
`total_pixels`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.4.0Sep 8, 2026

changedInput schema / properties / channel / description

Previous value: -"Which channel to read. \"composite\" (default) is the visible flattened image; if the active layer is an adjustment/fill/shape layer the tool transparently switches to a pixel layer to read it. \"red\"/\"green\"/\"blue\" require an RGB doc; \"gray\" a grayscale doc. \"luminosity\" dispatches per doc mode — Lab uses the Lightness channel (exact), Grayscale uses Gray (exact), RGB synthesizes a Rec.709 weighted approximation from R+G+B (mean is exact; stdev/median are approximations). The result's `channel` field annotates which path landed when a fallback was used."New value: +"Which channel to read. \"composite\" (default) is the visible flattened image; if the active layer is an adjustment/fill/shape layer the tool transparently switches to a pixel layer to read it. \"red\"/\"green\"/\"blue\" require an RGB doc; \"gray\" a grayscale doc. \"luminosity\" dispatches per doc mode — Lab uses the Lightness channel (exact), Grayscale uses Gray (exact), and RGB reads the per-pixel luminance Photoshop reports, weighted 0.30/0.59/0.11, so its shape and any clipping or percentile read taken from it are sound. Note that weighting is not Rec.709, so a luminosity mean will not match one computed as 0.2126/0.7152/0.0722. A channel value naming a marginal mixture means the document histogram was unavailable and the read fell back to combining the channel histograms: that mean is still sound, its shape is not. The result's `channel` field annotates which path landed when a fallback was used."

First observedv1.0.2Aug 8, 2026

TDQS

A5/5.0

Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses latency, composite-vs-per-channel reading behavior, required document mode, transparent layer fallback behavior, and the exact luminosity weighting with its non-Rec.709 caveat. It also explains what a marginal fallback value means and how the result's channel field annotates it. No contradiction with annotations.

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 dense but well-structured and front-loaded: one-sentence purpose, cost/read-only note, bolded use-case list, then channel-specific edge cases. Every clause carries operational value for a tool with non-obvious fallback behavior, so the length is justified.

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?

With one optional parameter, full schema coverage, an output schema, and read-only/idempotent annotations, the description covers selection criteria, return values, channel constraints, fallback paths, and interpretation caveats. Nothing an agent needs to call or interpret the tool correctly is missing.

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

Parameters5/5

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

The schema already fully documents the channel enum at 100% coverage, and the description adds substantial meaning beyond the schema: how composite reads fall back to a pixel layer, when red/green/blue/gray are valid, the exact luminosity weighting formula, and the fallback semantics. This far exceeds the baseline expectation.

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 states a specific verb and resource ('get histogram') and defines it as the quantitative complement to get_preview, listing the concrete return values (256 bin counts plus mean/stdev/median). This clearly distinguishes it from sibling inspection/read tools like ps_get_preview and ps_inspect.

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?

The 'Reach for this when' section explicitly enumerates four concrete use cases: clipping detection, exposure verification, neutral-gray checking, and confirming a destructive op had an effect. It also contrasts directly with get_preview, saying it answers questions get_preview can't reliably answer by eye. This gives an agent explicit selection criteria.

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

Deploy Server