morpheus-mcp

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

With no annotations provided, the description carries full disclosure burden. It successfully explains the validation logic, dual outcome paths (success with instructions vs. rejection with missing details), and auditability side effects ('Recorded in evidence for auditability'). Could be improved by mentioning idempotency or error states.

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?

Efficiently structured with the core action front-loaded, followed by behavioral details, then the Args block. Every sentence conveys necessary information; the example in skip_reason is illustrative without being verbose. No redundant or filler content.

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?

Given the workflow complexity (phase gates, validation, evidence collection) and lack of annotations, the description provides sufficient context for correct invocation. Since an output schema exists, the brief mention of return behavior ('Returns success...or rejection') is appropriate. Could explicitly note this is for single-task advancement.

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?

Compensates perfectly for 0% schema description coverage by documenting all 4 parameters in the Args section. Provides critical enum values for 'phase' (CHECK, CODE, TEST, GRADE, COMMIT, ADVANCE), clarifies the JSON string format for 'evidence', and explains the bypass logic for 'skip_reason' with usage context.

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 opens with a specific action ('Advance a task'), resource ('phase gate'), and mechanism ('with evidence'). The singular 'task' implicitly distinguishes it from sibling 'morpheus_advance_batch', while 'phase gate' differentiates it from tools like morpheus_close or morpheus_status.

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?

Provides explicit guidance on when to use the skip_reason parameter ('Use for intentional skips') with a concrete example ('greenfield — no diff for Seraph'). Explains the validation prerequisite (evidence must satisfy gate requirements). Lacks explicit comparison to the batch variant or when to prefer morpheus_gate_summary.

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