Connect any agent to the brand-facing API.

Any MCP client connects to https://mcp.offersuite.io/mcp and sends the workspace's secret key as a bearer token on each request. The server forwards the key to the API on every call and never stores it.

The server reads the API's OpenAPI document when it runs and builds one tool per operation, named after the operation in snake case (create_offer, publish_offer, get_offer_economics). The tools are always the deployed API's operations: a route added to the API becomes a tool without a change to the server, and a tool the API does not have cannot be listed. Operations that use GET are marked read-only.

{
  "mcpServers": {
    "offer-suite": {
      "type": "http",
      "url": "https://mcp.offersuite.io/mcp",
      "headers": {
        "Authorization": "Bearer os_sk_…"
      }
    }
  }
}

Both addresses, the MCP server and the OpenAPI document, are listed for crawlers and agents in llms.txt.

Offer Suite is not open yet: brands join the waitlist.

Beside the tools, the server hands an agent what it needs to write an offer from the schema alone, with no builder in between.

• An authoring guide, read as an MCP resource: the document's shape, how options, lines and pricing fit together, and how a publish proves them on a real cart.
• Three complete example offers, each with commentary on what to copy. They are the same documents the schema's own tests parse, so an example that stopped validating would fail the build.
• An error catalogue that a test keeps in sync with every error code the API can return and every schema validation message.
• A description on every field of the offer document, the resolve response and the event body, which agents read field by field in create_offer and replace_offer. A test fails any new field without one.

Everything the MCP tools do is plain HTTP underneath. The brand-facing API (offers, carts, costs, items, orders, experiments, events, stores, tenant and privacy) is described by an OpenAPI 3.1 document at api.offersuite.io/openapi.json. It is generated from the same Zod definitions that validate each request and linted on every change: the description and the validation are one definition.

Every error comes back in one shape, {error: {code, message, issues}}, with a stable code. A validation failure lists each field path that failed, so an agent can repair the document and send it again.

{
  "error": {
    "code": "invalid_document",
    "message": "The offer document is invalid",
    "issues": [
      {
        "path": "options[4].lines[0].purchase.sellingPlanId",
        "message": "a subscription purchase requires sellingPlanId"
      },
      {
        "path": "defaultOptionKey",
        "message": "defaultOptionKey \"ritual\" names no option in this document"
      }
    ]
  }
}

A subscription line without its selling plan, and a default option that names no option: both refused, nothing stored.

Shopify-facing endpoints (webhooks, Sidekick and the App Home simulator) are outside the document. They serve Shopify, not your agents.

One conversation from a question to a running experiment: six production tools, and one explicit approval before the publish.

• Keys and the team are managed in the dashboard only. They are not in the OpenAPI document, and an API key cannot call them.
• The full key is shown once, when it is created. Everyone in the workspace can see which keys exist.
• The API enforces roles on every dashboard call, not only the screens.

• Install happens only through Shopify: the MCP server and the API have no install tool.
• One store per workspace for now; a second store cannot join an existing workspace yet.
• No command-line client is offered. Not available yet