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 usefully discloses that only metadata (not content) is returned and that the path must be 'authorized', but it omits permissions requirements, error behavior, symlink handling, and what metadata fields are returned.

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 is appropriately sized, though its terseness is more under-specification than 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?

The tool is structurally simple, but there are no annotations and no output schema. The description should explain the returned metadata shape and path expectations; it does neither, leaving the agent unable to predict the output or how to form a valid path.

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 has 0% schema description coverage, so the description must compensate. Calling it an 'authorized path' adds little: there is no guidance on absolute vs. relative paths, whether it must be a file or directory, or validation rules.

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 resource ('non-content metadata'), and the phrase 'non-content' distinguishes it from the content-reading sibling read_file. It does not explicitly name alternatives, but the purpose is clear.

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 explicit when-to-use or when-not-to-use guidance, and no sibling is named. The phrase 'non-content metadata' implies the tool is for metadata-only requests rather than reading file contents, but the agent must infer that read_file is the alternative.

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 burden. "Return" implies a non-mutating read and the enumerated fields give a sense of the payload, but nothing is said about permissions, rate limits, caching, or whether calling it has any side effects (e.g., session accounting).

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 with zero filler, front-loading the verb and resource before the field list. Every clause maps to a distinct piece of returned 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?

With no output schema and no annotations, the description's field enumeration does double duty as an informal return-value summary, which is the right call. It falls short only on behavioral context, which is low-risk for a zero-argument read.

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 zero parameters, which sets the baseline at 4. There is nothing for the description to disambiguate, and it correctly avoids inventing parameter talk.

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?

Uses a specific verb ("Return") with a concrete resource (agent health) and enumerates the payload contents: active policy, platform support, session count. It is clearly distinct from the file/process siblings, though that differentiation is implicit rather than stated.

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 explicit when-to-use guidance, no mention of prerequisites, and no named alternatives. The diagnostic/status nature of a zero-parameter health call makes the intended usage inferable, but the agent must infer 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?

No annotations, so the description carries the full burden. It does disclose meaningful scope: these roots are authorization boundaries covering both reads and process working directories, which tells the agent this is a permissions-discovery tool rather than an arbitrary path listing. It stops short of stating the return shape (paths? objects with read/exec flags?) or whether the set can change between calls.

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. Every clause adds information (authorization, reads, working directories).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only discovery tool with no output schema, the description covers what the tool conceptually returns and why the concept matters. The one remaining gap is the concrete return format, which an agent must discover empirically.

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?

Zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate.

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?

Specific verb ('List') plus resource ('filesystem roots') with a qualifier that narrows scope to 'explicitly authorized for reads and process working directories.' This is clearly distinguishable from list_directory or read_file, though it never names a sibling to contrast with.

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: an agent would call this to discover which roots it may read or use as a working directory. There is no explicit 'use when' statement, no note about when to prefer list_directory, and no mention of whether the result is static or per-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?

No annotations are provided, so the description carries the full burden, but it does disclose two real behaviors: the listing is bounded and symlink entries are not followed. It says nothing about recursion depth, ordering, error behavior for missing/unreadable paths, or what a returned entry looks like.

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 front-loaded sentence with no filler. It is arguably undersized for the disclosure needs, but nothing is wasted and the most important constraint leads.

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 annotations, no output schema, and 0% parameter coverage, the description is the only source of guidance and it leaves path semantics, permission/allowed-root requirements, and error behavior unexplained for a filesystem-listing 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 0%, so the two parameters (path and limit) are undocumented. The description's 'bounded' hints that limit is capped but never states the 200 maximum or that path defaults to '.', so it only partially compensates for the coverage 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?

States a specific verb ('List') and resource ('directory') plus a scope qualifier ('bounded') and a safety trait (no symlink traversal). It is clearly distinct from read_file or get_file_metadata, though it never names search_files, the closest sibling, so the boundary between listing and searching 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 statement of when to use this versus search_files or list_allowed_roots, and no prerequisites (e.g. whether the path must be inside an allowed root). The only implied usage comes from the word 'directory' in the name.

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; it does disclose the two most important behavioral facts (metadata-only, agent-scoped) which convey a safe read operation. It says nothing about ordering, pagination, whether finished sessions are included, or whether the listing is bounded — gaps that matter for a session-listing call.

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 verb and resource, with the two qualifiers appended in the order an agent needs them (scope, then exclusion). Nothing redundant or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only listing with no output schema, the description covers the essentials: what is listed, whose processes, and that output is excluded. The remaining gap is what 'session metadata' actually contains (IDs, status, timestamps) and how many sessions come back, which the absent output schema leaves undocumented.

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 and the schema is empty, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly adds no parameter noise.

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 ('List') and resource ('process session metadata'), plus two scoping constraints: only sessions 'created by this agent' and explicitly 'without including process output'. The output exclusion directly separates it from the sibling read_process_output, so an agent can pick correctly without opening a schema.

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 'without including process output' implicitly routes the agent to read_process_output when output is actually wanted, and the 'created by this agent' scope sets the boundary of what is listed. It stops short of naming the alternative or stating when-not-to-use explicitly, so it is clear context rather than full routing 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?

With no annotations, the description carries the full burden and does disclose important constraints: UTF-8 handling, an authorized root, and a strict byte limit. However, it does not explain what happens when the limit is exceeded (truncation vs. error), how binary or non-UTF-8 files are handled, or permission failure 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?

The single sentence is front-loaded, compact, and free of filler. Every phrase contributes a useful constraint.

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 no annotations, no output schema, and 0% parameter description coverage, the definition is too thin. It omits error behavior, truncation semantics, return shape, and usage guidance relative to sibling tools.

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 for both parameters. It implies that `path` must be under an authorized root and that `maxBytes` enforces a byte limit, but it does not clarify path format, whether paths are relative or absolute, or the default/maximum byte behavior.

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 and resource ("Read a UTF-8 text file") and adds scoping qualifiers ("under an authorized root with a strict byte limit"). This clearly distinguishes reading file contents from siblings such as list_directory, get_file_metadata, and search_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?

It states what the tool does but gives no explicit guidance on when to use it instead of get_file_metadata or search_files. There are no exclusions, prerequisites, or alternative-selection cues.

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 bears the full burden. It usefully discloses that the read is paged ('bounded page') and that the return includes both output and status, which an agent could not infer from the schema alone. However, it omits important traits: whether reading consumes or drains buffered output, whether the call is safe/non-destructive, how output behaves after the process exits, and any size or rate limits beyond the parameter bounds.

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 verb and resource, with no filler. Its brevity edges toward under-specification rather than waste, but structurally it is well-formed.

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 three parameters, no output schema, and no annotations, the description should do more explaining than it does. It adequately conveys the return contents ('output and status') and the paged nature of the call, but it leaves open whether output persists after process exit and how status should be interpreted.

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 for three undocumented parameters. But it only hints at limit/offset via 'a bounded page' and at sessionId via 'agent process session'; it never explains whether offset is an absolute cursor or advances a read pointer, whether limit is bytes or lines, or what the defaults mean. The schema carries the type and default information, so this is not a total void, but it is thin.

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 names a specific verb and resource: 'Read a bounded page of output and status for an agent process session.' This clearly places it as the read counterpart to start_process and list_processes. It stops short of explicitly naming siblings, so it lands at 4 rather than 5.

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 says nothing about when to call this rather than list_processes, run_command, or start_process, and gives no prerequisite context such as requiring a sessionId from start_process or how to discover a valid session. The intended use is inferable from the phrase 'agent process session' but never 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 full burden and does disclose the important traits: read-only, allowlisted executable set, no shell interpretation, short-lived. It omits permission requirements, what happens on timeout, and what the response contains, so it is helpful but incomplete for a no-annotation 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 tight sentences, with the safety constraint front-loaded before the exclusion. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description gives an agent enough to call the tool safely: the executable set is enumerated in the schema and the shell/allowlist restrictions are stated. The only meaningful gap is the absent explanation of output shape and timeout 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 0% across 4 parameters, so the description must compensate. 'Without a shell' usefully clarifies that args are passed as direct argv rather than a command string, but cwd and timeoutMs receive no explanation and the allowlist itself is only visible via the enum.

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 (run) and resource (allowlisted command) with the key constraint that it is short, read-only, and shell-free. This distinguishes it implicitly from siblings like start_process, though no sibling is named explicitly.

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 makes clear that arbitrary commands and shell syntax are rejected, which is a useful guardrail, but it never states when to prefer this over start_process, read_file, or list_directory. Usage is only inferable from the read-only/short framing.

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 and no output schema, so the description carries the full disclosure burden. It usefully clarifies that only file names are searched (not contents) and that depth/results are bounded, but omits permission requirements, hidden-file behavior, result ordering, and 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?

A single, efficiently front-loaded sentence with no wasted words. It is perhaps too terse for a tool with four undocumented parameters, but structurally clean.

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 four-parameter search tool with no annotations, zero schema description coverage, and no output schema, the definition is significantly under-specified. An agent knows the broad purpose but lacks enough detail on inputs and behavior to invoke it 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%, so the description must compensate for all four parameters. It gestures at depth and result count, but never explains query, path, limit, or maxDepth semantics, formats, defaults, or bounds, leaving parameters undocumented in both places.

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?

Uses a specific verb+resource ("Search file names") scoped to an authorized root, which tells the agent it is a name-based file search rather than a content read or directory listing. It does not name or distinguish itself from siblings like list_directory, so it stops short of a 5.

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?

"Beneath an authorized root" implies the tool only works within allowed roots, giving some usage context. But there is no explicit guidance on when to prefer search_files over list_directory or how it relates to other listing tools, leaving selection 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 full behavioral burden. It usefully discloses that the executable is allowlisted, the session is bounded, and it runs with the user's account privileges, but it omits session lifecycle details such as how output is retrieved, whether the process persists, and cleanup 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?

The definition is only two sentences and front-loads the core action. The privilege note is useful, though the wording is slightly awkward and the description could better structure the key constraints.

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 4-parameter process-start tool with no annotations, no output schema, and 0% parameter description coverage, the description is too thin. It should explain session identity/return value, output retrieval, timeout behavior, and how this differs from run_command.

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% across four parameters. The description hints at the executable allowlist and bounded timeout behavior, but provides no meaning for cwd, args, timeoutMs, or how the parameters interact.

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 clear verb+resource phrase, 'Start an allowlisted bounded process session,' so the agent knows this initiates a process session. It adds useful qualifiers ('allowlisted', 'bounded', user-account privileges), but does not explicitly distinguish this from the sibling run_command 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?

There is no explicit guidance on when to use this tool versus run_command, list_processes, or read_process_output. The description implies it is for allowlisted persistent sessions, but an agent must infer that context and the exclusions.

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