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 states the calculation and inputs, but it directly contradicts the input schema by saying 'Provide group1 and group2 arrays' when the schema declares zero properties. This is misleading about how the tool is invoked. It also does not disclose the output format or any constraints (e.g., equal-length arrays, numeric types).

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?

The description is a single, dense sentence that front-loads the main purpose. It could be tightened by removing the redundant 'Cohens D:' prefix, but overall it earns its place with the formula explanation and input names.

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 no annotations, no output schema, and an empty input schema, the description needed to provide enough information to invoke it correctly. It explains the statistic and names inputs, but the mismatch between the described inputs and the actual schema leaves the agent without a viable way to send group1 and group2. This is a critical completeness gap.

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 schema has 0 parameters, so the description's naming of 'group1 and group2 arrays' is the only parameter information available and adds meaning beyond an empty schema. However, the description mentions parameters that are not declared in the schema, creating a contradiction that undermines an agent's ability to confidently construct a valid invocation.

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 clearly identifies the tool as computing Cohen's d effect size between two groups, with a specific formula definition ('measures how far two means differ in standard deviations'). This distinguishes it from generic siblings like x402-effect-size and related statistics tools. The verb 'Calculate' and resource 'Cohen's d' are unambiguous.

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?

The usage context is implied: use when you have two groups of data and need the effect size. However, it does not explicitly state when NOT to use this tool or mention alternatives like x402-effect-size or t-statistic. It gives input instructions but no selection guidance relative to the many similar statistical siblings.

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