design_research_check

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

No annotations are provided, so the description carries the full burden. It usefully discloses the concrete thresholds being checked, which is real behavioral context. However, it does not say whether the tool is read-only, what happens on failure (throw vs. boolean), or whether it triggers downstream actions, leaving mutation/side-effect behavior unspecified.

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?

A single front-loaded sentence that packs the acceptance criteria without filler. The nested parenthetical is dense but each clause is load-bearing, so little is wasted.

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 validation gate with an output schema, the criteria are adequately specified so the agent knows what 'pass' means. Gaps remain: the lone parameter is undocumented and there is no guidance on when in the pipeline to call it or what the failure output signifies.

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?

The single required parameter app_dir has 0% schema description coverage, so the description must compensate, and it never references the parameter at all. The parameter's role is only inferable from the tool's domain context, not from the description text.

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 gate/check and enumerates exactly what it validates: ≥6 reference apps with icon + screenshots on disk, plus a valid brief with specific citation and palette/type conditions. An agent can tell this is a design-research validation step, distinguishing it from collect/brief_template siblings. It stops short of an explicit verb like 'validate', relying on 'gate' to convey the action.

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?

There is no explicit statement of when to invoke this versus the sibling design_research_collect, design_research_brief_template, or other *_check tools. The 'gate' framing hints it runs as a pass/fail checkpoint, but no prerequisites or timing guidance are given.

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