imgui_export_cpp

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

No annotations are provided, so the description carries full disclosure burden. It correctly states this is a generation/export operation (non-destructive, reads current layout and produces code). It mentions the output format (C++ code) and scope (all windows and widgets with current values), which is reasonable transparency. However, it doesn't mention potential side effects (could it overwrite a file at path?), limitations, or fidelity guarantees of the generated code.

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, front-loaded with the primary action and scope. Efficient and gets the core purpose across immediately. Could add a tiny bit more differentiation but is concise and clear as-is.

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 conceptually simple (1 optional param, no output schema, no nested objects), and the description covers the primary behavior. However, it doesn't compare against the format-related siblings (export_lua, export_json), which would be valuable for tool selection. For a simple export tool, the description is adequate but leaves the format-selection guidance to the agent's inference.

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% (1 param, the 'path' with a clear description). The schema already explains that 'path' is optional and code is returned inline if omitted. The description adds the context that the output is C++ ImGui code, which partially relates to what gets generated. However, the description doesn't add details beyond what the schema prefix 'Optional file path to write the C++ code to' already covers—with full schema coverage, 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+resource ('Export current UI layout as C++ ImGui code') with a clear scope ('recreates all windows and widgets with their current values'). It's clearly distinct from sibling tools like imgui_export_lua and imgui_export_json, which export to different formats. Loses a point for not explicitly naming these alternatives in a way that differentiates format selection criteria.

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 purpose implies usage context (exporting to C++ format), but there's no explicit guidance on when to choose C++ over Lua or JSON exports. No mention of when this is appropriate (e.g., code generation for embedding, offline copying) versus when the other export formats are preferred. The use of the optional path parameter is clear but not elaborated.

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