figma_capture_screenshot

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

Annotations declare readOnlyHint: true, which is consistent with taking screenshots. The description details behavioral traits like token cost for base64 (~30K tokens), automatic fallback to summary when context usage >80%, and region splitting strategies (children vs slices). This goes well 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?

The description is compact and front-loaded with the core concept. However, it mixes English and Turkish (e.g., 'dosyaya yazar, base64 context'te YOK') which may reduce clarity for non-Turkish agents. Still, every sentence provides value and it's structured logically.

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 11 parameters, no output schema, and only readOnlyHint annotation, the description comprehensively covers all modes, fallback behavior, region strategies, and parameter details. It is sufficient for an agent to correctly invoke the tool without additional context.

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?

Despite 73% schema description coverage, the description adds crucial context for parameters like returnMode (explains each enum value beyond the schema description), regionStrategy (distinguishes children vs slices), and parameters like maxRegions, sliceHeight, requestedSlices—all clarified with concrete usage. The decision tree and token cost info are additive.

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 defines the tool as a screenshot capture tool with 4 return modes, distinguishing each mode's purpose. It goes beyond just stating the name by providing specific use contexts (planning, delivery, scroll screens) and contrasts with siblings through explicit mode selection guidance.

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 provides an explicit decision tree (planning→summary, delivery→file, scroll→regions, last resort→base64) and mentions context-aware fallback when context usage is high. This gives clear when-to-use and when-not-to-use guidance, fully addressing usage guidelines.

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