sequential_sdid

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

The description goes well beyond the readOnlyHint annotation, disclosing assumptions (parallel trends, no anticipation, SUTVA, stable control outcome process), preconditions, and failure modes (weighted pre-trend divergence and suggested next steps). This gives an agent a realistic behavioral model of how the estimator behaves and when results may be unreliable.

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 yet efficient, front-loading the method's purpose and advantage before assumptions, preconditions, failure modes, alternatives, and sample-size guidance. Every sentence adds selection-relevant information with no filler or repetition of schema-visible fields.

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 staggered-adoption estimator, the description covers what the method does, when it is appropriate, what assumptions are required, how failures manifest, and which alternatives exist. With an output schema present and full parameter schema coverage, no critical selection or invocation context 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?

Schema description coverage is 100%, so the schema already documents all 14 parameters. The description does not materially enrich specific parameter meaning beyond framing the method, which meets the baseline but does not exceed it. No compensation was needed because the schema is complete.

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 names a specific estimand and setting ('Sequential Synthetic DID for staggered-adoption panels') and states the core mechanism: processing cohorts in adoption order using not-yet-treated donors. It also distinguishes the tool by naming what it avoids (TWFE negative weights, SDID overlap failures) and lists explicit alternatives, so an agent can tell it apart from siblings.

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?

Clear pre-conditions (panel with treated/control units, clear treatment date, pre-treatment periods) and explicit alternatives (sp.synth, sp.augsynth, sp.callaway_santanna, sp.gardner_did) are provided. It lacks an explicit 'use this when X instead of Y' rule, but the assumptions, failure modes, and alternative list give strong contextual guidance for selection.

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