Skip to main content
Glama
mouser-mcp

mouser-mcp

Create a Mouser cart from a past order

create_cart_from_order

Starts a new Mouser cart with the parts from a past order so you can reorder them; it does not place the order.

Instructions

Starts a new Mouser cart containing the parts of a past order, e.g. to reorder. Does not place an order.

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": {
      "orderNumber": "<orderNumber>"
    },
    "name": "create_cart_from_order"
  }
}

Input Schema

NameRequiredDescriptionDefault
orderNumberYes

Output Schema

NameRequiredDescriptionDefault
itemsYes
cartKeyNo
currencyNo
itemCountNo
merchandiseTotalNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.0.5

TDQS

A4/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, but do not convey that the operation stops at the cart and never submits an order — the description adds that boundary explicitly. It leaves open whether a repeated call spawns a second cart or replaces an existing one, which matters given idempotentHint=false.

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 short sentences, front-loaded with what the tool does and immediately followed by the most important scope limit. Nothing extraneous.

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?

An output schema exists, so return values need not be described, and the tool is single-parameter, keeping requirements modest. The gap is the interaction with an already-existing cart and whether repeated invocations create duplicates — the one fact an agent most needs given non-idempotent behavior.

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 coverage is 0%, so the description must carry the burden for orderNumber. 'a past order' usefully implies the value must reference a historical order rather than a cart or quote, but no format, provenance (e.g. from get_order_history/get_order), or failure behavior is given. Partial compensation only.

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?

States a specific verb and resource: 'Starts a new Mouser cart containing the parts of a past order.' That clearly separates it from sibling add_to_cart (adding individual items) and get_cart (retrieving an existing cart), though it never names those siblings explicitly.

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?

'e.g. to reorder' supplies a concrete use case, and 'Does not place an order' bounds the outcome so an agent knows this is a cart-building step, not checkout. It stops short of naming alternatives (e.g. use get_order first to obtain the order number) or stating when this is preferable to manually adding items.

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