Skip to main content
Glama
mxcoppell

pixinsight

by mxcoppell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

pixelmath_new_image

Create a new image from PixelMath expressions referencing other open views by id. Supports RGB or grayscale, reports truncation fractions, and copies astrometric solution.

Instructions

Run PixelMath to create a NEW image from expressions that reference other open views by id. Color "rgb" takes red/green/blue expressions; color "gray" takes a single expression. The new image is truncated to [0,1]; the reply gives, per channel, the fraction of samples that were below 0 or above 1 before truncation. When size_from has an astrometric solution it is copied onto the new image (same geometry), unless copy_astrometric_solution is false. View ids used inside expressions must be simple identifiers (rename_view renames a view). No pow() — use exp(exponent*ln(base)) or the ^ operator.

Input Schema

NameRequiredDescriptionDefault
redNoRed channel expression (color "rgb")
blueNoBlue channel expression (color "rgb")
colorYes
greenNoGreen channel expression (color "rgb")
symbolsNoPixelMath symbols; constants only, e.g. "k=0.3". Symbols cannot hold images: write image expressions inline.
output_idYesId for the new image
size_fromYesA view whose width and height the new image copies
expressionNoSingle expression for color "gray"
copy_astrometric_solutionNoCopy size_from's astrometric solution onto the new image when it has one

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.4.1
    • addedInput schema / properties / copy_astrometric_solution
      Added value: +{
+  "default": true,
+  "description": "Copy size_from's astrometric solution onto the new image when it has one",
+  "type": "boolean"
+}
  2. First observedv2.1.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: output is truncated to [0,1], the reply reports per-channel fraction of pre-truncation out-of-range samples, the astrometric solution is copied only when size_from has one (and only unless copy_astrometric_solution is false), view ids must be simple identifiers, and pow() is unavailable. These are exactly the behavioral facts an agent cannot infer from schema or 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?

Information-dense and front-loaded, with the tool's core action first and constraints after. It is a single long paragraph of interrelated clauses rather than a run-on, but the lack of any structural break makes it heavier to scan than it needs to be.

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 9-parameter mutation tool with no output schema, the description supplies the return information (per-channel clipping fractions) and the key behavioral caveats, so an agent can call it correctly. It does not say what happens on failure (e.g., bad expression or unknown size_from) or whether the new image is opened/shown.

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 89%, so the baseline is 3, and the description adds real meaning on top: which parameters pair with which color mode, the semantics of size_from's astrometric propagation, and that symbols may hold constants only. It does not explain expression syntax operators beyond the pow() caveat or the exact meaning of each channel expression.

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 and resource ('Run PixelMath to create a NEW image from expressions that reference other open views by id'), which separates it from run_pixelmath, run_pjsr, and the measure_* siblings at a glance. The 'NEW image' framing tells an agent this constructs a view rather than modifying one in place.

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?

The description covers in-tool conditions (color 'rgb' takes red/green/blue, color 'gray' takes a single expression) and constraints on expression syntax, but never says when to choose this tool over the sibling run_pixelmath or run_pjsr. Usage is implied by the expressions-and-new-image framing rather than stated.

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