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

With no annotations, the description carries the full burden; it does disclose the destructive outcome (partial file deletion), which is the most important trait. It does not say whether the file is recoverable, what happens if no recording is active, or whether permissions are required.

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 short sentence with the action and its consequence 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?

An output schema exists, so return values needn't be explained, and for a zero-param mutating tool the description covers the essentials. Only edge-case behavior (no active recording) 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, so the schema provides everything needed and there is nothing for the description to compensate for. Baseline 4 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 (stop the running recording) plus a distinct consequence (delete the partial file). That consequence is what separates it from the sibling stop_recording, though it never names that sibling 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 word 'partial' implies this is for discarding an unwanted take, which hints at when to use it, but there is no explicit guidance on when to prefer it over stop_recording, nor any prerequisite or exclusion.

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. It does not say that the call writes a file to disk, whether an existing file at the destination is overwritten, whether conversion is slow or resource-intensive, or what happens if the recording is still in progress — all material for a side-effecting 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?

A single front-loaded sentence with no filler, expressing action and result compactly. However, that brevity leaves no room for the prerequisite and parameter detail the tool actually needs.

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 spelled out. But for a file-producing tool with zero annotation coverage and three undocumented parameters, the description omits essential context: preconditions, output location semantics, and the quality/size tradeoff.

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 three parameters, and the description names none of them. The purpose of `output` (destination path vs. directory) and the tradeoff controlled by `high_quality` (quality vs. file size) are completely undocumented, as is the expected form of `recording_id`.

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 (convert) and resource (a recording → animated GIF), which clearly separates it from the recording-lifecycle siblings like trim_recording or start_recording. It doesn't explicitly name a sibling or contrast with one, 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?

There is no statement of when to use this tool, no prerequisites (e.g., whether the recording must be stopped or trimmed first), and no alternatives mentioned. The only usage signal is the required recording_id, which the agent must infer from the schema.

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 does disclose two useful behavioral facts: the result ordering (newest first) and the inclusion of manual recordings. It does not state pagination behavior, whether there is a maximum page size, or the read-only nature beyond the implied 'history' framing.

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 short sentence with the key facts (resource, ordering, scope) front-loaded and no filler. It is a fragment rather than a full sentence, but nothing is wasted.

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-value explanation is not required, and the scope/ordering notes give context. However, for a paged list tool with an undocumented limit parameter, the description should say how to retrieve more history and how it differs from recording_status.

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% for the single 'limit' parameter, which only has a default of 20 in the schema. The description never explains what limit controls, what happens when it is omitted or exceeded, or how to page through older history, so it fails to compensate 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?

The description names the resource (recording history) and its ordering (newest first), and the scope note 'including recordings the user made by hand' implies auto-generated recordings are also included, which distinguishes it from status-oriented siblings like recording_status. It reads as a noun phrase without an explicit verb, but the resource 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?

There is no statement of when to use this tool versus recording_status (current state) or list_targets, and no prerequisites are mentioned. The agent must infer that this is the historical listing tool 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, the description carries the burden, and it does disclose two real behavioral traits: results are ordered front-most first, and monitors are identified as `monitor:N`. It does not state that this is a read-only, side-effect-free call, nor anything about when the target list changes.

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 no filler, front-loading the resource and appending the two facts an agent needs (ordering and monitor ID format). Nothing is wasted.

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 and the tool is parameterless, so return values need not be spelled out; ordering plus ID format covers what the schema won't. It would be complete at 5 if it noted these targets are the inputs to pick_region/start_recording.

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 baseline is 4; there is nothing to document. The description still usefully explains the shape of returned identifiers (`monitor:N`), which helps interpretation even though no inputs exist.

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 two concrete resources (recordable windows and monitors), and the parenthetical clarifies the identifier format `monitor:N`. It is clearly distinct from sibling list_recordings, though it never explicitly contrasts itself with the other listing 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?

There is no stated when-to-use, no prerequisites, and no mention of which siblings (pick_region, start_recording) consume the returned targets. Any guidance is inferred only from the fact that it is a list tool.

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. It does add one genuine behavioral fact — paused time is excluded from the recording — but says nothing about state restoration on resume, error behavior when nothing is recording, or whether the call is idempotent.

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 sentence that front-loads the action and appends the one behavioral consequence that matters. No wasted words.

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 state-toggle tool with an output schema handling return values, this is nearly sufficient. The remaining gap is precondition/error behavior when no recording is running.

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. Nothing about parameters needs explaining and the description correctly stays silent on them.

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 ('Pause the running recording'), which clearly distinguishes it from sibling pause/resume lifecycle tools like resume_recording and stop_recording. It doesn't explicitly name those siblings, but the lifecycle semantics are 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?

The phrase 'the running recording' implies a precondition that a recording must already be in progress, but the description never names resume_recording or stop_recording as alternatives or states what happens if no recording is active.

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 well: it discloses that the overlay is semi-transparent, that the OS may refuse to raise the target app, and that Esc yields null. It omits blocking/timeout behavior and any permission requirements, which are the remaining gaps for an interactive screen-grab 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?

Front-loaded with the single most important fact (a user-driven overlay), followed by short indented notes on target format, return value, and the focus caveat. No filler sentences; each line carries distinct 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, yet the description still usefully clarifies the null-on-Esc semantics, and it covers the target format and the OS focus failure mode. Missing are the interactive/blocking contract and permission notes, but for a single-parameter tool this is close to sufficient.

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

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

Schema coverage is 0%, and the description fully compensates by enumerating the accepted forms for `target`: window title, process name, window_id, or `monitor:N`. It does not explain how to obtain a window_id (a sibling, list_targets, presumably supplies them), which keeps it short of a 5.

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?

First sentence names a specific action (drag-to-crop overlay) and makes the human-in-the-loop nature explicit: 'the USER selects the area.' That distinguishes it from automated siblings like start_recording or list_targets without naming them, so it is clear but not sibling-differentiated by name.

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 one real precondition ('tell the user to keep the app visible before calling this') and implies the interactive step precedes recording, but never states when to prefer this over starting a recording with no region, nor that list_targets should be used to resolve a window_id. Usage is implied rather than spelled out.

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 behavioral burden. 'Report' implies a read-only operation and it discloses the key status fields, but it does not explicitly state non-mutation, permissions, error behavior, or whether it works only during an active recording.

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?

It is a single sentence that front-loads the core purpose and packs useful return-field information without waste.

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 an output schema and no parameters, so the description need not explain return values in detail. It adequately names the status contents, though it could clarify lifecycle context such as behavior when no recording is active.

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 schema parameter semantics are not a concern. The description appropriately does not invent parameter details.

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 ('Report') and resource ('running recording') and enumerates the status fields returned. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as list_recordings or the lifecycle controls.

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 'running recording' implies the tool is for checking an active recording, but there is no explicit guidance on when to use it versus list_recordings or other recording tools. No exclusions 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 are provided, so the description carries the full burden of disclosure. It conveys only that the action resumes a paused recording, and it does not state permissions required, error behavior when there is no paused session, whether the call is idempotent, or any other state effects beyond the obvious mutation.

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 one-sentence description is front-loaded with the verb and has no wasted words. It is tightly sized for a zero-parameter action, though it is arguably under-specified in ways that are out of scope for 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?

Because this is a simple zero-parameter state change with an output schema, the description does not need to explain return values. It is still missing the precondition and failure behavior that an agent would need in order to call this tool correctly alongside start_recording, pause_recording, and recording_status.

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 correspondingly empty, so there is nothing for the description to explain. The baseline for zero-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 names a specific verb (resume) and resource (recording), and the word 'paused' narrows the scope of the action. It does not explicitly contrast itself with the closest sibling, start_recording, so it falls short of full sibling differentiation.

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 'a paused recording' implies a precondition: a recording must already be paused before calling. The description gives no explicit when-to-use guidance about choosing resume over start_recording, and it never states what happens if no paused recording exists.

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 real work: it explains GPU-first with CPU fallback, that cpu capture is Windows-only and produces no cursor in the video, and that delay_seconds is a user-visible countdown and the desktop toolbar may appear. It omits failure/error behavior and where files land by default, keeping it out of the top band.

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 one-line purpose is front-loaded and the per-parameter bullets are terse and scannable, with no filler prose. The trailing note about the desktop toolbar is loosely related but slightly detached from the calling task.

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, but for an eight-parameter capture tool with zero annotation coverage the description leaves fps, output_dir and capture_cursor unexplained and never says how to reference or retrieve the finished recording (list_recordings/stop_recording). Adequate to initiate a basic call, insufficient for full control.

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 — and it does for five of eight params, adding syntax the schema lacks (`monitor:N`, region relative to target, audio enum values, capture mode semantics, visible countdown). However fps, output_dir and capture_cursor are never mentioned, leaving a substantial gap on a multi-param 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?

Opens with a specific verb, resource and output format: "Start recording a window or monitor to MP4 (H.264)." It immediately distinguishes scope (window vs monitor) and defers target enumeration to the named sibling list_targets, so an agent can separate it from pause_recording/stop_recording 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?

Gives concrete when-to-use routing: targets come from list_targets, regions "usually from pick_region," and audio should be set only when the user asked for it. It stops short of explicit exclusions (e.g., don't call this if a recording is already active — use recording_status), so it is a clear-context 4 rather than a full 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?

No annotations are provided, so the description carries the full disclosure burden. It usefully implies the file is finalized and its path returned, but it does not say whether the output file is retained afterward, what happens on an idle recorder, or what the returned `output` looks like if encoding is still in flight.

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 the action and its result; no filler, no redundancy. Nothing could be cut 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?

For a zero-parameter, single-purpose tool with an output schema, the description covers the essentials, and the output schema handles the return shape so it need not be elaborated. The only real gap is the lack of differentiation from sibling stop/cancel/pause operations.

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 there is nothing for the description to disambiguate. Baseline 4 applies 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 gives a specific verb and resource ("Stop the running recording") plus the side effect (returns the final MP4 path). It is clear in isolation, but it does not distinguish itself from the closely related siblings cancel_recording and pause_recording, which an agent will need to choose between.

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 "the running recording" implies a prerequisite state (a recording must be active), which is useful implied guidance. However, there is no explicit statement of when to choose this over pause_recording or cancel_recording, and no note about what happens if nothing is recording.

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; it does disclose the key non-destructive trait that a new file is saved and the original kept. However, it omits permission/auth requirements, failure modes (e.g., invalid range, missing recording), and whether the output format/codec is preserved, leaving material behavioral questions unanswered for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence, front-loaded with the operation and range, followed immediately by the most important side effect (new file, original kept). No wasted words.

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 details needn't be explained, and the non-destructive behavior is a useful addition. But for a 3-parameter mutation tool with zero annotation and zero schema description coverage, the description does not cover preconditions, validation rules, or recording_id semantics, so it is only adequate rather than 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 0%, so the description must compensate. It names the range bounds implicitly, but says nothing about recording_id, whether bounds are inclusive, units (seconds are implied by parameter names but not stated in the description), or validation such as start < end.

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 ('Cut a recording') plus the exact range semantics via '[start_seconds, end_seconds]'. It is clearly distinct from the lifecycle siblings (start/stop/pause/export), though it does not explicitly name an alternative or boundary case.

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, when-not-to-use, or alternative guidance. An agent can infer that this is for extracting a sub-range of an existing recording, but nothing clarifies prerequisites (e.g., must the recording be stopped first, does it need to be finalized) or relationships to siblings like export_gif.

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