Skip to main content
Glama

List checkout shipping rules

list_conditional_tariffs
Read-onlyIdempotent

List the checkout shipping rules (conditional tariffs) that decide what a connected store's customers pay for shipping: weight or cart-price ranges mapped to free, flat, marked-up, discounted or live carrier prices, plus each store's delivery-config, pricing-strategy and fallback-rate entries. Scoped to the connected Skydropx account; newest first. Without merchant_store_id it mixes every store's rules; an unknown id returns an empty data[]. Use it to answer '¿qué reglas de envío tengo?' and before create_conditional_tariff to see the priorities in use; get_conditional_tariff reads one rule by id, update_conditional_tariff and delete_conditional_tariff change or remove it. Not for prices or carriers: use quote_shipment for real carrier prices, list_carrier_services for the account's services, list_merchant_store_carriers for a store's checkout carriers. It answers NOT_FOUND when the ecommerce integration is not enabled on the platform. Returns { data, meta }: the rules and the paging cursor.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_conditional_tariffs"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoPage number, 1-based (default 1). Each page holds 10 items; this endpoint has a fixed page size and ignores per_page. To know whether more pages exist, read meta.next_page in the response (null on the last page); meta.total_pages and meta.total_count give the totals.
merchant_store_idNoRestrict to one connected store: its record id, data[].id from list_merchant_stores

Output Schema

NameRequiredDescriptionDefault
dataNo
metaNoPagination state of this page of results
includedNoSideloaded JSON:API records (id, type, attributes) referenced from relationships; absent when nothing is sideloaded

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / merchant_store_id / description
      Previous value: -"Restrict to one connected store"New value: +"Restrict to one connected store: its record id, data[].id from list_merchant_stores"
    • addedInput schema / properties / page / description
      Added value: +"Page number, 1-based (default 1). Each page holds 10 items; this endpoint has a fixed page size and ignores per_page. To know whether more pages exist, read meta.next_page in the response (null on the last page); meta.total_pages and meta.total_count give the totals."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "data": {
      +      "items": {
      +        "properties": {
      +          "attributes": {
      +            "properties": {
      +              "action": {},
      +              "additional_days": {
      +                "description": "Days added to the delivery estimate"
      +              },
      +              "calculation": {},
      +              "carrier_services_config": {
      +                "description": "Per-service settings of the rule"
      +              },
      +              "created_at": {},
      +              "enabled": {
      +                "description": "Whether the rule is live at checkout"
      +              },
      +              "id": {
      +                "description": "Rule id"
      +              },
      +              "max_price": {
      +                "description": "Cart subtotal upper bound; decimal as string"
      +              },
      +              "max_weight": {
      +                "description": "kg, inclusive upper bound; decimal as string"
      +              },
      +              "merchant_store_id": {
      +                "description": "Store record id (list_merchant_stores data[].id)"
      +              },
      +              "min_price": {
      +                "description": "Cart subtotal lower bound; decimal as string"
      +              },
      +              "min_weight": {
      +                "description": "kg, inclusive lower bound; decimal as string"
      +              },
      +              "name": {
      +                "description": "Human name of the rule"
      +              },
      +              "priority": {
      +                "description": "Evaluation order: lower runs first; the first match applies"
      +              },
      +              "tariff_type": {},
      +              "updated_at": {},
      +              "value": {
      +                "description": "Amount (or %) for increase/decrease/flat_rate; decimal as string"
      +              }
      +            },
      +            "type": "object"
      +          },
      +          "id": {
      +            "description": "Resource id"
      +          },
      +          "relationships": {
      +            "description": "Links to related records (see included)"
      +          },
      +          "type": {
      +            "description": "always 'conditional_tariff'"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "included": {
      +      "description": "Sideloaded JSON:API records (id, type, attributes) referenced from relationships; absent when nothing is sideloaded",
      +      "items": {},
      +      "type": "array"
      +    },
      +    "meta": {
      +      "description": "Pagination state of this page of results",
      +      "properties": {
      +        "current_page": {
      +          "description": "The page returned (1-based)"
      +        },
      +        "next_page": {
      +          "description": "Next page number; null on the last page"
      +        },
      +        "per_page": {
      +          "description": "Items per page; absent on v1 endpoints"
      +        },
      +        "prev_page": {
      +          "description": "Previous page number; null on the first page"
      +        },
      +        "total_count": {
      +          "description": "Number of items across all pages"
      +        },
      +        "total_pages": {
      +          "description": "Number of pages available"
      +        }
      +      },
      +      "type": "object"
      +    }
      +  },
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent and open-world, so the safety profile is covered. The description adds real value beyond that: scoped to the connected Skydropx account, newest-first ordering, that omitting merchant_store_id mixes all stores, that an unknown id yields an empty data[] rather than an error, and that NOT_FOUND is returned when the ecommerce integration is disabled. It stops short of stating rate limits or result-set size caps.

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?

Front-loaded with the resource definition, then scoping, then routing to alternatives and exclusions — a sensible order. It is dense and long for a two-parameter list tool, and the Spanish sample query is a slight digression, but no sentence is pure filler.

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 explaining return values is optional, yet the description still notes the { data, meta } shape and paging. Combined with the scoping and error-behavior notes, an agent has what it needs to call this correctly; only pagination details are left entirely to the schema, which is acceptable here.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description nevertheless adds semantics not in the schema, notably the default behavior with no merchant_store_id (results mix every store's rules) and the empty-data[] outcome for an unrecognized id. Both page and merchant_store_id are covered by the schema, so the added value is incremental rather than essential.

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 (list checkout shipping rules / conditional tariffs) and immediately explains the domain meaning: weight or cart-price ranges mapped to free, flat, marked-up, discounted or live carrier prices. An agent can distinguish it from list_carrier_services or quote_shipment without opening any schema.

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 names when to use it (answer '¿qué reglas de envío tengo?' and before create_conditional_tariff), which sibling handles a single rule (get_conditional_tariff), which mutate it (update/delete), and three explicit exclusions with the correct alternatives named. Nothing is left to inference.

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.

Resources