An MCP server for cross-border commerce

Commerce is one of the most agent-shaped workloads on the internet. A buyer asking an agent to "find me this jacket from GU and price it with duties to Kazakhstan" looks like a single sentence. Under the hood it is at least four primitives: parse the supplier page, localize its copy, compute the price with landed cost, and route the package via an optimal carrier.

For the last year every serious agent framework grew a tool-calling surface. Anthropic shipped MCP, OpenAI shipped the Apps SDK, Cursor and Zed ship MCP natively, and "call this tool over HTTP" is now the floor of any usable agent. Commerce still calls fragile scraping scripts. That is the gap Turaxia closes.

Primitives, not agents

Turaxia does not ship "a buying agent" or "a Shopify copilot". We ship typed primitives that any agent can call:

• turaxia.parse — supplier URL → typed product record with per-field confidence.
• turaxia.localize — a product record → translated, glossary-consistent copy in the target locale.
• turaxia.price.quote — a typed record + destination → landed cost including FX, duty, and shipping.
• turaxia.route.resolve — same typed record → optimal carrier and a package plan.

Each primitive is available as REST, CLI, TypeScript SDK, and MCP. Same contract everywhere. An agent calling turaxia.parse over MCP gets exactly what a human operator gets on the Console dashboard.

Why not just one giant "commerce agent" tool

Because agents lose their reasoning when you hide too many decisions inside a single tool. The agent-era lesson is that the useful abstraction level is one-primitive-per-tool, with typed inputs and typed outputs. Leave the reasoning to the agent. Ship stable primitives.

That is also the shape our public proof bundle validates. Every card in /proof corresponds to a single Turaxia primitive, not a meta-workflow.

How Turaxia ships MCP today

Every generally-available module (Parse, Localize, Price, Route, Connect, Console) exposes an MCP server. Configure it in a client like Claude Desktop or Cursor:

{
  "mcpServers": {
    "turaxia": {
      "command": "npx",
      "args": ["-y", "@turaxia/mcp"],
      "env": { "TURAXIA_API_KEY": "${TURAXIA_KEY}" }
    }
  }
}

That single entry gives the agent access to every generally-available Turaxia primitive. Scoping is handled inside Connect, our workspace-isolated control plane; the agent never needs to know about it.

What we are not doing

We are not shipping an opinionated "buying agent" as a product. We are not shipping a Shopify plugin that wraps the primitives and pretends they are one. We are not shipping "a commerce copilot" as a marketing layer.

We are shipping the substrate. When an agent wants to do commerce, it calls typed primitives. When an operator wants to do commerce, they call the same primitives through a dashboard. When a developer wants to do commerce, they call them through an SDK. Same contract.

Try it

• The MCP quickstart: /docs/mcp.
• The live proof bundle: /proof.
• Everything on the developer side: /developers.