xtabond

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

Annotations only carry readOnlyHint=true and openWorldHint=false, which already signal a read operation. The description goes well beyond annotations by disclosing assumptions (no second-order serial correlation, valid internal instruments), failure modes (instrument proliferation, AR(2) test rejection), and remediation paths (collapse instruments, reduce lag depth, compare with fixed effects). It does not detail the exact return payload, but the output schema exists and the detail parameter covers payload depth.

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 but efficient: it front-loads the method identification, then packs assumptions, pre-conditions, failure modes, alternatives, and minimum N into a compact block. It is on the longer side, but every sentence earns its place for a specialized estimator with many diagnostics; a structured list format would be slightly cleaner, hence 4 rather than 5.

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 complex dynamic-panel GMM estimator with 23 parameters and rich output schema, the description covers what an agent needs to decide and invoke it: validation status, statistical assumptions, data pre-conditions, failure modes, sample-size guidance, and sibling alternatives. The detail parameter even tells the agent how to request minimal vs agent-level payloads for chaining calls, and as_handle/result_id are documented in the schema.

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 description coverage is 100%, so the baseline is 3 even with no additional parameter context. The description adds meaning for key parameters: it ties h to xtabond2 defaults, explains collapse as Roodman 2009 instrument collapsing, and contextualizes method, endogenous/predetermined instruments, iv_equation, ah_instrument, and detail payload sizes. It does not touch every parameter, but it adds genuine meaning for the specialized GMM knobs, so a 4 is warranted.

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 specific verb+resource: 'Arellano-Bond / Blundell-Bond GMM for dynamic panels (standalone)' and immediately gives validation, assumptions, pre-conditions, failure modes, and alternatives. It clearly distinguishes itself from xtdpdsys, sp.panel, and sp.feols, so an agent can tell it apart from siblings without opening the schema.

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 names explicit when-to-use conditions: panel data with unit, time, outcome, lagged dependent variable structure; moderate time periods relative to units; minimum N of 100. It also names alternatives (sp.panel, sp.feols) and failure-mode remedies, giving clear context for when to choose this tool vs others.

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