Capture OBS screenshot

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

Annotations already mark the tool as readOnly, idempotent, and non-destructive. The description adds that it returns MCP image content directly, and that omitting a source captures the current program scene. These details go beyond annotations and inform the agent about output format and default behavior, which is valuable. No contradictions with 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?

The description is two sentences, front-loaded with the core action and return type, followed by a useful default behavior. No unnecessary words; every part adds value.

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 six parameters, none required, and low schema coverage. The description does not explain width, height, format, or quality, nor does it mention potential error conditions. However, the output schema likely describes the image return, and the tool is relatively simple. Still, with low schema coverage, the description should have provided more parameter guidance to be 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 only 33% (only sourceName and sourceId have descriptions). The description does not compensate for the undocumented width, height, format, and quality parameters. It only clarifies that source can be a scene or input, which is already partially in the schema descriptions. With low schema coverage, the description should have explained the meaning and defaults of the other parameters, but it does not.

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

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

The description clearly states the tool captures a scene or input via OBS GetSourceScreenshot and returns it as MCP image content for AI vision. It specifies the resource (scene/input) and the action (capture), and notes the default behavior when no source is given, which distinguishes it from all sibling tools that manage scenes/inputs but do not capture screenshots.

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 explains the fallback behavior when no source is specified, which is a usage guideline. It does not explicitly list alternatives, but since this is the only screenshot tool among siblings, that omission is acceptable. It could have stated 'use when you need a visual snapshot' but the mention of 'for AI vision' implies the use case.

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