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

Annotations already declare non-read-only, idempotent, non-destructive, open-world. The description adds genuine value beyond them: the provisioning is "on demand" with a latency expectation ("live within a minute") and it names the required permission scope (databases.write). Reversibility is only implied via the sibling disable_extension.

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?

Two compact sentences with the platform constraint front-loaded and no filler. Dense, but every clause (source of names, timing, permission scope) carries information an agent would otherwise lack.

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 3-required-param mutation with no output schema, the description covers precondition, valid value source, timing, and permission scope. Missing only an explicit statement of what is returned or how to undo it, which is minor given annotations and the disable_extension sibling.

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 67%, and the undocumented 'extension' parameter is exactly the one the description compensates for, giving examples that map logical names to extension ids (vector for pgvector). "in one logical database" also reinforces that 'name' is the database name while 'database' is the numeric id, resolving a confusing schema pairing.

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 (enables an extension in one logical database), scopes it to PostgreSQL only, and gives concrete extension examples (vector for pgvector, postgis, pg_trgm). An agent can distinguish it from disable_extension and from generic database mutations without opening the schema.

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?

"PostgreSQL only" sets a hard precondition, and pointing at get_database_options as the source of valid extension names tells the agent how to prepare the call. It doesn't explicitly say when not to use it (e.g., the disable_extension counterpart), but the operational context is clear.

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