Read Redshift Sequence Progress

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

With no annotations, the description provides key behavioral disclosure: the operation is non-invasive and reading state does not query or modify C4D. It also warns about the semantic meaning of an uncertain state, which is essential for safe automation. This exceeds a bare read-only statement.

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 sentences carry all necessary information with no fluff. The main action and scope are front-loaded, and the warning is placed where it will be noticed. Nothing is repeated from the schema.

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?

For a simple one-parameter status tool, the description covers return contents (state, frame, verified outputs, error), the non-modifying guarantee, and the retry caution. It omits behavior for invalid/missing job IDs, but this does not block correct invocation in the common case.

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 coverage is 0% and the description never explains the sole parameter, job_id. Although the name and UUID format hint at its role, the description does not state which session or job the ID refers to, leaving an agent to infer the mapping between 'this MCP session' and the parameter.

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 uses a specific verb ('read') and names a clear resource: the MCP session's sequence state, including current frame, verified completed outputs, and any error. This cleanly differentiates it from control-oriented siblings like rs_sequence_control.

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?

It says when to use the tool (to check session state without touching C4D) and adds an important caveat: an uncertain state may mean a timed-out render is still running and should not be auto-retried. It does not explicitly name alternative tools, but the read-vs-control distinction is implicit and sufficient.

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