godot_call

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

Annotations already indicate destructive and non-idempotent behavior, so the bar is lower. The description adds meaningful behavioral context beyond annotations: node_path parameters can accept session handles that survive renames/reparents but go stale on scene reload, and async mode returns a job_id for long operations. This clarifies real operational edge cases.

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 front-loaded with the core purpose, then guides the agent to the correct discovery tools, then explains the nontrivial handle behavior and async usage. Every sentence earns its place, and there is no redundant restatement of the schema or annotations.

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?

For a generic dispatch tool with no output schema, the description is quite complete: it explains how to discover methods, how to get parameter schemas, how to handle long operations, and the special node_path handle semantics. It does not explicitly state that a non-async call returns the method's result, but this is largely implied and hard to specify generically.

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%, so the baseline is 3. The description adds genuine value by explaining the special handle syntax for any node_path parameter, the async boolean's behavior, and pointing to godot_describe for method-specific params. This goes beyond what the schema alone communicates.

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 action ('Call any method') on a specific resource ('the Godot editor addon'). It also distinguishes itself from the sibling tools by pointing to godot_list_methods and godot_describe as exploration/preparation tools, making it clear godot_call is the execution entry point.

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 gives clear context: use godot_list_methods to browse and godot_describe for parameter schemas, and use async for long operations that would exceed the 30s timeout. However, it does not explicitly discuss when to prefer godot_call over other execution-like siblings such as godot_execute, so it lacks full exclusion guidance.

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