Godot Runtime Screenshot

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 doesn't state whether the project must be running, what happens if no project is running (does it fail silently?), what the screenshot captures (viewport vs full window), or how the image is returned (base64 blob? file path?). The 'from the bridge' phrasing is vague about threading/blocking behavior.

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

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

Single sentence, zero fluff. The description is appropriately brief for a tool with minimal surface area (one optional parameter). However, the brevity leans toward under-specification rather than polished conciseness—there's room to add a useful clause about return format without bloating it.

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 this is a runtime action with zero annotations and no output schema, more context is warranted. It doesn't clarify prerequisites (running project), failure modes, or deliverable format. The single optional parameter is simple, keeping the completeness need low, but the behavioral unknowns leave a meaningful gap for an action-type tool.

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

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

Schema description coverage is 0%, meaning the parameter is undocumented in the description. There's one optional parameter 'encoding' with an enum (base64/data-uri), which is self-explanatory. Since there's only one optional enum parameter that's fairly obvious from its name and value choices, the schema carries most of the meaning. A baseline 3 is appropriate—the description adds no explicit parameter value beyond the enum names.

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 'Fetch a runtime screenshot from the bridge' states a clear verb+resource (fetch screenshot from the bridge). It's reasonably clear it captures a visual snapshot of the running game, but it doesn't clarify what aspect is captured (viewport? whole window?), where it saves, or whether it blocks until capture succeeds. The purpose is understandable but somewhat terse.

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 on when to use this tool versus alternatives. Sibling tools like godot_runtime_status, godot_runtime_logs, and godot_runtime_perf all relate to runtime inspection, and the description doesn't explain when a screenshot is the right choice (e.g., when visual state matters) versus when another runtime tool would be more appropriate. No when-not-to-use guidance and no mention that a project must be running.

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