PrepPort Global Service Planner

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description then adds genuine business rules not in the annotations: 90 free days are shared across the same batch rather than reset, and Yanwen rates already bundle standard pick-pack. It stops short of stating auth requirements or how currency is derived.

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 core purpose is front-loaded and every sentence carries a rule or a mapping, with no filler. The middle section is telegraphic fragment lists that require a careful read, but nothing is redundant.

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

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

For an 8-parameter, single-required, no-output-schema estimator, the description covers the service-to-parameter mapping, duration semantics, and pricing caveats. The only real gap is that return shape is only implied by "public USD starting costs" rather than said explicitly, which is minor given there is no 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?

With schema coverage at 63%, the description compensates by mapping each service to its relevant inputs (sampleChecks for inspection, units for prep, orders for standalone pick-pack, cubicMeters + duration + alreadyStoredDays for storage), which the schema does not express. It also reiterates the 30-day month convention and the conditional alreadyStoredDays case, adding meaning beyond field names.

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: "Estimate public USD starting costs" at a base level, and clarifies the hard boundary ("does not quote, bill, purchase or ship"), which separates it from ordering/billing flows. It does not name or contrast with the siblings list_prepport_services or plan_prepport_first_job, so an agent still has to infer which estimator to pick.

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

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

Gives concrete invocation routing by service: inspection needs sampleChecks, prep needs units, standalone pick-pack needs orders, storage needs cubicMeters plus a duration. It also supplies an exclusion ("Sourcing is quote-only") and warns against double-counting the pick-pack fee for Yanwen parcels, though it never explicitly compares scope against the sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is fully covered. The description adds value by disclosing what the result contains (starting rates, exclusions, source pages), which is useful given there is no output schema. It says nothing about ordering, pagination, or how often the public catalog changes, so it stops short of rich behavioral context.

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 dense sentence with the scope front-loaded and no filler. It is slightly list-heavy in enumerating categories, but every clause (categories, rates, exclusions, source pages) conveys information an agent would otherwise have to discover by calling 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?

For a zero-parameter read-only listing tool with complete annotation coverage and no output schema, the description supplies the essential missing piece: what the records contain. It is complete enough to call correctly, with only minor gaps around ordering and result size.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for parameterless tools is 4. No misleading parameter hints are present.

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

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

The description uses a specific verb ('List') and a named resource ('public PrepPort sourcing, product inspection, FBA preparation, storage and fulfillment services'), enumerating the categories so an agent knows exactly what comes back. It does not explicitly differentiate from the sibling tools estimate_prepport_base_cost and plan_prepport_first_job, and it slightly conflicts with the title's framing of 'Compare' rather than 'List', but the underlying purpose is unambiguous.

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

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

Usage is implied: an agent would infer this is the catalog-browsing call to run before estimating or planning a job. However, the description never states when to use this versus the sibling cost-estimation or job-planning tools, and offers no exclusions or preconditions. This is minimum-viable guidance rather than explicit routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, but the description adds real context beyond them: it explicitly says no account, inquiry, order, or store connection is created, clarifies the channel is not a live connection, and warns against sending PII. It stops short of describing rate limits or how the registration link behaves.

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 action and output before the boundary conditions. Each sentence carries distinct information (purpose, return, channel semantics, safety constraint), with only minor overlap between the channel clarification and the 'no connection is created' line.

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

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

There is no output schema, so the description usefully spells out what is returned (requirements, steps, registration link). Combined with the safety constraints it covers the essentials for a schema-only tool, though shell/pagination details and sibling routing remain unstated.

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

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

Schema coverage is 100% and both enum parameters are documented in the schema, so the baseline is 3. The description earns extra credit by adding semantic meaning to 'channel' ('identifies the seller platform; it does not connect it'), clarifying that a non-integration enum value is still acceptable input.

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 ('Plan') and resource ('first sourcing, inspection, prep, storage or fulfillment job'), and enumerates the service scope, so an agent knows exactly what the tool produces. It does not name or differentiate itself from the siblings estimate_prepport_base_cost or list_prepport_services, which keeps it short of a 5.

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

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

The description frames the scenario ('first ... job') and gives exclusion-style guidance ('does not connect it', 'No account, inquiry, order or store connection is created'), implying when it is appropriate. However, it never names an alternative tool or states when to prefer a sibling like estimate_prepport_base_cost, so routing guidance is only implied.

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