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

No annotations are provided, so the description carries the burden of disclosing side effects. It presents a read-only style 'Return' behavior but does not disclose that setting clear=true clears the log after returning it; that only appears in the schema. This is a significant transparency gap, though not a contradiction.

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 front-loaded sentence with no filler. It directly states the action and the object, making it easy to scan and quick to parse.

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 one-parameter tool, the description plus the fully documented schema is mostly complete: the purpose is clear and the clear side effect is described in the schema. The main gap is the lack of any detail about the returned summary's shape, but 'summary' is adequate for a basic retrieval 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?

Schema description coverage is 100%: the sole parameter, clear, is fully documented in the schema with 'If true, clears the log after returning it.' The description adds no parameter semantics beyond what the schema already provides, so the baseline of 3 applies.

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 uses a specific verb ('Return') and a specific resource ('summary of all votes cast in the current session'). This clearly distinguishes the tool from siblings like covidence_log_vote or covidence_screen.

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 implies this tool is for retrieving a session vote summary, but it gives no explicit guidance about when to use it versus alternatives like covidence_log_vote, nor does it mention prerequisites such as being logged in. Usage context is inferable but not explicitly stated.

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?

With no annotations provided, the description carries the behavioral disclosure burden. It transparently states that the tool returns navigation instructions rather than performing the login itself, and that the user's password is never passed through the server. This is meaningful behavior beyond the schema, though it could further disclose session persistence or behavior on already-logged-in states.

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 with no filler. The primary action is front-loaded, and the security-relevant detail about the password is included concisely. 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 one-parameter tool with no output schema, the description provides enough context: what the tool does, what it returns, and a critical security boundary. An agent can invoke it correctly and understand the expected result.

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 email parameter is already documented. The description adds slight context by implying only the email is needed and that the password is handled externally, but it does not materially expand parameter meaning beyond the schema.

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 ('Start a Covidence session') and clearly differentiates this tool from the sibling screening/criteria/navigation tools. It also clarifies the tool's output is step-by-step login instructions, not an actual authenticated session, removing ambiguity about its role.

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 clearly implies this tool is the entry point for a Covidence session and should be used when login is needed. It does not explicitly name when-not-to-use it or mention alternatives, but the context is clear enough for an agent to select it ahead of the screening and voting siblings.

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 are absent, so the description carries the full burden of behavioral disclosure. It only says 'Record a vote' and 'Used to track progress,' but it does not disclose whether votes are appended, overwritten, whether duplicate votes are allowed, or what happens on error. This leaves an agent uncertain about repeated calls or response behavior.

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 short sentences, the first front-loads the action and the second gives purpose. There is no wasted wording or redundant restatement of the name.

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 two-parameter logging tool, the description covers what it does and when to use it. Since there is no output schema and no annotations, a bit more detail about duplicate handling or return value would make it fully complete, but the essential information for invocation is present.

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%, and both parameters already have descriptions. The tool description adds no parameter-specific meaning beyond 'vote' and 'session log,' so the baseline of 3 is appropriate.

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: 'Record a vote in the session log.' This clearly differentiates it from siblings like covidence_screen and covidence_get_session_log. The additional phrase 'after Claude has cast it in Chrome' disambiguates the intended workflow context.

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 condition for use: 'after Claude has cast it in Chrome.' This tells the agent when in the workflow the tool should be invoked. It does not explicitly mention alternatives or exclusions, but the context is specific enough to guide 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the key trait — the tool returns instructions rather than performing side effects — which is important because its action names (login, cast_vote) could imply direct execution. However, it says nothing about prerequisites (e.g., needing to be logged in first), whether instructions vary based on parameter combinations, or what form the output takes beyond 'plain-English.'

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 efficient sentences: the first states the core purpose, the second provides the consumer context and the action list. The action enumeration slightly duplicates the schema enum, but it is useful for quick scanning and earns its place. No filler or vague abstraction like 'navigate Covidence workflows.'

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 relatively simple instruction-retrieval tool, the description is reasonably complete: it identifies the output type (plain-English navigation instructions), the consumer (Claude driving Chrome), and the full action catalog. No output schema exists, so the description's mention of the return format is sufficient. Remaining gaps — which actions depend on which optional parameters — are adequately covered by the input schema itself.

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 75%, so the schema already documents decision, review_id, and batch_size with their per-action requirements. The description adds value primarily by enumerating valid actions in prose, which reinforces the action enum but adds little beyond it. It does not clarify relationships such as which actions require review_id versus which ignore it — the schema's brief 'Required for...' notes carry that weight.

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 ('Get plain-English navigation instructions for a specific Covidence action') and lists the full action set. The phrase 'Claude uses these instructions to drive Chrome tools' distinguishes it from sibling tools like covidence_login and covidence_log_vote, which appear to perform actions directly rather than provide navigation guidance.

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 implies the usage context ('Claude uses these instructions to drive Chrome tools') — an agent can infer this is a pre-step before driving the browser. However, it never explicitly contrasts with the sibling action tools or states when to call this instead of covidence_login or covidence_log_vote. No exclusions or alternatives are named, so the routing logic is left to inference.

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?

With no annotations, the description carries the burden of behavioral disclosure. It does clarify that the tool returns a prompt that Claude executes via Chrome tools rather than performing actions directly. Still, it does not disclose prerequisites such as login state, whether the prompt will cause real votes to be cast, or how failures are handled.

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 concise sentences front-load the purpose ('Run a screening session'), then efficiently describe the return value, scope, and execution model. There is no filler or redundancy; each 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?

The description explains what the tool returns and how Claude should execute it, which is essential since there is no output schema. However, it omits context about prerequisites, such as needing covidence_login first, and does not address how the returned prompt relates to stored criteria or the criteria_override parameter.

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 parameters are already fully documented. The description adds no extra meaning about review_id, batch_size, or criteria_override beyond what the schema states, so the baseline of 3 is appropriate.

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 action ('Run a screening session') and the concrete deliverable: a complete prompt for Claude to navigate Covidence in Chrome, covering navigation, reading abstracts, applying criteria, and casting votes. This distinguishes it from sibling tools like covidence_nav or covidence_log_vote, which handle individual steps.

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 implies this tool is for whole-session screening rather than individual steps by listing navigation, abstract reading, criteria application, and voting together. However, it never explicitly says when to choose this over covidence_nav, covidence_set_criteria, or covidence_log_vote, nor does it mention prerequisites like being logged in.

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?

No annotations are provided, so the description carries the full behavioral disclosure burden. It reveals that criteria are persisted ('Store') and that Claude will automatically apply them during screening, which are useful behavioral traits. However, it does not disclose whether calling the tool overwrites previous criteria, whether authentication is required, or any other side effects.

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 two sentences with no filler. It leads with the core action, then gives the important behavioral consequence, making it easy for an agent to parse quickly and act on.

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 two-parameter setter, the description is sufficiently complete: it states what object is operated on, what data is stored, and the downstream effect. It leaves authentication and overwrite behavior unstated, but those are minor for this straightforward 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 schema already documents both parameters fully, including an example for the criteria string, giving 100% schema description coverage. The description adds no parameter-level detail beyond the schema, so the baseline of 3 is appropriate.

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 uses a specific verb ('Store') with a clear object ('inclusion/exclusion criteria for a specific review'), and adds that Claude will apply them automatically during screening, which clarifies the tool's role. It does not explicitly differentiate from siblings like covidence_screen, but the described behavior makes the 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?

The description gives clear context by noting that criteria will be applied automatically during screening sessions, implying this tool should be used before or in support of screening. It does not explicitly state when not to use it or name alternatives, but the context is sufficient to guide a correct call.

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