panel_qtet

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

The description goes far beyond the annotations (readOnlyHint: true) by disclosing assumptions, failure modes, and validation parity. It explains that copula stability is untestable at t but checked on the untreated group via model_info['copula_check'], and that mass points distort the rank map while the ATT remains unaffected. It also states exact parity with R qte::panel.qtet (6.8e-12). These are behavioral traits that an agent needs to anticipate results and diagnose issues.

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 dense and information-packed, with a clear structure: purpose, assumptions, pre-conditions, and failure modes. It is front-loaded with the core purpose. While it is somewhat long, every sentence adds value and the organization is logical. It is not excessively verbose given 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 complexity (18 parameters, 8 required) and the presence of an output schema, the description covers essential context: the statistical assumptions, data pre-conditions, failure modes with guidance on alternatives, and validation evidence. It mentions model_info checks that the agent will need to interpret results. The description is comprehensive enough for an agent to call the tool correctly and interpret the output, especially with the output schema available.

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?

Schema coverage is 100%, so the baseline is 3. The description adds context for the time-related parameters (t, tmin1, tmin2) by explaining that the third period identifies the copula, and it clarifies the role of continuous outcome vs. mass points. This enriches the meaning beyond the schema's simple field names, though it doesn't enumerate every parameter. It earns a 4 for adding non-redundant context.

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 states this tool computes a Callaway & Li (2019) quantile treatment effect on the treated for panel data, using distributional DiD and a copula-stability assumption. It specifies the exact data requirement (balanced three-period panel) and the method's goal (recover counterfactual distribution of untreated outcomes). This is a specific, non-tautological statement that distinguishes it from related tools like qte or did by emphasizing the three-period structure.

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 gives explicit pre-conditions: balanced three-period panel, binary treatment read at period t, and continuous outcome. It also provides a when-not: for discrete outcomes with mass points, it recommends using sp.cic bounds. This effectively tells an agent when to select this tool over alternatives, which is exactly what usage guidelines should do.

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