get_database_list

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

With no annotations, the description carries the disclosure burden and does state this is a read-only listing plus the exact attributes surfaced (owner, encoding, size, connection limit), which is meaningful behavioral context. It omits operational traits such as whether elevated privileges are needed to see all databases or the cost of enumerating a large cluster.

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?

Bracketed section headers make it scannable and the purpose is front-loaded in the first line. There is mild redundancy between the Exact Functionality bullets and the trailing Returns block, which restates the same fields, but no sentence is truly wasteful.

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 zero-parameter read tool with an output schema declared, the description covers purpose, invocation triggers, exclusions and the shape of results, which is essentially everything an agent needs. The only shortfall is the absence of privilege/performance notes, which matter little given the output schema already defines the return values.

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 takes zero parameters and the schema is closed (additionalProperties: false), so there is nothing to disambiguate; baseline is 4. The description correctly signals the tool is unfiltered ('all databases') and takes no arguments.

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 ('Retrieve list of all databases and their basic information on PostgreSQL server') and scopes it to the whole server rather than a single database, which separates it from siblings like get_database_schema_info or get_table_list. The Exact Functionality block enumerates the returned attributes, so an agent knows exactly what this tool answers.

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?

Provides explicit positive triggers ('database list', 'DB list', checking what databases exist, size/owner needs) and a Strictly Prohibited list that steers away from tables, schemas, DDL and permissions work. It never names the alternative sibling tools (e.g. get_table_list, get_database_size_info) that should be picked instead, so the routing is implied rather than explicit.

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