godot_get_project_settings

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds only that the tool reads from the project.godot file and which categories of settings can be expected. This is a small but real addition; there is no deeper disclosure of behavior such as what happens when no section filter is given, but the annotations carry most of the weight.

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?

One sentence, zero waste: the verb and resource come first, and the parenthetical adds informative examples without padding. The description earns its place and remains perfectly scannable.

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 read-only tool with rich annotations, well-documented parameters, and a existing output schema, the description is largely sufficient for safe invocation. The main gap is the huge sibling set of config-related tools (setters and dedicated getters for autoloads/plugins/export presets), so an explicit cross-reference such as 'to modify settings use godot_set_project_setting' would have made it more complete.

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?

With schema description coverage at 0%, the description was supposed to compensate, but it barely does. The parenthetical examples overlap with the section parameter examples already present in the schema ('application', 'display/window'), and it says nothing about the response_format parameter or the option to filter by prefix. The schema itself provides good parameter docs, so the description adds negligible value beyond it.

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 clear verb and resource ('Query settings from project.godot') and gives helpful examples of what settings are covered ('application name, display, physics'). It is easily recognizable as a read-only config getter, but it does not explicitly differentiate itself from similar sibling getters such as godot_get_export_presets or godot_get_autoloads, nor from its write counterpart godot_set_project_setting.

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 no guidance on when to use this tool versus alternatives — no mention of the corresponding setter, no 'use when reading project config before modifying', and no exclusions such as 'for export presets, use godot_get_export_presets'. Usage has to be inferred entirely from the tool name and the word 'Query'.

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