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

No annotations are supplied, so the description carries the full burden; "Retrieve" implies a read-only operation, and it usefully discloses what the records contain (risk scores, PII redactions, blocked operations). It says nothing about ordering, retention window, pagination beyond the limit parameter, or required permissions, which are meaningful gaps for an audit tool.

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 resource and its contents come first with no redundant restatement of the tool name. Nothing could be removed without losing information.

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-optional-parameter read tool the description is serviceable, and the absence of an output schema is partly offset by enumerating the returned fields. However, with no annotations to declare its read-only safety profile, the definition leaves the agent without confirmation of side effects, ordering, or result volume.

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 100%, so the schema already documents limit, status, and minRiskScore semantics including the status enum values. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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 pairs a specific verb ("Retrieve") with a specific resource ("security and compliance query audit trail") and enumerates what it contains: blocked operations, risk scores, and PII redactions. That makes it clearly distinguishable from execution-oriented siblings like db_query or db_commit, though it does not explicitly name a sibling to disambiguate against.

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 compliance/security framing implies when an agent would reach for this tool (auditing blocked or risky queries), but there is no explicit when-to-use or when-not-to-use statement, and no guidance versus alternatives such as db_query or db_status. Usage must be inferred from the resource name.

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 discloses the three diagnostics performed, which is real behavioral substance, and 'inspect' implies a non-mutating operation, but it never states read-only safety explicitly, says nothing about cost/latency on large schemas, and does not describe what form the findings take.

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, and the most distinctive check (unindexed foreign keys causing cascade locks) is placed in the middle where it reads clearly. Slight overlap between 'schema health' and 'schema drift' keeps it from being maximally tight.

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 and no output schema, the agent is left guessing at the return shape (a findings list? a health verdict?) and at whether the call is guaranteed read-only. Complexity is low at zero parameters, which limits the damage, but a sentence on output form or safety would close the remaining gap.

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 is trivially complete. Baseline 4 applies, with no parameter gaps to compensate for.

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 names concrete verbs and resources: inspect schema health, identify unindexed foreign keys causing cascade locks, and detect schema drift. This is clearly a read-only diagnostic, distinct from query/commit siblings like db_query and db_commit. It stops short of differentiating itself from db_status or db_describe_schema, which overlap in the schema-inspection space.

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 by the enumerated checks: an agent would invoke this before a migration or when investigating lock contention from unindexed foreign keys. However, there is no explicit when-to-use/when-not guidance and no pointer to alternatives such as db_status or db_describe_schema for simpler schema questions.

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 disclose behavioral traits, but it does not say whether the tool executes SQL, is read-only, needs elevated permissions, returns findings, or what happens when it detects a violation. The single sentence only gives the detection purpose, leaving the operational profile largely unknown.

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?

It is a single front-loaded sentence with no filler; the sensitive-column categories are specific and earn their place.

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?

Because there is no output schema and no annotations, the description should say what the tool returns and how a finding is reported. It also omits usage context relative to sibling tools, so an agent cannot fully determine the invocation semantics from this definition alone.

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 sql and intent. The description maps them to 'stated user prompt intent' and 'SQL AST target columns' but does not add format, examples, or constraints beyond the schema, so baseline 3 applies.

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?

It names a specific comparison operation (intent vs. SQL AST target columns) and the security outcome (unauthorized modification of sensitive columns). That is enough for an agent to distinguish it from db_query or db_dry_run, which execute or simulate queries.

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 usage by calling it a check for unauthorized modification, but it never says when to call it, whether it precedes db_commit or db_dry_run, or whether it can be used independently. No sibling alternatives are named, so the agent must infer routing.

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 at all, the description carries the full burden and does solid work: it declares the operation permanent, requires prior authorization, and constrains the token to single use. It stops short of describing failure behavior, whether a failed commit burns the token, or transaction/rollback semantics — meaningful gaps for an irreversible 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?

Two short sentences, zero filler. The permanence warning and the sibling dependency are front-loaded, and nothing is repeated from the schema verbatim.

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 destructive tool with no annotations and no output schema, the description covers the essentials: what it does, the prerequisite, and the authorization requirement. It could say more about the result of a successful commit given there is no output schema to fall back on.

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 100%, so the schema already explains sql, params, and commitToken in detail. The description only restates the token's single-use, dry-run-derived nature, adding no syntax, format, or matching constraints beyond the structured fields; baseline 3 applies.

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 effect ('Permanently execute and commit a mutation') and ties itself to the prerequisite sibling 'db_dry_run', which separates it from db_query and db_explain_query. It does not address when db_distributed_commit would be preferred, so the sibling differentiation is clear but not complete.

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 usage context is explicit: this is the second half of a two-step flow that must follow 'db_dry_run' and requires a valid single-use commitToken. There are no explicit exclusions or guidance about the distributed variant, but the sequencing is unambiguous.

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. 'Safely' signals a non-destructive read, and the enumeration of returned fields (types, nullability, PKs, FKs) gives a partial return-shape picture. It does not state permission requirements, whether views/system tables are included, or the response structure, and there is no output schema to cover that gap.

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 verb and the return contents appear immediately, and no wording is redundant.

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 simple read-only introspection tool with one optional parameter and no output schema, the description covers the core question of what information comes back. The remaining gap, the exact response shape and permission requirements, is modest given the tool's low complexity.

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 single parameter has 100% schema description coverage, so the agent already knows that omitting tableName returns all tables. The description adds nothing beyond that schema text, which is the correct baseline for a one-parameter tool with full coverage.

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 ('introspect') and resource ('database tables') and enumerates exactly what is returned: column types, nullable flags, primary keys, foreign keys. An agent can distinguish it from db_query or db_commit on intent. It does not explicitly differentiate itself from the close sibling db_check_schema_drift, which keeps it at 4 rather than 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?

No when-to-use guidance and no alternatives named. Given siblings like db_check_schema_drift and db_query, the agent is left to infer that this is the schema-discovery step, and that inference is only weakly supported by the word 'introspect'.

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 disclose two behavioral facts beyond the schema: 'two-phase' implies atomicity semantics and 'authorized ... token' implies an authorization prerequisite. It omits critical traits for a destructive multi-store write: what happens on partial failure, whether the commit is all-or-nothing, idempotency, and irreversibility.

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 operation, scope, and authorization mechanism all appear before any trailing clause.

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 destructive, cross-store, two-phase commit with a nested operations array, no annotations, no output schema, and 0% parameter coverage, the description is far too thin. An agent cannot determine failure semantics, per-store targeting, or what the commit 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%, and the description adds no meaning for either parameter. It never explains that 'token' must be a dry-run-issued authorization token or that 'operations' is an array of per-store actions (SQL, KV_SET, KV_DEL, KV_EXPIRE) with storeId/storeType/queryOrKey. The nested operation structure is left entirely to inference.

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?

Names a specific operation and scope: 'Execute two-phase distributed commit across multi-store environments.' This distinguishes it from siblings like db_commit (single-store) and db_distributed_dry_run (the preview step), 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 phrase 'using an authorized distributed dry-run token' implies a prerequisite: you must first run a distributed dry-run to obtain the token. That is an implied usage condition rather than an explicit one, and the description never states exclusions or directly names db_distributed_dry_run as the alternative.

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 genuinely useful behavior beyond the schema: that this is non-mutating simulation and that it returns a single distributed commit token (no output schema exists). It omits lifespan of the token, whether failures are reported per-store, locking or permission requirements, and how token validity is checked.

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, and the outcome (commit token) is stated early. It is arguably too terse given the tool's complexity, but nothing is wasted.

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 complex multi-store transaction simulator with no annotations, no output schema, and no parameter documentation, the description covers the essence (simulation plus token) but leaves substantial operational gaps: error semantics, atomicity guarantees, token lifetime, and the hand-off to db_distributed_commit.

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 sole parameter is a nested array whose items require storeId, storeType, action (SQL/KV_SET/KV_DEL/KV_EXPIRE), and queryOrKey, plus an untyped paramsOrValue. The description adds nothing about this structure, the meaning of the action enums, or how mixed SQL and KV operations are composed.

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 ('Simulate atomic mutations') and scope ('across multi-store environments'), with concrete store examples. It does not explain how 'distributed' differs from the sibling db_dry_run, leaving an agent to infer the distinction.

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 when-to-use guidance appears. The description never says it is a prerequisite for db_distributed_commit (which presumably consumes the token it returns) or when to choose it over db_dry_run. Usage is only implied by the word 'Simulate'.

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 at all, the description carries the full burden and does substantial work: it discloses that execution happens inside an auto-rollback sandbox (no persistent writes), that blast radius and row counts are computed, and that a short-lived token is issued conditionally. The notable gap is the 'if safe' branch — the description never says what happens when the mutation is deemed unsafe (error, refusal, null token) or how long the token lives.

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 sentences, both information-dense, with the core behavior (simulation in a rollback sandbox) front-loaded before the outputs. 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?

There is no output schema, so the description usefully enumerates the return payload (blast radius, row count, token). For a mutation-adjacent tool with zero annotations, the missing piece is the failure/unsafe path and the token's downstream contract with db_commit.

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 100%, so the schema already documents sql, intent, and params including the accepted mutation types. The description adds no further meaning about parameter usage, such as whether parameterized values in params are required for safe blast-radius estimation or how intent influences the safety decision.

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 names a specific verb and resource — simulate a database mutation — and scopes it to an auto-rollback transaction sandbox, then adds what it computes (blast radius, affected row count) and what it emits (a short-lived authorization token). This clearly separates it from db_commit (which would apply changes) and db_query (which reads), though no sibling is named 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?

Usage is only implied: the word 'simulate' and the token return suggest this is a pre-flight step before db_commit. There is no explicit when-to-use or when-not statement, no mention that db_commit presumably requires the returned token, and no exclusion telling the agent to use db_query for read-only SQL or db_explain_query for plan inspection.

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 disclosure burden, yet it never says whether the query is actually executed (EXPLAIN ANALYZE) or merely planned, whether the operation is read-only, or what permissions/cost are involved. For a tool taking arbitrary SQL, that ambiguity is a meaningful safety gap.

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 core action appears first and the diagnostic targets follow. It is tightly scoped, though it could have used one additional clause on usage or safety at little cost.

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, the description should indicate what the analysis returns (raw plan text, findings list, recommendations), and it does not. It is adequate for a two-parameter tool but leaves the agent guessing about results and execution semantics.

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%, with both `sql` and `params` documented in the input schema. The description adds nothing about parameter binding behavior or how `params` interacts with placeholders, so the baseline 3 applies.

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 concrete verb and resource (analyze execution plan via EXPLAIN) and names the specific findings it targets (sequential scans, missing indexes, bottlenecks). This clearly separates it from db_query or db_dry_run, which are about running or validating queries rather than inspecting plans, though it never explicitly names those alternatives.

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 explicit when-to-use guidance and no mention of the many siblings (db_dry_run, db_query, db_check_semantic_intent) that an agent could easily confuse with plan analysis. The purpose implies a performance-tuning scenario, but the agent must infer that context 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?

With no annotations, the description carries the full burden, and it does disclose one genuine behavior beyond the schema: destructive DDL and mutations lacking a WHERE clause are intercepted and blocked. It does not say what a block looks like to the caller (error vs. partial result), whether execution is transactional, what permissions or tier gates apply, or anything about rate limits, so the behavioral picture is still incomplete for a query-execution tool.

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 sentences, front-loaded with the purpose and immediately followed by the safety constraint. Nothing is wasted, though the second sentence is a behavioral note rather than a routing aid, slightly misplacing emphasis.

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?

There is no output schema and no annotations, and this is a mutating, guardrailed tool — the highest-burden combination. The description covers safety interception but leaves return shape, failure modes, and the STRICT-tier/intent interaction to the schema and to discovery, which is not quite enough.

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 100%, so the baseline is 3. The description adds no parameter meaning beyond the schema — it does not explain that 'intent' is gated to a STRICT tier for sensitive-field mutations or how 'params' interacts with the 'sql' placeholder syntax, both of which the schema only touches lightly.

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 pairs a specific verb with a specific resource: execute a SQL query, mediated by 'DBShield guardrails'. That distinguishes it from db_dry_run, db_commit and db_explain_query by implication, but no sibling is named, so an agent must infer the routing rather than read it.

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: this is the tool that actually runs SQL. The description never says when to prefer db_dry_run, db_commit or db_explain_query first, nor whether a dry run is a prerequisite in this workflow. The one useful contextual statement is that DDL and unconstrained mutations get blocked, which hints at a boundary but is not framed as guidance.

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 must carry the behavioral burden. The word 'Check' implies a non-mutating read, but the description does not confirm it is safe/read-only, whether it hits the network, or whether results are cached; for a simple zero-argument status tool these gaps are minor but real.

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 naming the subject and the three things inspected, with no filler, hedging, or repetition. Nothing could be removed without losing information.

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 description enumerates the three facets of the response (status, safety tier, connection), which effectively tells the agent what it will learn even though no output schema exists. It falls short only on what the possible status values mean or how to interpret a degraded tier.

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 has an empty properties object, so there is nothing for the description to disambiguate beyond what the schema already establishes. Baseline for a parameterless tool applies.

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 pairs the specific verb 'Check' with three concrete resources: gateway status, active safety tier, and database connection. That clearly separates it from the sibling tools such as db_query and db_commit, which perform data operations rather than status inspection, 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?

Usage is only implied: an agent can infer this is a pre-flight or diagnostic check to run before queries or commits, but the description never states when to prefer it or what to do with the result. No exclusions or alternatives are named among the eleven sibling tools.

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 full behavioral burden. It usefully discloses the rule categories checked (lock risks, NOT NULL, destructive drops), which implies static analysis without execution, but it never states whether a live database connection is required, whether the tool only reads, or how violations are reported back.

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 front-loaded sentence with the core purpose first and the detection categories after. Dense but every clause adds a distinct check; only mild redundancy between "DDL migrations" and "migration script" framing.

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?

There is no output schema, so the description should signal what comes back — a list of violations? pass/fail? severities? — and it does not. For a one-parameter validator, the input side is complete, but the result shape and any prerequisites are left for the agent to discover.

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 single parameter has 100% schema description coverage, so the baseline is 3 by rule. The description reinforces DDL/migration scope, which matches the schema, but adds no syntax rules, dialect notes, or batching constraints for multi-statement scripts beyond what the schema field already says.

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?

Specific verb plus resource ("Analyze DDL migrations against zero-downtime safety rules") with concrete examples of what it flags: locking risks, NOT NULL columns, destructive drops. It is clearly distinguishable from siblings like db_dry_run or db_check_schema_drift, 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?

Usage is only implied: an agent can infer it should call this before applying a migration. There is no explicit when-to-use statement, no mention of when this is unnecessary, and no routing to alternatives such as db_dry_run or db_check_schema_drift.

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