Skip to main content
Glama
mxcoppell

pixinsight

by mxcoppell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

run_sxt

Separates stars from an image view using StarXTerminator, replacing the view with a starless result and generating a separate stars view. Set is_linear based on whether data is linear or non-linear.

Instructions

Run StarXTerminator to separate stars from a view, replacing it in place with the starless result and producing a separate stars view. is_linear selects the unscreen mode: off for linear (pre-stretch) data, on for non-linear (stretched) data.

Input Schema

NameRequiredDescriptionDefault
overlapNoTile overlap (default 0.5). The former default 0.10 left a faint rectangular tile grid (cells of about 470 px) in linear starless images; 0.5 did not.
view_idYesView ID to extract stars from (modified in place to become starless)
is_linearYesWhether the image is linear (pre-stretch)
ml_versionNoNeural network model version (the process's ml_version parameter). Omitted, the process keeps its own setting.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.5.0
    • addedInput schema / properties / ml_version
      Added value: +{
+  "description": "Neural network model version (the process's ml_version parameter). Omitted, the process keeps its own setting.",
+  "type": "number"
+}
  2. Changed1 schema field changedv2.4.1
    • changedInput schema / properties / overlap / description
      Previous value: -"Star overlap parameter (default 0.10)"New value: +"Tile overlap (default 0.5). The former default 0.10 left a faint rectangular tile grid (cells of about 470 px) in linear starless images; 0.5 did not."
  3. First observedv2.1.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does disclose the critical behavior: the input view is modified in place and destroyed/replaced, and a new stars view is produced. It omits anything about runtime cost (this is an ML process), permissions, or whether the operation is reversible, so it is not fully transparent but is well above average for a mutation tool.

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?

Two tight sentences, front-loaded with the operation and its side effects, followed immediately by the one parameter whose semantics need explanation. 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 mutation tool with no annotations and no output schema, the description covers the operation, its destructive in-place effect, the created stars view, and the key parameter's semantics. Remaining gaps (runtime, failure modes, overlap/ml_version behavior) are documented in the schema, so the definition is adequate but not exhaustive.

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 genuine meaning beyond the schema by explaining what is_linear actually controls — the unscreen mode mapping for linear vs non-linear data — which the schema's terse 'Whether the image is linear' does not convey.

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 names a specific verb (run StarXTerminator) and resource (a view's stars), and states the exact outcome: in-place starless replacement plus a separate stars view. That scope distinguishes it from sibling tools like run_nxt, run_bxt, and run_pjsr without needing to open any schema.

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?

It gives the condition that drives the required is_linear flag (off for pre-stretch data, on for stretched data), which is real usage context. However, it never says when to choose this tool over its star-processing siblings, nor any prerequisites or ordering relative to stretching.

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