Skip to main content
Glama
Sign In
fedeclavero

tiendanube-mcp

by fedeclavero
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Orders Create

tiendanube_orders_create

Create Tiendanube orders for imports or manual sales with line items and customer details; set inventory_behaviour to bypass or reserve stock.

Instructions

Create an order (e.g. for imports or manual sales). Check inventory_behaviour to control stock. HTTP: POST /orders Required scope: write_orders API version: 2025-03

Input Schema

NameRequiredDescriptionDefault
noteNoCustomer note
statusNoOrder status (open | closed | cancelled)
gatewayNoPayment gateway name
currencyNoISO currency code, e.g. ARS
customerNoCustomer: {name, email, phone, document}
discountNoDiscount amount
languageNoLanguage code (es, pt, en)
productsYesLine items: [{variant_id, quantity, price}]
shippingNoShipping carrier name
owner_noteNoPrivate store note
payment_statusNoPayment status (pending | authorized | paid | voided | refunded | abandoned)
billing_addressNoBilling address
shipping_optionNoShipping option name
shipping_addressNoShipping address
additional_fieldsNoExtra raw API body fields not covered above; merged into the request body
inventory_behaviourNobypass = do not touch stock; claim = reserve stock (bypass | claim)
shipping_cost_ownerNoShipping cost paid by the store
shipping_pickup_typeNoDelivery type (ship | pickup)
send_fulfillment_emailNoEmail fulfillment updates to the buyer
shipping_cost_customerNoShipping cost charged to customer
send_confirmation_emailNoEmail confirmation to the buyer

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare the mutation and safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent). The description adds useful operational context: required scope 'write_orders', API version, and the inventory_behaviour switch. It does not cover failure behavior or return semantics, so it is adequate but not rich.

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

Conciseness4/5

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

The description is short and front-loaded with the core action and key caveat. The HTTP method, scope, and API version add useful operational metadata, though the line breaks could be slightly more organized.

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 21-parameter create tool with full schema coverage and annotations, the description supplies the critical scope and stock-control hint. It does not describe the response, but no output schema exists and the schema itself covers the input details.

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 schema already documents all 21 parameters. The description only highlights inventory_behaviour and is otherwise silent on parameter semantics, making 3 the appropriate baseline.

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 and resource ('Create an order') and gives examples ('imports or manual sales'). It does not explicitly differentiate this from sibling tools such as draft_orders_create or orders_update, so it falls short of a 5.

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 examples give some context for when to use the tool, and the description points to inventory_behaviour for stock control. However, it does not name alternatives or state when not to use this tool versus creating a draft order or updating an existing order.

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