list_tools

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only states that it returns a list and never discloses behavioral traits such as whether the list is exhaustive/session-specific, whether any side effects or permissions apply, or how 'available' is determined. The read-only nature is inferable but not explicit.

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 one short sentence with no filler: 'returns a list of available tools'. Every word earns its place, and the core purpose is immediately visible.

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 parameterless introspection tool, the description is minimum viable: it states what is returned and the output schema likely covers return structure. However, 'available' is ambiguous and may mean session-scoped, permission-scoped, or platform-wide, and no behavioral or usage context compensates for the lack of annotations.

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?

The tool has zero parameters and the schema correctly declares no properties, so there is no parameter meaning left to explain. Per calibration, a zero-parameter tool receives a baseline of 4.

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?

Provides a clear verb ('returns') and resource ('a list of available tools'), and it is plainly distinct from the sibling operation tools like git_quick_upload or create_image. It does not explain what 'available' means or what fields the list includes, which holds it back from 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?

The description implies the tool should be used when an agent needs to know which tools are available, but it gives no explicit when-to-use guidance, no exclusions, and no alternatives. This is adequate for a self-evident metatool, but not generous.

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