PrepPort Global Service Planner

Estimate a base service cost

estimate_prepport_base_cost

Read-onlyIdempotent

Estimate public USD starting costs. Inspection: sampleChecks; prep: units; standalone pick-pack: orders. Storage: cubicMeters and either storageDays or months (30 days each), plus alreadyStoredDays when the batch is not new. The same batch gets 90 free days, not a new grace period. Yanwen parcel rates include standard pick-pack: do not add the standalone fee. Sourcing is quote-only. This does not quote, bill, purchase or ship.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "service": "<service>"
    },
    "name": "estimate_prepport_base_cost"
  }
}

Input Schema

Name	Required	Description
`units`	No
`months`	No	Total planned duration in 30-day periods. Do not also provide storageDays.
`orders`	No
`service`	Yes	Choose sourcing, inspection, prep, storage or fulfillment.
`cubicMeters`	No	Estimated stored volume in CBM, up to three decimal places; not a warehouse measurement.
`storageDays`	No	Planned additional storage days. Prefer days for precise free-period estimates.
`sampleChecks`	No
`alreadyStoredDays`	No	Days already elapsed since actual receipt of this same batch. Defaults to zero for a new batch.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 8, 2026

addedInput schema / properties / alreadyStoredDays

Added value: +{
+  "description": "Days already elapsed since actual receipt of this same batch. Defaults to zero for a new batch.",
+  "maximum": 36500,
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / cubicMeters / description

Added value: +"Estimated stored volume in CBM, up to three decimal places; not a warehouse measurement."

removedInput schema / properties / cubicMeters / exclusiveMinimum
```
Removed value: -0
```
addedInput schema / properties / cubicMeters / minimum
```
Added value: +0.001
```

addedInput schema / properties / months / description

Added value: +"Total planned duration in 30-day periods. Do not also provide storageDays."

addedInput schema / properties / service / description

Added value: +"Choose sourcing, inspection, prep, storage or fulfillment."

addedInput schema / properties / storageDays

Added value: +{
+  "description": "Planned additional storage days. Prefer days for precise free-period estimates.",
+  "maximum": 3650,
+  "minimum": 1,
+  "type": "integer"
+}

First observedOct 3, 2026

TDQS

A4/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

All PrepPort Global Service Planner tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?