Skip to main content
Glama

Shop Request

shop_request

Call the API of a connected e-shop (Shoptet, Upgates, Shopify, WPJ Shop, WooCommerce, PrestaShop, Shoper, Shopware, Magento, BigCommerce, IdoSell) — ecomdly adds the owner's API access, you never see or need the key. Follow the platform's skill (shop_list names it) for paths and limits, and for the job itself (product titles, descriptions, translations, prices, stock, feeds) a skill from the ecomdly catalog — search_skills first, before you change products. path is relative to the API (Shoptet: /api/orders?page=1, Upgates: /orders?page=1, Shopify: /graphql.json and WPJ Shop: /admin/graphql/ with a POST body {"query": …}, WooCommerce: /orders?per_page=50, PrestaShop: /orders?display=full, Shoper: /orders?limit=50, Shopware: /search/order with a POST body of criteria, Magento: /V1/orders?searchCriteria[pageSize]=50, BigCommerce: /v2/orders?limit=50 or /v3/catalog/products, IdoSell: /orders/orders/search with a POST body {"params": {…}}). Reading always works (GET, GraphQL queries, Shopify bulk queries, Shopware and IdoSell searches, a Shoper bulk of GETs); changes (other POST/PUT/PATCH/DELETE, GraphQL mutations) only where the owner allowed them on ecomdly, and only what the owner confirmed in this conversation. For a custom API you sign in yourself as its docs say, writing {{secret}} where the key goes (headers, path or body). Returns the status, the limit headers and the body (long bodies are cut — page through, or use a snapshot / bulk query).

Input Schema

NameRequiredDescriptionDefault
bodyNoThe body of a POST/PUT/PATCH as text: JSON — for GraphQL (Shopify, WPJ Shop, BigCommerce /graphql) {"query": "…", "variables": {…}} — or, for PrestaShop writes, the resource XML.
pathYesThe API path with its query string, e.g. /api/orders?page=1&itemsPerPage=50 (Shoptet), /orders?page=1 (Upgates), /graphql.json (Shopify), /admin/graphql/ (WPJ Shop), /orders?per_page=50 (WooCommerce), /orders?display=full (PrestaShop), /orders?limit=50 (Shoper), /search/order (Shopware), /V1/orders?searchCriteria[pageSize]=50 (Magento), /v2/orders?limit=50 (BigCommerce), /orders/orders/search (IdoSell). A full https URL on the platform's own hosts also works (a Shoptet snapshot resultUrl).
shopNoThe e-shop to use — its name or id from shop_list; may be left out when only one is connected.
methodNoGET (default), POST, PUT, PATCH or DELETE.
headersNoCustom API only: a JSON object of headers the API wants, e.g. {"Authorization": "Bearer {{secret}}"} or {"Authorization": "Basic {{basic:apiuser}}"}. Write {{secret}} where the key goes (also in the path or body); ecomdly puts it in on the server and never shows it to you.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / body / description
      Previous value: -"The body of a POST/PUT/PATCH as text: JSON — for GraphQL (Shopify, WPJ Shop) {\"query\": \"…\", \"variables\": {…}} — or, for PrestaShop writes, the resource XML."New value: +"The body of a POST/PUT/PATCH as text: JSON — for GraphQL (Shopify, WPJ Shop, BigCommerce /graphql) {\"query\": \"…\", \"variables\": {…}} — or, for PrestaShop writes, the resource XML."
    • changedInput schema / properties / path / description
      Previous value: -"The API path with its query string, e.g. /api/orders?page=1&itemsPerPage=50 (Shoptet), /orders?page=1 (Upgates), /graphql.json (Shopify), /admin/graphql/ (WPJ Shop), /orders?per_page=50 (WooCommerce), /orders?display=full (PrestaShop), /orders?limit=50 (Shoper), /search/order (Shopware). A full https URL on the platform's own hosts also works (a Shoptet snapshot resultUrl)."New value: +"The API path with its query string, e.g. /api/orders?page=1&itemsPerPage=50 (Shoptet), /orders?page=1 (Upgates), /graphql.json (Shopify), /admin/graphql/ (WPJ Shop), /orders?per_page=50 (WooCommerce), /orders?display=full (PrestaShop), /orders?limit=50 (Shoper), /search/order (Shopware), /V1/orders?searchCriteria[pageSize]=50 (Magento), /v2/orders?limit=50 (BigCommerce), /orders/orders/search (IdoSell). A full https URL on the platform's own hosts also works (a Shoptet snapshot resultUrl)."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: auth is injected server-side (the key is never seen), reads always succeed while mutations are gated on owner permission and prior confirmation, and returns include status, limit headers, and a truncated body with paging/snapshot guidance. These are exactly the behavioral traits an agent needs.

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 purpose before the routing detail and read/write rules, and every clause is informative. It is long and the per-platform path parenthetical partly duplicates the schema, but a single tool covering eleven platforms justifies the density.

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?

No output schema exists, so the description explains the return shape (status, limit headers, truncated body, paging). Combined with the auth, gating, and platform-dispatch detail, nothing an agent needs to invoke this correctly is missing.

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, but the description adds meaning beyond the schema: it maps each platform to its path convention, clarifies GET as default, describes the {{secret}} placeholder convention for custom APIs, and the GraphQL POST-body shape. Most of this overlaps the schema descriptions, so it stays just above baseline.

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 — 'Call the API of a connected e-shop' — and names the concrete platforms (Shoptet, Upgates, Shopify, etc.). It distinguishes itself from siblings by pointing to shop_list for the platform skill and search_skills for the job, so an agent can route correctly without opening a 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 says to call shop_list first to learn the platform, to run search_skills before changing products, and to consult a skill for the job. It also spells out the read/write rule (reads always work; changes only where the owner allowed and confirmed in this conversation) and the custom-API sign-in procedure. This is a complete when/when-not/alternatives set.

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