cpp

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

Beyond the annotations (write-side effect, idempotent, non-destructive), the description adds important behavioral detail: it explicitly says '不联网/不编译' (no network, no compile), so the agent knows the output is a source skeleton only, not a built extension. It also names the expected generated files.

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 dense but front-loaded with the key purpose, followed by the artifact list and constraining behavior. There is no filler. Slightly long, but each clause carries meaning. It could be split into a clearer, structured layout, but it remains concise.

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 description is largely sufficient for a scaffolding tool, especially considering a fully schema-documented input. It covers the output scope, generated files, and non-network/non-compile behavior. The force/overwrite semantics are handled by the schema itself. It could add a sentence about choosing between this and the other generation-related tools, but that is a relative weakness rather than a completeness gap.

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 schema has 100% description coverage, including enums, defaults, and parameter-level comments for all 6 parameters. The description itself only reinforces that project_path is the generation root. It does not need to add much more, so a 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 identifies a specific operation ('scaffold_gdextension') with a specific verb ('生成') and resource (godot-cpp GDExtension project skeleton), and lists concrete artifacts. It clearly differentiates from generic sibling tools such as script or project via the C++/GDExtension scope, though it never names alternatives explicitly.

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: use this tool to scaffold a C++ GDExtension project. It does not explicitly state when to use it versus the sibling script/project tools, nor does it mention exclusions. The 'C++ GDExtension' framing gives a defensible context but leaves comparison to alternatives implicit.

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