Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

save_shipping_profile

Destructive

Save a local shipping profile with explicit user consent, storing contact and address details for reuse during checkout or order creation.

Instructions

Save a local shipping profile after explicit user consent.

        Args:
            name: Profile name, e.g. ``"home"`` or ``"office"``.
            shipping_address: Full shipping contact/address dict. Keys:
                ``first_name``, ``last_name``, ``email``, ``phone``,
                ``street``, ``city``, ``postal_code``, ``country``;
                include ``state`` for US addresses.
            overwrite: Replace an existing profile with the same name.
            set_default: Make this the default shipping profile.
            consent_to_store: Must be ``True``. This is the explicit
                consent gate for storing personal contact/address data.

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": {
      "name": "<name>",
      "shipping_address": "<shipping_address>"
    },
    "name": "save_shipping_profile"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesProfile name, e.g. ``"home"`` or ``"office"``.
overwriteNoReplace an existing profile with the same name. Default: false.
set_defaultNoMake this the default shipping profile. Default: false.
consent_to_storeNoMust be ``True``. This is the explicit consent gate for storing personal contact/address data. Default: false.
shipping_addressYesFull shipping contact/address dict. Keys: ``first_name``, ``last_name``, ``email``, ``phone``, ``street``, ``city``, ``postal_code``, ``country``; include ``state`` for US addresses.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.5.1
    • changedInput schema / properties / consent_to_store / description
      Previous value: -"Default: false."New value: +"Must be ``True``. This is the explicit consent gate for storing personal contact/address data. Default: false."
    • addedInput schema / properties / name / description
      Added value: +"Profile name, e.g. ``\"home\"`` or ``\"office\"``."
    • changedInput schema / properties / overwrite / description
      Previous value: -"Default: false."New value: +"Replace an existing profile with the same name. Default: false."
    • changedInput schema / properties / set_default / description
      Previous value: -"Default: false."New value: +"Make this the default shipping profile. Default: false."
    • addedInput schema / properties / shipping_address / description
      Added value: +"Full shipping contact/address dict. Keys: ``first_name``, ``last_name``, ``email``, ``phone``, ``street``, ``city``, ``postal_code``, ``country``; include ``state`` for US addresses."
  2. Changed6 schema fields changedv1.5.0
    • removedInput schema / properties / consent_to_store / default
      Removed value: -false
    • addedInput schema / properties / consent_to_store / description
      Added value: +"Default: false."
    • removedInput schema / properties / overwrite / default
      Removed value: -false
    • addedInput schema / properties / overwrite / description
      Added value: +"Default: false."
    • removedInput schema / properties / set_default / default
      Removed value: -false
    • addedInput schema / properties / set_default / description
      Added value: +"Default: false."
  3. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already disclose readOnlyHint=false and destructiveHint=true, so safety is partly covered; the description adds real value beyond that by explaining that overwrite replaces an existing profile of the same name and that set_default changes the default profile, indicating what gets destroyed or mutated. It stops short of saying what happens if consent_to_store is false/omitted or whether the prior default is cleared.

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

Conciseness3/5

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

The lead sentence is front-loaded and useful, but the docstring-style Args block duplicates parameter descriptions already fully covered in the schema, adding length without new information. Functional but not tight.

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 a write tool with a nested address object and no output schema, the description covers the consent gate, overwrite semantics, default-profile behavior, and the required address keys. Remaining gaps are edge-case behavior (consent false, name collisions, returned result) rather than anything blocking a correct call.

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%, so the Args block largely restates the schema verbatim, including the shipping_address key list. The one bit of added meaning is the 'Must be True' emphasis on consent_to_store, which is already present in the schema description, so the baseline 3 applies.

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?

The first sentence states a specific verb and resource ('Save a local shipping profile') plus the consent precondition, which an agent can distinguish from list_shipping_profiles and delete_shipping_profile. It does not name those siblings explicitly, so differentiation relies on the reader scanning the tool list.

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 'after explicit user consent' clause is an actionable prerequisite an agent must satisfy before calling, and the overwrite/set_default parameter docs imply the intended update scenarios. There is no explicit when-not guidance or reference to the sibling list/delete/validate tools that would complete the routing story.

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

Deploy Server

Other Tools