alza-mcp

by samuelseidel

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Add a product to the account cart

add_to_cart

Add a product to the authenticated user's Alza account cart by Alza product code, with optional quantity (1-99).

Instructions

Add one product to the authenticated user's Alza account cart by its Alza product code (the code from search_products/get_product, e.g. RI054b1 — not the numeric id). Use when the user wants a product put into their Alza account; pass quantity (default 1, max 99). Side effect: mutates the user's cart — the item stays there until removed or ordered (there is no basket-remove tool). Do not use for the anonymous web checkout cart — that is web_add_to_cart. Requires a loaded mobile API access token — check account_status first; if none is loaded, run auth_start, have the user complete the browser sign-in, then auth_exchange with the returned code and state. The response echoes the added line and the new basket count; verify with cart if in doubt. Example: add_to_cart({code: "RI054b1", quantity: 1}).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`code`	Yes	Alza product code, e.g. 'RI054b1' (the `code` field from `search_products`).
`quantity`	No	How many units to add. Default 1, max 99.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`err`	No
`msg`	No
`data`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Sep 15, 2026

TDQS

A5/5.0

Behavior5/5

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

Goes beyond annotations by disclosing the mutation side effect (item persists until removed or ordered), the absence of a removal tool, the requirement of a loaded mobile API token, and the response shape (echoes line and basket count). Annotations only say readOnlyHint=false and destructiveHint=false, so this description adds substantial behavioral context.

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?

Though longer than typical, every sentence earns its place: purpose, usage, side effects, exclusions, auth steps, response note, and a concrete example. Well-structured and front-loaded with the core action. No redundancy.

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 complexity (auth dependency, side effects, alternatives, parameter nuances) and that an output schema exists, the description covers everything an agent needs to call this tool correctly: purpose, constraints, prerequisites, and verification path. No gaps.

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

Parameters5/5

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

Schema coverage is 100% and already documents both parameters, but the description adds meaningful clarifications: the code format example (RI054b1), explicit statement that it's not the numeric id, and that quantity defaults to 1 and max 99. This exceeds the baseline and aids correct invocation.

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?

States a specific verb and resource: 'Add one product to the authenticated user's Alza account cart'. Distinguishes from the anonymous web checkout via `web_add_to_cart` and clarifies the product code is the Alza code, not numeric id. 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 Guidelines5/5

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

Explicitly states when to use ('when the user wants a product put into their Alza account') and when not to ('Do not use for the anonymous web checkout cart'), names the alternative (`web_add_to_cart`), and provides a detailed prerequisite auth flow (`account_status`, `auth_start`, `auth_exchange`). No ambiguity left.

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