sensitivity_from_result

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

Annotations declare readOnlyHint=true, so the description isn't required to restate safety. It adds context about what each method produces (omitted-confounder bound, delta/R-max, OVB bounds), which is useful. However, it doesn't describe error behavior or dependencies on result validity, which are minor given the read-only annotation.

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?

Two sentences, front-loaded with purpose and method options, with zero waste. The structure is clear and efficient, placing the core action and method guidance upfront.

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?

With an output schema present and readOnlyHint annotation, the description covers the essential operational details: what it runs, how to select methods, and that it operates on cached results. It doesn't explicitly reconcile the optional data_path with 'cached result' framing, but that's a minor gap given schema documentation and the tool's read-only nature.

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 description enriches the 'method' parameter beyond the enum list by explaining what each option yields (e.g., 'evalue' for omitted-confounder-strength bound). Schema coverage is 88%, so most params are documented; this adds value on top of the schema. It doesn't elaborate on data_path or other params, but the schema covers those adequately.

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 the tool runs four specific sensitivity-analysis functions on a cached result, with a specific verb and resource. It distinguishes itself from siblings like sensitivity or evalue by the 'cached result' qualifier, making its purpose 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?

It gives explicit guidance on choosing the 'method' parameter (evalue, oster, cinelli_hazlett), but does not explicitly state when to use this tool versus alternatives like sensitivity or evalue that might operate on fresh data. The 'on a cached result' phrase implies usage but doesn't name alternatives or conditions.

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