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

Since no annotations are provided, the description carries the full burden of behavioral transparency. It reveals critical behavioral constraints, specifically the requirement of confirm=true and the non-retry policy upon timeout.

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 three sentences are highly efficient. The critical information (naming, requirement, workflow advice) is front-loaded and delivers maximum actionable intelligence with minimal word count.

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?

Despite the high parameter count (24), the description provides the necessary contextual glue for an agent: the 'why' and 'how' of the workflow (preview -> confirm -> handle failure), which compensates fully for the lack of detailed parameter documentation.

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?

While the schema provides the definitions, the description adds semantic meaning by identifying the 'confirm' flag as a crucial submission trigger. Given the very low schema description coverage (29%), these high-level operational constraints are highly valuable.

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 identifies the tool's function ('Create an SFC order'), includes the technical endpoint name ('addOrder'), and establishes a clear preference relative to the sibling tool sfc_preview_order.

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 operational boundaries: it requires confirm=true for successful submission, advises using sfc_preview_order first, and gives a specific failure strategy (do not retry on timeout; search 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?

No annotations, so the description carries the full burden. It does disclose a genuine behavioral trait — the response will not expose secret material — which is useful for an agent deciding whether to call it. It does not state that it is read-only (implied), nor what the response actually contains.

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

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

One short sentence, front-loaded with the operation and followed by the one caveat that matters. Nothing wasted.

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

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

For a trivial zero-parameter status check, this is close to adequate, and the no-output-schema rule means return values needn't be detailed. Still, the agent cannot tell what a positive/negative result looks like or whether this confirms reachability versus mere configuration.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies.

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 (check) and resource (whether SFC credentials are configured), which is clear on its own. However, it does not differentiate itself from the near-identical sibling sfc_verify_credentials, leaving the agent to guess at the boundary between 'status' and 'verify'.

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

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

No when-to-use guidance is given beyond the implied 'check before operating'. With siblings sfc_verify_credentials and sfc_setup present, the description should say which to call when, and it says nothing.

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 burden. It discloses the confirm guard and a safety recommendation to search first, which is useful, but does not state that deletion is irreversible, what errors occur on invalid orderCode, or what is returned.

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, front-loaded clauses with zero waste; the destructive action and its guard come first, and the recommendation follows.

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

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

For a two-parameter destructive tool with no output schema and no annotations, the description covers the essential guard and a pre-step but omits irreversibility and failure behavior, leaving meaningful gaps for a delete 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?

Schema coverage is 50%: confirm is already documented in the schema as 'Must be true to delete', and the description merely repeats it. orderCode, the undocumented parameter, is only identified as the key ('by orderCode') with no further format or lookup semantics.

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

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

States a specific verb+resource: 'Delete an SFC order by orderCode'. It is clearly the only destructive/delete sibling among the listed tools, so it is distinguishable, though it does not explicitly contrast with siblings.

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

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

Gives a prerequisite ('Requires confirm=true') and steers the agent toward an alternative action ('Prefer searching the order first'), effectively pointing at sfc_search_order. No explicit when-not guidance, but the pre-step recommendation is concrete.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a read, but nothing is said about what the fee represents (per-order fee, shipping charge, surcharge), whether it requires an existing order, or what happens for an invalid/unknown order code.

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

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

A single front-loaded sentence with no padding. It is terse rather than padded, though the parenthetical method name is the only element beyond the bare minimum.

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

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

With no output schema and no annotations, the description should explain what the returned fee looks like (amount, currency, breakdown) and error behavior. None of that is present, leaving the agent guessing about the response shape for a lookup 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 0%, so the description must compensate. It does add one meaningful bit: the orderCode is the 'SFC order code', distinguishing it from internal identifiers. But no format, example, or validation hints are given for the single required parameter.

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 ('Get fee') plus the key it is looked up by ('SFC order code'), and even names the underlying method (getFeeByOrderCode). It does not distinguish itself from the nearby sibling sfc_get_rates, so an agent may hesitate between the two.

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

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

There is no guidance on when to use this versus sfc_get_rates or sfc_preview_order, both of which plausibly return cost information. No prerequisites, no exclusions, no context about which order states this is valid for.

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

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

No annotations are provided, so the description carries the burden. It does clarify that this is a non-side-effecting URL builder rather than a print trigger, which is genuinely useful, but it says nothing about auth requirements, whether the URL expires, or what the return value looks like.

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

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

Two short sentences, front-loaded with the action and followed by the key usage distinction. Every sentence earns its place with no filler.

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

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

With four parameters at 25% coverage, no annotations, and no output schema, the description should explain the return shape (a URL string) and the meaning of isPrintDeclare/printType. It leaves those gaps open, so an agent cannot call this confidently beyond the required field.

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 25%: printType and isPrintDeclare have no schema descriptions, and the description adds nothing about them. Only orderCode ('confirmed') and printSize (via the schema) are covered, so the description fails to compensate for the low coverage.

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

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

States a specific verb-plus-resource: build a label PDF URL for a confirmed orderCode. It distinguishes itself from a print action, but it doesn't differentiate against siblings like sfc_get_track or sfc_preview_order by name.

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

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

Explicitly frames the when-to-use case (you only need the link) and implicitly the when-not case (don't call print). The 'confirmed' qualifier also hints at a prerequisite state, though no alternative tool is named and no prerequisite steps are 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does mention that setting shipTypeCodes switches to HTTPS getRatesByShip and otherwise uses SOAP/HTTPS getRates for all methods, but it omits whether the operation is read-only, what permissions are needed, and what side effects or response characteristics to expect.

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 and front-loads the core purpose before the conditional routing detail. It avoids repetition, though the second sentence uses internal API jargon that could be clearer for an agent.

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 12 parameters, 5 required fields, no annotations, and no output schema. Given that complexity, the description is incomplete: it does not explain return values, units, defaults, required-field significance, or how quoted rates relate to sibling order tools.

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

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

Schema description coverage is only 33% across 12 parameters, so the description must compensate. It only explains the shipTypeCodes branching behavior and does not clarify the semantics of required inputs like country, weightKg, lengthCm, widthCm, or heightCm, nor optional inputs like city, zipCode, or divisionId.

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: 'Quote rates.' That is clear enough for an agent to know it retrieves shipping rate quotes. However, it does not distinguish this tool from siblings such as sfc_get_fee or sfc_preview_order, so it falls short of a 5.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives like sfc_get_fee or sfc_preview_order. The only conditional mentioned is an internal routing detail based on shipTypeCodes, not a usage recommendation or exclusion.

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

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

With no annotations, the description carries the full behavioral burden and only partially delivers: it discloses the upstream host (tracking.sfcservice.com) and the 40-number batch limit, implying a read-only lookup. It says nothing about return content, partial-failure behavior when one of several numbers is invalid, or error handling.

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

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

Two short sentences with zero padding, and the core action plus the batch limit are front-loaded. Nothing could be removed without losing information.

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

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

For a simple two-parameter read tool this is close to adequate, but there is no output schema, so the description should at least sketch what a track response contains (status events, carrier, timestamps) or the order of results matching the input numbers. That gap keeps it at minimum viable.

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 50% — `client` is documented in the schema, `numbers` is not — and the description only restates the numbers parameter ("by tracking number(s)", "up to 40"). It adds nothing about what the `client` tag affects, so the undocumented half of the schema remains unexplained.

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

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

The description pairs a specific verb ("Track") with a specific resource ("shipments") and the key input (tracking numbers), so an agent knows exactly what the tool does. It does not distinguish itself from siblings like sfc_search_order or sfc_get_label_url, so it stops short of a 5.

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

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

It never says when to use this versus sfc_search_order or sfc_get_label_url, nor does it state prerequisites such as valid credentials or that numbers must be SFC-issued tracking IDs. The only guidance present is the batch cap, which is a constraint rather than usage direction.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only list operation and cites the underlying endpoint (getShiptypesByCountry), which adds provenance, but it says nothing about rate limits, error behavior for unsupported countries, or what happens when dimensions are omitted.

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

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

A single front-loaded sentence with the resource and its scoping conditions first; the parenthetical endpoint reference is slightly extra but useful for tracing. Nothing is padded.

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

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

For a tool with no annotations, no output schema, and 5 of 6 parameters undocumented, the description leaves real gaps: the shape of the returned ship-type list (and the identifiers needed to feed sfc_get_rates) and the divisionId semantics are unaddressed.

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 17%, with just country documented, so the description must compensate. It does partially by framing the widthCm/heightCm/lengthCm/weightKg group as 'parcel size' (and the param names carry units), but divisionId is entirely unexplained and it never says whether the dimension params are required together.

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

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

States a specific verb (List) and resource (shipping methods) with its scoping conditions: destination country and parcel size. It is clearly differentiable from sfc_get_rates or sfc_create_order, though it does not name any sibling explicitly.

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

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

Usage is only implied: the mention of country and parcel-size inputs hints this is a pre-quote lookup that precedes sfc_get_rates, but the description never states when to choose it over that sibling or what prerequisites (credentials, valid country) apply.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the most important trait — the operation is local and non-submitting, which is a genuine safety clarification for a 23-parameter order-builder. However, it says nothing about whether credentials are required, what a validation failure looks like, or what the caller receives back, leaving real gaps for a no-annotation tool.

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

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

Three short sentences, zero waste, with the non-submission constraint front-loaded where it matters most for a tool named 'preview'. Nothing is padded or repeated.

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

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

There is no output schema and no annotations, so the description should explain what a 'preview' returns — a validated payload, a list of validation errors, or both — and it does not. Given the tool's 23-parameter complexity, this is the main missing piece; the call/no-call decision is well covered, the result interpretation is not.

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 only 26% across 23 parameters (7 required), so the description is expected to compensate, and it does not mention a single field. Only 'addOrder payload' hints at the schema as a whole. The agent must infer required fields, formats, and enums (e.g. orderStatus) entirely from a sparsely annotated schema.

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

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

States a specific verb and resource: 'Build and validate an addOrder payload locally', and immediately disambiguates from the sibling that actually submits ('Does NOT submit'). An agent can distinguish this from sfc_create_order 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?

Gives a clear sequencing rule: preview here, then 'Call sfc_create_order with confirm=true after customer approval', which names the alternative and the gate condition. It stops short of stating prerequisites (e.g. credentials) or when previewing can be skipped, so it falls just under fully explicit.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Look up' implies a read, but the description does not say what happens when the orderCode is not found, whether errors are returned, whether rate limits apply, or what the response contains — significant gaps for a tool with zero annotation coverage and no output schema.

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

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

One short sentence with no wasted words, and the key discriminator (orderCode) is front-loaded. It is arguably too terse rather than verbose, but nothing in it is 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 one-parameter read tool this is minimally viable: the input is fully documented by the schema. However, with no annotations and no output schema, the description should disclose at least the return shape or not-found behavior, and it does neither.

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

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

There is a single parameter with 100% schema description coverage ('SFC order code', minLength 1), so the schema already does the work. The description's 'by SFC orderCode (searchOrder)' restates the field without adding format, sourcing, or validation details beyond the schema.

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

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

The description states a specific verb (look up) and resource (an order) and identifies the key lookup field (SFC orderCode). It does not explicitly distinguish this from siblings such as sfc_preview_order or sfc_get_track, so an agent must infer that this is the canonical single-order retrieval.

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

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

Usage is implied by the phrase 'Look up an order by SFC orderCode' — call it when you have an orderCode. There is no explicit statement of when to prefer it over sfc_preview_order or sfc_get_track, and no mention of prerequisites such as needing credentials validated first.

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 burden and does reasonably well: it discloses that this writes a file, that the file is private and local with a specific path, and adds a security constraint about not repeating credentials in chat. It omits write-side behavior an agent would want, such as whether an existing credentials file is overwritten and whether a confirmation is returned.

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, zero filler, with the core action and destination front-loaded before the security guidance. Every sentence earns its place.

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

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

For a four-parameter credential-write tool with no output schema and no annotations, the description covers purpose, storage location, and a key safety rule. Remaining gap is minor: overwrite semantics and any success/failure signaling are unstated.

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

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

Schema description coverage is 100%, so all four parameters (appKey, token, userId, divisionId) are already documented in the schema. The description adds no further meaning about parameter formats or the optional divisionId default. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Save SFC API credentials') plus the exact destination path (~/.sfc/credentials.json), which is unambiguous. It does not explicitly differentiate from siblings like sfc_verify_credentials or sfc_credential_status, though the 'prefer env vars' line implies this is the one-time setup path.

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 alternative ('Prefer MCP env vars when possible') that tells the agent when this tool is not the right choice, plus a security rule about not echoing credentials in chat. It stops short of naming the sibling tools (e.g. use sfc_verify_credentials to check saved creds) or stating prerequisites such as where to obtain the appKey/token.

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 does useful work: it declares read-only semantics and discloses the auto-discovery order (division 1 then 17). It omits what a failure looks like, whether the parcel probe has any side effects, and any auth/latency considerations.

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

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

Two tight clauses with the read-only qualifier and fallback order front-loaded, no filler. It is efficiently sized for what it chooses to say.

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

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

For a zero-required-parameter tool with no output schema, the description should indicate what a result means (pass/fail, error vs boolean) and whether the probe is side-effect free. Those gaps matter for a diagnostic tool an agent will call before other operations.

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 both parameters are documented in the schema itself. The description only adds the concrete discovery sequence behind 'auto-discover', which is genuinely extra meaning but thin overall — consistent with the baseline 3 for high-coverage schemas.

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

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

The description gives a concrete mechanism (probe ship types for US with a small parcel) and flags it as read-only, but never explicitly states the actual goal — verifying credentials/connectivity. Because it talks about ship types, an agent could easily mistake it for sfc_list_ship_types or sfc_credential_status.

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

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

There is no statement of when to use this versus sfc_credential_status or sfc_list_ship_types. The only conditional ('unless divisionId is set') describes internal fallback behavior, not invocation guidance.

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