Skip to main content
Glama
mxcoppell

pixinsight

by mxcoppell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

run_pixelmath

Executes a PixelMath expression in place on a view, truncating results to [0,1] and reporting per-channel out-of-range statistics.

Instructions

Run an arbitrary PixelMath expression in place on a view. The result is truncated to [0,1]; the reply gives, per channel, the fraction of samples that were below 0 or above 1 before truncation, and their min and max. RULES: (1) NO pow() — use exp(exponent*ln(base)). (2) Channel access is $T[0] for R, $T[1] for G, $T[2] for B — NOT $T.R or $T.B. (3) For other images use viewId[0], viewId[1], viewId[2].

Input Schema

NameRequiredDescriptionDefault
symbolsNoSymbol declarations (comma-separated)
view_idYesView ID to process
expressionYesPixelMath expression using $T for current pixel value
single_expressionNoApply the same expression to all channels (default true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the in-place mutation, that output is truncated to [0,1], and that the reply reports per-channel out-of-range fractions plus min/max. It omits whether the underlying image data is permanently altered versus a preview copy.

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 purpose, then behavior, then a compact numbered rule list. Dense but every sentence serves a purpose with no filler.

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 4-parameter tool with no output schema and no annotations, the description covers mutation semantics, return contents, and expression syntax pitfalls. It lacks error/precondition details (e.g., whether the view must already be open) but is largely self-sufficient.

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%, so the baseline is 3, but the description adds real meaning beyond the schema by specifying channel access syntax ($T[0] vs $T.R) and viewId[0] referencing, which directly governs how the expression parameter must be written.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Run), resource (arbitrary PixelMath expression) and scope (in place on a view). The 'in place' qualifier implicitly distinguishes it from the sibling pixelmath_new_image, though that sibling is never named.

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 strongly implied by the operation itself, but there is no explicit when-to-use guidance and no routing to alternatives such as pixelmath_new_image for non-destructive work. The agent must infer the choice.

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