Run opt-in advisory JEV checks on requirements, design, test cases, red evidence, security findings, or principles to catch gaps before commit.
Run an opt-in advisory JEV check
| Name | Required | Description | Default |
|---|---|---|---|
| cases | No | ||
| check | Yes | ||
| units | No | ||
| baseRef | No | ||
| evidence | No | ||
| findings | No | ||
| testName | No | ||
| taskNumber | No | ||
| featureName | No | Feature name under .spec/specs |
Changes observed during successful MCP inspections.
v5.5.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It does not reveal that behavior changes drastically per check value, that some checks require evidence/commands, whether results block workflow or are purely advisory in effect, or anything about returned content. One sentence of undefined jargon is all the agent gets.
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?
It is short, but this is under-specification rather than conciseness — a single fragment with no structure. Nothing is front-loaded because there is essentially nothing there to load.
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 tool with nine parameters, deep conditional schema branching, nested objects, no annotations, and no output schema, the description is completely inadequate. An agent would have to reverse-engineer the schema's if/then blocks and guess what a successful check returns.
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?
Nine parameters with schema description coverage of 11% (only featureName documented). The description adds zero meaning: the conditional allOf requirements keyed on check (e.g. red needs taskNumber/testName/evidence, security needs findings, principles needs units) and the purpose of cases, baseRef, and units are entirely unexplained.
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 verb ("Run") and an object ("JEV check"), but "JEV" is undefined jargon that appears nowhere in the schema, and the seven check kinds (requirements, design, testcases, red, security, principles, commit) are never mentioned. An agent cannot tell from this what the tool actually validates or how it differs from siblings like sdd-validate-design or sdd-quality-check.
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?
"Opt-in advisory" is the only usage signal and it is not actionable: it never says when to run a check, which check to pick, or what alternatives exist. Among 16 sibling sdd-* tools, no routing guidance is provided at all.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.