run_spcc

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It states prerequisites but never explains what the tool does to the image, whether it mutates pixel values, what it produces, or what happens when prerequisites are not met. For a calibration operation this is a significant transparency gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, each earning its place: the first expands the tool abbreviation, the second provides the critical prerequisites. There is no fluff, and the most important usage condition is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the key preconditions and the schema fully documents all 8 parameters, so an agent can assemble a valid call. However, with no output schema and no annotations, the description leaves out what SPCC actually changes, what the expected result is, and whether any side effects or long-running behavior should be anticipated.

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

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

Schema description coverage is 100%, so the baseline is 3 even without additional parameter information in the description. The description adds one useful clarifying note about linearity and astrometric requirements for view_id, but it mostly repeats what the schema already states and does not materially enrich the other parameters.

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

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

The description names a specific action and resource: 'Run SpectrophotometricColorCalibration (SPCC)', which clearly identifies the tool's purpose and expands the cryptic name. It does not explicitly contrast it with siblings like run_spfc, but the unique process name makes the distinction clear enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete conditions for use: the image must have an astrometric solution and be linear (not stretched). It also points to run_plate_solve as the way to satisfy the astrometric prerequisite. It does not, however, describe when SPCC would be inappropriate relative to other calibration tools.

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