MCP integration

The GetSize Public API is deliberately shaped to be wrapped as a Model Context Protocol (MCP) server. You can generate one automatically from our OpenAPI spec, or hand-build one for tighter control.

Quick start with the OpenAPI generator

Open-source tools like openapi-mcp and mcp-openapi-proxy consume an OpenAPI 3.x spec and emit an MCP server whose tools map 1:1 to operations.

  1. Fetch our spec: GET /v3/api-docs
  2. Feed it to your generator of choice.
  3. Configure the generator to inject X-Api-Key from an environment variable.
  4. Register the resulting server with your MCP client.

Claude Desktop snippet

{
  "mcpServers": {
    "getsize": {
      "command": "npx",
      "args": ["-y", "mcp-openapi-proxy", "https://www.getsize.shoes/v3/api-docs"],
      "env": {
        "API_KEY": "gsk_live_..."
      }
    }
  }
}

Hosting a remote MCP for multiple tenants

For production use, such as hosting a shared MCP server that shoe stores and their customers' LLM clients connect to, you'll want a custom MCP server in front of our API.

Topology

End user's LLM client (Claude Desktop / in-store chatbot)
        ↕ MCP (stdio or HTTP/SSE)
Your remote MCP server
        ↕ HTTPS + X-Api-Key
GetSize Public API (/api/public/v1/*)

Per-tenant key mapping

Each shoe store gets its own DeveloperApiKeyEntity provisioned by GetSize admins. Your MCP server authenticates the tenant (via MCP's OAuth 2.0 layer, or whatever identity protocol you choose) and looks up the downstream X-Api-Key it holds for that tenant before forwarding. Tenant isolation is inherited for free, since sessions created under one tenant's key cannot be accessed from another.

Session-per-conversation discipline

The MCP server must call POST /sessions once per LLM conversation and thread the returned sessionId through every subsequent tool call for the rest of that conversation. Never share sessions across conversations.

// Pseudocode
function handleToolCall(conversation, tool, args) {
  let sessionId = conversation.state.getSizeSessionId;
  if (!sessionId) {
    sessionId = createSession(tenantApiKey);
    conversation.state.getSizeSessionId = sessionId;
  }
  return callGetSize(tenantApiKey, sessionId, tool, args);
}

Tool design

Expose five tools, each taking sessionId as an argument so the LLM threads it:

  • create_session starts a new session.
  • identify_shoe runs the progressive loop on /shoe-selection.
  • add_shoe_to_session adds an identified shoe.
  • set_foot_measurement sets the foot length.
  • get_recommendation computes a target-shoe recommendation.

What you build vs what GetSize provides

You (MCP server)GetSize (Public API)
MCP server processClosed-world shoe validation
OAuth to the MCP clientPer-key rate limiting
Tenant provisioning UXSession isolation (per key)
Per-tenant quotas (if splitting further)Structured error envelope
Conversation-to-session bindingOpenAPI spec for codegen

Rate limit planning

The per-key rate limit aggregates across all end users of a tenant. Busy integrations should request a higher rateLimitPerMinute when their key is minted. Contact GetSize admins to raise it.

Security notes

  • Never log the downstream X-Api-Key.
  • Never embed the key in tool-call payloads the LLM can see.
  • Rotate by minting a new key, waiting for your MCP to pick it up, then revoking the old one via the admin UI.
  • Use HTTPS end-to-end.

See also: Identifying shoes, API reference.