list_dir

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint=false), but the description adds genuinely useful behavior: recursion depth is capped at 1-5 and .git, node_modules, .venv and caches are deliberately not entered, which materially changes what an agent will see. Gaps remain on error handling (e.g. nonexistent path) and symlink behavior.

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 line of purpose followed by two compact parameter notes; front-loaded and every sentence adds information. 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 an output schema present, return values need no explanation, yet the description still usefully documents result ordering. Both parameters are covered and the traversal exclusions are stated; the only shortfall is unstated failure behavior for bad paths or depths.

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 0%, so the description carries the full burden and largely meets it: path defaults to the first root (~/dev) when empty, and depth is bounded to 1-5 levels. Only the 'depth' interplay with the excluded-directory behavior and out-of-range values is 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 specific verb and resource ('List a folder') and even specifies the output shape: subfolders first with trailing '/', then files with sizes. That distinguishes it from read_file and search, though it never explicitly names the closest sibling list_roots as a contrasting option.

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 only implied — an agent can infer this is for browsing a directory tree rather than finding files by name. There is no explicit 'use this when... instead of find_files/search/list_roots' statement, so routing among the eight siblings is left to inference.

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