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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key behaviors: per-item error collection, independent call execution, and auto-injection of the database parameter. While it does not explicitly state that operations execute sequentially (covered in the schema) or describe the exact return structure (output schema exists), the description adequately discloses the most critical behavioral traits for an agent to use the tool safely.

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 exceptionally concise, using three short paragraphs. The main purpose is stated in the first sentence, followed by usage guidance and a note on database handling. Every sentence adds value without redundancy. It is front-loaded and well-organized, making it easy for an agent to quickly grasp the tool's function and when to use it.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (3 parameters, array of operations, output schema), the description covers the essential aspects: purpose, usage, and database injection. It does not explicitly mention the maximum of 50 operations or sequential execution, but these are documented in the schema. The description is sufficient for an agent to correctly invoke the tool, especially since the schema provides the remaining details.

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. The description adds significant value by explaining the auto-injection behavior of `database` and how to override it for cross-database operations, which is not obvious from the schema alone. It also clarifies the 'independent' nature of operations, which complements the operations array schema. The description does not rehash the `stop_on_error` parameter, which is already described in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Run 2+ independent tool calls in a single request with per-item error collection.' It uses a specific verb ('run') and resource ('tool calls'), and explicitly differentiates from the sibling `execute` by mentioning it is preferred for independent calls. Concrete examples (decompile, rename, set comments, fetch xrefs) further clarify the intended use.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool vs. alternatives: 'Preferred over `execute` for independent calls' and 'Use `execute` only when chaining one tool's output into another.' It also instructs on parameter handling ('`database` is auto-injected into each operation — omit from params') and cross-database overrides, leaving no ambiguity about selection or invocation 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose key behaviors: it can call hidden tools, and it auto-injects the database parameter into arguments unless already present (via schema but also implied). It also implies single-call behavior. However, it does not describe what happens if a tool fails, error handling, or any side effects, leaving some gaps. Still, given the tool's meta nature, it covers essential aspects.

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 extremely concise, just two sentences. The primary purpose is front-loaded in the first sentence, and usage guidance follows immediately. Every word earns its place with no fluff 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?

Given the tool's complexity as a meta-tool with nested objects and an output schema, the description is fairly complete. It clarifies the main use case (single hidden-tool calls), the differentiation from batch, and the auto-injection behavior. However, it could benefit from a brief note on what the output schema represents (e.g., the result of the called tool) and how errors might be returned, but the output schema itself may cover return values. The absence of these details loses a point.

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 documents all three parameters (tool, database, arguments). The description adds context about how the database parameter is auto-injected into arguments, which is additional value beyond the schema. However, it does not elaborate on the tool parameter's format or how arguments are structured. With full schema coverage, a baseline of 3 is appropriate, and the auto-injection note adds slight value.

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 clearly states the tool's purpose: 'Call any tool by name, including hidden tools not in the client tool list.' It specifies the verb (call) and the resource (any tool by name), and distinguishes itself from batch for multiple calls. However, it does not explicitly differentiate from the sibling 'execute' or other calling mechanisms, so it loses one point for not naming alternatives beyond batch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance: 'Use for single hidden-tool calls. For multiple calls, prefer **batch**.' This clearly indicates when to use this tool and names the alternative batch for multiple calls. It does not, however, mention other potentially relevant alternatives like execute or when not to use call, so it loses a point for not being more comprehensive.

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 meaningful annotations beyond the title, the description carries the full behavioral burden and does so well. It discloses the worker-process termination, the failure mode when the DB is not attached unless force=True, and the detach-but-keep-worker-alive behavior for multi-session cases. It does not mention the save parameter's effect, but the core side effects are clearly presented.

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 compact and front-loaded, with the primary action in the first sentence and supporting conditional behavior in three short follow-up sentences. Every sentence adds information, and there is 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?

The description covers the essential invocation context: which database argument to provide, when force is needed, and what happens with concurrent sessions. Since an output schema exists, return values need not be described. The only notable gap is the undocumented save parameter, which could affect whether close persists or discards changes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for all three parameters. It explains database ('specify when multiple are open') and force ('unless force=True'), but save is never described. This is a meaningful but incomplete compensation for the schema's lack of parameter documentation.

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 uses a specific verb-object pair, 'close a database and terminate its worker process', which makes the action unambiguous. It also clearly distinguishes this tool from siblings like open_database, save_database, and list_databases by focusing on closure and process termination.

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 clear conditions for use: specify database when multiple are open, force=True to override the attached-session requirement, and behavior when other sessions still use the database. It does not explicitly name alternative tools or say 'use save_database instead', but the context is strong enough for an agent to decide when this tool applies.

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 responsibility. It discloses important behavioral traits: database auto-injection, blocked tools, allowed imports, prohibition of FS/network I/O, paginated result shape, and the requirement to check has_more. This is far beyond a minimal summary.

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 long but every section earns its place: main usage, examples, exclusions, reference constraints. It is well-structured with clear headings and code blocks, ensuring an agent can quickly extract the rules that matter.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and the absence of annotations and output schema, the description is exceptionally complete. It covers when to use, when not to use, parameter behavior, execution environment, tool-blocking rules, and result conventions. Nothing critical 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 coverage is 100%, but the description adds substantial meaning: database is auto-injected into invoke and can be overridden, code is Python async code, plus practical details like address formats, Python regex for filter_pattern, and available imports. This greatly aids correct invocation.

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 opens with a specific verb and resource: 'Run Python code that chains tool calls.' It clearly distinguishes itself from siblings by positioning execute as the multi-step pipeline meta-tool, with explicit contrast to call and batch.

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 has a dedicated 'When NOT to use execute' section naming alternatives (call, batch, built-in batch parameters) and a 'When to use execute' section with concrete scenarios (multi-step pipelines, cross-database parallel queries). This gives the agent unambiguous routing 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?

There are no annotations, so the description carries the full burden. It discloses meaningful behavioral details: the nuance of detail levels, that hidden tools are included, and that direct calls to hidden tools fail unless routed through call, batch, or execute. It does not cover unknown-tool error behavior, but the output schema covers return structure.

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 compact and well-structured: one sentence for purpose, one for workflow context, one for an important parameter tip, and one for the hidden-tool caveat. Every sentence earns its place 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?

Given the tool's moderate complexity, the description covers purpose, workflow placement, and the critical hidden-tool caveat. Since an output schema exists, the description does not need to explain return values. A small gap is that 'pinned' is never defined, but this is minor.

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 thoroughly. The description adds only a usage hint ('Pass detail="full"'), which is helpful but not extra semantic meaning beyond the enum documentation. 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?

The description opens with a specific verb and resource: 'Get parameter schemas for specific tools by name.' It further narrows scope to 'pinned and hidden' tools and positions itself relative to search_tools and execute/batch, so an agent can clearly distinguish it from siblings 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 explicit workflow placement: 'Use after search_tools or before execute/batch to check parameter types and return shapes.' It also provides a when-not and alternative behavior for hidden tools by stating that direct calls will fail and that call, batch, or execute must be used instead.

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?

The description adds useful behavioral context by noting that metadata includes opening/analyzing status. However, with no annotations like readOnlyHint or destructiveHint, the description carries the full burden of disclosing side effects. It does not explicitly state that the operation is read-only or that it has no side effects, though 'List' implies it. The added metadata detail is valuable but insufficient for full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that front-loads the action and resource. It includes relevant detail about metadata without any fluff or redundancy. Every word earns its place, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters) and the presence of an output schema, the description is largely complete. It clearly states what the tool does and the key additional detail about status. It does not mention any prerequisites or limitations beyond 'open' databases, which is inherent in the wording. For a list tool with an output schema, this is sufficient.

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 has zero parameters, so the baseline is 4. The description does not need to explain any parameter semantics, and the schema is empty with 100% coverage. No additional parameter guidance is necessary.

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 clearly states the tool's purpose: listing all open databases with metadata, including opening/analyzing status. It distinguishes from siblings like list_targets (which lists targets) and open_database (which opens a database). The verb 'List' and resource 'all open databases' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide any guidance on when to use this tool versus alternatives. It does not mention that it only covers open databases (which is implied) or that list_targets should be used for targets. No exclusions, conditions, or recommended contexts are given, leaving the agent to infer usage 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?

The verb 'List' conveys a read-only enumeration behavior, and 'available' suggests the result set is context-dependent. However, the description does not explain how availability is determined, what exactly counts as a target, or any behavior beyond returning a list. Since annotations provide no readOnlyHint or other safety signals, the description bears most of the burden but only partially fulfills 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?

A single sentence with no wasted words. The core action and object are front-loaded, and the parenthetical adds clarifying examples without bloating the 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?

For a parameterless list tool with an output schema present, little else is strictly required. The description names the target categories and implies an enumeration, which is enough for an agent to call it. The main gap is the lack of usage context relative to sibling listing tools, but this is a minor omission for such a simple operation.

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 schema has nothing to document and the description cannot add parameter-level meaning. Per the baseline for zero-parameter tools, this is sufficient.

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: 'List available targets' and elaborates with examples ('processors, loaders, languages, etc.'). This clearly distinguishes it from siblings such as list_databases, since it targets a different object type.

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 is given about when to use this tool instead of alternatives like list_databases or search_tools. The use case is only implied by the word 'List', but there is no explicit context or 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?

Annotations are minimal (title only), so the description carries the full behavioral burden. It discloses the immediate return with opening:true, the need to wait, re-opening returning the existing worker, the destructive effect of force_new, and fat-arch requirements. This is far beyond what the annotations provide.

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 organized into short, bolded sections that each carry distinct operational guidance. There is no filler; every sentence contributes to correct invocation, including concurrency notes, destructive-force warning, and Mach-O edge cases.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 10 parameters and an output schema, the description covers the critical behavioral contract: return semantics, sequencing with wait_for_analysis, concurrency model, destructive flag, fat-arch constraints, and re-opening behavior. The presence of an output schema means return-value details do not need to be repeated here.

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 already solid, but the description adds meaningful cross-parameter context: force_new deletes prior analysis, fat_arch must be omitted for thin/existing databases, distinct database_id values are needed for concurrent slices, and re-opening an open DB reuses the worker. These constraints are not fully inferable from the schema alone.

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 opens with a specific verb and resource: 'Open a binary or existing IDA database (.i64/.idb) for analysis.' It also distinguishes itself from the sibling wait_for_analysis by stating it returns immediately with opening:true and instructs the agent to wait before using other tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use and when-not-to-use guidance: call wait_for_analysis after opening, use a separate subagent per binary, do not serialize open+wait calls, and only use force_new for stale or incompatible databases. It also covers fat Mach-O handling and maps to sibling wait_for_analysis without confusion.

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?

Annotations contain only a title, so the description carries the full behavioral burden and delivers: it discloses a potentially long-running operation ('may take minutes for large DBs'), a specific failure condition (unattached DB unless force=True), and progress notification cadence (every 5s). It also makes the disk-write nature explicit given no destructiveHint/readOnlyHint 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?

Four sentences, each earning its place: core purpose, multi-DB guidance, failure-mode caveat, and progress behavior. The purpose is front-loaded and the length is proportional to the tool's complexity, 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?

Covers purpose, duration, failure conditions, and two of four parameters, and an output schema exists to document return values. However, outfile and flags remain unexplained at 0% schema coverage, and with no safety annotations an agent cannot fully predict behavior without opening the 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?

Schema description coverage is 0%, so the description must compensate. It explains 'database' (needed when multiple are open) and 'force' (overrides the attachment requirement), but 'outfile' and 'flags' are never described—a real gap for a save operation where outfile plausibly controls the destination path and flags is entirely opaque.

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: 'Save the current database to disk', which is unambiguous about what the tool does. It doesn't explicitly name sibling distinctions, but a save/persist operation is naturally distinct from siblings like open_database, close_database, list_databases, and execute.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides concrete usage conditions: 'Specify *database* when multiple are open' and the force=True escape when the DB is not attached to the current session. This gives an agent actionable guidance on how to call it correctly, though it never explicitly mentions when to prefer an alternative—likely because no sibling performs saving.

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 discloses that pinned tools are excluded, that direct calls to hidden tools will fail, and that they must be called via call, batch, or execute. This is significant behavioral information beyond a simple search function, though it doesn't detail edge cases like regex matching nuances or performance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each with a distinct purpose: scope definition, output/detail guidance, and invocation warning. It is front-loaded with the core action and is entirely 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?

The tool has a simple two-parameter interface, an output schema (so return values are handled there), and the description covers the search scope, detail levels, and the critical invocation constraint. An agent has everything it needs to correctly search and then call hidden 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%, so the baseline is 3. The description adds value by explaining the default 'brief' output and the alternative of using detail='detailed' or get_schema for richer schemas, but the parameter descriptions in the schema already cover the meanings. It doesn't introduce new semantics beyond what the schema provides.

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: 'Search hidden tools by regex', and adds a critical scoping detail (pinned tools excluded). It differentiates from siblings by implying that get_schema is for schema retrieval, not search, and that call/batch/execute are for invocation. This leaves no ambiguity about the tool's core function.

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 clear context: it explains how to use the detail parameter and suggests get_schema as a follow-up for full schemas. It also warns that hidden tools must be invoked via call, batch, or execute, and that direct calls will fail. While it doesn't explicitly contrast with list_targets or list_databases, the primary usage scenario is well-defined.

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 readOnly or destructive annotations, the description carries the behavioral disclosure burden. It explicitly reveals that the call blocks, that backend thread becomes blocked while analysis runs, and that tool calls queue during that time. It also discloses the subtle 'at least one' multi-database return condition, which is not inferable from the schema alone.

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 compact, well-organized with bold single/multi sections, and every sentence contributes useful information. The core behavior is front-loaded, and the concurrency warning is placed at the end without unnecessary 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?

Given the schema, output schema, and the provided behavioral notes, the description is largely complete for correct invocation. The main gap is that neither parameter is required, but the description does not state what happens if both 'database' and 'databases' are omitted or how conflicts between them are resolved.

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 already documents both parameters at 100% coverage, so the baseline is 3. The description adds practical meaning beyond the schema by mapping each parameter to a specific usage scenario: 'database' for single and 'databases' for multi. It clarifies the intended interaction pattern but does not add new constraints or format details.

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 uses the specific verb 'Block' and clearly identifies the resource: database(s) finishing opening and optional auto-analysis. It distinguishes itself from siblings by defining wait behavior rather than open/save/close actions, and it explicitly covers single vs multi-database semantics.

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 clear instructions for the two invocation patterns: pass 'database' for one DB and pass 'databases' for multiple, returning when at least one is ready. It also advises the caller to work on the ready one and call again for the rest. However, it does not explicitly name alternative tools or state when not to use this tool.

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