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

Annotations already declare readOnly/destructive/idempotent behavior, so the description's main value is adding that no database connectivity is required and that the drivers are licence-gated, native ADBC drivers returning Arrow. That is useful context beyond the annotations, though it does not discuss limits or output shape.

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 front-loaded and the operational guidance is clear. Some of the client-language list ('Python, C/C++, C#, Go, Java, R, Rust') is marketing detail that is not needed to invoke the 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?

With one optional parameter, full schema coverage, annotations covering safety, and an output schema handling return values, the description contains everything needed to call the tool correctly in either mode.

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

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

Schema coverage is 100%, so the schema already documents accepted name forms. The description still adds meaningful mode semantics — omitting the parameter lists the family, passing it returns one driver's full metadata — which goes beyond the parameter's field description.

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

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

The description states a specific verb and resource ('Get information about the Arpe ADBC drivers') and enumerates the exact driver family covered. It also distinguishes its domain from sibling info tools by tying the drivers to FastBCP's adbc_* connection types.

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 mode guidance: omit `driver` to list the family with versions, pass it for one driver's details. It does not name alternative tools or exclusion cases, which keeps it short of a full 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?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuine operational context: no binary is required by default, execution is only available when a binary is installed, and no database connectivity is needed. It doesn't describe the returned status fields, but an output schema exists to cover that.

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 core purpose, then the mode caveat, then the preflight guarantee. Every sentence carries information, though the final clause slightly restates what the empty schema already implies.

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 an output schema present, no parameters, and full annotation coverage, the description only needs to establish what the tool reports and what it requires. It does both, and adds the binary-vs-command-builder nuance that an agent needs to interpret the results.

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

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

Zero parameters, so the baseline is 4. The description reinforces the empty schema by stating it does not require any parameters, removing any ambiguity about whether auth or connection details 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 ('Show the status') and names the exact resource: the four Arpe.io CLI tools, listed by name. This implicitly differentiates it from the per-tool siblings (fastbcp_info, lakexpress_info, migratorxpress_info) by being the aggregate status view, though it never says so explicitly.

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

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

The description explains the command-builder vs. binary-installed execution modes, which is real context for deciding whether preview/execute siblings are usable. But it never states when to call this tool rather than arpe_quick_start or the per-tool *_info tools, leaving the selection 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?

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds real value beyond that: it explains what the call produces (recommended tool, required parameters, sequence of calls) and reinforces that nothing is executed. It does not discuss latency or how 'all' vs a specific product changes the output volume, which keeps it below 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?

Four short sentences, front-loaded with the purpose and then the trigger condition, with no filler. Slight redundancy in restating non-execution after the 'workflow guide' framing, but it earns its place as a safety signal.

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 routing tool with an output schema and fully documented params, the description covers what it does, when to use it, and what it returns. The only gap is guidance on how results differ when the user already knows the product, which the enum hints at but the prose never addresses.

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%, including an enum on 'product' with a clear description, so the schema carries the parameter burden. The description only paraphrases the use_case parameter ('Accepts a plain English use case description') and never mentions the 'product' override, adding essentially no meaning beyond the schema. 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 and resource ('Determine which Arpe.io tool to use and get a step-by-step workflow guide') and explicitly separates itself from the execute_* siblings with 'Does not execute anything.' An agent can immediately tell this is a router/advisory tool rather than an action tool.

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 clear trigger condition: 'Call this when the user's intent is unclear or they are new to arpe.io tools.' It does not name concrete alternatives for the clear-intent case (e.g. 'go straight to fastbcp_execute_export'), but the readOnly/non-executing framing makes the boundary with action siblings fairly obvious.

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 already declare readOnlyHint/idempotentHint/openWorldHint=false, so the safety profile is covered; the description adds meaningful context beyond that: it queries a local docs cache and ADBC drivers return their full 'What's new' history when no version is given. It restates 'Read-only' redundantly, which is the main thing keeping it from 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?

Short and front-loaded, with the core purpose in the first sentence and driver-specific behavior after. The sentence 'Pass `product` to select which tool' is imprecise wording that costs a bit of clarity but no padding is present.

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?

Output schema exists, so return-value description is unnecessary, and annotations cover safety. What remains is complete for an agent to call it correctly, with only the ambiguous 'select which tool' phrasing as a residual 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 100% with an enum on product and a documented version format, so the schema already carries the semantics. The description's ADBC load-name mapping and the 'whole history for a driver' behavior duplicate or lightly reinforce what the schema states, yielding 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?

States a specific verb and resource ('Return release-notes chunks for any Arpe.io product') and scopes the result set to a product/version. It is distinguishable from the *_info and search_docs siblings by scope, though it never names an alternative explicitly. The phrase 'select which tool' is slightly ambiguous but the intent (which product's release notes) is inferable.

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 clear input contract (pass product, optionally version; omit version for newest) but no when-to-use/when-not guidance relative to siblings such as search_docs, which could also surface release-note content. Usage is implied by the parameter narrative 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?

Annotations already indicate destructiveHint=true, and the description reinforces this with 'safety gate' and 'requires confirmation=true'. It adds context about command source and binary requirement. No contradictions.

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 sentences, each containing essential information. Front-loaded with purpose. No redundant or irrelevant 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?

Given full schema coverage and existence of an output schema (not shown), the description provides sufficient context for usage. It covers prerequisites, safety, and failure conditions. However, it could mention output details or error scenarios.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds value by specifying the command must be from fastbcp_preview_export and include actual passwords, which goes 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 clearly states it executes a FastBCP export command built by fastbcp_preview_export, using the verb 'execute' and specifying the resource. It distinguishes from the sibling tool fastbcp_preview_export by noting it does not build the command.

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 explicitly states the prerequisite (command from fastbcp_preview_export) and the safety gate (confirmation=true). It also notes failure case (binary not installed). However, it does not mention when not to use this tool or provide explicit alternatives.

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 already declare read-only, idempotent, non-destructive, and the description is consistent with them while adding genuinely new context: no database connectivity is required. It stops short of describing the shape or volume of the returned information, but for a static info tool that is a minor omission.

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 capability list is front-loaded before the operational hint. No filler, 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?

With 7 parameters at full schema coverage and annotations covering the safety profile, the description need only explain intent and prerequisites, which it does. The remaining minor gap is that it does not hint at what the responses look like, and there is no output schema to cover that.

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 enum description already explains each action plus its dependent parameters (source_type, output_format, has_numeric_key, table_size_estimate). The description only mentions that `action` selects the information, so it adds nothing beyond the schema — 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?

Specific verb and resource: 'Get information about FastBCP capabilities, parallelism recommendations, workflow guidance, or binary version' — enumerates exactly the four info categories it serves. It is clearly a metadata tool rather than an export action, but it never explicitly contrasts itself with fastbcp_execute_export/fastbcp_preview_export or with the docs-search 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?

'Use `action` to select what information you need' points the agent at the routing parameter, and 'does not require database connectivity' tells the agent it can be called safely up front. However, it gives no explicit when-to-use versus alternatives (e.g., search_docs, or calling this before an export), leaving the usage context 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?

Goes beyond the readOnly/idempotent annotations by disclosing that passwords are masked in output and that one parallelism method is auto-suggested when unspecified. It stops short of saying whether inputs are validated or what happens on an invalid combination, but the annotation set already carries the safety profile.

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 non-execution guarantee, then the masking behavior, the auto-suggestion, and the handoff. No filler and no repetition of 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?

With annotations and an output schema present, the description covers the essentials: non-execution, secret masking, default suggestion behavior, and next step. Given the large nested input schema, a bit more guidance on the lesser-documented option fields would round it out.

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 only 40%, so the description should compensate for the many thinly documented nested fields (os_type, config_file, cloud_profile, run_id, license_path). It only adds meaning for one parameter group, the auto-suggested options.method, while the rest relies on the schema's own text.

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 and preview a FastBCP export command') with an explicit negation ('WITHOUT executing it') that separates it from the sibling fastbcp_execute_export. An agent can pick this tool over its execute counterpart without opening either 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 names the when-not ('Does NOT test connectivity or execute the export') and the downstream alternative ('After reviewing, pass the command to fastbcp_execute_export'). The two-step preview→execute workflow is fully spelled out.

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 already indicate destructiveHint=true and readOnlyHint=false. The description adds that the command contains actual passwords, requires a safety gate, and will fail if binary is not installed, providing valuable behavioral context beyond annotations.

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 concise sentences, each providing essential information. Front-loaded with the main action and prerequisite, no unnecessary 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?

Given the full schema description, output schema availability, and annotations, the description covers workflow dependency, safety valve, and failure condition. It is sufficiently complete for correct usage.

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

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

Schema coverage is 100% with good descriptions. The description adds extra guidance: 'Do not modify this string' for command and 'Always confirm with the user' for confirmation, enhancing 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?

The description clearly states the verb 'Execute' and the resource 'a FastTransfer command previously built by fasttransfer_preview_transfer'. It distinguishes itself from the sibling fasttransfer_preview_transfer which builds the command.

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 specifies prerequisites (must have a prior preview call, binary installed) and a safety gate (confirmation=true). It does not explicitly mention when not to use or compare with other siblings, but the context makes it 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?

The description states 'Read-only, does not require database connectivity,' adding context beyond annotations (readOnlyHint, idempotentHint). It reinforces the non-destructive, idempotent nature and clarifies no DB connection is needed, which is valuable for agent decision-making.

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 only two sentences, both front-loaded with key information. It covers purpose, usage hint, and behavioral trait without any fluff. 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?

Given the tool's simplicity, abundant schema descriptions, and annotations, the description is mostly complete. It doesn't explain return format or error behavior, but for a read-only info tool with strong schema support, this is acceptable. Could optionally mention that some actions require additional parameters (already in 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?

All parameters have descriptions in the schema (100% coverage), so the description adds no new semantics. The description mentions using 'action' but doesn't elaborate on other parameters. Baseline score of 3 is appropriate given the high schema 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?

The description clearly states the tool retrieves information about FastTransfer capabilities, parallelism, workflow, or version. The verb 'Get information' and the specific resource 'FastTransfer' make the purpose explicit, distinguishing it from sibling info tools like fastbcp_info or lakexpress_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 advises to use the 'action' parameter to select the needed information and notes the tool is read-only and doesn't require database connectivity. While it provides clear context, it doesn't explicitly contrast with alternative tools for transfers or other operations, but the purpose is clear enough for an agent to infer when 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?

Beyond the readOnlyHint annotations, the description discloses that passwords are masked, that a parallelism method is auto-suggested when omitted, and that the tool does not test connectivity or execute the transfer. It does not cover input validation or failure behavior, but the key read-only and non-executing traits are explicit.

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 are tightly scoped: the core operation, output presentation, defaulting behavior, and next step are front-loaded. No sentence is redundant, and the limitations are placed where an agent will see them before calling.

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 tool with nested source/target/options structures, annotations, and an output schema, the description covers the essential workflow, masking behavior, non-execution guarantee, and follow-up tool. Minor validation details are left to the schema, which is reasonable given its richness.

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 schema description coverage at 25%, the description compensates only partially: it explains the auto-suggestion behavior for options.method and notes that passwords are masked. It does not add much meaning for the source, target, or os_type parameters beyond what the nested schema already 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: 'Build and preview a FastTransfer database-to-database transfer command.' It emphasizes 'WITHOUT executing it' and names the sibling tool fasttransfer_execute_transfer, so the agent can distinguish preview from execution immediately.

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 clearly establishes the preview-before-execute workflow by saying the command should be reviewed and then passed to fasttransfer_execute_transfer. It also explicitly excludes connectivity testing and execution, leaving little ambiguity about when 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.

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

Annotations already indicate destructiveHint=true, so the description adds value by disclosing that the binary must be installed and that confirmation is required. No contradictions.

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 sentences, each necessary and front-loaded. No redundant 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?

Given output schema exists, annotations provide safety info, and parameters are well-documented, the description covers prerequisites, safety, and execution constraints fully. No 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 coverage is 100% and description adds critical context: the command must be passed as-is from preview, and confirmation must be true after user review. This goes beyond schema definitions.

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 'Execute' and names the resource 'LakeXpress command that was previously built by lakexpress_preview_command', clearly differentiating from sibling tools like lakexpress_info or lakexpress_preview_command.

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 explicitly states when to use (after preview), the prerequisite (command must come from lakexpress_preview_command), and the safety gate (confirmation must be true). This provides clear guidance and excludes misuse.

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?

Description adds 'Read-only, does not require database connectivity' beyond the annotations that already declare readOnlyHint and idempotentHint. No contradictions.

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 no wasted words. Essential information is front-loaded: purpose, action usage, read-only nature.

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

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

Given no output schema, description could mention output format, but parameter descriptions already specify what each action returns. Covers key aspects adequately for this simple 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% with detailed enum explanations. The description adds only minimal guidance ('Use `action` to select what information you need'), not significantly beyond 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?

Description clearly states 'Get information about LakeXpress capabilities, workflow guidance, or binary version' using a specific verb and resource. It differentiates from sibling info tools (e.g., arpe_get_status, fastbcp_info) by specifying LakeXpress scope.

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?

Description provides context by naming LakeXpress as the subject and instructs to use the 'action' parameter. While it implies alternative tools for other products, it does not explicitly exclude them or contrast with search_docs.

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 confirms the no-side-effect nature (read-only, idempotent) matching annotations. It adds transparency by noting it does not execute or validate connections, beyond what annotations declare.

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 concise (4 sentences) and front-loaded with the main purpose. Every sentence is informative and 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?

Given the complexity (21 parameters, nested objects, many sub-commands), the description provides clear usage flow. The output schema exists, so return values are documented elsewhere. Minor gap: no explicit mention of output format beyond 'shows the exact command', but the schema covers 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 baseline is 3. The description does not add parameter-level explanations, but the schema already provides thorough descriptions for all properties.

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 builds and previews a LakeXpress CLI command without executing it. It explicitly distinguishes itself from the sibling tool lakexpress_execute_command and provides a specific use case: call after lakexpress_info with action='workflow'.

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 when-to-use guidance: after lakexpress_info, before lakexpress_execute_command. It also states what it does not do (execute, validate connections), helping the agent decide when to use this preview tool versus alternatives.

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 indicate destructive and non-idempotent; description adds safety gate requirement and failure condition (binary not installed), enhancing understanding beyond annotations. No 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?

Three sentences, each serving a distinct purpose: execution, safety constraint, and prerequisite. No redundancy or fluff.

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 essential context: prerequisite (preview command), safety gate (confirmation), and failure condition (binary). Has output schema, so return details not needed. Complete for execution 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 already covers both parameters with descriptions (100% coverage). Description adds context that command must be from migratorxpress_preview_command output and confirmation is a safety gate, adding value beyond 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?

Clearly states 'execute a MigratorXpress command' with verb and resource, and distinguishes from sibling migratorxpress_preview_command by specifying the command must come from a prior preview call.

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 explicit conditions: requires confirmation=true and command from preview. Implicitly indicates use after preview; no explicit when-not-to-use but clear enough.

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 already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description reinforces read-only and adds that no database connectivity is required, providing extra behavioral context. No contradictions.

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, front-loaded with the core purpose, and every word adds value. No wasted or redundant 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?

Given rich annotations and schema, the description is adequate for understanding the tool's role. However, it lacks information about the return format or examples, which would be helpful given the absence of an 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?

Schema description coverage is 100%, so the description does not need to add much. It mentions 'Use action to select what information you need,' which is a high-level summary but does not add significant meaning beyond the schema's own parameter descriptions.

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 it gets information about capabilities, workflow guidance, or binary version, using the action parameter. It is distinguished from sibling tools like migratorxpress_execute_command by its read-only nature, but does not explicitly differentiate from other 'info' tools for different products.

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 usage context: use action to select info, and notes it is read-only without DB connectivity. However, it does not specify when not to use it or suggest alternatives (e.g., when to use search_docs 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?

Annotations already declare readOnly/idempotent/non-destructive, but the description adds concrete behavior beyond them: passwords are masked in output, no execution or connectivity validation occurs, and upgrade_migdb cannot be combined with task_list or resume. These are actionable constraints an agent cannot derive from structured fields 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?

Four tight sentences, front-loaded with what the tool does and immediately followed by its boundaries and the handoff to the execute tool. No filler; every clause carries routing or constraint 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?

With an output schema present, return values need not be described, and the description covers the key edge cases (masking, no execution, upgrade mode constraints). For a 43-param preview tool whose schema is fully documented, nothing an agent needs to invoke it 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% across 43 parameters, so the schema already documents each parameter's meaning. The description explains the upgrade_migdb flag's reduced parameter requirement, but that detail is also present in the schema, so it adds marginal value. 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 and resource: builds and previews a MigratorXpress migration command without executing it. It explicitly distinguishes itself from migratorxpress_execute_command and clarifies scope ('Does NOT execute the migration or validate database connectivity'), so an agent can tell it apart from siblings immediately.

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 names the alternative ('pass the command to migratorxpress_execute_command') and gives the condition that selects it (after reviewing). It also flags a special mode (upgrade_migdb=true) with its prerequisites, leaving little 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?

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, so safety is clear. Description adds important context that actual connectivity is not tested, which annotations do not cover. Minor gap: no mention of return value or error behavior.

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 redundant phrases. Front-loaded with core purpose, followed by usage hint and limitation. Every sentence contributes meaning.

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 tool with 2 parameters and no output schema, the description covers purpose, usage, and a key limitation (no connectivity test). It could improve by describing the validation result format (e.g., returns success/failure messages), but it's still clear enough for an AI agent.

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 each parameter is documented. The description adds value for required_auth_ids by explaining its purpose ('verify source, target, and migration DB credentials are all present'). This goes beyond the schema's 'optional list.'

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 explicitly states the tool validates a MigratorXpress JSON credentials file, specifying it checks well-formedness and required fields. It distinguishes from siblings by positioning as a pre-check before migratorxpress_preview_command.

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 clear when-to-use guidance: 'Call this before migratorxpress_preview_command to catch credential issues early.' Also clarifies what it does not do ('Does NOT test actual database connectivity'), preventing misuse.

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 already declare readOnly, idempotent, non-destructive, open-world. The description adds real value beyond them by clarifying that retrieval spans all product docs and the blog simultaneously and that it 'does not execute anything', which heads off any confusion with the preview/execute siblings. Return shape is covered by the output schema, so no gap there.

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 sentences, each carrying distinct information: capability, trigger conditions, and scope/behavior. The long product roll-call is the only slightly heavy element, but it is load-bearing for knowing what corpus is searched.

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?

Purpose, trigger conditions, corpus scope, and a non-execution disclaimer are all present, and annotations plus the output schema cover safety profile and return format. What remains thin is only the query-formulation guidance, which the schema already handles.

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 fully documented in the schema, so the description is not required to compensate. It reinforces the kind of natural-language query expected but adds no syntax, ranking, or top_k guidance 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 (search) and resource set (arpe.io documentation and blog) plus the exact topic domain it covers (CLI parameters, parallelism, integrations, best practices). It also enumerates the covered products, which lets an agent separate it from the per-product info tools in the sibling list.

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 three concrete triggers: unsure about a parameter value, need an example command, or want a recommended approach for a source/target/format combination. It does not name a specific alternative sibling (e.g., fastbcp_info) to prefer for static product facts, so routing is strong but not fully explicit.

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