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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states only that the screen is captured but does not explain what the tool returns, whether it saves to a file, whether permission is needed, or any side effects. The optional save_path parameter hints at saving but is not described in the tool description.

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 concise sentence that directly conveys the tool's core purpose. It wastes no words and is appropriately front-loaded for a tool this simple.

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

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

Given there is no output schema, annotations, or return-value information, the description is incomplete for an agent to fully understand the tool's behavior. It does not explain what happens after capture, how the save_path is used, or what the tool returns, which are essential for correct invocation.

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

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

The input schema has full description coverage for the single optional save_path parameter, so the schema documents the parameter adequately. The tool description itself adds no parameter-level meaning beyond the schema, so a baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Capture' and the resource 'entire screen', which distinguishes it from siblings like capture_window and capture_region. However, it does not explicitly name alternatives or contrast itself with them beyond the scope phrase, so it falls short of a perfect 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 guidance on when to use this tool versus capture_window or capture_region. The description only implies that it is for full-screen captures, with no exclusions, conditions, or mention of alternative tools.

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 present, the description carries the full burden of behavioral disclosure, but it only restates the tool's name. It does not explain what happens to the captured image (returned vs. saved to disk), how the optional save_path interacts with behavior, which coordinate system is used, or how out-of-bounds coordinates are handled.

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

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

The description is one short, front-loaded sentence with no wasted words, which is structurally clean. However, it is under-specified rather than genuinely concise: a tool with five parameters, no annotations, and no output schema needs more substance to earn its place.

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

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

For a tool with 5 parameters, no annotations, and no output schema, a single clause is insufficient. Critical context is missing: return-value behavior, save_path behavior, coordinate system, and which sibling tools this replaces. An agent cannot fully determine how to invoke this tool correctly or interpret its result.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds marginal meaning by referring to a 'specific region,' which maps to the x/y/width/height parameters, but it does not clarify save_path semantics or whether capture returns image data when save_path is omitted.

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 ('capture') with a clear resource ('a specific region of the screen'), and the qualifier 'specific region' implicitly differentiates it from siblings like capture_fullscreen and capture_window. However, it does not explicitly name these alternatives, so an agent must infer the distinction.

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

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

No guidance is provided on when to use this tool versus capture_fullscreen, capture_window, or monitor_screen_region. The description offers no context, prerequisites, or exclusions, leaving the agent to guess which capture tool fits the task.

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 behavioral disclosure. It states the action and target but does not describe what the capture returns or where it is saved, whether window content is included, or any permission/visibility requirements. This leaves the agent with gaps about side effects and prerequisites.

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 containing only the essential action and selection criterion, with 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?

Given that no output schema or annotations exist, the definition should clarify the output behavior, such as a saved image path, and constraints like window visibility or permissions. It does not, so the definition is incomplete for a tool with no structured metadata to fill the gaps.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description's 'by app name' reflects the required app_name parameter but adds no new meaning about save_path or value formats.

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 'Capture', identifies the resource as 'a specific window', and includes the selection criterion 'by app name'. This clearly separates it from sibling tools like capture_fullscreen and capture_region.

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 'by app name' implies the tool should be used when the agent needs to capture a window belonging to a known application. However, it does not explicitly mention alternatives or state when not to use this tool over capture_fullscreen or capture_region, leaving usage guidance implicit.

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 full responsibility for behavioral disclosure. It only says 'click' without mentioning potential side effects, such as triggering UI actions, moving the mouse pointer, or the fact that it mutates the system state by performing a real click. This is a significant transparency gap.

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

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

The description is a single, front-loaded sentence with zero filler. Every word earns its place.

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

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

For a simple tool with a fully described schema, the description is adequate but minimal. It lacks any note about return behavior, side effects, or when to use it, which leaves some context for an agent to infer. It is not incomplete enough to be confusing, but it could be richer.

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

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

Schema coverage is 100% and each parameter already has a clear description. The description adds no additional meaning beyond the word 'position', which maps to the x/y parameters. Baseline 3 is appropriate.

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

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

The description states a specific verb ('click') and resource ('screen position'), making the tool's function immediately clear. It implicitly distinguishes itself from the sibling capture/inspection tools, but does not explicitly reference them, so it stops short of a perfect 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?

No explicit when-to-use or alternative guidance is given. Usage is implied by the description and the sibling tool names, which are all capture or search operations, but the description itself provides no context about when to choose this tool over others.

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 behavioral disclosure. It only states the high-level behavior (screen capture + OCR) and omits important traits such as the return format, permission requirements, coordinate system for the region, or whether any temporary files are created.

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 focused sentence that front-loads the action and includes the key differentiator (OCR). There is no filler or redundancy; 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?

Given the lack of an output schema and annotations, the description is incomplete. It does not specify what the OCR output looks like, how region coordinates relate to the screen, or any side effects and permissions, leaving an agent with significant uncertainty about the tool's full 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?

The tool description adds no parameter-level meaning beyond the schema, but the schema itself fully documents the only parameter, region, including its optionality and default behavior. With 100% schema description coverage, the baseline of 3 is appropriate.

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

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

The description states a clear action: capture the screen and extract text using OCR. It names the resource (screen) and the operation (OCR text extraction), which distinguishes it from the capture-only sibling tools, though it does not explicitly contrast with them.

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

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

There is no guidance on when to choose this tool over alternatives like capture_region or find_text_on_screen. The description only implies use when text extraction is needed, with no explicit context, prerequisites, or exclusions.

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. It discloses the core behavior — searching the screen and returning a location — but it does not define what 'location' means (e.g., x/y coordinates, bounding box), how multiple matches are handled, or whether it relies on OCR.

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 sentence with no filler: the action and return value are front-loaded. It is appropriately sized for a simple two-parameter tool.

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 simple, but there is no output schema, so the description should clarify the return value format. Saying 'location' is incomplete for an agent that may need to pass coordinates to click_at_position, and the description does not disambiguate from extract_text_from_screen.

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

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

Schema description coverage is 100%, so the baseline is 3 and no additional parameter documentation is required. The description adds no parameter-specific detail, but the schema already fully describes 'text' and 'case_sensitive'.

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

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

The description states a specific action ('find text on screen') and its result ('return its location'), which is clearly distinct from the sibling capture and text-extraction tools. It does not explicitly contrast with extract_text_from_screen, but the search-and-locate behavior is identifiable.

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 'find text on screen' implies use when the agent needs to locate a specific string rather than extract all text or capture the screen. However, there is no explicit when-to-use guidance, exclusion criteria, or mention of sibling alternatives.

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

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

No annotations are present, so the description carries the full burden. 'Get information' clearly signals a non-mutating read-only operation, and 'available screens/displays' adds scope. However, it does not describe the return format or what specific screen properties are exposed, which matters because there is no output schema.

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

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

The description is a single front-loaded sentence with no filler, tautology, or unnecessary detail. For a simple zero-parameter read-only tool, this is an appropriate size.

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 definition is adequate for invoking a no-argument tool and understanding that it returns display information. But with no output schema, it leaves the nature of that information vague, such as whether it includes bounds, resolutions, or display names.

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?

There are zero parameters and 100% schema coverage, so there is nothing for the description to clarify. This matches the baseline score for a no-parameter tool.

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

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

The description states a clear action and resource: it retrieves information about available screens/displays. It is distinguishable from capture, click, and window-list siblings because it is a read-only query, though 'information' is left somewhat underspecified.

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: call this when you need details about available displays rather than capturing the screen, extracting text, clicking, or listing windows. However, the description never explicitly says when to prefer this over siblings like get_window_list or monitor_screen_region.

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 of explaining behavior. It correctly indicates a read-only listing operation, but it does not disclose the output format, coordinate system, or whether minimized/hidden windows are included. Basic transparency exists, but meaningful details are missing.

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 efficient sentence with no wasted words. The core action and result are front-loaded and immediately actionable.

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, simple listing tool, the description covers the essential purpose. There is no output schema, so a bit more detail about the returned data structure or coordinate format would improve completeness, but the current level is adequate for correct invocation.

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

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

The tool has zero parameters, so there are no parameter semantics to clarify. The baseline of 4 applies because no parameter documentation is needed.

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 ('Get list'), a clear resource ('all open windows'), and the returned detail ('with their positions'). This clearly distinguishes it from siblings like capture_window or get_screen_info.

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

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

The description implies usage when an agent needs to enumerate open windows, but it gives no explicit guidance about when to prefer this tool over alternatives or any exclusions. The intended context is reasonably inferable but not 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?

There are no annotations, so the description bears the full burden of disclosing behavior. 'Monitor' implies repeated checking over time, but the description does not state whether the call blocks, polls continuously, stops after duration_seconds, or what it returns when a change is detected.

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 focused sentence with no filler, and the core action is front-loaded. It is appropriately concise, though the brevity contributes to under-specification in other dimensions.

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, no annotations, and six parameters including timing controls, this one-line description is not complete enough for reliable invocation. An agent is left to guess the return value, coordinate semantics, and what 'changes' means in terms of output or termination.

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 only 33% and the description does not compensate. 'Screen region' loosely maps to x, y, width, and height, but the description omits coordinate origin, units, and any meaning for interval_ms or duration_seconds beyond the schema's own minimal text.

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 pair ('Monitor a screen region') and the purpose 'for changes', which distinguishes it from sibling one-shot capture tools like capture_region. It doesn't explicitly name a sibling, but the wording is sufficient to convey the core operation.

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 'for changes' implies the tool should be used when change detection is needed rather than a one-off screen capture, but no explicit when-to-use or when-not-to-use guidance is given. Alternatives such as capture_fullscreen or capture_region are not mentioned.

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