Computer-Use Agents API

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

With no annotations, the description must disclose behavior. It states the operation and idempotency, but does not mention permissions, side effects (e.g., resource release), or what happens to a running session beyond cancellation. Adequate but leaves some gaps.

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?

Single sentence, 13 words, front-loaded with the verb and resource. Every word earns its place, no 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?

The tool is simple (1 param, no nested objects, has output schema). Description covers purpose and idempotency. Could mention output structure or side effects, but given low complexity, it is mostly complete.

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?

Only one parameter (session_id) with no description in the schema. The description does not elaborate on its format, constraints, or meaning beyond what the name implies. Since schema coverage is 0%, the description should compensate, but it fails to add value.

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?

Name and description clearly state the action (cancel) and resource (session). Idempotency detail distinguishes it from siblings, all of which are different operations.

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 says 'Cancel a session' and clarifies that it's a no-op if the session does not exist or is already finished, giving clear context on when to use it. No explicit alternatives are needed as no sibling tool performs cancellation.

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 full burden for behavioral disclosure. However, it does not disclose pagination behavior, rate limits, required permissions, or any side effects. It only states 'List agents' without further behavioral context.

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 concise sentence that communicates the core purpose. It is front-loaded and avoids unnecessary words. However, it could include parameter info without losing conciseness.

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 no annotations, low parameter coverage, and sibling tools like 'run_agent', the description is incomplete. It does not explain what the output contains, pagination, or how to interpret results. The output schema exists but does not fully compensate for missing behavioral context.

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 input schema has two parameters (page, size) with defaults, but the description does not explain their meaning or usage. Schema description coverage is 0%, and the description fails to compensate, providing no parameter semantics.

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 lists agents the caller can run, specifying the scope as their org's agents and public 'h/' ones. It uses a specific verb ('list') and resource ('agents'), distinguishing it from sibling tools like 'run_agent' or 'cancel_session'.

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 usage for listing available agents before running them, but does not explicitly state when to use this tool versus alternatives like 'run_agent'. No guidance on prerequisites or when not to use it.

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 full burden. It reveals that results are sorted newest first and, more importantly, details the pagination protocol: when truncated, use modified_before and name_after, and why (timestamps not unique). This is substantial behavioral insight beyond a simple description.

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, each with a clear job. The first defines the operation; the second explains edge-case behavior. No 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?

With 5 parameters and no annotations, the description covers the most complex aspects (ordering and pagination). It leverages the output schema for return format. Minor gaps: max_entries is not explicitly linked to truncation, but it is inferable.

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 has 0% description coverage, so the description must explain parameters. It explicitly describes modified_before and name_after (pagination, non-unique timestamps), and implies path with 'downloads' example. It does not explicitly discuss session_id or max_entries, but their purpose is evident from context and naming.

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 first sentence clearly states the action ('List files'), the resource ('on a browser session's machine'), and the ordering ('newest first'), with a concrete example ('downloads'). This distinguishes it from siblings like list_agents (agents) and read_file/write_file (content).

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 context: listing files on a session's machine, e.g., downloads, which implies use when you need to see available files. It does not explicitly name alternative tools or exclusion cases, but the scope is clear enough to differentiate from 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?

With no annotations, the description carries the burden. It discloses return type (base64 content and metadata) but doesn't cover error behavior, permissions, or implicitly confirming no side effects beyond the verb 'read'.

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?

A single sentence that front-loads the verb and resource, with no filler or repetition. Every word adds value.

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 tool is simple and has an output schema, so the description's brevity is acceptable. It covers what the operation does and its return form, though more parameter detail would help.

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 0%, and the description only vaguely implies the parameters ('browser session' for session_id, 'a file' for path) without explicitly explaining their roles or expected formats.

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 ('Read') and resource ('a file from a browser session's machine'), and distinguishes itself from siblings like write_file and list_files by clearly indicating content retrieval and return format.

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 context is clear: use it to read a file from a browser session. It doesn't explicitly mention alternatives, but the read vs. write/list distinction is implicitly obvious.

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 bears full responsibility for behavioral disclosure. It only states the basic action and outcome, without mentioning potential side effects, resource usage, authentication needs, or error conditions.

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 long, immediately stating the purpose and key outcome. Every word adds value, and it is front-loaded for quick comprehension.

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?

Despite having an output schema, the description fails to explain when to expect an answer versus a session handle, how parameters like max_steps or max_time_s affect behavior, or how this tool interacts with others like wait_for_session.

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 adds meaning only for the 'agent' parameter by referring to list_agents. The other four parameters (task, max_steps, max_time_s, idempotency_key) are not described, and schema coverage is 0%, leaving their purpose unclear.

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 the verb 'start' with the resource 'agent on a task', which clearly indicates the action. It also mentions returning an answer or session handle, and references 'agent from list_agents', which distinguishes it from sibling tools like list_agents and wait_for_session.

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 implicitly suggests use after list_agents by referencing it, but does not explicitly state when to use this tool versus alternatives like send_message or wait_for_session. No exclusions or prerequisites are provided.

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 must disclose behavioral traits. It only states the action 'send' but does not explain blocking behavior, return values, side effects, or any permissions needed. This is insufficient for a mutation tool.

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 sentence that conveys the core purpose efficiently. It is front-loaded and contains no unnecessary words, though it could be expanded with behavioral details without losing conciseness.

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?

Despite having an output schema, the description lacks essential context like whether the call is blocking, what happens if the session is not running, or how to interpret the response. For a tool with no annotations, this is incomplete.

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 0%, and the description adds almost no meaning beyond parameter names. 'message' and 'session_id' are self-explanatory from their names, but no format, constraints, or usage hints are provided.

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 verb 'send', the resource 'message', and the context 'follow-up to a running session'. It distinguishes this tool from siblings like cancel_session or run_agent because no other sibling sends messages.

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 specifies that the tool is for sending a follow-up message to a 'running session', implying prerequisite of having an active session. However, it does not explicitly mention when not to use it or provide alternative tools for different scenarios.

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 present, so the description must carry the full burden. However, it does not disclose behavioral traits such as whether the action is reversible, if authentication is required, or any rate limits. The phrase 'make publicly readable' implies a mutation but lacks detail on 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 very concise, consisting of one sentence. However, it is too sparse for a tool with no annotations and minimal schema details. While front-loaded clarity is good, the brevity sacrifices essential 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?

Given the lack of annotations and output schema details (though output schema exists), the description is incomplete. It does not explain what 'publicly readable' entails, whether the URL is permanent, or any associated permissions. The agent lacks enough context to use the tool confidently.

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 0% and the description adds no meaning beyond the parameter name 'session_id'. It does not explain format, constraints, or examples, leaving the agent without guidance on how to provide a valid value.

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 (make a session publicly readable) and the resource (session), and specifies the output (absolute share URL). It distinguishes from sibling tools like cancel_session or wait_for_session, which have different purposes.

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?

No usage guidance is provided. The description does not indicate when to use this tool over alternatives, nor does it mention any prerequisites or contexts where it should not be used.

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 must carry the full burden of behavioral disclosure. It mentions long-polling and snapshot return but omits critical details like blocking behavior, timeout, error conditions, or safety. The read-only nature is implied but not explicit.

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 sentence with no fluff, using backticks for code formatting. It's appropriately concise, though it could benefit from a bit more structure to separate modes.

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, the return shape is covered. However, the description lacks context on prerequisites, error handling, and when to use each mode. The minimal description is adequate for a simple tool but leaves room for improvement.

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 0%, so the description must compensate. It explains the 'wait' parameter (long-poll vs snapshot) but fails to describe the 'session_id' parameter or its format. Only one of two parameters is addressed, leaving a significant 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 uses a specific verb 'Poll a session' and distinguishes two modes (long-poll vs snapshot), clearly identifying the resource and action. However, it doesn't differentiate from siblings like cancel_session or send_message, though those are distinct enough.

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 when to use the tool (to get session answer or snapshot) but lacks explicit guidance on when not to use it or alternatives. No exclusions are mentioned, but the behavioral difference is clear.

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 must carry full behavioral disclosure. It states a write operation but does not mention whether it overwrites existing files, creates parent directories, enforces size limits, or any side effects. It also fails to describe the return value or error behavior, leaving the agent without crucial safety and outcome information.

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 sentence that is direct and front-loaded with the primary action and object. Every word adds value, with no redundancy or filler, making it highly efficient for an agent 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?

Despite having an output schema (not shown), the description lacks essential context for a write operation: overwrite semantics, permissions, side effects, and error handling. The lack of annotations increases the burden, and the terse description does not sufficiently compensate, leaving the agent uncertain about the tool's full behavior and expectations.

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 input schema has zero descriptions, but the parameter names (session_id, path, content_base64) are self-explanatory. The description adds that content must be base64-encoded and that the path is on the browser session's machine, which partially compensates for the lack of schema documentation. However, it doesn't explain path format, encoding requirements beyond base64, or how session_id is used.

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 ('Write'), the object (file), and the specific context (on a browser session's machine). It also clarifies the content format (base64-encoded), which distinguishes it from sibling tools like read_file and list_files that operate on the same resource but with different purposes.

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 minimal context about when to use this tool, mentioning 'browser session's machine' but no explicit prerequisites, such as needing an active session, or guidance on when to choose this over alternative tools. There are no exclusions or conditions specified.

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