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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine behavioral value by disclosing what is returned (uid, размер, признак импорта) and that mode=references scans text files, but it says nothing about the 2000-item limit, pagination, or how each mode behaves.

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?

Two compact sentences, front-loaded with the primary search behavior and appending the references capability second. No filler, though the parenthetical type list makes the first sentence dense.

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 7-parameter tool with 0 required params, no output schema, and only 57% schema coverage, the description covers the search and references paths but leaves the `info` mode, default directory, limit behavior and meta inclusion unexplained. Adequate but with clear gaps.

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 57% schema description coverage, the description roughly meets the baseline and adds real value for `type` by enumerating concrete Godot resource classes (Texture2D, PackedScene, Script, AudioStream, Font, Shader) beyond the schema's single example. But `mode`, `limit`, `include_meta` and `query` receive no semantic explanation in either place, and the undocumented `info` mode is never mentioned.

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?

Names a specific verb (поиск) and resource (ассеты проекта) and enumerates the two axes of search (имя/путь и тип ресурса), plus the returned attributes. It does not, however, differentiate itself from close siblings like godot_files or godot_resource, so an agent must guess which tool owns file/resource lookup.

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 hints at a second usage path ("Дополнительно mode=references находит..."), which implies when the references mode applies, but it never states when to prefer search vs info vs references, nor how this tool relates to godot_files/godot_resource. Usage is only implied.

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

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

Annotations already declare read-only, non-destructive, closed-world. The description adds that class structure comes from ClassDB and is accurate/current, and that search covers global project classes, which is useful context beyond annotations. But it does not disclose build_api_index behavior and misdescribes documentation as a mode rather than the include_docs flag.

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 dense paragraph, front-loaded with the tool's purpose and then each mode. No filler; parenthetical details are compact. Slightly cluttered but efficient.

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?

9 parameters with 56% schema coverage and no output schema. The description should document all modes and parameters but misses build_api_index, confuses modes with the include_docs flag, and leaves kinds/limit/sections unexplained. Too incomplete for a tool of this complexity.

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 56%. The description explains the mode parameter values but contains an error: mode=docs does not exist (include_docs boolean does), and build_api_index is never mentioned. Parameters kinds, limit, and sections remain undocumented in both places. Partial compensation only.

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?

States it is a reference for engine classes and breaks down what each mode returns (methods/properties/signals for info, API-wide search, enum values, inheritance). Clear verb+resource, distinguishable from project-oriented siblings. However it references a nonexistent mode=docs and omits build_api_index, which slightly muddies the purpose for an agent.

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?

Gives explicit mode-by-mode guidance: mode=info for class structure, mode=search for API queries, mode=props for enum values, mode=inheritors for inheritance. No explicit when-not or sibling comparisons, but mode dispatch is well covered. The missing build_api_index and spurious mode=docs reduce reliability.

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

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

Adds real behavior beyond the annotations: the environment prerequisite and an explicit warning that mode=install_bridge modifies the project. But annotations declare destructiveHint=true and readOnlyHint=false, and the description never separates the genuinely mutating modes (save, reload, edit_scene, run, stop, install_bridge) from the read-only ones (status, log, screenshot) — the most useful per-mode safety signal.

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?

A single dense sentence, front-loaded with the prerequisite and the modification warning before the mode enumeration. Every clause carries information; the mode list is long but each entry is needed since the enum alone conveys no semantics.

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?

No output schema exists, so return values for status, log, and screenshot are undocumented, and the description never maps which parameters each mode requires (path for open_scene, limit for log, ops for edit_scene). Adequate for choosing a mode, insufficient for predicting or validating results.

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 only 40%, so the description has to compensate, and it does well for the dominant parameter by spelling out all ten mode values. It adds nothing for limit and timeout_ms, and path/ops are handled by the schema text, leaving a partial gap.

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?

States a specific verb+resource ('Управление редактором через аддон-мост') and enumerates every mode with its meaning, so an agent can tell what each call does. However, it never differentiates itself from siblings that overlap heavily (godot_screenshot, godot_logs, godot_scene), which is the only reason it falls short of a 5.

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?

Gives a concrete precondition — a running editor with the Bismuth MCP Godot Bridge plugin — which is the key gating context an agent needs before calling. It does not, though, say when to prefer this tool over godot_scene/godot_logs/godot_screenshot for the same operations.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false, so the safety profile is covered structurally. The description adds mode-level behavior (export writes pack or binary, tests run headless with output parsing) but never warns that export overwrites the file at 'target' or explains the destructive/idempotency implications, leaving a gap for a destructive tool.

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?

A single compact sentence whose clauses are ordered by mode, front-loading the mode enumeration so the agent hits the decision-relevant information first. No filler or redundancy.

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?

With no output schema, the description should carry more of the return and failure story (e.g., what 'разбором вывода' yields, exit codes, overwrite behavior on target). It covers the mode semantics adequately but is thin for a destructive, 7-parameter build tool.

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 71%, and the description meaningfully expands the undocumented enum values (presets/export/test), links pack vs binary to pack_only, and references a custom runner corresponding to test_command. It does not touch timeout_ms, release, or the preset-index convention that the schema itself notes.

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 names the tool's resource (Сборка/build) and enumerates all three operational modes with concrete verbs: listing presets, exporting by preset as pack or binary, and running headless tests. It is clear what the tool does, though it does not differentiate itself from siblings like godot_run or godot_script_check that could also execute things.

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?

Usage is implied by the mode breakdown — an agent can infer that mode=test is for running tests and mode=export for producing builds — but there is no explicit when-to-use statement, no guidance on which mode fits which task phase, and no mention of alternatives such as godot_run for non-export execution.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds real behavioral context beyond them: write auto-creates directories, restore pulls from a .mcp-backups store, and path traversal outside the project root is blocked. It does not say when backups are produced or how append interacts with write.

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 tight paragraph, front-loaded with the resource and then a scannable mode-by-mode breakdown. No filler; the sandbox rule is placed last as a constraint. Slightly dense but every clause carries information.

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 13-param, destructive, no-output-schema tool the description leaves notable gaps: the 'stat' mode present in the enum is never explained, and semantics for append, limit and backup lifecycle are absent. It covers the main modes adequately but is not complete for correct invocation of all paths.

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 only 46% across 13 params, so the description has to carry weight. It adds meaning for include globs and read's line-range concept, but leaves limit, append, exclude, max_bytes, max_depth, recursive and directories undocumented, so it only partially compensates.

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 resource (project files) and enumerates four of the tool's modes with concrete behavior (list tree, read text, write creates dirs, restore from backup), which makes the tool's remit distinguishable from sibling file tools. It stops short of explicitly naming which sibling (e.g. godot_script, godot_scene) to use for script/scene-specific work.

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?

By mapping each mode to its task the description implicitly tells the agent when to pick list vs read vs write vs restore. However there is no explicit when-not or alternative routing against the many overlapping siblings (godot_script, godot_scene, godot_assets), which is the main ambiguity left.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the return shape (PNG block plus size/format info) and resize behavior, but it does not spell out the side effect of writing a PNG to the `out` path, which sits awkwardly against the read-only hint.

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?

Two sentences, front-loaded with the return behavior before the parameter note, with no filler. Slightly dense parenthetical, but every clause earns its place.

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?

With no output schema, the description correctly takes on the burden of describing the return (PNG block plus size/format summary), and it covers the one undocumented parameter. What remains thin is the file-output side effect and any relation to sibling tools, but for a simple read-and-render tool this is close to 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?

Schema coverage is 67% and the `size` parameter has no schema description at all; the description compensates by defining it as a square resize where 0 means no change. `path` and `out` are already documented in the schema, so the description fills the meaningful gap without redundancy.

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 and resource — it returns a project texture rendered as a PNG block plus size/format metadata — which distinguishes it from generic siblings like godot_status or godot_files. It does not explicitly separate itself from godot_screenshot, the closest sibling, so it stops short of a 5.

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?

It supplies a use case ('визуальная проверка спрайтов, иконок, атласов'), which implies when to reach for it, but never states when not to use it or names an alternative such as godot_screenshot or godot_assets. Usage is inferred rather than directed.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, readOnlyHint=false, so the mutation profile is covered. The description adds real context beyond that: input is simulated inside the engine rather than via the OS, and it functions even in headless mode. It does not explain reversibility or the required step to actually advance the game, but the core behavioral trait is disclosed.

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?

Dense but front-loaded: the purpose and the headless/no-OS constraint come first, followed by the mode list and the follow-up step. Every sentence carries information, though the mode enumeration runs together without clear grouping.

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 13-parameter tool with no output schema and low schema coverage, the description covers the modes but leaves parameter-to-mode applicability unstated and never mentions the response. It is usable but leaves real gaps an agent must guess at, e.g. what pressed/strength mean for joy_button.

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 13 parameters at only 23% schema coverage, the description should compensate more than it does. It names the modes and gives key/action examples, but never maps the many modifier and motion parameters (alt/ctrl/meta/shift, pressed, strength, position, relative) to their modes. Notably the schema's unicode param references mode=text, which the description's mode list omits.

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?

States a specific verb+resource (input injection into a running game) plus the key distinguishing constraint (no OS involvement, works headless). Enumerates the six modes with examples for action and key, so an agent can tell this apart from godot_run/godot_editor siblings.

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?

Gives a concrete workflow cue: after pressing, run godot_run { mode: "step" }. This explains the intended sequence clearly, but there is no explicit when-not-to-use guidance or note about which tool to prefer for reading state instead of injecting it.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, yet mode=clear explicitly resets (destroys) the log buffer — a state mutation. The description therefore contradicts the declared read-only/non-destructive profile. This is an Annotation Contradiction.

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?

Three tightly packed sentences, front-loaded with the resource and then the mode semantics. No filler; each clause carries information, though the cursor/since sentence is slightly redundant with the schema's own since description.

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?

With no output schema, the description does hint at a response cursor, which is useful. However, for a 5-parameter, 0-required tool it leaves grep/level/limit unexplained and creates the readOnly-vs-clear inconsistency the agent must resolve.

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 only 40% (5 params). The description adds real meaning for mode (three value semantics) and for since (incremental reads via the response cursor), but grep, level, and limit remain undocumented anywhere. It also refers to a 'cursor' that does not appear as a distinct parameter, slightly muddling since.

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?

States a specific verb+resource: reading output (prints, errors, traces) from a running Godot instance, and enumerates the three modes. No sibling does log retrieval, so differentiation is implicit rather than stated, but the purpose is unmistakable.

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?

Explains what each mode does (tail = last lines, errors = errors/warnings with parsed stack traces, clear = reset buffer) and tells the agent to use the response cursor with since for incremental reads. Covers when to pick each mode, though it offers no explicit when-not guidance.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, which is unusual for a diagnostics tool; the description earns credit by disclosing the mechanism behind that (didOpen is queued against the editor) plus the up-to-ten-second first-call headless startup cost. It stops short of stating what state the queued didOpen alters or whether it persists, so not a 5.

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?

A single dense paragraph, but information-dense with no filler; the mode list is front-loaded after the identity sentence. A bulleted mode list would scan better, but nothing is wasted.

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 an 8-parameter, multi-mode tool with no output schema and no required fields, the description covers modes and coordinate conventions well but omits what each mode returns, how limit/include_declaration behave, and how dir scanning relates to paths. An agent can invoke it but will have to discover some semantics by trial.

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 description coverage is only 38%, so the description does real work: it explains what each mode= value means, that path is mandatory except for mode=status, and that line/character are 1-based. It leaves limit, include_declaration, and the relationship between dir and paths undocumented, so the compensation is incomplete.

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 names a specific resource (Godot's built-in GDScript LSP) and enumerates all seven modes with what each returns, so an agent can tell exactly what the tool does. It does not, however, differentiate itself from siblings like godot_script_check or godot_class, which is why it falls short of a 5.

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?

Per-mode behavior is described (diagnostics needs an existing file, status needs no path), and it notes the headless-editor fallback when the editor is closed. But it never says when to prefer this tool over the sibling godot_script_check or godot_script diagnostics paths, so routing remains implicit.

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

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

Annotations already flag destructiveHint=true, idempotentHint=false and non-read-only, so the agent knows this mutates state; the description adds the rescan/reimport/uid scope and the return format. However it never explains WHAT is destructive (overwritten .import files, regenerated uid cache, partial-failure behavior), leaving a real gap against the destructiveHint it carries.

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?

Three short sentences, front-loaded with the command and effects, then the usage trigger and return value. No filler, though it is fairly dense and nothing is broken out for scanning.

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?

No output schema exists, and the description covers the return shape (summary plus output tail), which is the main thing an agent needs to interpret results. Combined with existing annotations, only the destructive semantics remain under-explained.

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?

Two parameters at only 50% schema coverage: force is described in the schema, timeout_ms is documented nowhere. The description mentions no parameters at all, so it does not compensate for the undocumented timeout_ms.

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?

Names the exact underlying command (godot --headless --import) plus the concrete effects (rescan filesystem, import/reimport assets, generate uid). This is specific enough to separate it from siblings like godot_assets or godot_files without opening any schema.

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?

Explicitly states the trigger condition: after adding new asset files and before using them. That gives a clear when-to-use rule, though it does not name alternatives (e.g. why not godot_assets) or state when-not-to-use.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond that – nothing about cost, size of the returned data, or that the boolean flags gate expensive sections. It contributes nothing the annotations don't already imply.

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?

A single front-loaded sentence beginning with the summary scope and using a colon-delimited list of contents. Dense but well organized with zero filler, appropriate for an info tool.

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?

With no output schema, the description carries the burden of describing return values, and the enumerated contents effectively serve that role. It is complete enough for a low-complexity read-only tool, though it omits how the optional boolean flags alter the response and how this differs from sibling project tools.

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 only 67% (the 'autoloads' flag has no description), so the description must compensate, and it partially does by listing 'autoloads', 'input-карта' and 'глобальные классы (class_name)' among the summary contents, letting the reader infer these flags toggle those sections. However, it never states that these are optional opt-in flags, leaving the toggle semantics to the schema.

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 names a specific resource (the Godot project) and enumerates the exact contents of the summary: name, version/features, main scene, autoloads, layers, input map, plugins, global classes, export presets. This enumeration implicitly distinguishes it from sibling godot_project_settings, but it never explicitly differentiates itself from that or other project-level siblings.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as godot_project_settings or godot_status. The agent must infer that this is the read-only overview tool from the description's content alone.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds real value on top: it lists exactly which files get written and clarifies the blast radius — the current server project is not modified. It still omits any mention of the overwrite parameter's destructive effect.

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?

Two tight sentences with no filler, front-loading what is created before the use-case note. Efficient and well-structured, though it spends words on generated files while leaving key parameters unexplained.

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 7-parameter destructive scaffolding tool with no output schema, the description covers the produced artifacts and the safe scoping well, but it is incomplete on parameter behavior (notably overwrite) and renderer/physics/scene-type choices.

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 description coverage is only 43%, so four of seven parameters (renderer, overwrite, physics_2d, main_scene_type) are undocumented in the schema. The description explains none of them, leaving the agent without guidance on the destructive overwrite flag or the enum choices.

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 and resource ('Создаёт новый Godot 4 проект') and enumerates the concrete artifacts generated (project.godot, .gitignore, main.tscn, player script, directories). It also implicitly separates itself from sibling tools by noting the current server project is untouched, though it never names a specific sibling.

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?

'Используйте для старта с нуля' gives a clear use context, and the trailing clause clarifies the non-effect on the running server project. However, no explicit alternatives or when-not-to-use conditions are named.

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

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

Annotations declare destructiveHint=true and idempotentHint=false, so the agent already knows writes can be destructive and non-idempotent. The description meaningfully adds that save=true persists project.godot while the default is in-memory only, which is critical behavioral context beyond the annotation. It still doesn't spell out that overwriting settings can corrupt a project or that writes are destructive.

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?

A single dense sentence front-loads the resource, then enumerates each mode compactly, ending with a crucial key-format example. No waste, well-structured.

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 6-parameter tool with no output schema and destructive writes, the description covers the modes, key format, and persistence semantics well. It could more explicitly warn that set with save=true mutates the project file, but overall it is complete enough for correct invocation.

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 83%, so most parameters are already documented. The description adds value by clarifying the key format (no section prefix, e.g. "display/window/size/viewport_width") and by mapping keys/items/save to their respective modes, which the schema only partially conveys.

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 names a specific resource (project.godot settings) and enumerates three explicit sub-operations (list/get/set) with what each does. It clearly distinguishes this tool from siblings like godot_project_info (read-only info) and godot_resource by focusing on project settings read/write.

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?

It explains what each mode does and gives a usage example for key format, which helps the agent choose. However it does not explicitly name when to use this vs. godot_project_info or godot_resource, nor does it state when *not* to use it.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description adds meaningful operational context: mode=set writes properties, save=true persists the file, and save_as writes to a new path — i.e. it discloses that the existing resource can be overwritten. It stops short of describing permissions, reversibility, or error behavior, so not a 5.

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?

Front-loaded with the core purpose, then modes, then value formats. Two dense sentences with little waste, though the value-syntax sentence is long and could be gated by mode for easier scanning.

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 an 11-parameter, four-mode tool with no output schema, the description covers the main flows and value formats but leaves limit, props, and property_mode unexplained and never states the return shape per mode (beyond 'метаданные и зависимости'). Adequate but with clear gaps for a tool this complex.

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 only 45%, so the description must compensate, and it does: it explains the mode enum values, save/save_as, and gives detailed value-syntax rules for property items (nested paths, 'Vector2(10, 20)' strings, '$'-tagged objects, resource refs). The undocumented limit, props, and property_mode parameters are the remaining gap.

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?

States a specific verb+resource ('чтение и изменение любого Resource' with the .tres/theme/shader/scene-resource scope) and enumerates the four operating modes. An agent can tell what the tool manipulates, though it never explicitly distinguishes itself from siblings like godot_scene or godot_script.

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 explains what each mode does (info/get/set/create), which helps an agent pick the right internal option, but gives no guidance on when to reach for this tool versus godot_scene, godot_assets, or godot_files. Usage is implied through mode semantics rather than stated.

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

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

Annotations declare destructive=true, readOnly=false, idempotent=false, covering safety basics. The description adds meaningful behavior beyond that: it operates in a headless host, render=true opens a window, mode=step auto-pauses after execution, and mode=stop unloads the scene. It does not detail what happens to unsaved state, but the gaps are minor given annotation coverage.

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?

A single dense paragraph: purpose first, then mode-by-mode explanation, then a crucial workflow note. Every sentence adds information; nothing is repetitive or wasteful.

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 an 11-parameter tool with 45% schema coverage and no output schema, the description covers the core modes and the screenshot workflow, but omits guidance on several parameters (paused, restart, fixed_fps, timeout_ms) and their mode dependencies. An agent can handle common cases but may struggle with edge configurations.

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 description coverage is only 45%, so the description must compensate. It explains the key parameters (mode, frames/seconds, render, time_scale, max_fps) but leaves paused, restart, fixed_fps, and timeout_ms completely unexplained, and does not fully clarify which parameters apply to which modes. Partial compensation, so a 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?

States a specific verb (управление) and resource (запущенной игрой внутри headless-хоста Godot), then enumerates each mode's effect, making the tool's scope unmistakable. It also explicitly distinguishes the workflow from godot_screenshot, so an agent can tell it apart from siblings.

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?

Provides clear context for each mode (e.g., step is for step debugging) and an explicit workflow for seeing the game: call mode=start with render=true, then godot_screenshot. However, it does not state when to avoid this tool or compare it to alternatives like godot_runtime.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds real value beyond that: it requires a live game to be started first and details how values are serialized for set, which an agent would otherwise have to discover by trial. It does not explicitly warn that get/set writes mutate running state, but the annotations carry that signal.

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?

It is dense but front-loaded: the tool's purpose comes first, then mode semantics, then the startup prerequisite, then value formats. The mode and value-format sentences each earn their place, though the compact run-on enumeration of value encodings is heavy and would read better split up.

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?

With 25 parameters, 8 modes, and no output schema, the description covers mode semantics and value formats well but never describes what the read operations (tree/inspect/get) return, nor the undocumented parameters. For a high-complexity, mutation-capable tool with no output schema, this leaves gaps an agent must fill by guessing.

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 description coverage is only 44%, so the description must compensate. It explains the mode enum thoroughly and gives rich guidance on the value encoding (nested paths, "Vector2(10, 20)", {"$":"Vector2",...}, resource refs), which is the hardest parameter. However, roughly half the parameters (props vs property_mode, prop_names, prop_limit, method_filter, has_script, disconnect, items, args, from/to) get no explanation in the description, leaving meaningful ambiguity.

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 (inspecting and manipulating a live running game) and enumerates all eight modes with their meanings: tree, inspect, find, get/set, call, emit, connect. It clearly distinguishes the tool from siblings by deferring game startup to godot_run, so an agent knows this operates on an already-running game.

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?

It gives a concrete prerequisite ("Сначала запустите игру через godot_run { mode: 'start' }") and maps each mode to its use case, which is strong context. It stops short of stating when to prefer this over editor-time tools like godot_scene or godot_scene_edit, so there is no explicit exclusion guidance.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is carried by structured data. The description adds useful mode semantics but never warns that mode=create (with overwrite/root_type) mutates or destroys scene data, and its 'reading scenes' framing understates the destructive modes it does list. This is a mild inconsistency rather than a contradiction, since create is explicitly disclosed.

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?

It is compact and front-loaded: the reading purpose is stated first, then each mode is glossed in a single clause. No filler sentences. Slightly dense as one run-on line, but every clause earns its place.

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 16-parameter multi-mode tool with no output schema, the description cannot cover everything, but relative to its structure it is fairly complete: all five modes are named and their behaviors sketched. The remaining gap is parameter-level detail and any note on what create/backups return, but the mode enumeration covers the agent's primary routing decision.

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 16 parameters and only 56% schema description coverage, the description should compensate more than it does. It maps several params implicitly to modes (path/source for tree, node for inspect, root_type for create, props for tree), but most of the under-documented params (limit, max_depth, max_nodes, overwrite, prop_limit, method_filter, property_mode) get no added meaning from the text.

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 the resource (scenes/.tscn) and enumerates all five modes with a concrete verb-like gloss for each (state=exact file contents, tree=node tree, inspect=node properties/signals/methods, create=new scene, backups=backups). This lets an agent pick a mode without opening the schema. The only weakness is the headline 'Чтение сцены' (reading scenes), which undersells the write-capable 'create' mode bundled into the same tool.

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?

It provides implied usage per mode, notably that mode=state is 'the best way to understand what's actually written in the scene', which is genuine selection guidance among the read modes. However, it never states when to prefer this tool over the sibling godot_scene_edit (only referenced incidentally in the ops param description) and gives no explicit exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and a closed world, so the safety profile is covered. The description usefully adds that backups are auto-created before every scene write, which explains the origin of the data, but says nothing about ordering, pagination, or return shape.

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?

A single front-loaded sentence that conveys the resource, its location, and the creation trigger with zero filler. Nothing is wasted.

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 listing tool with full safety annotations and no output schema, the description covers the essentials but omits the return format and any pagination/limit behavior. Adequate but with visible gaps.

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 50%: 'file' is documented in the schema while 'limit' is not, and the description adds no parameter meaning at all. It neither clarifies the file-filter naming nor the limit's purpose, leaving the coverage gap unaddressed.

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?

States a clear verb and resource ('Список автоматических бэкапов сцен') plus the storage location (.mcp-backups), which is specific enough to distinguish it from godot_scene and godot_scene_edit. It doesn't explicitly name a sibling as an alternative, but the purpose is unambiguous.

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 explains what the tool returns but gives no guidance on when to reach for it versus godot_scene or godot_scene_edit, and states no preconditions or exclusions. Usage is only implied by the resource name.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false. On top of that the description discloses the default dry-run behavior, that changes apply in memory first, that a backup is auto-created in .mcp-backups, and that edits are transactional — real context beyond the 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?

Dense but front-loaded: transactional statement and dry-run workflow come first, then the operation catalog, then value-format rules. Every sentence carries load-bearing information; only minor tightening would be possible.

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?

No output schema exists, and the description notes the dry-run result lands in the log rather than a return payload. For a destructive batch-mutation tool it covers transactionality, backup, and value syntax adequately, though it does not explain failure/rollback semantics when one op in the batch is invalid.

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 80% and documents path/save/backup, but the ops array is left untyped (additionalProperties: {}). The description compensates heavily by enumerating all 14 operation types and the op fields (parent, type, name, props, script, groups, index, path, to, signal, method, binds) plus value encoding formats for vectors, colors, and resource refs.

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?

Names a specific verb and resource ('Транзакционное изменение .tscn пачкой операций') and scopes it as batched, transactional editing, which separates it from sibling godot_scene (read) and godot_scene_backups. An agent knows exactly what the tool mutates without opening the schema.

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?

Gives a concrete workflow: default save=false is a dry run, inspect the logged result, then re-run with save=true. This tells the agent when the safe path applies and how to escalate to a real write, though it does not explicitly compare against other scene-editing siblings.

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

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

Annotations declare destructive=true, readOnly=false and idempotent=false, and the description explains why mutation is involved (it writes a PNG to disk) while adding the crucial constraint that headless sessions cannot render. It does not state overwrite/cleanup behavior for existing files, so it stops short of full disclosure.

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?

Three tight sentences, front-loaded with what the tool produces, then the prerequisite, then the node option and return value. No filler, though the embedded godot_run call syntax is slightly dense for a description.

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?

With no output schema, the description compensates by stating it returns both the file path and the image, and it covers the render prerequisite. The only missing piece is behavior around default path collisions or file overwrite.

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 75%, already the main source of parameter meaning. The description clarifies node's semantics (crop region, Control/Node2D/Node3D) and mentions the returned path, but says nothing about scale or timeout_ms, adding only marginal value.

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 names a concrete verb and resource (capture a game frame as PNG) and adds a distinguishing capability (optional node cropping). This separates it from generic siblings like godot_image, though it does not explicitly say what godot_image is for. Purpose is unambiguous.

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?

It states a clear precondition — the run must have been started with render=true via godot_run, since headless has no renderer. That is real when-to-use guidance, but there is no explicit contrast with alternatives such as godot_image or godot_runtime.

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

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

All four documented modes are pure inspection operations, yet the annotations declare readOnlyHint=false and destructiveHint=true. The description describes no write capability, no data being modified or destroyed, and no mode that would justify a destructive classification, so the agent receives directly conflicting signals about safety.

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?

A single dense sentence front-loaded with the general purpose, then a compact mode-by-mode clause list. Every clause carries information; it is slightly run-on but has no filler or restatement of the tool name.

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?

With no output schema and 38% schema coverage on 8 parameters, the description does the important work of describing what each mode returns. It still leaves gaps: paging/limit behaviour, the default mode, the conditional path requirement, and the unresolved safety conflict with the annotations.

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 description coverage is only 38% across 8 parameters, so the description must compensate and it partially does: it explains each mode's semantics and hints at line-range usage for mode=read (from_line/to_line) and symbol/dirs usage for references. It says nothing about limit, include_definition, or the fact that path is required for all modes except references.

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 names the resource (GDScript scripts) and enumerates all four modes with the concrete payload each returns (metadata, symbol structure, raw text, call-site references), so an agent understands exactly what the tool does. It is weaker only on sibling differentiation — it never distinguishes itself from godot_script_check or godot_class, which an agent could reasonably confuse with the symbols/references modes.

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 mode-to-need mapping (info for metadata, symbols for structure, read for text, references for call sites) gives implicit guidance on which mode to pick, which is genuinely useful. However there is no explicit 'use this when / not when', no mention of the default mode, and no routing to alternatives such as godot_script_check for validation.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description partially explains why (headless project load executes initialization code), which is useful context beyond the annotations, but it never explicitly warns about side effects, permissions, or that boot_check may run arbitrary project code. Adequate but not rich.

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?

Three sentences, each earning its place: purpose+mechanism first, return value second, usage trigger last. Front-loaded and waste-free, though fairly dense.

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?

With no output schema and 5 optional params at 60% coverage, the description does cover the return shape and the primary mode switch. It leaves secondary params (limit, boot_frames, dir defaults) and the destructive side-effect unpitched, so it is good but not airtight.

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 description coverage is 60%; the description explains the two operating modes (check-only vs headless boot) which maps to boot_check, but dir, limit, and boot_frames are left entirely to the schema. It neither repeats nor compensates fully for the coverage gap.

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 names a specific verb (checks syntax/compilation) and resource (.gd files), and adds the mechanism (godot --check-only, headless project load). It also defines the output (error list with files and lines), which clearly separates it from sibling tools like godot_script or godot_run.

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?

It gives a concrete trigger condition: 'Используйте после массового редактирования скриптов' (use after mass script edits). That is clear context, but there is no when-not guidance and no reference to alternative tools such as godot_lsp for lighter checks.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: it functions even without a discoverable project, and in that case the other tools fail with no_project — useful for sequencing agent calls.

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?

Two sentences: the first front-loads the returned state list, the second carries usage and the no_project caveat. Nothing is padded, though the enumerated field list is dense and slightly list-like rather than prose.

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?

There is no output schema, so the description must convey what the tool returns — and it does, field by field (version, root, host, render mode, import readiness, capabilities, limits). Combined with annotations covering safety and the schema covering the single param, an agent has everything needed to call it correctly.

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?

Only one parameter and schema description coverage is 100%, including the note that refresh_api rebuilds the API index and is slow (~7s). The description adds no parameter semantics of its own, so the baseline 3 applies since the schema does the work.

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?

States a specific resource (MCP server + Godot engine state) and enumerates exactly what it reports: version, project root, headless host status, render mode, import readiness, capabilities, limits. That is far more than a restatement of the name. It does not explicitly contrast itself with the close sibling godot_project_info, so sibling differentiation is only implicit.

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?

'Вызывайте в начале работы' gives an explicit trigger condition (call first). It also states the failure-mode behavior: it works even when no project is found, while other tools then return no_project. No alternative siblings are named, but the when-to-use guidance is concrete.

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