wopee-mcp

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

No annotations provided, so description carries full burden. It discloses non-idempotency ('each call creates a new suite'), implicit dependency ('uses WOPEE_PROJECT_UUID from environment'), failure condition ('Fails if WOPEE_PROJECT_UUID is not configured'), and return structure ('suite object with UUID, name, type, and status').

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?

Four sentences covering purpose, workflow dependencies, alternative tools, and behavioral constraints. No redundant information; every clause provides actionable guidance. Well front-loaded with the core action.

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?

No output schema exists, so description compensates by detailing return fields (UUID, name, type, status). Given 0 parameters and no annotations, it adequately covers prerequisites, failure modes, and sibling relationships necessary for correct invocation.

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?

Input schema has 0 parameters (baseline 4). Description adds value by clarifying the implicit input mechanism ('uses WOPEE_PROJECT_UUID from environment') rather than leaving the agent to wonder how project context is determined.

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?

Description opens with specific verb ('Create') + resource ('empty analysis suite') + scope ('current project'). It explicitly distinguishes from sibling tool wopee_dispatch_analysis by contrasting manual suite building vs. auto-analysis workflows.

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 when-to-use ('first step when you want to manually build a test suite'), names specific dependent tools requiring the returned UUID (wopee_generate_artifact, etc.), and offers clear alternative ('use wopee_dispatch_analysis which creates and populates a suite in one step').

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