get_project_structure

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

With no annotations, the description carries the full burden and does well: it discloses the output shape ('Source roots with packages and file counts'), the load_project prerequisite, and the failure mode for bad input ('maxDepth outside 1 to 20 is INVALID_PARAMETER'). It still does not say whether the call is safe/read-only, whether it can be slow on large projects, or whether results are cached, keeping it out of 5 territory.

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?

Labeled USAGE/OUTPUT blocks keep it front-loaded and scannable, with no filler sentences. The maxDepth validity line duplicates the schema range, a small redundancy that costs it a perfect score.

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 properly summarizes the return value, and it states the load_project prerequisite plus the invalid-input behavior. For a two-optional-parameter read tool that is essentially complete; only edge cases (large-project performance, empty/unloaded project) remain unaddressed.

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%, so both parameters are already documented; the description only restates the maxDepth range plus an error code, and says nothing about includeFiles or default behavior. Baseline 3 is correct when the schema does the heavy lifting.

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 project structure showing package hierarchy') and the scope is clearly project-wide, which separates it from the symbol-level siblings like get_symbol_info or go_to_definition. It does not name an overlapping sibling (e.g., get_dependency_graph) to draw the boundary explicitly, 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?

'USAGE: Call to see the package tree of the loaded project' gives a clear context, and the prerequisite 'Requires load_project to be called first' is exactly the kind of guidance an agent needs. No explicit when-not or alternative-sibling routing is given, so 4 rather than 5.

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