synth_survival

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

Annotations already provide readOnlyHint=true, which the description does not contradict. The description adds substantial behavioral context: it discloses the method's assumptions (SUTVA, no anticipation), pre-conditions, and specific failure modes (pre-treatment RMSPE, placebo inference). This goes beyond the annotation and informs the agent about limitations and when results might 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 long but well-structured with clear sections (Assumptions, Pre-conditions, Failure modes). It front-loads the purpose and then organizes constraints. While verbose, each section adds value for a complex estimator. The cut-off at the end suggests it might be even longer, but the visible portion is justified and not repetitive.

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 complexity of the tool, the description covers a lot: method, assumptions, pre-conditions, and failure modes. An output schema exists to document return values, so the description doesn't need to detail that. The only minor gap is that it doesn't explicitly tie parameters to usage steps (e.g., how to set treat_time), but this is compensated by schema descriptions. Overall, an agent has enough to invoke it correctly.

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% — every parameter already has a description in the input schema. The tool description does not add parameter-specific guidance beyond what the schema provides (e.g., it doesn't explain how to map 'pre-treatment window' to treat_time or how data_path interacts with survival). It mostly repeats context already available. Baseline 3 is appropriate given full schema coverage.

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 states a specific verb ('fits'), a resource (donor Kaplan-Meier curves), and a clear method (convex combination on complementary log-log scale to match pre-treatment survival, then reports post-treatment gap). It distinguishes itself from other synth tools by focusing on survival outcomes, which is explicit. The citation and technical detail leave no ambiguity about what the tool computes.

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 provides pre-conditions (panel data, pre-treatment window, outcome observed) and failure modes with suggested alternatives (sdid, augsynth). However, it never explicitly states 'use this when you have survival/time-to-event data' or contrasts it with sibling tools like synth or synthdid_estimate. The guidance is implied through the survival focus, but not made explicit enough to route an agent decisively.

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