gate_test

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

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description substantially enriches the picture by stating the statistical assumptions (unconfoundedness, overlap, consistent nuisance estimation, cross-fitting), the pre-conditions, and the failure modes. It also gives practical guidance about typical minimum sample size (N=500). This goes far beyond what annotations provide and helps the agent understand the tool's operational constraints and behaviors.

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 moderately long but well-structured with labeled sections: assumptions, pre-conditions, failure modes, alternatives, typical minimum N. Each sentence contributes operational information. It could potentially be tightened (e.g., the assumptions list could be compressed), but it remains concise relative to the complexity of the tool.

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 tool's statistical complexity, the description covers all key contextual elements: purpose, assumptions, required inputs (in prose), failure modes, alternatives, and sample-size guidance. Since the output schema exists, the description does not need to explain return values. Nothing essential for an agent to invoke this tool correctly is missing.

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 input schema has 100% parameter description coverage, so each of the 10 parameters is already documented with meaningful detail (e.g., 'by' explains 'cate' option, 'detail' describes payload depths). The description itself adds no parameter-specific information beyond the schema. Per the rubric, the baseline is 3 when schema coverage is high, and the description does not need to compensate.

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 clear verb and resource: 'Test for significant heterogeneity across GATE (Group ATE) groups.' This specifies exactly what the tool does and differentiates it from the broad set of causal inference siblings by focusing on a test for heterogeneity in GATE groups. While it doesn't name a sibling in the purpose statement, the specificity of 'GATE groups' and the test-oriented intent make its role 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 description explicitly lists alternatives: 'Alternatives: sp.dml, sp.causal_forest, sp.tmle.' It also provides pre-conditions (covariates, treatment, outcome, enough data) and failure modes that imply when to switch to alternatives (e.g., unstable CATE estimates → use doubly-robust learner). However, it stops short of a precise 'use this when... use alternative when...' decision rule, leaving some inference to the agent.

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