Godot Catalog

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

No contradiction with annotations: readOnlyHint=true, idempotentHint=true, destructiveHint=false align with a catalog/read tool. The schema itself describes action as 'Read-only catalog action', which reinforces the safe-read behavior. However, the description adds no behavioral context beyond what annotations already provide — no mention of result ranking, pagination, or how describe differs in output from search. With comprehensive annotations covering the safety profile, the description adds minimal value here.

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 extremely short (one truncated sentence), which could be concise — but it's incomplete rather than deliberately minimal. A truncated sentence that trails off ('the complete Godot…') is a structural defect, not concise prose. One would expect at least a full sentence articulating what the catalog contains and its two modes of operation.

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?

Despite the truncated description, the tool benefits from a 100% documented schema, 8 enum-filtered parameters, comprehensive annotations, and an output schema. The complexity of this tool (11 params, two action modes, 8 filters) is largely self-documented through the schema. However, the description could meaningfully enhance completeness by explaining the search-vs-describe distinction and how filters combine — a gap the schema alone partially fills but doesn't fully cover.

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 100%, so all 11 parameters have descriptions in the schema itself (e.g., 'Optional required-state filter', 'Required for describe'). The description adds nothing beyond what the schema documents. Baseline 3 is appropriate since the schema does the heavy lifting, and the description doesn't need to duplicate 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 reads 'Search or inspect the complete Godot…' which is truncated and incomplete. The verb is present (Search/inspect) but the resource is truncated mid-sentence ('Godot…'), making the purpose only partially clear. The name 'godot_catalog' and title 'Godot Catalog' suggest a catalog/metadata tool, and the two actions (search/describe) are visible in the schema, but the description itself fails to fully convey the scope.

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. With 19 sibling tools ranging from run_project to game_screenshot, an agent cannot tell from the description alone when to consult the catalog versus using a specific operation tool. No when-to-use, when-not-to-use, or filtering strategy is given, despite 8 filter parameters (state, domain, effect, backend, mutation, privilege) that would clearly benefit from usage guidance.

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