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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is largely covered. The description adds useful scope limits ('cannot delete files', 'cap scanning'), but mostly restates the read-only nature and discloses nothing about performance cost or output shape beyond what the schema carries.

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 with the purpose front-loaded and the constraints trailing; no sentence is wasted. The all-caps lead-in and line break are slightly noisy but cost nothing in length.

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 description needn't explain return values, and annotations plus 100% schema coverage fill the rest. It is nearly complete, only omitting any note on expected runtime or cost for large scans, which the max_files mention partly addresses.

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 each parameter (path, top_n, max_depth, max_files) is already documented with defaults and ranges. The description only echoes max_files as a cap, adding no syntax or semantics beyond the schema, which matches the baseline 3 when the schema does the heavy lifting.

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 verb+resource ('READ-ONLY DIRECTORY SCAN') and enumerates exactly what the tool produces: counts, extensions, sizes, and largest paths. It also explicitly separates itself from the sibling simulate_disk_allocation by stating it is 'not a disk-allocation simulation.' An agent can identify this tool's job without opening the 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?

'Use max_files to cap scanning' gives a concrete usage tip, and the negation 'not a disk-allocation simulation' implicitly rules out one sibling. However, it never states when to reach for this tool versus get_filesystem_info or monitor_file_metadata, so routing guidance is only implied.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the useful operational detail that it 'never scans' beyond a simple snapshot, which is not implied by readOnlyHint alone, though the remaining side-effect guarantees largely reinforce annotations.

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?

Three short, front-loaded sentences with no waste. The read-only constraint and return contents are stated immediately.

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?

An output schema exists, so the description need not explain the return format, but it helpfully states that it returns space and inode usage. For a zero-argument, read-only snapshot tool, this is nearly complete; only explicit sibling routing 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?

Zero parameters is the baseline score of 4. The description correctly notes it takes no arguments, and there are no parameter semantics to clarify.

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 resource ('mounted-filesystem') and exactly what it returns ('space and inode usage'). Distinguishes itself from sibling memory and CPU tools by resource, and the read-only snapshot framing makes the operation unambiguous.

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

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

Clearly says it takes no arguments and never scans, changes, or deletes files, which tells the agent when it is safe to call. Does not explicitly name alternatives such as analyze_file_distribution or simulate_disk_allocation, so sibling routing relies on the resource 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the description's 'READ-ONLY' and 'Never deletes files or stops processes' largely restate structured data. It does add that the source is /proc/meminfo and that no arguments are needed, which is modest added context given the already-strong annotation coverage.

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?

Three short, front-loaded lines with no wasted prose; the read-only guarantee is stated first. Minor redundancy between 'READ-ONLY' and 'Never deletes files or stops processes', which repeat the same point.

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?

An output schema exists, so return values need not be explained, and the description covers scope and safety for a no-argument tool. It leaves minor gaps around how fresh/sampled the snapshot is versus sample_memory_trend, but nothing an agent needs to invoke 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?

Zero parameters, so the baseline is 4. 'Takes no arguments' confirms the empty schema, though with 100% coverage there is nothing further 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?

States a specific resource (system RAM, swap, /proc/meminfo) and explicitly frames the operation as a read-only snapshot. The 'Use only for...' clause scopes it against siblings like get_process_memory and sample_memory_trend, which target different memory views.

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 only for current system RAM, swap, and /proc/meminfo' gives a clear usage boundary and implicitly excludes per-process memory tools. It stops short of naming the sibling to use for trends or per-process data, so the routing guidance is contextual rather than explicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is partially covered, but the description reinforces it with a concrete refusal instruction for kill/modify requests, which is actionable behavior beyond the flags. It adds no detail on permissions, cost, or pagination behavior of the mapping list.

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?

Three short sentences, front-loaded with the read-only scope before the return summary and the refusal rule. Every sentence earns its place with 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?

For a low-complexity, single-PID read tool with an output schema present, the description covers scope, return contents, and the refusal boundary. Nothing an agent needs to call it correctly 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%, and the schema already documents pid and mapping_limit thoroughly (including the top-N guidance). The description adds no parameter-level meaning beyond it, 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?

States a specific verb+resource+scope: 'READ-ONLY memory inspection for one PID', and names what is returned (RSS, VMS, largest mappings). This cleanly separates it from the system-wide get_memory_info sibling and the trend/simulation tools.

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 an explicit when-not: 'This cannot stop, kill, or modify the process; refuse such requests' — a clear routing rule for destructive-sounding requests. It stops short of naming sibling alternatives (e.g., get_memory_info for system-wide data), so it is not a full when/when-not/alternatives statement.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the "READ-ONLY" framing is largely redundancy. The description does add genuine behavioral context beyond the annotations: results are bounded by depth and node count, and the tool will not modify processes. It does not address the idempotentHint=false flag or any cost/latency of a full tree walk.

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 read-only framing and the entry point. Every clause carries information and there is no filler, though the overall text is thin enough that brevity shades into under-specification.

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?

An output schema exists, so return values need no explanation, and all three parameters are documented at 100% coverage with no required fields. For a simple bounded read tool the description is sufficient, with the only real gap being routing guidance against sibling process/memory 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 100%, so root_pid, max_depth, and max_nodes are all fully documented in the schema, including the non-obvious "pass an explicitly requested depth even when it is below the default" caveat. The description only echoes root_pid and adds no syntax or format 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?

States a specific resource and scope ("PROCESS TREE starting at root_pid") in a single clear clause, so the agent immediately knows what is returned. It does not explicitly differentiate itself from adjacent siblings such as get_process_memory or get_memory_info, but the visualization of a parent-child tree is distinctive 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?

There is no statement of when to use this tool versus alternatives, nor any prerequisites or exclusions. The only negative guidance ("This cannot stop, kill, reprioritize...") is about capability, not about when this tool is the right choice over a sibling like get_process_memory.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is structured data. The description reinforces this ('observes counters only and cannot stop or modify processes') and adds the useful framing that it is pure observation, not simulation, but discloses nothing beyond that: no sampling overhead, blocking behavior, or resource cost of running the monitor.

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?

Front-loaded with the operation and scope in the first clause, with the two disambiguating statements following. Slightly redundant in that 'READ-ONLY' and 'cannot stop or modify processes' say the same thing twice, but there is no filler beyond that.

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?

An output schema exists, so return values need not be explained, and all three parameters are covered by the schema. Safety is covered by annotations and reinforced in text. For a zero-required-param observational tool this is sufficient, though a note on sampling duration cost would make it airtight.

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 pid, duration_seconds, and interval_seconds are already fully documented with defaults and bounds in the schema. The description adds no parameter-level meaning (e.g., cost trade-offs of short intervals), so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('CONTEXT-SWITCH sampling') and pins the scope ('the system or one PID'), so the agent knows exactly what is measured and at what granularity. The closing clause explicitly separates it from the sibling simulate_cpu_scheduling, which is the nearest lookalike in the toolset.

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 a clear when-not signal by naming simulation as the wrong mental model ('It is not a CPU scheduling simulation'), which correctly routes the agent away from simulate_cpu_scheduling. It stops short of telling the agent when to prefer this over sample_cpu_time_ratios or other observation tools, so no full alternative routing.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds genuinely useful behavioral context: this is repeated *polling* over an interval, not a one-shot read, and it is restricted to a single file. It still omits anything about rate/interval cost or what a poll cycle returns over time.

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 plus a scope-exclusion clause. The read-only, single-file constraint is front-loaded and every sentence carries distinct information; nothing is 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?

With an output schema present and rich annotations, the description needn't explain return values, and the scope/exclusion statements cover the main misselection risk. It is nearly complete for a 3-param tool; only the polling-semantics cost is left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so path, duration_seconds, and interval_seconds are already fully documented in the schema. The description restates the path requirement but adds no syntax, format, or bounds detail (e.g., polling cost of duration × interval) beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 precise verb and resource ('READ-ONLY polling of one FILE's size and timestamps') and explicitly scopes it to a single file, not a directory. The negative framing ('not a directory scan, access tracing, or a delete/modify operation') actively separates it from siblings like analyze_file_distribution.

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?

Makes the triggering condition clear: the agent must have the exact file path, and it is not a directory scan or a tracing/delete operation. It rules out whole classes of misuse but does not name a specific alternative sibling to use when a directory-level view is wanted.

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

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

Annotations already declare readOnlyHint, destructiveHint=false, idempotentHint=false and openWorldHint, so the safety profile is covered. The description adds that sampling is of live CPU time, but says nothing about blocking behavior, cost, or what happens across the duration/interval window. Adequate added context, not rich.

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 core purpose is front-loaded in one clause and the rest is a tight exclusion list with no filler. The enumerated exclusions are somewhat listy but each one serves a real disambiguation purpose against siblings.

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, return values need no explanation, and the description covers purpose plus sibling disambiguation for a two-parameter read-only tool. Only the absence of timing/behavioral notes for the sampling window keeps it from being 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?

Schema description coverage is 100% and both parameters carry bounds, defaults and units, so the schema does the heavy lifting. The description adds no syntax, unit, or interaction detail beyond what the schema already states; 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?

States a specific verb ('sampling') and resource ('live CPU user/system/idle percentages') and flags the READ-ONLY character up front. The explicit exclusions (job lists, RR/SJF, context switches, scheduling simulation) distinguish it cleanly from the many simulate_* and monitor_* siblings.

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?

Provides an unusually strong set of negative guidelines ('Never use for...', 'not context-switch monitoring, process control, or CPU scheduling simulation'), which routes an agent away from the wrong siblings. It stops short of a positive 'use this when' clause, but the purpose sentence supplies the selecting condition.

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

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

Annotations already declare readOnlyHint, destructiveHint=false, idempotentHint=false and openWorldHint, so the 'READ-ONLY' label largely restates them. The description adds that output is a time series over a requested duration (which implicitly explains why idempotentHint is false), but says nothing about sampling cost, blocking behavior, or whether limiting the duration affects fidelity. Net: modest value beyond annotations.

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, zero filler, with the operation and its identity front-loaded ahead of the exclusion list. Every clause carries routing 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?

An output schema exists, so return values need not be re-explained, and the schema bounds the duration/interval parameters. The only minor gap is that cost or behavior at the 30s maximum, and whether sampling blocks the caller, is left unstated for an openWorld, non-idempotent tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both duration_seconds and interval_seconds documented including defaults and bounds, so the schema carries the semantic load. The description adds no format or interaction guidance (e.g., how interval relates to total sample count), making 3 the correct 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?

States a specific verb and resource with scope: 'READ-ONLY time-series sampling of system memory'. The exclusion list ('not for a single snapshot, files, page algorithms, or processes') maps cleanly onto the sibling tools get_memory_info, analyze_file_distribution, simulate_page_replacement, and get_process_memory, so an agent can route 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?

Explicitly states the selecting condition ('Use for trends over a requested duration') and enumerates the cases where it should not be used, one per competing capability. This is a clear when/when-not statement with the alternatives identified by category.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that this is a 'pure simulation' with no effect on real processes, which is useful framing but largely restates what readOnly/closed-world hints already imply. No mention of determinism, output shape, or job-count limits.

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 guidance is front-loaded and short, but the second sentence ('The tool name must remain simulate_cpu_scheduling') is a meta-instruction that conveys nothing to an agent choosing a tool, and the ALL-CAPS opener is stylistic noise. Two of the four sentences could be trimmed without losing 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 full schema coverage, an output schema, and annotations covering safety and world-model, the description supplies the remaining needed context: what the tool computes, when to use it, and that it has no real-system side effects. Only the parameter elaboration and behavior under extreme job counts (maxItems 10000) are left implicit.

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% – jobs, algorithm (with FCFS/SJF/RR/PRIORITY and lower-priority-first semantics), and the RR time_slice default are all documented in the schema itself. The description sentence 'Include every requested job, the explicit algorithm, and RR time slice' echoes the schema without adding format or constraint 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?

It names a specific verb+resource (CPU job scheduling) and enumerates the exact algorithm choices (RR, SJF, FCFS, PRIORITY), which separates it from sibling simulators like simulate_page_replacement and simulate_disk_allocation. The ALL-CAPS 'CALL THIS EXACT TOOL' and the instruction to keep the tool name are noise rather than clarification, but the core purpose is unambiguous.

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

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

It gives a clear usage condition ('for RR, SJF, FCFS, or PRIORITY job scheduling') and an explicit exclusion: this does not inspect, stop, or modify real processes, which routes the agent away from real-process siblings like get_process_tree or monitor_context_switches. It stops short of naming those alternatives directly.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description reinforces this with 'simulation' and 'no real disk changes', and adds that arguments are flat, but discloses no extra traits such as complexity limits (maxItems 256) or failure behavior. With annotations carrying the burden, a 3 is appropriate.

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, front-loaded with the core identity and boundaries. Slight redundancy in enumerating the four arguments, which the schema already names, but it functions as a fast orientation and costs little.

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?

An output schema exists, so return values need not be explained, and the description covers purpose plus exclusions. It is nearly complete; only a positive usage condition and any note on simulation scale would add value.

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% – every parameter, including the strategy enum values and block defaults, is documented in the schema. The description only repeats the parameter names without adding format, valid values, or constraints, so baseline 3 is correct.

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+resource ('PURE DISK-BLOCK ALLOCATION SIMULATION') and immediately carves out what it is not, naming the page-reference algorithm case that distinguishes it from the sibling simulate_page_replacement. An agent can route between the two simulations without opening either 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?

It gives explicit when-not guidance ('Not for page-reference algorithms, directory scans, or real disk changes'), which is strong negative routing. It stops short of a positive 'when to use' statement or naming the alternative tool by name, so it is clear context rather than full alternative-routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's 'PURE' framing reinforces that this is a side-effect-free simulation and rules out live-memory effects, but adds no further behavioral detail (no scale limits, no runtime expectations).

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?

Front-loaded with the core identity, then exclusions, then required inputs — each sentence serves a purpose. The 'Required JSON keys' line is mildly redundant with the schema's required array and the line breaks make it slightly choppier than necessary.

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, return values need no explanation, and the algorithm set, exclusions, and required inputs are all covered. Eligibility constraints such as maximum reference-string or frame limits are left entirely to the schema, which is acceptable but leaves little margin.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and each parameter (algorithm, frame_count default/min/max, reference_string with example) is fully documented in the schema. The description only restates the two required keys already marked required in the schema, adding no new semantics, 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?

States a specific verb and resource ('PURE PAGE-REPLACEMENT SIMULATION') and enumerates the four supported algorithms (FIFO/LRU/CLOCK/OPT). It also explicitly carves out adjacent domains ('not for disk block allocation'), which separates it from the sibling simulate_disk_allocation without requiring schema inspection.

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 a clear usage condition ('Use only for a page reference string') and explicit exclusions ('not for disk block allocation, filesystem scans, or live memory'), which is strong routing guidance. It stops short of naming a specific sibling tool to use instead, so it is not quite a 5.

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