lu-query

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

With no annotations, the description carries the full burden and does so well: auto-commit behavior, required GRANT EXECUTE privilege, SYS_REFCURSOR results being fetched into row arrays, and explicit rejection of BOOLEAN/RECORD/TABLE/VARRAY/OBJECT types with remediation guidance.

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?

Four dense sentences, each delivering distinct information (capability, arg format, rejection policy, privilege/commit semantics). Slightly packed but front-loaded and free of filler.

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 output schema exists, yet the description explains what comes back for functions (returnValue) and REF CURSOR out/return args (row arrays). It omits error/exception reporting behavior, which for an execute-style tool is a minor 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?

Schema coverage is already 100%, so the baseline is 3, but the description adds real value: a worked JSON arg example, direction semantics, and the fact that isFunction registers a return slot and populates returnValue. The type-rejection rule also constrains what dataType values are legal.

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 (execute) and resource (PL/SQL procedure, function, or package subprogram) with scope (typed arguments, IN/OUT/INOUT). It is clearly separable from execute_dml and describe_plsql among the siblings.

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?

Gives concrete usage conditions: pass args as a JSON array, requires GRANT EXECUTE, and pins the commit behavior to execute_dml for consistency. It stops short of an explicit 'use this instead of X when...' statement, but the context is clear.

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 real behavior: this is an upsert ('add or replace') rather than an append, and it is gated on table ownership by the MCP user. That is meaningful. It stops short of saying whether this is DDL, whether existing comments on other columns are affected, or what the 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, zero filler, with the operation stated before the caveat. Nothing to trim.

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 mutation tool with no annotations and no output schema, the description covers the operation and the key access constraint, and the schema fully documents each parameter. It is nearly complete; only permissions/DDL-side effects and result reporting are left unstated.

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% and each of the four parameters is described in the schema, including the non-obvious schema/default guidance ('omit rather than guess') and automatic quote escaping. The description's 'add or replace' clarifies the comment parameter's overwrite semantics, but otherwise adds little the schema does not already carry, 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 specific verb pair and resource: 'Add or replace the comment on a column.' An agent immediately knows the operation and target. It does not, however, name or distinguish itself from the sibling comment_on_table, so sibling differentiation is left to the name.

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 ownership restriction ('Only works for tables the MCP user owns') gives an implied usage boundary, which is genuinely useful. But there is no explicit when-to-use guidance and no routing to the obvious alternative (comment_on_table) or to describe_table for reading existing comments.

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 does disclose meaningful behavior: the operation replaces any existing comment, and it requires table ownership, with the exact failure mode (ORA-01031) spelled out. It omits return/response behavior and required privileges beyond ownership, but the safety-relevant constraints are well covered.

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: the first front-loads the action, the second gives the constraint and failure mode. No redundant restatement of the name or schema, and every clause earns its 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?

For a mutation tool with no annotations and no output schema, the description covers the key behavioral facts an agent needs: what it does, who can run it, and the error on failure. Return value is unspecified, but that is a minor gap given the operation's simplicity.

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 all three parameters (table, schema, comment) are already documented, including the schema-defaulting and quote-escaping behavior. The description adds nothing about parameters, so the baseline of 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 ('add or replace') and resource ('comment on a table'), which clearly differentiates from the sibling comment_on_column without needing to name it. The 'add or replace' phrasing also communicates the upsert nature of the operation. It lacks explicit sibling routing but the resource scope 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?

Gives a concrete precondition — only tables the MCP user owns — and explains why (no system privilege exists for COMMENT on others' objects) plus the resulting error (ORA-01031). This is a clear 'when this works' constraint, though it does not route the agent between this tool and comment_on_column.

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. "Without running SQL" is a genuine behavioral disclosure (no SQL parsing/privilege path), but it omits whether the count is exact or from stats, the cost on very large tables, required table-level privileges, and behavior for views or missing tables.

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 with zero filler; the core operation is front-loaded before the use-case rationale. Nothing could be cut 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 low-complexity two-parameter tool this is nearly adequate, but with no output schema the description never states the return shape (a single integer row count) or error behavior on nonexistent/inaccessible tables, leaving a small but real 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?

schema_description_coverage is 100%, and the schema itself carries a strong hint for the optional schema param ("omit rather than guess"). The description adds no parameter-level 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?

States a precise verb+resource ("Count rows in a table") and adds the differentiator "without running SQL," which implicitly contrasts it with run_query. It doesn't explicitly name a sibling alternative, so it lands just 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?

"Useful to size a table before indexing, partitioning or sampling" gives clear when-to-use context tied to concrete workflows. It stops short of naming the alternative for similar information (e.g., get_table_stats, which also exposes row counts) or saying when not to use it.

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 available, the description carries the full behavioral burden. It helpfully discloses the privilege requirement and the specific Oracle error on insufficient authorization, but it does not describe DDL side effects such as table locking, resource consumption, index-name conflicts, or whether the operation can be safely retried.

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 two sentences with no wasted language. The primary action is front-loaded, and the privilege caveat follows directly as supporting detail.

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 DDL creation tool with fully documented parameters and no output schema, the description covers the essential action and the key authorization prerequisite. It is nearly complete, though it could better route agents away from suggest_index and mention operational side effects.

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 all parameters are already documented in the input schema. The description adds no additional parameter meaning beyond what the schema provides, making the baseline score of 3 appropriate.

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 (Create) and resource (an index on a table), which is unambiguous and distinguishes it from sibling read tools like list_indexes and suggest_index. An agent can identify the operation 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?

The description gives a prerequisite for use: it requires CREATE ANY INDEX or table ownership, and failure returns ORA-01031. However, it does not say when to choose this tool over alternatives such as suggest_index or explain_plan, nor does it state any exclusions.

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 does add real value: it discloses required privileges (CREATE TABLE, tablespace quota) and the concrete failure modes (ORA-01031 / ORA-01950), which an agent could not infer from the schema. It stops short of covering idempotency or what happens if a log already exists.

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, no filler, and the core action is front-loaded ahead of the prerequisite/error detail. Every clause earns its 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?

For a DDL tool with no annotations and no output schema, the description covers purpose, prerequisites, and error conditions adequately. Minor gaps remain around duplicate-log behavior and return value, but the essentials for a correct call are present.

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 all five parameters including the schema default and the withPrimaryKey recommendation. The description adds no parameter-level meaning beyond that, 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?

States a specific verb (Create), resource (materialized-view log), and target (on a table), plus the reason (for fast refresh). An agent can distinguish it from read-side siblings like list_mview_logs and from other create_* tools 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?

The phrase 'for fast refresh' implies the scenario in which this DDL is warranted, which is useful context. However, it names no alternatives and gives no explicit when-not guidance (e.g., how it relates to creating the materialized view itself, or to list_mview_logs). Usage is implied rather than stated.

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. It does disclose the privilege requirement and error code, but says nothing about the destructive 'replace' semantics (an existing view and its grants are dropped), transaction/commit behavior, or invalidation of dependent objects.

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 action and scope, then the precondition. Every clause earns its place with zero filler.

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 mutation tool with no annotations and no output schema, the definition is workable but incomplete: it omits the replacement consequences (lost grants, dependent-object invalidation) and any return/confirmation behavior, leaving an agent under-informed about side effects.

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 all three parameters, including the schema default. The description only echoes the 'own schema' constraint and adds no syntax or format detail beyond what the schema provides, 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?

States a specific verb (create or replace) plus resource (view) and scope (the MCP user's own schema). No sibling tool creates views, so the agent can distinguish this from list_views, get_ddl, or describe_table without opening a 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?

The description names the required CREATE VIEW privilege and the resulting ORA-01031 error, which is useful precondition context. However, it gives no explicit when-to-use vs alternatives guidance or exclusions, so usage is only implied.

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 a genuine behavioral fact: the CREATE SEQUENCE privilege requirement and the resulting ORA-01031 error. It omits other important traits such as behavior when the sequence already exists, idempotency, and the return value.

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 tight sentences with zero waste; the scope constraint is front-loaded and the privilege/error note follows. Nothing extraneous.

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 output schema and no annotations, but the schema fully documents every parameter and the description adds scope plus the privilege/error requirement. For a simple creation tool this is nearly complete, though it doesn't cover existing-sequence behavior or the success 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 100%, so all 7 parameters (cache, cycle, order, schema, sequence, startWith, incrementBy) are already well documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline of 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 ('Create') and resource ('sequence') plus a scope qualifier ('in the MCP user's own schema'). This clearly separates it from read siblings like list_sequences, get_sequence_info, and get_next_sequence_value, though it doesn't name any of them 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 implied by the verb and the privilege prerequisite, but the description never states when to choose this over alternatives or when not to use it (e.g. if the sequence already exists). The 'own schema' scoping note is a mild usage constraint, but no routing guidance is given.

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 does disclose the auth requirements and the exact error returned when they are missing — the kind of context the rubric explicitly credits. It stops short of covering other behavioral edges such as what happens if the synonym name already exists or whether creation is idempotent.

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 tight sentences: the operation is front-loaded, and the privilege/error sentence immediately follows as the actionable constraint. No filler or restated boilerplate.

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 5-parameter mutation tool with no annotations and no output schema, the description covers purpose, scope choice, and the failure mode an agent will actually hit. The main remaining gap is the behavior on name collision/overwrite, which an agent would want before retrying.

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 every parameter (including the isPublic/schema interaction and the 'omit rather than guess' guidance on schema) is already documented in the schema. The description adds no parameter-level detail beyond what the schema provides, 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 specific verb+resource ('Create a ... synonym') plus the scope variant (private vs public) and the target ('pointing at another schema's object'). This clearly separates it from the read-side sibling list_synonyms and from the other create_* tools (create_sequence, create_index, create_mview_log).

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?

Gives a concrete prerequisite that determines whether the call can succeed at all: CREATE SYNONYM for private, CREATE PUBLIC SYNONYM for public, with ORA-01031 as the failure signal. It does not explicitly route between alternatives (e.g., create_or_replace_view or list_synonyms), so it stops short of full when/when-not 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 provided, so the description carries the full behavioral burden. It states 'Read-only' and enumerates the return content, which is useful, but omits permissions, error behavior (e.g., object not found, invalid type), and any caveats about source retrieval.

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 purpose and return payload, ending with the safety trait. 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 read-only describe tool with a fully documented schema and no output schema, the description supplies the essential contract: what it returns and that it is non-mutating. It could do more to mention error handling or permissions, but it is close to 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?

Schema description coverage is 100%, with clear descriptions for name, type, and schema (including the default behavior). The description adds no parameter-level detail, so it sits at the baseline.

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 ('Describe') and resource ('PL/SQL object'), and enumerates the return payload (arguments and source code). However, it does not name or contrast with the closest siblings such as describe_table, get_ddl, or list_procedures, so differentiation is left to the agent.

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 or when-not-to-use guidance is provided. The description gives no prerequisites or alternative conditions; it only implies usage by describing the action, leaving the agent to infer that this is the right call when source code and signature are needed.

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. It discloses the operational protocol (verify before DML) and the return shape, but says nothing about permissions required, cost, or whether the call is read-only — the read-only nature is only implied by the verb 'describe'.

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 with zero waste: the first front-loads what the tool returns, the second front-loads the imperative usage rule. Nothing is repeated from the schema.

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, but the description enumerates the returned column attributes, so an agent knows what it will get back. Combined with a fully documented 2-parameter schema, nothing needed to call this correctly is missing.

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 both parameters — including the useful 'omit rather than guess' note on schema. The description adds no additional parameter meaning, making 3 the correct baseline.

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 (describe) and resource (a table's columns) and enumerates exactly what is returned: name, data type, nullability, default value and comment. That field-level specificity separates it from get_ddl, list_lob_columns and list_constraints without the agent opening any 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?

Gives an explicit trigger: call it before writing SELECT/INSERT/UPDATE against an unverified table, with the rationale that column names and types should be known rather than invented. It does not name alternative metadata tools (get_ddl, get_table_stats) or state when not to bother, so it stops short of a 5.

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 does so well: it discloses auto-commit semantics, the absence of a cross-call transaction boundary, one-statement-per-call enforcement, the row-count return, and how privilege failures surface (isError=true). It stops short of flagging irreversibility/rollback options, but the auto-commit statement implies it.

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?

Front-loaded with the core verb and target, then layered with commit semantics, call constraints, and return/error behavior. Slightly dense but every clause is load-bearing and there is no filler.

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 output schema, so the description correctly explains the return value (rows affected) and error channel (isError=true). Given a single required parameter, this is nearly complete; the only gap is routing guidance versus the preview/rollback sibling tools.

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% for the single 'sql' parameter, so the baseline is 3. The description reinforces the allowed statement types and the single-statement constraint, but adds no syntax or format detail beyond 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 (Execute) and resource (a single INSERT/UPDATE/DELETE/MERGE statement on existing tables), and constrains to one statement per call. This distinguishes it from run_query (reads), execute_dml_preview, and execute_dml_rollback_first without opening any 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?

Conveys the operating model (single statement, auto-commit, no cross-call transaction) which implies when it applies, but never names the obvious alternatives. Siblings execute_dml_preview and execute_dml_rollback_first exist and an agent gets no explicit rule for choosing between them.

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 behavioral burden and does so well: it clarifies the operation is non-executing (a true dry-run) and specifies what it returns (affected row count plus a sample). It stops short of stating permission requirements or whether any read locks are taken, so it is strong but not exhaustive.

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 tight sentences: purpose, return behavior, and the exclusion/alternative. The key constraint (dry-run, no execution) is front-loaded and nothing 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?

With no output schema, the description covers the return values (total affected rows and a sample). It handles the exclusivity constraint and points to the correct alternative, leaving nothing an agent needs in order to call it correctly.

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?

Only one parameter with 100% schema description coverage, so the schema already documents the sql argument fully. The description reaffirms that it must be a single non-executed UPDATE/DELETE statement but adds nothing beyond the schema's own wording. Baseline 3 is appropriate.

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 (dry-run) and resource (UPDATE/DELETE statements) with scope, and names the sibling tools it is NOT by excluding INSERT/MERGE. An agent can distinguish this from execute_dml and execute_dml_rollback_first without opening any 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?

Explicitly states when to use it (dry-run UPDATE/DELETE), when not to (INSERT and MERGE unsupported), and routes the agent to the correct alternative (execute_dml_rollback_first) for the excluded cases. Both the positive and negative routing are present.

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 does well: it discloses that nothing is persisted, that the transaction rolls back, and that it reports rows affected, so the agent understands the side-effect profile. It omits permission/auth requirements and how the statement is validated, which keeps it short of a 5.

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 tight sentences, front-loaded with the rollback semantics before the workflow instruction. Every sentence adds information (what runs, what persists, what to do next) with no redundancy.

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 one-parameter tool with no output schema, the description supplies the missing return information ('reports the number of rows affected') and the non-persistence guarantee. Minor gaps remain around required privileges and the ambiguity versus execute_dml_preview, but the definition is essentially callable as written.

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% for the single `sql` parameter, so the schema already documents the accepted statement types. The description restates the same INSERT/UPDATE/DELETE/MERGE list and the dry-run behavior without adding syntax, size, or binding detail beyond the schema. 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 (execute) and resource (INSERT/UPDATE/DELETE/MERGE) plus the key differentiator: the statement runs inside a transaction that is immediately rolled back. This clearly separates it from execute_dml and run_query without needing to open a 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?

Explicitly states the workflow: validate here first, then 'Call execute_dml afterwards to apply the change for real.' This names the alternative tool and the condition that selects it. It does not, however, distinguish against the closely-named sibling execute_dml_preview, leaving one routing question 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?

With no annotations, the description carries the full load and does well: it discloses non-execution of the target SQL, the PLAN_TABLE requirement, that missing table/access failures surface as error results, and that progress is reported to progress-token clients. It omits that EXPLAIN PLAN itself writes rows into PLAN_TABLE, which is a relevant side effect an agent should know.

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 tight sentences, front-loaded with the action and mechanism, then prerequisites and failure behavior. No filler and no repetition of the schema.

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 single-parameter tool with no output schema and no annotations, it covers action, mechanism, prerequisite, failure mode, and progress reporting. The remaining gap is the shape of the returned plan and the PLAN_TABLE write side effect.

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?

Only one parameter with 100% schema description coverage, so the schema already explains `sql` including the typical statement types. The description adds no syntax or formatting detail beyond that, 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?

States a specific verb (generate and return) plus resource (Oracle execution plan) and the exact mechanism (EXPLAIN PLAN and DBMS_XPLAN). The clause 'without executing the statement' cleanly separates it from siblings like run_query, execute_dml, or execute_dml_preview.

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?

Gives clear conditions for use: planning a statement without running it, and the PLAN_TABLE prerequisite. It stops short of naming alternatives such as suggest_index or run_sql_tuning_advisor, so it lacks explicit when-not 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?

With no annotations, the description carries the full burden, and it does disclose useful traits: NULLs are excluded, the minCount threshold is applied, and the return includes a COUNT plus a sample ROWID. However, it says nothing about read-only vs mutation semantics, permissions, or cost on large tables, so the behavioral picture is only partially covered.

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 tightly written sentences with zero filler, and the core operation is front-loaded before the threshold/return detail. Every clause carries information not already implied by the 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 and no annotations, but the description partially compensates by stating the return contents (COUNT and sample ROWID) and the NULL/minCount semantics. Only the read-only guarantee and any performance caveat are left unstated.

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 table, schema, columns and minCount are already documented in the schema; the baseline is 3. The description reinforces the minCount default and NULL exclusion but adds no format or syntax detail beyond what the schema already supplies.

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 ('Find duplicate value groups') and pins the scope ('in one or more columns of a table'), which is enough to distinguish it from adjacent siblings like count_rows or get_sample_data. An agent can tell what it returns without opening any 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 by the purpose (you call it when you suspect duplicates across given columns), but there is no explicit when-to-use, no when-not-to-use, and no routing to or from siblings such as validate_fk_integrity or count_rows. Adequate but leaves the agent to infer the trigger condition.

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 does well: it discloses the scan algorithm (1..maxRange), the default (1000), the cap (10000), and the return semantics (lowest unused value). It omits caveats about performance on large scans or concurrency races between find and insert, so it is not exhaustive.

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 sentence that front-loads the action and packs the range, default, cap, and return value without wasted words. Dense but readable; slightly long for one sentence but every clause earns its 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?

For a 5-parameter tool with no annotations and no output schema, the description explains the mechanism and the returned value adequately. It could say more about failure cases (no free id within range) or concurrency, but an agent has enough to call it correctly.

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 all five parameters are already documented in the schema. The description restates maxRange's default and cap but adds no new semantics for table, column, schema, or excludeTable. Baseline 3 applies when the schema does the heavy lifting.

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 ('find a free id for a new row') and clarifies the mechanism: scanning a range and returning the lowest unused value. This is distinguishable from the sibling get_next_sequence_value since the description explicitly frames it as an alternative 'without a sequence'. It stops just short of naming the sibling outright.

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 'so a key can be inserted without a sequence' implies when to use it (when no sequence exists), but there is no explicit when-not guidance or named alternative. The condition is suggested rather than stated.

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 behavioral burden. It does useful work by disclosing the exact shape of the payload (the metric list) for a tool with no output schema, but it never states that this is a read-only dictionary lookup, whether statistics may be stale/missing if never gathered, or how it behaves for a nonexistent table or column.

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?

Front-loaded with the verb and resource, then the returned metrics, then the filter note — dense and almost waste-free. The trailing 'Optional column filter' fragment slightly duplicates the schema's column description, a minor redundancy.

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 read-only stats lookup with a fully documented 3-parameter schema and no output schema, enumerating the returned metrics in the description is the right compensation. It is slightly short on context about stat provenance and staleness, but nothing needed to invoke the tool correctly is missing.

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%; all three parameters (table, column, schema) are documented directly in the schema, including a helpful 'omit rather than guess' warning for schema. The description only restates the optional column filter and adds no format, casing or default semantics beyond the schema, 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?

Specific verb ('Return optimizer statistics') plus precise resource and granularity ('columns of a table'), and it enumerates exactly which metrics come back (NDV, density, null count, buckets, low/high, histogram type). It implicitly separates itself from table-level siblings like get_table_stats, but never names the neighboring get_histogram or get_table_stats, which is the only thing keeping it 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 notes an 'Optional column filter' but gives no when-to-use guidance, no prerequisites (e.g., stats must have been gathered), and no routing against the obvious alternatives get_table_stats, get_histogram or describe_table. The agent must infer the choice purely from the tool 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 disclosure burden. It does real work by enumerating exactly which database attributes come back (log mode, open mode, role, flashback status), which is the main behavioral question for a metadata read. It says nothing about required privileges, cost, or failure modes, but for a parameterless read-only lookup the risk surface is small.

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 that states the scope first and then the payload. No filler, no restatement of the tool name, every listed field earns its 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?

With no output schema, the description must describe the return value, and it does so field by field for a parameterless read. Minor gaps remain (value formats for creation date, whether flashback status implies any prerequisite), but an agent has enough to call it and interpret the result.

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?

Zero parameters, so the schema cannot carry meaning and there is nothing to mis-specify; the baseline of 4 applies. The description correctly offers no argument syntax because none exists.

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 ('Return') plus resource ('database-level information') with an explicit inventory of the fields returned (name, creation date, log mode, open mode, role, flashback status). It implicitly separates itself from the instance-level sibling get_instance_info by scoping to 'database-level', though it never names that sibling or any other.

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 this is the right call versus get_instance_info, get_system_stats, get_parameter, or the health report. The agent must infer from the field list alone that this is a one-shot database identity/settings snapshot.

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. It does disclose the underlying source (V$SYS_TIME_MODEL), which implies a read-only dynamic performance view and cumulative-since-startup semantics, but it omits privileges required for V$ access, whether values are cumulative or delta, and the unit/format of the returned numbers.

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 no filler; the source view and representative metrics are packed in efficiently. The trailing 'etc.' is the only mild weakness but does not bloat the definition.

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 no output schema, the description names the source view and sample fields, which gives the agent enough to know what comes back. It stops short of clarifying cumulative semantics, units, or row shape, which would fully close the gap left by the absent output schema.

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 and the description adds no misleading parameter claims.

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 ('Return') and resource ('database time model') and names the exact source view (V$SYS_TIME_MODEL) plus example contents (DB CPU, DB time, parse time). An agent can distinguish it from other stats tools like get_system_stats or get_instance_info, though the description never says how it differs from those siblings.

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. It does not tell the agent whether this is the right tool versus get_system_stats, get_instance_info, or get_database_info, nor any prerequisites, leaving selection entirely to inference.

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 does so well: it declares read-only behavior, that the DDL is never executed, the required grants (SELECT_CATALOG_ROLE plus EXECUTE on SYS.DBMS_METADATA), and how privilege/not-found failures surface. This is exactly the behavioral context an agent needs before calling a DDL 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?

Dense but front-loaded: purpose first, then safety, then parameters, then privileges/errors. Every sentence carries useful information, though the packing makes it read more like a spec than a description.

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 output schema and no annotations, yet the description covers return type (CLOB string), safety, prerequisites, and failure modes — everything needed to call it correctly. The one gap is the required/optional contradiction with the schema, which should have been aligned.

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 baseline is 3, and the description adds real value with the full list of valid type values (absent from the schema) and case-insensitive matching semantics. However, it claims 'All three parameters (schema, name, type) are REQUIRED' while the schema marks only name and type as required and explicitly calls schema optional/defaulting to the current schema — a direct conflict that undercuts the otherwise useful guidance.

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 ('Return the DDL definition of an object') and names the underlying mechanism (DBMS_METADATA.GET_DDL). An agent can immediately distinguish this object-level DDL extraction tool from the many list_* siblings.

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 strong operational context (read-only, required privileges, error behavior) but never explicitly states when to choose this over alternatives like describe_table or search_objects. Usage is implied rather than routed.

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 usefully discloses the edge direction semantics (dependent→referenced) and that the return includes a Mermaid diagram string, which is genuine behavioral detail. It says nothing about permissions, cost, or failure modes, so it is adequate but not rich.

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 tight sentences with the core action front-loaded and the return shape trailing. Nothing is wasted, though it is dense enough that the return description is somewhat compressed.

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 still covers the source view (all_dependencies), the scoping/filtering, and the return format (edges plus Mermaid string). Only permission and error behavior are omitted, which is minor for a read-style graph 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 description coverage is 100%, so the baseline is 3. The description restates that name/type are optional filters but adds no format, syntax, or interaction detail beyond what the schema already documents, so it neither helps nor hurts.

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: "Build an object-dependency graph for a schema," and specifies the output (directed dependent→referenced edges plus a Mermaid string). It does not, however, differentiate itself from sibling tools like list_dependencies or get_fk_graph, which an agent could easily confuse it with.

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 notes the graph is scoped to a schema and can be narrowed by name/type, but gives no when-to-use guidance, no exclusions, and never mentions the alternatives (list_dependencies, get_fk_graph) that an agent would weigh it against. Usage must be inferred.

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 usefully discloses the return content ('directed edges (child→parent) and a Mermaid diagram string'), which is real behavioral value since there is no output schema, but it never states that the operation is read-only, whether it hits the live database, or any cost/latency characteristics.

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 action and followed immediately by the return format. No filler or redundancy.

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 description covers the essential missing piece by describing the returned edges and Mermaid string. It is largely sufficient for calling the tool, though it omits read-only assurance and any indication of graph size or depth limits.

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 both parameters are already documented, including the 'omit rather than guess' default for schema. The description's 'for a schema or a single table' merely restates that split and adds no syntax or format detail beyond 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?

The description states a specific verb and resource ('Build a foreign-key relationship graph') plus its scope ('for a schema or a single table'), and it names the output shape. It does not, however, distinguish itself from close siblings such as get_dependency_graph or validate_fk_integrity, leaving the agent to infer the difference.

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?

Scope guidance is present ('a schema or a single table', 'leave blank for the entire schema'), which implies when the table parameter matters, but there is no explicit when-to-use or when-not-to-use guidance relative to get_dependency_graph or validate_fk_integrity.

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 discloses what is returned (endpoint values, histogram type), which implies a read operation, but says nothing about permissions, read-only nature, error behavior, or pagination.

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 return content and followed by the use case; both sentences earn their place with no filler.

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 low-complexity read tool with fully documented parameters and no output schema, the description covers what it returns and why it matters. It is largely complete, with only minor gaps around output format and safety.

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 table, column, and schema are already documented in the schema (including the default-schema guidance). The description adds no parameter meaning beyond the schema, 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 specific verb (Return) and resource (optimizer histogram endpoints for a column), and names the two histogram types (frequency, height-balanced). This clearly distinguishes it from a plain stats tool, though it does not explicitly contrast with the close sibling get_column_stats.

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?

"Useful to understand data skew and cardinality estimates" gives a rationale for calling it, but there is no explicit when-to-use versus alternatives like get_column_stats or get_table_stats, and no exclusions or prerequisites.

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 return payload (name, host, version, startup time, status, archiver, thread). It says nothing about permissions, cost, or whether it is guaranteed read-only, but for a zero-argument instance-metadata read there is limited further behavior to disclose.

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 the verb and resource first and the field list after the colon. Nothing is padding; every token earns its 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?

With no output schema, the description usefully enumerates the returned attributes, and with zero parameters and no annotations there is little else required. The only gap is the absence of any differentiation from get_database_info, which a sibling-aware agent would want.

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 are no parameter semantics to document and the baseline is 4. The enumerated field list is a return-value description rather than a parameter description, but it is not misleading here.

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 ('Return Oracle instance information') and enumerates the exact fields returned, so the scope is unambiguous. It does not explicitly distinguish itself from the nearby sibling get_database_info, which an agent may reasonably confuse it with.

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 no when-to-use guidance, no prerequisites, and never mentions the alternative get_database_info sibling that covers similar ground. The agent is left to infer selection from the name 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 burden, and it does so well: it discloses non-idempotence (advances the counter, value cannot be reused) and the cache>0 hazard that makes the returned value potentially already-consumed. It omits failure/privilege behavior and the concrete return type, which are the remaining gaps for a 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?

Four short sentences, front-loaded with the core action and then escalating to the warning. Every sentence adds a distinct fact (what it returns, that it mutates, the cache caveat, the sparing-use advice) with no filler.

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 description must carry the behavioral contract, and it covers the critical side-effect and correctness risks thoroughly. It stops short of naming the sibling alternative for obtaining safe keys and does not state error behavior, leaving minor gaps.

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% and both parameters (schema, sequence) are documented there, including the 'omit rather than guess' default for schema. The description adds no parameter-level meaning beyond the schema, so the baseline of 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 resource ('Return the NEXTVAL of a sequence') and immediately frames the operation as a side-effecting read, which separates it from the read-only list_*/get_* siblings. An agent can distinguish it from list_sequences, get_sequence_info and create_sequence without opening any 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?

Gives clear operational context ('Use sparingly') and a concrete pre-use condition: verify the value is not already present in the target table when cache > 0. It does not name an alternative tool (e.g. find_free_id, which exists among siblings and serves a similar key-generation need), so the routing guidance is incomplete but the caution guidance is genuinely useful.

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 data source (V$PARAMETER) and the shape of returned fields, which implicitly signals a read-only catalog query, but it never explicitly states read-only semantics, permission requirements, or result-set size expectations.

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, zero filler, and the core operation is front-loaded before the optional filtering detail. Nothing in the text is redundant boilerplate.

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 one-optional-parameter read tool with no output schema, the description compensates by listing the returned columns, which is the main gap an absent output schema would otherwise leave. Minor omissions (read-only confirmation, row-volume expectations) keep it short of perfect.

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?

With a single parameter at 100% schema description coverage, the schema already documents the LIKE pattern, case-insensitivity, and % wildcard. The description restates the same facts rather than adding syntax, escaping rules, or edge-case behavior, 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?

States a specific verb and resource ('Return Oracle initialization parameters from V$PARAMETER') and enumerates the returned attributes (type, value, default/modified flags, modifiability), which cleanly separates it from sibling info tools like get_instance_info or get_database_info. An agent can identify the exact data domain 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 description conveys that omitting the pattern lists all parameters and supplying one filters, which covers the two calling modes. It never explains when to prefer this tool over adjacent instance/database introspection tools, so guidance stops at the implicit level.

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 disclosure burden. 'List' implies a safe read operation and the scope (all schemas when no schema given) is noted, but there is no mention of permissions, result limits, pagination, or volume of output.

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 with zero waste, front-loading the action and resource before the filters and use case. Nothing needs trimming and the important information comes first.

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 read-only list tool with three optional, fully documented parameters and no output schema, the description covers what to expect and when it matters. It could be more complete by clarifying how it relates to sibling tools that report invalid or dependent objects.

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 all three parameters, including the enumerated type list. The description merely restates that schema, name, and type are optional filters without adding format or behavioral detail beyond 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 ('List') and resource ('compilation errors of PL/SQL units') and enumerates the covered object kinds (procedures, functions, packages, triggers, types). The purpose is immediately clear, though it does not explicitly distinguish itself from close siblings like list_invalid_objects or describe_plsql.

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?

'Critical for diagnosing broken code' gives implied usage context, but there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as list_invalid_objects. Usage is left to inference from the purpose statement.

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 a real trait — only the *first* N rows, i.e. a truncated preview with no ordering guarantee — but it never confirms read-only safety, side effects, or any row ceiling beyond the server default.

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 short sentence, front-loaded with the action and scope, with no wasted words. Sized appropriately for a simple preview tool.

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, so the description is the only source of behavioral context, and it covers only the row-count behavior. It omits return shape, ordering determinism, and safety profile — minor but real gaps for an agent deciding whether to call it.

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 all three parameters (rows, table, schema) are already documented in the schema. The description's "first N rows" mildly reinforces the rows parameter but adds no format or default nuance beyond what the schema states.

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?

"Return the first N rows of a table as a quick data preview" gives a specific verb (return), resource (table rows), and the scope qualifier (first N, preview). It is clear, but it does not name or distinguish itself from close siblings like run_query, count_rows, or describe_table.

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 "quick data preview" implies the intended context (eyeballing data rather than querying or counting), but it never states when to prefer this over run_query or count_rows, nor any exclusions. Usage is left to inference.

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 present, the description carries the full behavioral burden and does so well: it declares read-only semantics, explicitly states NEXTVAL is not consumed so the counter is untouched, and enumerates the returned metadata fields. It omits error behavior (e.g., unknown sequence name) and required privileges.

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 tight sentences with zero filler, front-loading what is returned before the behavioral caveat and the alternative-query guidance. Every sentence earns its 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?

No output schema exists, so the enumeration of return fields (min_value, max_value, increment_by, etc.) usefully compensates. Scope, source, and safety profile are covered; only failure/error behavior for a missing sequence is left unstated.

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% and both parameters are already documented in the schema, including the 'omit rather than guess' guidance for schema. The description adds no syntax or format detail for either parameter, so baseline 3 is appropriate.

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 ('Return metadata for a single sequence') and names the exact source view (ALL_SEQUENCES). The tool is cleanly distinguishable from sibling list_sequences (plural listing) and get_next_sequence_value (which mutates the counter).

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?

Gives explicit routing guidance: 'Prefer this over querying ALL_SEQUENCES/DBA_SEQUENCES directly,' and the read-only note implicitly steers callers away from get_next_sequence_value when they don't want to advance the counter. It stops short of naming that sibling tool or stating when a metadata read is inappropriate.

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 usefully discloses that only in-progress operations are returned and that each row carries progress percentage and ETA, but says nothing about privilege requirements (V$ views typically need elevated access), row volume, or read-only safety beyond the implicit 'List'.

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 tight sentences with zero filler: the source view and scope lead, and the filter/visibility constraint follows. Every clause earns its 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?

For a single-parameter read tool with no output schema, the description adequately covers source, scope, return content (progress %, ETA), and filtering. The only meaningful gap is the absence of privilege/pagination context, which is minor for a V$ monitoring query.

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% and the single parameter is already documented as 'Optional session id (SID) filter.' The description's 'Optional sid filter' merely restates the schema, adding no syntax, format, or edge-case guidance, 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 specific verb (List) and resource (long-running operations) and names the exact source view V$SESSION_LONGOPS, plus concrete examples (backups, stats gathering, long queries). An agent can distinguish this from monitoring siblings like list_active_sessions or get_wait_events 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?

The description implies usage (in-progress operation monitoring) and notes the optional sid narrowing filter, but never states when to prefer this over adjacent tools such as list_active_sessions or get_session_sql_text, nor any prerequisites. Usage is inferable but not 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?

With no annotations, the description carries the full burden and delivers substantive behavioral detail: it aggregates directly granted privileges plus effective privileges from enabled roles, deduplicated and ordered. It does not describe the return shape or whether ordering is deterministic, but the aggregation semantics are disclosed well.

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 purpose is front-loaded in the first clause, followed by a clearly demarcated WHEN TO CALL section. Both sentences are dense with load-bearing information and there is no filler.

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 must convey the return contents, and it does so reasonably by enumerating what is included (direct grants plus effective role privileges, deduplicated, ordered). It could be marginally richer on output format, but is largely complete for a no-arg read 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?

The tool takes zero parameters, so there is no parameter semantics to document; the schema is empty and coverage is 100%. Baseline 4 applies for a no-parameter 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 ('List') and resource ('system privileges available to the current connection'), and further clarifies scope as 'directly granted system privs plus effective privs from enabled roles'. This distinguishes it from the sibling get_session_roles, which covers roles rather than privileges.

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 an explicit WHEN TO CALL condition (only when the user explicitly asks what privileges the connection has) and an explicit when-not-to-call exclusion (do NOT call as a preamble before querying tables or objects). Nothing is left to inference.

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 the returned fields (admin option, default-role flag) and a misuse warning, but never states that it is a side-effect-free read, nor any permission/connection prerequisites. That is a modest but real gap for a zero-annotation 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, zero filler: the first front-loads what is returned, the second front-loads the calling condition and the prohibition. Every clause earns its 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?

With no output schema, the description compensates by naming the returned attributes, and the usage constraints cover the main selection risk. The only shortfall is the absence of any behavioral note (read-only nature, connection prerequisite), which would matter more given 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 takes no parameters, so there is nothing for the description to disambiguate; the schema is trivially complete at 100% coverage. Baseline for zero parameters 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 (List) and a precisely scoped resource (roles enabled for the current connection), plus the returned attributes (admin option, default-role flag). This clearly separates it from the nearby sibling get_session_privs, which deals with privileges rather than roles.

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?

Explicit when-to-call ('only when the user explicitly asks which roles the connection has') and an explicit exclusion ('do NOT call as a preamble before querying tables or objects'). Nothing about usage is left to inference.

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. 'Currently being executed' implicitly hints that idle sessions yield nothing, but it never states what happens for an inactive/unknown session, whether querying another user's session SQL requires elevated privileges, or whether the result is truncated for very long statements.

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, resource, and qualifier appear in order. It is efficient, though the terseness leaves behavioral gaps unaddressed.

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 two-parameter read with fully covered schema and no output schema, the definition is minimally adequate. It hints at the return value ('full SQL text') but omits behavior for inactive sessions and any privilege requirements, which an agent would need to invoke it confidently.

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 sid (SID) and serialNum (session serial number). The description merely names the same two identifiers, adding no format, source, or retrieval guidance beyond 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?

The description states a specific verb (Return) and a precisely scoped resource (the full SQL text currently being executed by a session), which clearly separates it from siblings like list_top_sql or get_wait_events. It does not explicitly name a sibling or contrast scope, so it falls short of the top band.

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, no mention of alternatives (e.g., list_top_sql for aggregate SQL, get_wait_events for waits), and no exclusions. The phrase 'given its sid and serial#' only restates the input requirement rather than explaining when this tool is the right choice.

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. It usefully discloses that values are 'cumulative' (versus deltas/rates) and names the underlying V$SYSSTAT view, which implies a read-only operation, but it says nothing about permissions, row volume, or snapshot semantics.

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 waste; the resource, its source, and representative metrics are all delivered immediately.

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 no output schema, the description does the needed work by naming the source view and sampling the returned metrics. It would be stronger with a note on the volume/granularity of returned rows, but coverage is reasonable.

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. Baseline 4 applies since no parameter semantics are needed.

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 (Return) and resource (cumulative system statistics from V$SYSSTAT) and enumerates concrete metrics like parse count, execute count, DB time, and physical reads/writes. This makes the tool's scope evident, though it does not explicitly distinguish itself from sibling stats tools such as get_db_time_model or get_instance_info.

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 offers no when-to-use guidance, no prerequisites, and no comparison against alternatives in the crowded stats/info sibling set. An agent must infer that this is the instance-wide cumulative-stat source.

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. It usefully discloses the returned data fields, which implies a read-only operation, but says nothing about privileges required to read stats views, what happens when a table was never analyzed (null/stale stats), or freshness/refresh considerations.

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 verb and resource lead and the field list follows 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?

No output schema exists, but the description effectively enumerates the return fields, which covers the main informational need for this low-complexity read tool. Only the privilege/null-stats behavior is missing, a minor gap for a simple read.

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%: both 'table' and 'schema' are documented in the schema, including the 'omit rather than guess' guidance for schema. The description adds no parameter meaning beyond that, so the baseline of 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 (Return) plus a precise resource (optimizer statistics for a table) and enumerates the exact fields returned (row count, blocks, sample size, last analyzed, degree, partitioned, compression). That field list cleanly separates it from siblings like get_column_stats, get_histogram, and count_rows.

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 says what it returns but never states when to use it versus alternatives such as get_column_stats, get_histogram, count_rows, or describe_table. There are no preconditions or exclusions, so the agent must infer usage 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 are provided, so the description carries the full behavioral burden. It discloses the underlying data source (V$SESSION_WAIT), which is useful context, but says nothing about required privileges, whether the read is truly side-effect-free, rate/cost implications, or what the result set 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 tight sentences, front-loaded with the core action and source view before the optional filters. No wasted words.

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 should carry more weight, yet it does not describe return columns or result shape for the V$SESSION_WAIT view. It is adequate for invoking the tool (optional filters fully covered) but leaves the return and safety context thin.

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 both parameters are already documented, establishing a baseline of 3. The description restates the filters and adds one extra wait_class example ('Concurrency'), but adds no syntax or behavioral meaning beyond 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 ('List current wait events') and even names the source view (V$SESSION_WAIT), so the agent knows exactly what data is returned. It does not differentiate from the many sibling session/diagnostic tools (list_active_sessions, list_blocked_sessions, get_session_longops), 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?

The word 'current' implies a live-snapshot diagnostic use case, but there is no explicit when-to-use, when-not-to-use, or named alternative among the session-oriented siblings. Usage is only implied.

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 provided, the description carries the full behavioral burden. It conveys read-only intent and the notion of an ACTIVE scope, but says nothing about privileges required to read session data, any row caps or pagination, or whether the elapsed/last-call values are snapshots. That is meaningful missing context for a monitoring tool, though not a contradiction.

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, purpose and returned fields front-loaded, filters last. Every clause carries information and there is no filler.

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 returned columns, which is the key information an agent needs. Missing only secondary context such as privilege requirements or result-size behavior, which keeps it short of a 5.

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?

Both parameters have 100% schema description coverage ('Optional session id (SID) filter', 'Optional Oracle username filter'), so the schema already documents them fully. The description only restates that these filters are optional, adding no format, matching, or edge-case semantics beyond 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 (List) and resource (ACTIVE sessions) and enumerates the columns returned (username, machine, program, last call elapsed, module, logon time), so the agent knows exactly what it gets. It does not, however, differentiate itself from the nearby siblings list_blocked_sessions or get_session_sql_text, which an agent might reasonably confuse for session inspection.

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?

"Currently ACTIVE" plus the two optional filters implies the use case (inspect live sessions, optionally narrowed by user or SID), but there is no explicit when-to-use or when-not-to-use guidance and no pointer to the blocked-session or session-SQL siblings. Usage is inferable rather than stated.

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. It usefully discloses the shape of the result (blocker sid/username/program plus wait event), which acts as informal output documentation, but says nothing about whether the call is read-only, its cost, or any limits.

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 that leads with the verb and scope and appends the returned detail. Every clause earns its place with no redundancy.

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 covers the essential contract for a parameterless read: what it lists and what fields come back. It is nearly complete for this complexity level, missing only explicit read-only confirmation and any ordering/pagination note.

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 the baseline is 4; there is nothing for the description to disambiguate. The schema is an empty object and no additional parameter meaning is needed.

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 ('List sessions currently blocked by another session') and enumerates the returned fields (blocker sid/username/program, wait event). It is clearly distinguishable from list_locks and get_wait_events by focusing on the blocked/blocker pairing, but 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 implied by 'currently blocked' – an agent can infer this is for diagnosing blocking chains – but there is no explicit statement of when to use this versus list_locks, list_active_sessions, or get_wait_events, and no exclusions or prerequisites.

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 discloses the return contents (constraint types with columns and references), but says nothing about permissions, row limits, or pagination for what is presumably a read-only listing.

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 that names the resource first and then the returned fields. Zero waste, no filler.

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 two-parameter read tool with no output schema, the description covers what is listed and what the entries contain. The lack of a stated return shape is a minor gap but acceptable given the tool's simplicity and full 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 coverage is 100% and both parameters (table, schema) are fully documented in the schema, including the 'omit rather than guess' default note. The description adds no parameter detail beyond the schema, so baseline 3 is appropriate.

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 (list) and resource (constraints on a table), and enumerates the constraint types returned (primary key, foreign key, unique, check). This clearly separates it from list_indexes and describe_table, though it never names a sibling 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 implied by the resource — you call it to enumerate a table's constraints — but there is no explicit when-to-use guidance and no mention of alternatives like get_ddl or validate_fk_integrity that overlap in the integrity domain.

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. It discloses the returned metrics but says nothing about the operation being read-only, which datafiles are covered (whole DB vs. tablespace subset), or permission requirements.

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 sentence that front-loads the verb and resource, then lists the relevant columns with no filler. Every clause earns its 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?

With no parameters and no output schema, the description reasonably tells the agent what comes back. The main gap is scope – it doesn't state whether IO stats cover all datafiles or a filtered subset.

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, which is the baseline-4 case; there is no parameter semantics to clarify. The description's field listing is a bonus rather than a substitute for schema detail.

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 (List) and resource (datafiles) and enumerates the metrics returned (size, physical/block reads and writes, average IO time). This is clearly distinct from sibling stat tools like get_system_stats or get_table_stats, though it never 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 guidance on when to use this versus related tools such as get_table_stats, get_system_stats, or list_top_sql. No prerequisites or scope conditions are mentioned, leaving the agent to infer context on its own.

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 present, so the description carries the full disclosure burden. It usefully adds that results are scoped to the current user and names three returned attributes, but it does not explicitly confirm the operation is read-only, describe required privileges beyond visibility, or mention side effects or rate limits.

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 tightly written sentence with the resource and scope front-loaded, followed by the returned attributes. Every component earns its place and there is no redundant or filler text.

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, zero-parameter list tool with no output schema, the description covers the essential facts: what is listed, what scope applies, and what fields are returned. It stops short of richer return-format details or explicit read-only confirmation, but those gaps are minor for this tool's 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 tool takes zero parameters, so there is no parameter semantics for the description to clarify. The baseline score of 4 applies because no compensation for schema gaps is needed.

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 states a specific verb (List) and resource (database links), plus the visibility scope (visible to the current user), so the purpose is immediately clear. However, it does not explicitly differentiate itself from other list_* siblings such as list_synonyms or list_objects, relying instead on the resource name to do that work.

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 tool versus alternatives. The description only states what the tool returns; an agent must infer that this is the tool for listing database links rather than reading it as an explicit usage recommendation.

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. It usefully clarifies directionality (dependencies, not dependents), but does not state whether traversal is recursive/transitive, whether results are depth-limited, or the return shape. For a low-risk list tool this is adequate but not complete.

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 tight sentences, zero waste, with the core action front-loaded and the purpose cue following. Nothing to trim.

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?

Adequate for a simple three-parameter listing tool with full schema coverage and no output schema, but it omits recursion/depth behavior and the shape of returned rows, which an agent would want before trusting the result for impact analysis.

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 schema already documents name, the optional type filter, and the schema-defaults guidance; the description adds nothing parameter-specific, which is acceptable given 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 and resource ('List objects that a given object depends on') and pins down the direction as 'referenced objects', which disambiguates from the reverse 'who depends on me' reading. It does not name the closely related siblings get_dependency_graph or get_fk_graph, so differentiation is left to the agent.

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?

'Useful for impact analysis' gives an implied context, but there is no explicit when-to-use versus get_dependency_graph or get_fk_graph, nor any stated exclusions or prerequisites. The agent must infer the 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?

No annotations are supplied, so the description carries the full burden. 'List' implies a read-only operation, which is reasonable for this verb, but the description says nothing about privilege scoping (which directories are visible to the current user), whether results are paged, or what the return shape looks like. For a low-risk zero-parameter listing tool this is acceptable but not rich.

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 core purpose front-loaded and the 'filesystem paths' detail appended without waste. It is appropriately sized, though it stops just short of the detail that would make it fully self-sufficient.

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 description is the only source of behavior, and it omits Oracle-relevant context such as visibility scoping (ALL_DIRECTORIES vs DBA_DIRECTORIES) and required privileges. Adequate for a trivial listing tool, but thin.

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 schema defines zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool is 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?

States a specific verb (List) and resource (Oracle directory objects) and clarifies the output includes filesystem paths, which disambiguates it from OS-level directory listings. It is easily distinguished from siblings like list_schemas or list_datafile_io, though it does not explicitly name or exclude any sibling.

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 when-to-use guidance, no prerequisite or privilege context, and no mention of alternatives (e.g., run_query against ALL_DIRECTORIES/DBA_DIRECTORIES). The usage is only implied by the verb 'List'.

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. It does disclose the returned attribute set, which is useful behavioral context, but is silent on row limits, ordering, pagination, and privilege requirements for reading external table definitions. 'List' implies read-only, but nothing confirms scope or safety.

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 resource lead and the attribute list follows economically. It is appropriately sized for a simple listing tool, though the attribute enumeration crowds out space that could have held scope or usage guidance.

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, but the description names the columns that come back, which partly covers return semantics. For a one-optional-parameter list tool with no annotations, it is adequate but leaves open whether regular tables are excluded, how results are ordered or capped, and what privileges are needed.

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?

Only one parameter and schema description coverage is 100%, so the schema fully documents the optional schema/owner filter and the omit-to-search-all behavior. The description adds nothing beyond that, which is the expected baseline when the schema does the heavy lifting.

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 (List) and resource (external tables), and enumerates the attributes returned (access driver, default directory, reject limit, access parameters), which distinguishes it from the plain list_tables sibling by implication. It never explicitly contrasts with list_tables, so differentiation relies on the reader knowing what an external table is.

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 this over list_tables or list_directories, and no statement of exclusions or prerequisites. The only usage hint is the schema parameter's own text in the schema itself.

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 what is surfaced (columns, uniqueness, status), but says nothing about pagination, permissions, or exhaustive-vs-filtered behavior. The read-only nature is only implied by 'List'.

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, leading with the verb and resource and closing on return contents.

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 two-parameter read tool with no output schema, the description covers scope and the salient return fields. It would be stronger with a note on result ordering or volume, but it is largely sufficient to invoke correctly.

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% and the schema fully documents both 'table' and 'schema' (including the helpful 'omit rather than guess' default note), so the description adds no parameter detail beyond it. 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?

Specific verb (List) + resource (indexes) + scope (on a table) + what is returned (columns, uniqueness, status). An agent can immediately tell it apart from create_index or suggest_index, though it never names the closest sibling list_unused_indexes.

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 scope 'on a table' but there is no explicit when-to-use, no exclusion, and no routing to alternatives like list_unused_indexes. Adequate but leaves the agent to infer 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. 'List' implies a read-only operation and it discloses the returned columns (index name, partition, status, leaf blocks, distinct keys, num rows), which is useful. However, it says nothing about permissions, behaviors on unpartitioned tables, or result volume.

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 waste, naming the resource first and then the return fields.

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 tool with no output schema, listing the returned columns is a valuable substitute. But with no annotations and no usage guidance, an agent still lacks enough context to confidently pick this over sibling list tools.

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% and both parameters (table, schema) are well documented in the schema itself. The description adds no syntax or format detail beyond what the schema provides, so the baseline of 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 (List) and resource (index partitions on a table), and enumerates the returned fields, making it distinct from table-level siblings like list_partitions. It stops short of explicitly naming the alternative to differentiate in ambiguous cases, but the scope is clear.

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 use this versus list_partitions, list_subpartitions, or list_indexes. No prerequisites, permissions, or mention of what happens on non-partitioned indexes.

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. It does disclose useful scope behavior (excludes index/LOB partitions) and the semantics of the INVALID status, but does not state that it is read-only, whether results are paginated or ordered, or any privilege requirements. 'List' implies a safe read, but that is left to inference.

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, front-loaded with the defining filter criterion and followed by scope and parameter notes. 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?

There is no output schema and no annotations, so the description should ideally say what a returned row looks like (name, owner, type, status) and whether the list is exhaustive. It covers the selection semantics well but leaves the return shape entirely unspecified for a read tool with zero structured support.

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 enum examples for type and the 'omit to search all schemas' semantics for schema are already documented. The description only restates 'Optional schema and type filter' and adds no syntax, default, or interaction detail beyond 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 (List) and resource (objects) qualified by a precise and uncommon criterion: status = INVALID, glossed as 'broken code needing recompile'. That criterion cleanly separates it from the many sibling listers such as list_objects, list_procedures and list_views, which have no status filter.

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 when this tool is relevant (you want invalid/broken objects) and notes the scope exclusion for index/LOB partitions, but it never says when to prefer it over list_objects or search_objects, nor points to a recompile/remediation tool. Usage is inferable rather than explicit.

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 discloses the shape of the result set (the LOB-specific attributes), and 'List' implies a read-only operation, but it says nothing about permissions required, behavior when the table has no LOB columns, or error handling for an unknown table.

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 sentence with the resource front-loaded and the returned attributes trailing. Every clause earns its place; there is no filler or repetition 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?

For a two-parameter read tool with full schema coverage and no output schema, the description supplies the return fields an agent needs to decide whether to call it. It is only missing edge-case behavior (non-LOB tables, unknown table errors), which is a minor 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?

Schema description coverage is 100%, and the schema already explains both 'table' and the optional 'schema' with its default-to-current-schema caveat. The description adds only the implicit notion that 'table' is the target of the listing, so the baseline 3 for schema-covered parameters is appropriate.

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 LOB columns of a table') and enumerates the attributes returned (segment, index, caching, logging, SECUREFILE flag, retention), which scopes it well against generic siblings like describe_table. It does not explicitly name or contrast itself with any sibling, which is what keeps it 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?

There is no when-to-use guidance, no preconditions, and no mention of alternatives such as describe_table or get_ddl for broader column metadata. Usage is only weakly implied by the phrase 'of a table'; the agent must infer the call 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that output includes the locked object name and a decoded lock mode, and that both held and requested locks are covered, but it says nothing about permissions required, row limits, or whether the read is expensive.

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 tightly-written sentence with the resource front-loaded and the output contents trailing. Every clause earns its place with no filler.

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 listing tool with no output schema, the description adequately explains what the returned rows describe (object name, lock mode, held vs requested). A brief note on required privileges or result size 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 the baseline of 4 applies. There is no parameter surface for the description to clarify or for the schema to document.

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 (List) and resource (locks), then narrows scope to DML/transaction/user locks and clarifies it covers both held and requested locks. An agent can tell exactly what this tool surfaces without consulting any 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?

No when-to-use guidance, no prerequisites, and no mention of related siblings such as list_blocked_sessions or list_active_sessions. The agent must infer from the name alone that this is a diagnostic listing tool.

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 full behavioral burden. It does disclose the read-oriented payload (refresh mode, method, last refresh, staleness), but says nothing about privileges required, row volume, or result limits for a catalog-wide listing when schema is omitted.

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 with the core capability front-loaded; the second sentence mostly echoes what the schema already documents, so it is efficient but slightly redundant rather than fully earning its 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?

For a read-only listing tool with no output schema, naming the four returned attributes compensates well for the absent return contract, and the parameters are fully documented. Only the missing when-to-use context and any large-result caveat keep it from being 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?

Schema description coverage is 100%: the schema already explains that omitting schema searches all schemas and that namePattern is a LIKE defaulting to '%'. The description only restates 'Optional schema and LIKE name pattern', adding no semantics beyond 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 materialized views') plus the salient returned attributes (refresh mode, method, last refresh, staleness), which differentiates it in substance from list_views and list_mview_logs. It stops short of explicitly naming those siblings or contrasting scope with them, so it is clear but not routing-grade.

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 when-to-use guidance: the description never says to prefer this over list_views, list_mview_logs, or search_objects, nor any prerequisite. Usage is only implied by 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?

With no annotations, the description carries the full behavioral burden but discloses almost nothing: it never states this is a read-only/safe operation, what fields are returned, ordering, or any privilege requirements. For an Oracle catalog-listing tool, this leaves meaningful 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?

Two short, front-loaded sentences with no wasted words. It is efficient, though the brevity borders on under-specification rather than crisp completeness.

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 one-parameter read-only listing tool with no output schema and no annotations, the description is minimally adequate. However, given zero annotation coverage, it should say more about the read-only nature and what the listing yields.

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?

There is a single optional parameter with 100% schema description coverage ('Schema (owner) name. Omit to search all schemas.'). The description's 'Optional schema' adds nothing beyond the schema, 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 specific verb and resource (List materialized view logs), which is discernible from siblings like list_materialized_views and create_mview_log. It does not explicitly contrast itself with those siblings, but the resource is precise enough to route correctly.

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 offers no when-to-use guidance, no prerequisites, and no pointer to alternatives such as list_materialized_views or create_mview_log. 'Optional schema' is the only usage hint and is a restatement of the parameter's optionality.

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-only enumeration but says nothing about result volume, paging, ordering, required privileges, or how object names are returned — material gaps for a catalog-wide listing 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 short sentences, well front-loaded with the action and resource. Minor deduction for the open-ended '...' list, which is vague rather than 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?

With two optional params, no annotations and no output schema, the description is minimally adequate — it lets an agent call the tool — but leaves an agent guessing about scope overlap with dedicated list_* siblings and about result shape/size.

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%: the 'type' enum-ish values and the 'schema' semantics (omit to search all schemas) are already spelled out in the schema. The description restates 'Optional schema and object type filter' without adding syntax or format detail, so it earns the baseline 3.

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?

Clear verb+resource ('List database objects') with a parenthetical enumeration of object kinds, so the agent knows this is the generic catalog lister. It does not, however, distinguish itself from the many single-kind siblings (list_tables, list_views, list_procedures, list_types), which overlap heavily with what it claims to return.

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 only notes that the schema and type filters are optional. It never says when to pick this broad lister over list_tables/list_views/list_procedures, nor what happens if type is omitted (does it return everything, including types with dedicated 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the returned columns (name, position, high value, row count, compression, last analyzed), which is genuine output context, but says nothing about permissions, behavior on non-partitioned tables, or result limits.

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 that names the action, the target, and the returned fields with zero filler. Every clause earns its 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?

With no output schema and no annotations, the description partially compensates by enumerating the returned columns, and the two parameters are fully documented in the schema. It is only short of error/edge-case behavior for non-partitioned tables and sibling routing.

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% and the two parameters are documented in the schema, including the 'omit rather than guess' caveat for schema. The description adds no parameter-level 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?

States a specific verb (List) and resource (partitions of a partitioned table), and the qualifier 'of a partitioned table' scopes it away from index partitions. It does not, however, explicitly name its close siblings list_ind_partitions or list_subpartitions, so the agent must infer 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?

No when-to-use guidance, no prerequisites, and no named alternatives. With list_ind_partitions and list_subpartitions in the same family, the absence of routing guidance is a real gap.

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 nothing is said about result size, truncation, ordering, pagination, or what a returned row contains. For a catalog-scan tool in a database with many objects, those omissions are material.

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, front-loaded sentences with no padding, and the resource list comes first where it matters. The second sentence largely duplicates schema content, so it earns its place only marginally, keeping this just under a top score.

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 description should compensate by explaining what the call returns and any behavioral caveats. It instead stops after naming the object classes and filters, leaving return shape, volume, and read-only confirmations 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 100%, so the schema already documents type, schema, and namePattern in detail, including the LIKE semantics and the default '%'. The description only restates that these filters exist and are optional, adding essentially nothing 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?

The description states a specific verb ('List') and the exact resource classes it returns (stored procedures, functions, packages, types), which is more informative than the bare name. However, it offers no differentiation from closely related siblings such as list_objects, search_objects, list_types, or describe_plsql, so an agent cannot easily tell when this one is the right pick.

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 second sentence lists the available filters ('Optional schema, LIKE name pattern and object type filter'), which is parameter information rather than usage guidance. There is no statement of when to prefer this over list_objects or list_types, and no exclusions or prerequisites.

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 disclosure burden. It does add real behavioral context — result ordering (start time desc), the underlying scope (recent runs), and an explicit boundary on what this view does not contain — but it says nothing about privileges needed to read scheduler views, truncation behavior, or pagination.

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, front-loaded with the verb and resource, then return fields, then ordering, then the boundary caveat. Every sentence contributes and nothing is 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?

With no output schema, the description correctly enumerates the returned columns and states the sort order, so an agent can interpret results. It could still note the default row cap or privilege requirements, but for a simple read-only list tool it is nearly 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?

Schema description coverage is 100%, so limit, schema, and jobName are fully documented in the schema itself. The description adds no syntax, default, or semantics 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?

Specific verb+resource ('List ... DBMS_SCHEDULER job run details') plus an enumeration of the returned columns, which is more than a restatement of the name. It clarifies the resource is run details rather than job definitions, but never explicitly names the sibling list_scheduler_jobs as the tool for job definitions, so sibling differentiation is only partial.

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 (inspect recent execution history) but there is no explicit when-to-use or when-not-to-use clause. The parenthetical pointing operation/status to ALL_SCHEDULER_JOB_LOG is useful negative guidance but it steers toward a different Oracle view, not toward a sibling MCP tool.

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