Zicron medical chronology

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces this with 'Read-only; no side effects.' The description adds valuable behavioral context beyond annotations, including scope limits (medical facts only, no standard-of-care/causation/damages opinions), 48-hour turnaround, and security practices. No contradiction with annotations.

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 a single, dense paragraph that front-loads the main purpose ('Returns Zicron's done-for-you medical chronology service') and then lists specific details in a structured, readable manner. It is not short, but every clause adds substantive value. It could be slightly more concise, but it is well-organized and free of fluff.

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 zero-parameter, read-only information tool with no output schema, the description is comprehensive. It covers deliverables, target audience, pricing, discounts, turnaround, scope limits, security, and how to start, plus explicit usage conditions. An agent has all necessary information to decide when to call it and what to expect, with no gaps.

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 tool has zero parameters, so the input schema is an empty object. There is nothing for the description to add about parameters. The baseline for zero-parameter tools is 4, and the description correctly avoids inventing parameters.

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 ('Returns') and a well-defined resource (Zicron's medical chronology service), enumerating exactly what is delivered (case summary, all-provider timeline with page citations). It clearly distinguishes itself from sibling tools like get_sample_chronology and quote_chronology by being the overview/offer tool. The purpose is unambiguous and actionable.

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 explicitly states when to use: 'Use this when a user asks what Zicron does, what a chronology from Zicron includes, or whether it fits their case.' This provides clear usage context. However, it does not mention when not to use it or point to specific alternatives among the sibling tools, which keeps it from a 5.

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

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

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds meaningful context by stating 'built from a fictional case (no real patient data)' and clarifies the return format (page, PDF link, sections), which goes beyond the annotations.

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 the primary purpose and contents, followed by usage guidance and safety. Every sentence adds value with no redundancy or filler.

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 zero-parameter, read-only sample tool with annotations covering safety, the description fully covers what it does, when to use it, and adds a privacy-relevant detail. No output schema exists, so not explaining return values beyond the listing is acceptable.

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 tool has zero parameters, so the description needs no parameter detail. Baseline for zero-parameter tools is 4, and the description doesn't need to add anything here.

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 a specific verb and resource: 'Returns links to a sample Zicron medical chronology'. It also differentiates from siblings by noting it is a fictional sample to view before sending a case, which distinguishes it from quote/request tools.

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 an explicit context: 'Use this when a user wants to see what the deliverable looks like before sending a case.' It doesn't explicitly mention when not to use it or name alternative tools, but the context is clear enough for selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint; the description reinforces this with 'Read-only; no side effects' and adds useful context about the pilot's rule-based scoring and page-cited findings. It does not contradict annotations.

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 front-loaded with the core purpose and uses a colon to organize the return contents. It is slightly repetitive about the intended audience ('SSDI representation and intake firms' vs 'law firms or intake operations'), but each sentence contributes useful scope or behavior information.

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 read-only, zero-parameter info tool with no output schema, the description fully covers what the agent needs: the subject, the returned categories, the target audience, and an explicit non-audience. Nothing critical is missing for selecting and invoking this tool.

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 tool has zero parameters and an empty schema, so there is no parameter semantics to add. The description's lack of parameter detail is appropriate and does not create a gap.

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 and resource: 'Returns Zicron's 30-day SSDI intake-scoring pilot...' and enumerates the returned content (what it does, price, inclusions, limits, request method). It also narrows the audience to SSDI representation/intake firms, which distinguishes it from the general offer/sample/quote/request 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?

It explicitly says when to use it: 'Use this only for law firms or intake operations handling SSDI claims,' and gives a clear when-not: 'It is not for individual claimants...' However, it does not name an alternative tool for individual claimants, so it stops short of full alternative routing.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description builds on this by adding genuinely new behavioral context: the computation is deterministic, nothing is ordered, and the result is only an estimate pending written confirmation from Zicron. Since there is no output schema, the description of the return breakdown (base price, pages over included amount, first-case discount, total, turnaround) must be carried by the description, and it is. No contradiction with annotations.

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?

Three sentences, no filler. The primary action and return value are front-loaded in sentence one, the usage trigger sits in sentence two, and the estimate caveat closes with essential expectation-setting. Every sentence earns its place.

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 simple 2-parameter calculator with no output schema, the description covers everything an agent needs: what it computes, what it returns, when to invoke it, and the critical caveat that the price is an estimate pending written confirmation. The safety profile is covered by annotations, and the read-only/estimate framing fully prepares the agent to communicate the result correctly to a user.

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 fully documents both pages and first_case. The description's references to 'approximate page count' and 'first-case discount' reinforce but do not extend the schema content. Baseline 3 applies because the schema does the heavy lifting and the description adds no new parameter-level meaning.

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 and resource — 'Computes the price of a Zicron medical chronology from the approximate page count' — and enumerates the exact output components (base price, pages over included amount, first-case discount, total, turnaround). The explicit 'Use this when a user asks what a chronology for N pages would cost' differentiates it from siblings like request_chronology and get_offer without needing to open their schemas.

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 a clear, direct trigger condition: 'Use this when a user asks what a chronology for N pages would cost.' It also implies a non-ordering boundary ('nothing is ordered', 'Zicron confirms... before any work starts') that separates it from requesting work. However, it never names alternatives explicitly (e.g., pointing to request_chronology when the user wants to place an order), so it falls just short of the 5 bar.

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

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

The description discloses key behaviors beyond the annotations: no order or charge is created, a human replies within one business day, patient-related requests are rejected, dry_run sends nothing, and idempotent retries return the original request. This complements the idempotentHint and openWorldHint annotations without contradicting them.

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?

Although long, every sentence earns its place: the core outcome is front-loaded, followed by the no-patient-information rule, consent requirement, validation mode, and idempotency semantics. The structure is logical and dense without redundancy.

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 14-parameter mutating tool with no output schema, the description is complete: it explains what happens after the request, what is not sent, how to validate first, and how to avoid duplicates. An agent has enough context to invoke it correctly and safely.

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, but the description adds meaningful parameter context: confirmed_by_user must only be true after explicit user consent, dry_run validates without sending, and notes are limited to general case terms. This goes beyond the schema's property descriptions.

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 action and resource: it sends Zicron a request to prepare a medical chronology. It also sharply distinguishes this from an order by clarifying it is a 'contact request only: nothing is ordered or charged,' which separates it from sibling tools like quote_chronology.

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?

Usage guidance is explicit and actionable: call only after the user asks and agrees to email, set confirmed_by_user=true, use dry_run=true to validate without sending, and never include patient information. It also warns that patient-looking requests are rejected, giving clear when-to and when-not-to-call conditions.

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