XportL

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

Annotations already establish the safe read-only, idempotent, non-open-world profile, so the bar is lower. The description adds real behavioral context beyond that: it auto-detects node/GPU counts from raw output, flags specific failure modes (data errors, degraded bandwidth, dips vs message size, run-to-run instability) with likely causes, and names the returned health status and bandwidth-loss figure.

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 core action and followed by the analysis/return detail; little waste. The first sentence is long with many clauses, which slightly taxes readability but every clause carries 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 no output schema, the description correctly compensates by naming the return values (health status and bandwidth-loss figure) and the consumer tool. For a 9-parameter tool it covers inputs, detection behavior, and outputs adequately, though it does not describe the shape or units of the health status 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?

Schema description coverage is 100%, so the schema already documents all nine parameters and the baseline is 3. The description adds conditional meaning the schema does not carry, notably that raw output should be pasted unchanged and that rank/host lines drive node detection, plus that expected_busbw_gbs is required for single-node runs.

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 ('Analyzes nccl-tests / rccl-tests results') plus the concrete analyses performed: node/GPU detection, busbw vs NIC line rate comparison, and error/degradation flagging. It also distinguishes itself from the sibling calculate_fabric_degradation_cost by naming it as the downstream consumer of its output.

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 useful input-mode guidance ('paste raw all_reduce_perf output, or give size/busbw points') and a conditional requirement ('expected_busbw_gbs ... required to judge single-node runs'), which is implied usage context. However, it never states when to use this tool versus the sibling tools or any exclusion conditions, so routing remains partly inferential.

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, idempotentHint=true, and openWorldHint=false, so safety is covered. The description adds genuine context beyond that: this is a purely input-driven estimator ('all assumptions are inputs with stated defaults'), so results are not measured telemetry — an important distinction for an agent interpreting the 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?

Purpose is front-loaded in the opening clause, and the trailing enumeration of outputs earns its place because there is no output schema. It is a single dense sentence, but the output list runs long and could be tightened.

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 carries the burden of enumerating return values (throughput lost, GPU-hours/dollars per year, idle-GPU equivalent, cost per degraded hour, extra training days, recovery scenario and sensitivity table). All nine inputs are documented in the schema, so nothing an agent needs in order to invoke 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%, with defaults, ranges, and per-parameter rationale already documented in the schema itself. The description's only parameter-relevant statement is the meta note that assumptions are inputs with defaults, which adds little beyond what the schema already conveys. 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 (estimates) and a precisely scoped resource (the annual cost of silent fabric degradation in a GPU cluster), then enumerates the concrete outputs it produces. An agent can tell this apart from analyze_nccl_benchmark or check_cluster_compatibility at a glance.

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 this is a planning/what-if calculator whose assumptions are user-supplied defaults, but it never states when to reach for it versus the measurement sibling (analyze_nccl_benchmark). The only routing signal (measure bandwidth with nccl-tests) lives in the schema's bandwidth_loss_pct, not the description, so guidance is inferred 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?

Annotations already establish readOnly, idempotent and closed-world, and the description is consistent with all three. It adds genuine behavioral context beyond them: the three-way verdict taxonomy, the fact that each check and next steps are returned, and the conservative fallback that anything off the published list is reported as 'review', never 'supported'. That safety-relevant bias is exactly the kind of trait annotations cannot express.

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 action and closing with the most decision-relevant behavior (the conservative 'review' fallback). The long parenthetical of matrix factors is dense but each item earns its place by telling the caller what is evaluated; it is slightly list-like inside prose rather than a bulleted structure.

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 nine parameters and no output schema, the description carries the return-value burden and does it: verdict, per-check results, and next steps are all named. It also explains the unknown-input behavior. It stops short of describing what 'next steps' contain or what the caller needs before invoking, leaving a small 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%, so the schema already documents all nine parameters including enums, defaults and the uname -r format. The description names the matrix axes that correspond to those parameters (Linux 5.8+, InfiniBand/RoCE v2/NVLink, NCCL/RCCL) but adds no input syntax or value semantics the schema lacks. 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 ('Checks') and resource ('a GPU cluster against XportL's published support matrix'), then enumerates the exact dimensions checked (kernel, fabrics, GPU vendors, collective libs, deployment, host access). None of the siblings (analyze_nccl_benchmark, calculate_fabric_degradation_cost, get_xportl_overview) overlaps this function, so an agent can route to it unambiguously.

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 defines the evaluation surface but never says when to reach for this tool versus get_xportl_overview or request_enterprise_demo, nor what prerequisite inputs the caller must already have. Usage is implied by the verb 'Checks a cluster' — a pre-onboarding fit assessment — but the agent must infer the positioning 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered by structured data. The description adds useful domain context (that it pulls from xportl.io and includes links to engineering guides) but says nothing about return shape, caching, or how large an 'all' response is. Adequate but thin 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?

One front-loaded sentence led by the verb, with the long enumeration placed after the core claim. Dense and waste-free, though the trailing list is lengthy enough that it slightly blurs into a catalog rather than crisp 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?

For a read-only, single-parameter reference tool with no output schema, the description covers what content can be retrieved across the topics. It is nearly complete; only the relationship between the topic enum and the returned subset is left implicit.

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 'topic' parameter is a fully enumerated 8-value list with a default, so the schema carries the weight. The description's content list loosely mirrors the enum sections but does not add syntax, precedence, or behavior for the 'all' default, so baseline 3 is correct.

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 ('Returns cite-ready facts') plus the exact resource (XportL from xportl.io) and enumerates the content domains covered (failure classes, telemetry, supported fabrics/GPUs, company details). An agent can immediately tell this is the reference/profile tool, distinct from its analytical siblings like analyze_nccl_benchmark or check_cluster_compatibility.

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 'cite-ready facts' implicitly signals to use this when answering questions about XportL or needing sourced context, but there is no explicit when-to-use, when-not, or routing to alternatives such as request_enterprise_demo. 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?

Annotations already cover the safety profile (readOnly, idempotent, non-open-world), so the bar is lower; the description still adds real context by disclosing the MTTF fallback to 'Meta's published 2024 reliability data' and the async-checkpointing caveat. It doesn't cover error conditions, but for a pure computation tool that is minor.

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

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

Two sentences, front-loaded with the purpose and method, followed by a compact enumeration of return values. The second sentence is dense but every listed output earns its place given there is no output 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 no output schema, the description carries the full burden of describing returns and does so completely: recommended interval, expected failures per day, GPU time wasted at recommended vs current intervals, and daily saving. Inputs are fully documented in the schema, so nothing needed for correct invocation 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 all six parameters are already documented with ranges and defaults; baseline is 3. The description names GPU count, checkpoint write time, restart time and MTTF as the driving inputs and restates the MTTF fallback, adding marginal but not new 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 (recommends), resource (checkpoint interval for a training job) and the underlying method (Young and Daly formulas). It is unmistakably distinct from siblings like analyze_nccl_benchmark or calculate_fabric_degradation_cost without needing to open 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 (plan checkpointing for a training job given GPU count, write time, restart time, MTTF) but never states when to prefer this tool, when not to use it, or names an alternative. The MTTF-estimation fallback is the only conditional guidance offered.

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 annotations show an open-world, non-read-only action, and the description adds crucial behavioral context: this transmits user contact details and cluster information to the vendor team, requires user-visible disclosure and consent, and forbids fabricated details. That is exactly the kind of external-effect behavior an agent must understand before calling.

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 tight sentences, front-loads the purpose, then lists the preconditions. Every sentence carries operational value 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 high-stakes external submission tool, the description covers what will be sent, the required consent workflow, and the prohibition on fabricated details, while the schema fully documents all fields. It could mention post-submission behavior or expected confirmation, but the essential invocation context is 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 coverage is 100%, so parameter meanings are already documented. The description still adds useful semantics for the summary field and user_confirmed by specifying that summary should include benchmark, cost, or compatibility results and confirmation must follow explicit user agreement.

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

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

The description names a specific action and resource: sending contact details and cluster summary to the XportL enterprise team to arrange a technical assessment or demo deployment. It clearly distinguishes this outreach action from the analytical sibling 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 pre-call requirements: collect the user's details and summary, show exactly what will be sent, and obtain explicit agreement. It also states a hard when-not condition: never call without agreement or with made-up details, though it does not explicitly compare against sibling tools.

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