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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions a 'secure sandboxed environment,' which is useful, but it does not describe output handling, state persistence, timeouts, filesystem or network access, or side effects. This is a significant gap for a code execution 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?

Two short sentences, front-loaded with the core purpose and followed by the language support. No wasted words, and every sentence contributes to understanding.

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 has no output schema and no annotations, so the description should explain what the agent can expect after execution, such as return values or output format. It also lacks details about sandbox constraints and error behavior, making it incomplete for safe and correct invocation.

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%; both 'code' and 'language' already have descriptions and the language enum is fully specified. The description's mention of supported languages duplicates the enum and adds no new 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 clear verb and resource: 'Execute code in a secure sandboxed environment,' and lists the supported languages. It is not a tautology, but it does not explicitly differentiate itself from the sibling 'execute_command,' so the distinction is left to inference.

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?

There is no guidance on when to use this tool versus alternatives like execute_command, or how it relates to sessions. The description implies code execution but does not provide any context for tool 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says the tool executes a shell command, but omits critical traits: whether the command can mutate the filesystem, install packages, access the network, time out, or how output and exit codes are returned. For an arbitrary command executor, this is a significant transparency gap.

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 conveys the core operation efficiently, though the extreme brevity comes at the cost of behavioral context that other dimensions penalize.

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 a simple one-parameter schema, this is a powerful tool with potentially wide-ranging effects. The description lacks essential context about return values (stdout/stderr, exit status), side effects, and sandbox restrictions, and there is no output schema to compensate. An agent has enough to guess the call shape but not enough to anticipate the tool's behavior.

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% for the single 'command' parameter, and its description ('The shell command to execute') already conveys the parameter's meaning. The tool description adds no further nuance about command syntax, allowed shells, or working directory, so it neither improves nor worsens the baseline.

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 clear action ('Execute') on a defined resource ('shell command') within a bounded environment ('sandbox'). It is distinguishable from the sibling execute_code, which implies code execution rather than shell commands, though it doesn't explicitly name the sibling as an alternative.

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 guidance is given about when to use execute_command versus execute_code or other file/session tools. There are no eligibility criteria, no exclusions, and no mention of prerequisites such as an active session, leaving an agent to infer usage from the name alone.

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 burden of disclosing behavior. The verb 'Get' indicates a read-only operation, which is useful context, but the description does not disclose what happens for invalid or nonexistent session IDs, response format, or any side effects. It is sufficient for a simple getter but not richly transparent.

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, short sentence with no wasted words. It is appropriately front-loaded but leans heavily on the tool name, adding only the qualifier 'information about a specific' to clarify scope. This is concise and effective, though not exemplary in adding unique 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 has only one parameter with full schema description and no output schema. The description provides minimal context about what 'information' will be returned, but for a straightforward get-by-ID tool this may be sufficient. Given the lack of annotations and output schema, slightly more detail about return contents or error behavior would improve completeness.

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 coverage is 100%, with sessionId described as 'The session ID to query'. The description adds no additional parameter semantics beyond the schema, so the baseline score of 3 applies. The tool name and description reinforce the parameter's role but do not provide extra 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 clearly states the verb 'Get' and the resource 'information about a specific session', making the tool's purpose immediately understandable. It distinguishes from sibling tools like list_sessions by scoping to a specific session, though it does not explicitly name alternatives.

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 tool should be used when information about one particular session is needed, in contrast to listing all sessions or starting/stopping sessions. However, it provides no explicit guidance on when to prefer this over siblings or mention prerequisites like owning a session ID, leaving the agent to infer usage context.

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 burden for behavioral disclosure. It only states the core listing action and does not mention whether results include directories, hidden files, sorting, or error 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?

One concise sentence with no filler; the action and sandbox scope are front-loaded. Every word 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 one-parameter listing tool, the description covers the essential operation. However, without an output schema or annotations, it leaves unstated what the returned listing contains (e.g., names only, directories included, hidden files).

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 single parameter path is already fully described in the schema (directory path with default '.'). The description adds no new parameter meaning, so the high schema coverage establishes a baseline of 3.

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?

States a clear, specific action: list files in a directory within the sandbox. This distinguishes it from read_files (file content) and write_files/remove_files (mutations).

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 it should be used when an agent needs to see what files exist in a path within the sandbox. However, it does not explicitly contrast it with alternatives like read_files or state 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 provided, the description carries the full disclosure burden. It clearly indicates a read-only listing operation and the scope ('all sessions'), but it does not mention ordering, which session states are included, whether results are paginated, or exactly what fields are returned. This is minimal but not misleading.

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 phrase with no filler or redundant information. Every word contributes to understanding the tool's function.

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 tool with zero required parameters and one optional parameter, the description is nearly sufficient. However, with no output schema and no annotation context, it leaves some ambiguity about the return format and the exact meaning of 'all sessions' (e.g., active, historical, or both).

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 only parameter, maxResults, is fully described in the schema, so schema coverage is 100%. The description adds no additional meaning about defaults, bounds, or how the limit is applied, which is acceptable given the schema already documents the parameter.

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 ('List') and a precise resource ('all code interpreter sessions'), making the tool's purpose unambiguous. It is easily distinguished from siblings like get_session (single session) and start_session/stop_session (session lifecycle).

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 is implied by the name and description: use this tool when you need a list of all code interpreter sessions. However, there is no explicit guidance about when to prefer list_sessions over get_session, or whether this is appropriate before starting a session.

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?

There are no annotations, so the description carries the disclosure burden. It tells the agent that reading is a non-mutating operation by using 'Read', which is useful, but it does not disclose behaviors such as limits on file size, path restrictions, handling of missing files, or whether partial results are returned if one path fails.

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 one short, front-loaded sentence with no wasted words. It states the action and scope immediately, which is ideal for an agent parsing tool definitions.

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 single-parameter read tool, the description is mostly adequate, but the complete absence of annotations and lack of any behavioral caveats (e.g., sandbox path restrictions, error behavior) leaves some gaps. Sibling tools show a file-focused cluster, so a note on when to use read_files vs execute_code to view files would improve completeness.

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% and the single parameter 'paths' is described as 'Array of file paths to read'. The description adds minimal meaning beyond the schema—it conveys that contents are returned, not just metadata—but it does not clarify path format, absolute vs relative paths, or behavior when multiple paths are supplied.

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 'Read' and the resource 'file contents from the sandbox filesystem', which distinguishes it from sibling tools that write, list, remove, or execute. It is concise and unambiguous, though it does not explicitly contrast with a similar sibling beyond the resource scope.

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 implies it is the tool to use for reading files, while siblings write_files, list_files, and remove_files cover other file operations. However, it does not provide explicit guidance on when to prefer this over execute_code or execute_command for file contents, nor does it mention that paths must be within the sandbox or that multiple paths are allowed.

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 full burden of behavioral disclosure. It states the basic removal action but does not mention irreversibility, behavior on non-existent paths, whether directories can be removed, or any side effects. For a destructive operation this is a notable gap.

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 wasted words. It immediately conveys the action and scope.

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?

This is minimally viable for a one-parameter file operation: the schema documents the parameter fully and the description states the action. However, because it is a destructive operation with no annotations, it should mention irreversibility or path/directory behavior to be fully 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?

The schema covers 100% of parameter documentation with 'Array of file paths to remove', so the description does not need to add much. It adds the sandbox filesystem scope, but no further semantic value. 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 clearly states a specific action ('Remove') on a specific resource ('files from the sandbox filesystem'). This distinguishes it from siblings like read_files, write_files, list_files, and execute_command without needing to inspect 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?

No guidance is provided on when to use this tool vs alternatives, such as using execute_command for more complex deletion logic. There are also no usage conditions or caveats stated, so the agent must infer appropriate usage from the tool name alone.

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 full burden of behavioral disclosure, but it only states the bare action. It doesn't disclose side effects (resource allocation, what happens to an existing active session), idempotency, or prerequisites for use. There is no annotation contradiction, but there is also no behavioral context beyond the verb itself.

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, tight, front-loaded sentence with zero filler — the verb and object appear immediately. It is efficient, though the brevity is partly responsible for the thin behavioral coverage penalized in other dimensions. As a structural matter, it 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?

This tool creates a stateful resource, yet the description doesn't explain how the agent obtains a session handle from the return value (no output schema exists to fill this gap), what the timeout means for session lifetime, or how a started session is consumed by execute_code. For an agent planning a multi-step session workflow, this is insufficiently 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?

Schema description coverage is 100%, so the baseline of 3 applies even though the description adds no parameter-level detail. Both parameters (name, and timeout with its default of 900) are fully documented in the input schema, leaving nothing undocumented for the description to compensate for.

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 ('start') and resource ('new code interpreter session'), which is unambiguous and distinguishable from the sibling family (execute_code, stop_session, get_session, list_sessions). The word 'new' usefully signals a fresh session is created. It stops short of 5 because it doesn't explicitly contrast with execute_code, which is the most likely source of agent confusion.

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 no guidance on when to start a session versus calling execute_code directly, whether a session is a prerequisite for code execution, or how sessions relate to commands. An agent must infer the execution model from the name alone. No exclusions, conditions, or alternatives are mentioned.

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 exist, so the description carries the full behavioral disclosure burden. It clearly states the core behavior, but it does not disclose side effects such as losing interpreter memory/state, whether stopping a nonexistent session errors, or whether the action is idempotent. The primary behavior is transparent, but consequences are left implicit.

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 short sentence with the verb front-loaded and no filler. Every word contributes meaning, and there is no redundant restatement of the tool 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, parameterless lifecycle command, the description is nearly complete for selecting and invoking the tool. It could be improved by noting the precondition that a session must exist and what happens if no current session is active, but these are minor 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 and schema coverage is 100%, so there is nothing for the description to add about parameter meanings. This is the appropriate baseline for a parameterless tool.

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 ('Stop') and a specific resource ('current code interpreter session'), making it immediately clear what this tool does. It is naturally distinct from siblings like start_session, get_session, and list_sessions, which have opposite or observational 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 phrase 'current session' provides clear context: this tool is for ending the active session rather than creating, inspecting, or listing sessions. It does not explicitly name alternatives or state when not to use it, but for a zero-parameter lifecycle command the intended usage 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 carries the full behavioral burden. It only says 'Write files' and does not disclose whether existing files are overwritten, whether directories are created, whether writes are atomic, or what failure behavior looks like. The sandbox scope is helpful but minimal.

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 wasted words. It communicates the action and scope immediately, though additional behavioral details could improve it without much cost.

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 mutation tool with no annotations and no output schema, the description omits important context such as overwrite behavior, return value, error cases, and path constraints. The simple schema and clear purpose make it minimally usable, but it is not complete enough for an agent to understand the full implications of writing files.

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 100% description coverage for the single `files` parameter, including path and content fields. The description adds no additional parameter meaning, but because the schema covers the parameters well, 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 clear action ('Write') and a specific resource ('files to the sandbox filesystem'). It is distinguishable from sibling tools like read_files, list_files, and remove_files, though it does not explicitly contrast itself with execute_code or execute_command, which could also affect files.

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?

There is no guidance about when to use write_files versus alternatives such as execute_code or execute_command for file creation. The description does not state prerequisites, path restrictions, or when a direct file-write tool should be preferred over command execution.

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