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

With no annotations, the description carries the full burden. It transparently discloses that the server list is derived from .env.<name> files on disk and that return content includes screen_do keys. It does not state output format or explicitly confirm it is a read-only operation, but the verb 'List' makes the lack of side effects reasonably clear.

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 sentence, front-loaded with the action and resource, with no filler. Every part adds useful information about what the tool returns.

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 zero-parameter listing tool, the description is adequate: it names the resource, the source of server names, and the additional keys included in the result. A slightly more explicit statement of output shape would make it fully complete since no output schema is provided.

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 takes zero parameters, so the description does not need to explain any. The schema already covers this fully, and the baseline for no-parameter tools 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 ('List') and names a concrete resource ('configured IBM i servers'), and it further clarifies the naming source ('named by the .env.<name> files on disk') and that it also exposes the keys screen_do accepts. This clearly distinguishes it from sibling tools like session_open and screen_do.

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 context is implied: an agent would call this to discover available servers and screen_do keys before using other session tools. However, the description does not explicitly state when to use this versus alternatives, nor does it provide exclusions or ordering guidance.

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 carries the full disclosure burden. It covers the test file format, the outcome ('report what passed'), and important session lifecycle behavior: opens/closes its own session unless `session` is passed, and leaves the session where the last test finished. It does not disclose failure behavior or output format, but the added session context is genuinely useful and goes beyond the schema.

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?

Four sentences, each earning its place: the main action, the test format, the recommended usage timing, and the session behavior. The primary verb and result are front-loaded, and there is no repetition of schema properties 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 tool with four fully documented optional parameters, the description is close to complete: it explains what a test is, when to run it, and the session side effects. The main gap is 'report what passed' — there is no output schema and no detail about how pass/fail results are presented, though this is a minor omission for a test runner.

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 documents all four parameters with descriptions (100% coverage), so the baseline is 3. The description adds useful background on authoring test files with 5250-do/5250-expect blocks, which helps an agent understand the tool's domain, but it does not add parameter-specific meaning beyond what the schema already provides.

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 specific verb and resource: 'Replay screen regression tests against a program and report what passed.' It also distinguishes itself from siblings by explaining the 5250-do/5250-expect Markdown test format and how it relates to screen_do, making it clear this is the batch test-runner rather than an interactive screen tool.

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?

Gives explicit timing guidance: 'Use this after compiling a change... or before making one...' to verify preserved behavior or drive expected screens. It also explains when to reuse a session versus letting the tool open and close its own. It does not explicitly name when-not-to-use alternatives, which keeps it just below 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?

With no annotations, the description carries the full burden, and it delivers: it discloses execution order, failure semantics ('If an action fails the run stops there and the error names it'), and the 5250 transmission model where typing sends nothing to the host until a key is pressed. This prevents a caller from assuming per-action round-trips.

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?

Every sentence earns its place: overview, batch rationale, action grammar, network-behavior caveat, and failure mode. The most important facts are front-loaded, and the examples make the syntax immediately understandable without padding.

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 no output schema, the description still states what is returned ('only the final screen comes back') and what happens on failure. With no annotations, it explains the host-communication behavior and stopping semantics. Together this is enough for an agent to construct valid, correctly batched calls.

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?

Although schema coverage is 100%, the description adds a full action mini-language beyond the schema: valid prefixes like 'type', 'key', and 'cursor', accepted key names, field-addressing modes (ref, row,col, DDS name), and cursor behavior. It also clarifies the session parameter's default behavior and when to omit it.

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 concrete action and resource: 'Drive the screen: type into fields, move the cursor and press keys, in one call.' It clearly enumerates what the tool does and its one-call scope, and it distinguishes itself from observational siblings like screen_snapshot by being the interactive/input-driving tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit usage guidance: batch a whole interaction into one call rather than one action per call, with a rationale about order and the final screen. However, it does not explicitly name sibling alternatives such as screen_snapshot for read-only inspection, so the when-not-to-use guidance is implied rather than 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, the description carries the full burden and performs well: it explicitly states 'without changing anything' and lists the full return payload (screen text, field list, cursor, keyboard, message line), making the non-destructive behavior unmistakable.

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 sentence that front-loads the verb and scope, then a dense colon list of return components and a final usage pointer. 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?

The description fully specifies what the snapshot contains and its safety profile, and the schema resolves the session selection. For a simple read-only tool without an output schema, nothing essential is missing.

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 only parameter (session), including a default and guidance on when to omit it. The description adds no further parameter detail, so the baseline 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?

Clear verb+resource: 'Return the current screen' plus an explicit enumeration of the snapshot contents. The qualifier 'without changing anything' differentiates it from action tools like screen_do.

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?

'Use this to look before acting' gives explicit timing guidance and implies it precedes mutation tools, but it does not name sibling alternatives 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?

The description discloses important behavioral traits beyond the schema: it releases the virtual device, and it warns that simply dropping the connection leaves a disconnected interactive job that can cause problems on the next run. It also explains the impact on licensed interactive capacity. Since no annotations are provided, the description carries the full burden, and it does so well, though it could mention whether the operation is reversible or if it requires confirmation.

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 concise and front-loaded with the core action ('Sign off and close the session, releasing the virtual device'), followed by a clear directive and consequence. Every sentence earns its place, and the warning about the 'Attempt to Recover Interactive Job' screen is valuable context without being verbose.

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 tool's simplicity (2 optional parameters, no output schema), the description is quite complete. It explains the purpose, the consequence of misuse, and the parameter behavior. It could be slightly more complete by mentioning what happens after closing (e.g., whether the session is immediately terminated or if there's a grace period), but overall it provides enough context for an agent to use it correctly.

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 description coverage is 100%, so the schema already documents both parameters ('session' and 'signOff'). The description adds context about the 'signOff' parameter by explaining the default behavior ('type signoff on the command line first') and the alternative ('Pass false to drop the connection immediately'). However, it doesn't add much beyond what the schema already states, so a 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 tool's purpose: 'Sign off and close the session, releasing the virtual device.' It uses a specific verb ('close') and resource ('session'), and distinguishes it from siblings like session_open by focusing on the teardown action. The description also explains the consequence of not using it, which further clarifies 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 explicitly states when to use this tool: 'Always do this when finished.' It also explains the negative consequence of not using it (leaving a disconnected interactive job, causing an 'Attempt to Recover Interactive Job' screen and holding licensed capacity). This provides clear guidance on when it is necessary, though it doesn't explicitly name alternatives, the context makes it obvious this is the closing counterpart to session_open.

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 burden, and it discloses two non-obvious behaviors: it starts a live browser view for a human observer, and its return value is a literal 24x80 screen plus a field list. It does not mention cleanup via session_close or failure behavior, but the key side effects and return contract are named.

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 main action is front-loaded, followed by the browser side effect and the return contract, so 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?

The description defines the return value, names the browser side effect, and references the downstream tool, which is strong for a tool with no output schema. It omits explicit lifecycle guidance such as closing the session with session_close or behavior when reopening the same session name, leaving a small but real gap.

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 all 7 parameters with 100% coverage, so the description does not need to add per-parameter meaning. It usefully ties output field refs to screen_do, but that is output-oriented rather than parameter-oriented, matching the baseline for fully covered schemas.

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 action and resource: 'Open a 5250 session to an IBM i and sign on, then return the first screen.' It also differentiates from siblings by defining the return artifact as a screen snapshot with field refs meant for screen_do, so an agent can tell it apart from screen_snapshot and screen_do.

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 establishes clear context: use it at the start of a session, and the returned field refs are explicitly tied to screen_do, giving natural next-step guidance. It does not explicitly state when not to use it (e.g., if a session already exists, prefer screen_snapshot), so it stops short of full exclusion criteria.

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