Файлы проекта

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.