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

With no annotations, the description carries the full disclosure burden, and "release its pool" does hint at resource cleanup beyond a simple handle drop. However, it is silent on whether the call is idempotent, what happens to in-flight operations on the connection, whether an invalid or already-closed id errors, and whether the close is reversible.

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?

A single tight sentence with the action and effect front-loaded and no filler. Its brevity is appropriate in form, though it shades into under-specification for a tool with an undocumented parameter.

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?

The tool is simple (one param, no output schema), but with no annotations and no parameter documentation, the definition omits the two things an agent most needs: where the connection_id comes from and what state results after closing. It is not adequate for reliable invocation.

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% for the single required parameter connection_id, so the description must compensate and does not. It never says what a connection id is, where to obtain one, or what format it takes, leaving the only parameter undocumented in both schema and prose.

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?

The description states a specific verb and resource ("Close a connection") plus the concrete side effect of releasing its pool, which distinguishes it from open_connection and list_connections among the siblings. It does not explicitly name those alternatives, so the differentiation is implicit rather than stated.

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?

There is no guidance on when to call this versus leaving a connection open, no note that the connection_id typically comes from open_connection or list_connections, and no warning about what stops working after the close. The agent must infer the entire usage context.

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

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

No annotations are provided, so the description carries the full burden. 'Describe' reasonably implies a non-mutating metadata read, and it discloses the shape of what comes back (columns, types, nullability, defaults, indexes), which is useful. It does not cover error behavior for a missing table, permission requirements, or whether indexes are always included.

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?

A single front-loaded sentence with zero filler; the colon-plus-enumeration structure conveys the return payload efficiently.

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 no annotations, no output schema, and 0% parameter coverage, the description should do more. It partially compensates by listing returned fields, but leaves the connection_id/schema semantics and read-only guarantees entirely to inference.

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 three parameters — connection_id, table, and the optional schema — are completely undocumented. The description mentions 'table' only implicitly and never explains that schema selects a non-default namespace, which is the most likely source of a failed call.

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 ('Describe a table') and even enumerates the returned fields (columns with name/type/nullable/default, plus indexes). It is clearly distinct from db_query and db_execute, though it never names a sibling like db_list_tables or mongo_describe_collection to sharpen the boundary.

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?

There is no guidance on when to call this versus db_list_tables (discover tables) or db_query (inspect data). Nothing says whether the table must already exist, whether this is the right tool before writing a query, or what to do with the optional schema argument.

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

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

With no annotations, the description carries the full burden: it does disclose that this is a mutation requiring a writable connection and that it returns affected_rows, which is real behavioral value. It omits error behavior, transaction/commit semantics, and whether statements are reversible — significant gaps for a write tool with zero annotation coverage.

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 short sentences, front-loaded with the core action and prerequisite, followed by the return value. No filler or repetition.

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 three-parameter mutation tool with no annotations and no output schema, the description is thin: it never explains parameter binding via 'params', failure modes, or commit semantics. The one return-value note is helpful but doesn't close the gap left by 0% schema coverage.

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% across all three parameters, so the description must compensate and largely does not. Only connection_id gets indirect mention ('writable connection'); 'sql' and especially the 'params' binding array are never explained in the description or schema.

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 ('Run a write statement') and the resource it operates on (a writable DB connection), which clearly distinguishes it from a read-oriented db_query. It does not explicitly name the sibling to use for reads, so sibling differentiation is only implicit.

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 parenthetical '(read_only=false)' gives a concrete precondition for the connection, which is useful. However, it never states when to prefer db_query over db_execute, what happens on a read-only connection, or any alternatives — usage is implied rather than guided.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it does not state that this is a read-only operation, whether it requires an active connection, whether system tables are included, or what the result shape looks like. For a discovery tool with zero annotation coverage, one sentence leaves real gaps.

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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though the brevity borders on under-specification rather than tightness.

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 no annotations, no output schema, and 0% parameter documentation, the description should explain return contents (table names only? schema-qualified?) and connection prerequisites. As written, an agent knows the intent but not enough to call it confidently or interpret the response.

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 must compensate and does not. It never explains what `connection_id` selects, nor what the optional `schema` parameter does (filter scope? default schema? case sensitivity?), leaving both parameters as bare strings in the schema.

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 tables/views") with the scope qualifier "in the connected database," so the operation is immediately legible. It does not differentiate itself from siblings like db_describe_table, mongo_list_collections, or db_query, leaving the agent to infer which listing tool applies.

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?

There is no guidance on when to use this versus db_describe_table (column-level detail) or db_query, and no stated prerequisite that a connection must be opened first via open_connection. The agent must infer all routing decisions from tool names alone.

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

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

No annotations exist, so the description carries the full behavioral burden. It discloses the read-only enforcement and the allowed statement classes, but says nothing about what happens when a write statement is submitted (rejection vs. error message), whether a connection must be pre-opened, permission requirements, row-count limits, or what the returned rows look like.

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?

A single front-loaded sentence with zero filler; the read-only constraint and accepted statement types come first. Nothing is redundant or padded.

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 four-parameter query tool with no annotations and no output schema, the description leaves too much unstated: parameter roles, connection lifecycle, and result/pagination behavior. It is a good one-line summary but not a complete operating contract.

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% across four parameters, and the description compensates only for 'sql' by naming statement types. It never explains connection_id (is it from list_connections/open_connection?), limit (row cap? default?), or params (bind-variable array vs. positional placeholders) — exactly the fields an agent is most likely to misuse.

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 ('Run a read-only SQL statement') and enumerates the accepted statement forms (SELECT/SHOW/EXPLAIN/read-only WITH), which sharply bounds what the tool does. It does not name or differentiate against the sibling db_execute, so an agent must infer the read/write split from the read-only qualifier alone.

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 read-only framing implies when to reach for this tool versus a mutating one, but no alternative is named. With db_execute sitting in the sibling list, the agent is left to guess whether db_execute handles writes or is a different execution mode entirely.

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

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

No annotations exist, so the description carries the full burden. It does disclose that results include an alive/dead status, which is useful behavioral detail, but it says nothing about scope (all connections vs. this process), snapshot semantics, permissions, or whether dead entries are retained.

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?

A single front-loaded sentence with no filler; the resource and the returned status are stated immediately. It is arguably too terse, leaving gaps that a slightly longer definition could close, which keeps it off a 5.

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 no output schema and no annotations, the description is the only source of runtime expectations. It only notes the alive/dead field and says nothing about the shape of returned entries (identifiers, endpoints) or whether the list spans servers, so it is minimally adequate rather than complete.

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, so there is nothing for the description to disambiguate; the schema itself is complete. Baseline 4 applies for a parameterless tool.

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 active connections') plus the distinguishing payload ('alive/dead status'), which separates it from open_connection and close_connection. It does not explicitly name those siblings as alternatives, 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 is only implied: the word 'active' plus the status field hints at a diagnostic/health-check scenario, but there is no explicit when-to-use, when-not-to-use, or pointer to open_connection/close_connection for related actions.

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

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

No annotations are supplied, so the description carries the full burden. It does add one genuinely useful behavioral fact (read-only connections reject write stages $out/$merge), but says nothing about result-size handling, cursors, the purpose of the limit parameter, or permissions.

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 short sentences, front-loaded with the core action followed by the constraint. Nothing is wasted, though the terseness borders on under-specification rather than efficient density.

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?

No annotations, no output schema, and zero parameter documentation, yet the description covers only the action and one $out/$merge caveat. For a five-parameter tool with an untyped pipeline, an agent still lacks what connection_id expects, how limit interacts with results, and what a call returns.

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% across five parameters, including an untyped 'pipeline' object and an unconstrained 'limit'. The description mentions none of them (connection_id, database, collection, pipeline, limit), so it does not compensate for the coverage gap; only the word 'pipeline' is implicitly explained.

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: run a MongoDB aggregation pipeline. It is distinguishable from mongo_find in practice (aggregation vs. query), but the description never names the sibling or contrasts the two.

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?

No guidance on when to choose aggregation over mongo_find, no prerequisites, and no note on which connection types are usable. The only usage-adjacent hint is that read-only connections reject $out/$merge, which is a constraint rather than a routing rule.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose the return shape (sample doc, indexes, inferred fields) — useful signal. It does not state that the operation is read-only, how large the sample is, whether inference can be slow on large collections, or whether it errors on missing collections.

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?

A single front-loaded sentence with no filler; the payload items are listed compactly after the colon. Nothing to cut.

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 three-parameter tool with zero schema descriptions, no annotations, and no output schema, the description is too thin: the optional 'database' semantics and the fact that this is a safe read are unaddressed. The one sentence covers the what but not the how.

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% across three parameters (connection_id, collection, database), and the description compensates for none of them. Notably it never explains that 'database' is optional or what happens when it is omitted, which is the single most ambiguous part of the schema.

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+resource ('Describe a MongoDB collection') and enumerates exactly what is returned: a sample document in EJSON, indexes, and inferred fields. This clearly differentiates it from mongo_find/mongo_aggregate, though it never names those siblings explicitly.

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 word 'describe' plus the inventory of returned artifacts implies an inspection/schema-discovery use case, so the agent can infer this is what you call before writing a query. However, there is no explicit 'use this when… use mongo_find instead when…' guidance and no prerequisites (e.g., connection must be open).

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation and mentions that results are relaxed EJSON, but it does not state permissions requirements, pagination behavior, limits, error handling, or confirm read-only safety relative to mongo_write.

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 three short sentences with no wasted text, and the core purpose is front-loaded. The return-format note is secondary but still relevant.

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 seven-parameter, nested-object tool with no annotations and no output schema, the description is too thin. It gives only basic purpose, partial parameter syntax, and return format, but omits connection/database/collection semantics, limit behavior, and any operational or safety context.

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%, and the description only explains the EJSON format for filter, projection, and sort. It says nothing about connection_id, collection, database, or limit, leaving four of seven parameters undocumented in both schema and description.

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?

The description states a specific verb and resource: query documents from a MongoDB collection. It is clear enough for an agent to understand the core action, but it does not explicitly distinguish this tool from sibling mongo_aggregate or explain why to choose find over aggregate.

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 provides no explicit when-to-use guidance, no exclusions, and no comparison to alternatives such as mongo_aggregate. An agent must infer that this is the general read/query tool from the name and description alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a read-only operation, but the description does not state permissions, side effects, error behavior, or what happens with the required connection.

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 a single, front-loaded sentence with no wasted words. Its brevity is appropriate structurally, even though more content is needed elsewhere.

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 no annotations, no output schema, and no parameter documentation in the schema, the description is too thin. It does not clarify required connection handling, optional database behavior, or the returned data.

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 must compensate. It only hints at the database parameter and does not explain the required connection_id, its purpose, or whether database is optional.

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?

The description gives a specific verb and resource: list collections in a MongoDB database. It is clear enough to distinguish from write/query siblings, though it does not explicitly differentiate itself from db_list_tables or mongo_describe_collection.

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 provides no guidance on when to use this tool versus alternatives. It does not mention using it before mongo_describe_collection, nor does it distinguish MongoDB collection listing from db_list_tables.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the key permission gate (writable connections only). What it omits is significant for a mutation tool: that delete is destructive, whether update requires a filter, whether upserts are possible, and what a success/failure response looks like.

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 short sentences, front-loaded with the verb and resource, with the constraint immediately after. Zero filler; the only shortfall is that the brevity comes at the cost of information the agent actually needs.

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?

This is a mutation tool with no annotations, no output schema, a nested free-form `payload`, and 0% parameter documentation. Given that complexity, the description is under-specified: an agent cannot tell from it what shape `payload` must take per action or what happens to matched records on delete.

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% across 5 parameters, so the description must compensate and mostly doesn't. It adds the allowed values for `action` (which the schema does not enumerate) but says nothing about the critical ambiguity of `payload` — a document for insert versus a filter for update/delete — nor about `database`, `collection`, or `connection_id`.

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 ("Write to MongoDB") and enumerates the three operations (insert|update|delete), which lets an agent separate it from the read-side siblings mongo_find and mongo_aggregate. It stops short of distinguishing the semantics of the three actions, but the core purpose is unambiguous.

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 gives one hard prerequisite — the connection must be writable (read_only=false) — which is genuinely useful usage guidance. However, it never explicitly says when to pick this over mongo_find or db_execute, or how to choose between insert/update/delete; routing is only implied by the verb "write".

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

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

No annotations exist, so the description carries the full burden. It usefully discloses that connections may be reused rather than always created, and enumerates supported DSN schemes, but says nothing about authentication expectations, what happens on an unsupported scheme, connection lifetime/pooling limits, or whether the connection must be explicitly closed via close_connection.

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?

Three short sentences, no filler, with the core action and the return contract front-loaded before the scheme enumeration. Every sentence carries distinct information (action, output, accepted input formats).

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 three-parameter entry-point tool with no output schema and no annotations, the description covers action, return value, and accepted schemes adequately. The remaining gap is lifecycle: it does not state that the connection should be released with close_connection or what happens on connection failure, which matters for a resource-holding tool.

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 the schema already documents all three parameters and the baseline is 3. The description earns above baseline by enumerating the concrete accepted DSN schemes (postgres://, mysql://, redis://, mongodb://, mongodb+srv://, sqlite:), which is real added meaning beyond the schema's bare 'Database URL / DSN'.

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+resource ('Open (or reuse) a database connection') and immediately clarifies the return contract ('Returns a connection_id used by the other tools'), which places it as the entry point of the sibling family (close_connection, list_connections, db_query, etc.). An agent can tell what it does and where it sits 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?

Usage is implied rather than stated: the 'used by the other tools' clause signals this must be called before db_query/redis_command/mongo_find, but there is no explicit 'call this first' directive and no guidance on when to open a new connection versus reuse an existing one, or when to prefer a fresh connection over list_connections.

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

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

With no annotations, the description must carry the behavioral burden. It usefully discloses the read-only and allow-list constraints and the outcome for writes, but it omits important details such as connection requirements, error behavior, and what the allow-list includes.

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 short and front-loads the most important constraint: read-only allow-listed commands. It is efficient, though its brevity contributes to gaps elsewhere rather than being maximally informative.

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?

Given no annotations, no output schema, and 0% schema description coverage across three parameters, the description is insufficient for an agent to invoke the tool confidently. It explains the safety boundary but not argument structure, connection handling, or expected results.

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% for all three parameters, so the description must compensate. It implies that the command is a Redis command subject to an allow-list, but it does not explain the command string format, the args array, or connection_id, leaving most parameter semantics undocumented.

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?

The description states a specific verb and resource: running a Redis command, with the key constraint that it is read-only and allow-listed. It clearly identifies the Redis domain, though it does not explicitly differentiate this tool from generic siblings like db_query or db_execute.

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?

It gives clear usage context by specifying read-only Redis commands and explicitly states that writes return UNSUPPORTED. This establishes when to use it and when not to use it, although it does not name alternative tools for write operations.

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