Retrieve detailed instructions for any Previs Director pipeline phase (1–8), including the gate criteria required before advancing to the next phase.
Get detailed instructions for a specific phase (1–8) of the Previs Director pipeline, including the gate criteria that must be met before advancing.
| Name | Required | Description | Default |
|---|---|---|---|
| phase_number | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.5.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the payload's contents (instructions plus gate criteria), implying a read-only lookup, but does not state side effects, error behavior for out-of-range phases, or whether it is safe/idempotent beyond the 'Get' verb.
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 compact sentences, front-loaded with the verb and resource, with no filler. The trailing 'including the gate criteria...' clause earns its place by describing the return payload, though it slightly blurs the boundary with get_gate_criteria.
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?
An output schema exists, so return-value detail needn't be spelled out, and the description covers the valid input domain and the main content returned. The remaining gap is the lack of any relation to the sibling gate/validation tools.
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 0% and the single parameter has no schema description, so the description is the only source of meaning. It does compensate meaningfully by declaring the valid domain as phases 1–8, which the schema would otherwise leave as an unconstrained integer; it omits what happens outside that range.
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?
States a specific verb ('Get') and resource ('detailed instructions for a specific phase'), plus the scope (phases 1–8 of the Previs Director pipeline). It is clearly distinguishable from validate_gate, though it does not explicitly distinguish itself from the sibling get_gate_criteria, which its mention of 'gate criteria' overlaps with.
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?
Usage is implied by the phrasing 'a specific phase (1–8) of the Previs Director pipeline', which tells the agent the context in which to reach for it. But there is no explicit when/when-not guidance and no routing versus the nearby get_gate_criteria or validate_gate siblings, which look closely related.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.