Retrieves the UID for a specific file in a Godot 4.4+ project using the project path and relative file path, enabling file references by UID.
Get the UID for a specific file in a Godot project (for Godot 4.4+)
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the file (relative to project) for which to get the UID | |
| projectPath | Yes | Path to the Godot project directory |
Changes observed during successful MCP inspections.
v0.6.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-destructive, read-only, closed-world operation. The description adds the Godot 4.4+ applicability constraint, which is genuine value, but says nothing about what happens when the file has no assigned UID or the path is invalid.
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 with no filler; the version caveat is compact and placed inline. Nothing wasted, though it could have spent that space on return-value behavior instead.
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 arguably should indicate that the result is a UID string and how failure appears; it does not. For a simple two-parameter lookup this is adequate but leaves a 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?
Schema coverage is 100% with both parameters fully documented (projectPath, filePath relative to project), so the schema carries the burden. The description adds no parameter meaning beyond what the schema states.
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 ('Get the UID for a specific file') plus a version constraint, so the agent knows exactly what operation is performed. It does not differentiate itself from near-siblings like update_project_uids or list_project_files, so it falls short of 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?
The '(for Godot 4.4+)' qualifier implies a usage precondition, which is useful, but there is no explicit when-to-use/when-not guidance or mention of the related update_project_uids / list_project_files tools. 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.