Skip to main content
Glama

Change the cart

update_checkout
DestructiveIdempotent

Replace the items in an open checkout (e.g. the user changed their mind). Any PayPal payment created for the old total is dropped.

Input Schema

NameRequiredDescriptionDefault
itemsYes
api_keyNoSandbox key from create_checkout (not needed if the connection already carries one).
session_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already mark the tool as destructive and idempotent. The description adds critical context: that any PayPal payment for the old total is dropped. This discloses a specific destructive consequence not apparent from the annotations alone, though it does not mention permission requirements or rate limits.

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?

Two sentences: the first front-loads the core action, the second adds a key side effect. No wasted words; every sentence earns its place.

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

Completeness3/5

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

The description conveys the main purpose and a critical destructive side effect, but it omits important contextual details: it does not clarify that the session must be open, does not mention the replacement of all existing items, and does not address the required parameters given sparse schema documentation. For a destructive mutation tool, more guidance would be helpful.

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

Parameters2/5

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

Schema description coverage is only 33%, and the description provides no information about the parameters. It does not explain the session_id, the items structure, or the optional api_key. With such low coverage, the description should compensate but does not.

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 description states a specific verb ('Replace') and resource ('items in an open checkout'), making it clearly distinct from create_checkout or get_checkout. It gives an example of when this might be used, but does not explicitly name a sibling tool to contrast with.

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

Usage Guidelines3/5

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

The parenthetical 'e.g. the user changed their mind' implies a use case, but there is no explicit guidance on when to use this tool versus alternatives like create_checkout or cancel_checkout. The reader must infer that this is for modifying an existing open session.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.