agentee-mcp

Set shipping address

set_shipping_address

Idempotent

Sets the delivery address for the current cart's checkout so order preview and preparation can use it. Requires at least one cart item and replaces any previously saved address.

Instructions

Set the delivery address for the current cart's checkout; get_order_preview and prepare_order use it. Needs at least one item in the cart and replaces any address set before. For a returning buyer, offer get_saved_addresses first and pass the chosen one here. The phone is normalized to international form; if that fails the result carries a warning — ask the human for the number with its country code, since the courier calls it. Only the required fields and the phone are checked; the street itself is not verified. Missing fields or an empty cart return an error and save nothing. The country can switch the order to local currency (UZS for Uzbekistan).

Input Schema

Name	Required	Description
`zip`	No	Postal / ZIP code; omit where the country has none.
`city`	Yes	Destination city.
`name`	Yes	Recipient full name.
`phone`	Yes	Recipient phone, ideally with country code, e.g. +61 412 462 423.
`address`	Yes	Street, house and apartment in one line.
`country`	Yes	Destination country: name or 2-letter code, e.g. 'Australia' or 'AU'.

Output Schema

Name	Required	Description
`ok`	No
`error`	No	Missing fields or empty cart.
`warning`	No	Phone could not be put in international form — ask the human for it with the country code.
`shipping`	No	Saved address snapshot.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv1.2.0Oct 23, 2026

changedInput schema / properties / address / description

Previous value: -"Street address line."New value: +"Street, house and apartment in one line."

changedInput schema / properties / country / description

Previous value: -"Destination country."New value: +"Destination country: name or 2-letter code, e.g. 'Australia' or 'AU'."

changedInput schema / properties / phone / description

Previous value: -"Contact phone number for delivery."New value: +"Recipient phone, ideally with country code, e.g. +61 412 462 423."

changedInput schema / properties / zip / description

Previous value: -"Postal / ZIP code (optional where not used)."New value: +"Postal / ZIP code; omit where the country has none."

addedOutput schema / properties / warning

Added value: +{
+  "description": "Phone could not be put in international form — ask the human for it with the country code.",
+  "type": "string"
+}

First observedOct 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond annotations, the description discloses phone normalization to international form, a warning result when normalization fails, that only required fields and phone are checked while the street is not verified, and that country can switch the order to local currency. These are meaningful behavioral details for a mutating checkout tool.

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 dense but front-loaded: purpose and consumers first, then prerequisites, alternatives, validation behavior, and side effects. Every sentence carries operational meaning with no filler.

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

Completeness5/5

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

Given the mutation, prerequisites, validation rules, warning behavior, currency side effect, and output schema presence, the description is complete enough for an agent to call this tool correctly. Annotations cover safety and idempotency, and the description covers what they do not.

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?

Schema description coverage is already 100%, so the baseline is 3. The description still adds semantic value beyond the schema by explaining phone normalization and country-code fallback, country-driven currency switching, and the fact that street text is not verified.

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 states a specific verb and resource: setting the delivery address for the current cart's checkout. It also names downstream tools (get_order_preview, prepare_order) that consume the address, clearly distinguishing it from siblings like get_saved_addresses or set_shipping_method.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance, including the prerequisite of having at least one cart item, the behavior of replacing a prior address, and the recommendation to offer get_saved_addresses first for returning buyers. It also states failure conditions: missing fields or an empty cart return an error and save nothing.

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