ActionShip by Teapplix Demo

Get Shipping Rates

teapplix_get_rates

Read-only

Get shipping rates for a shipment without an existing order. [DEMO]

Input Schema

TableJSON Schema

Name	Required	Description
`To`	Yes	Destination address.
`From`	Yes	Ship-from address OR a saved shipping profile — supply exactly one shape.
`Packages`	Yes	One or more packages to rate. Each package must include Method; Weight and Dimensions set the package size for the rate query. All packages must use the same carrier. To compare carriers, prefer a RATESHOP method; otherwise make separate calls per carrier.
`ShipDate`	No	Ship date (YYYY-MM-DD). Defaults to today. Interpreted as Pacific timezone.
`CustomsDeclaration`	No	International shipments only. Omit unless shipping outside US. Fields: ReasonForExport, IOssNumber, Items: [{Description, Quantity, Value, Weight, HSTariffNumber, CountryOfOrigin}].

Output Schema

TableJSON Schema

Name	Required	Description
`Rate`	No	Rate for the requested method when it succeeded. Absent means the requested method failed — inspect AltRates for carrier suggestions. For RATESHOP, this is the winning (lowest-cost) candidate.
`Zone`	No	Carrier zone for the selected rate (e.g. "3").
`AltRates`	No	Carrier-provided alternate quotes. May appear alongside a successful Rate (carrier suggestions) or without Rate (requested method failed). Items with Error set are methods the carrier could not quote. For RATESHOP, all non-winning evaluated candidates — valid higher-cost quotes and failed methods.
`Warnings`	No	optional warning message, you can safely ignore

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, covering the safe read-only nature. The description adds no extra behavioral context such as whether rates are estimates, carrier-specific quirks, or that no label is purchased. It is not misleading but contributes nothing beyond the annotations.

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

Conciseness5/5

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

The description is a single concise sentence that leads with the action and key scope qualifier. It contains no fluff, and the '[DEMO]' tag is a minor, harmless marker that does not detract from clarity.

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?

Given the rich parameter schema, available output schema, and sibling tools like teapplix_purchase_label, the description adequately sets the tool's scope. It could theoretically mention that this only quotes rates and does not purchase labels, but the sibling set makes that evident. Overall, it is complete for its purpose.

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

Parameters3/5

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

Schema description coverage is 100%, with detailed parameter documentation covering the From address/saved profile shapes, Package Method constraints, ShipDate defaults, and CustomsDeclaration. The tool description itself adds no parameter semantics, so the baseline of 3 is appropriate.

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

Purpose5/5

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

The description uses the verb 'Get' and resource 'shipping rates' with a specific qualifier, 'without an existing order', which immediately distinguishes it from the sibling tool teapplix_get_rates_for_order. This makes the tool's purpose clear and unambiguous.

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?

The phrase 'without an existing order' provides clear context for when to use this tool and implicitly points to the alternative for existing orders. However, it does not explicitly name the sibling tool or spell out when not to use it, so it falls short of a perfect score.

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

All ActionShip by Teapplix Demo tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Most tools have clearly distinct purposes (orders, labels, rates, zones, profiles). A few name pairs like manage_tag vs manage_order_tags and set_order_ship_options vs update_order could be confused, but the descriptions explicitly clarify when to use each.

Naming Consistency5/5

All tools share the teapplix_ prefix and follow a consistent verb_noun pattern (e.g., get_orders, create_order, purchase_label, validate_address). The only deviation is the bare 'help' tool, which is conventional and does not disrupt the pattern.

Tool Count4/5

At 28 tools, the server is slightly over the ideal 3-15 range, but the breadth of shipping operations (orders, labels, rates, manifests, tracking, configuration) justifies the count. It is not bloated.

Completeness5/5

The tool surface covers the full order-to-shipping lifecycle: order create/update/retrieve, splitting/merging, label purchase and cancellation, rate quotes, tracking, manifesting, address validation, 3PL submission, and configuration (profiles, warehouses, queues, tags). No significant gaps are apparent.

Resources

Need Help?