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.
- Fetch our spec:
GET /v3/api-docs - Feed it to your generator of choice.
- Configure the generator to inject
X-Api-Keyfrom an environment variable. - 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_sessionstarts a new session.identify_shoeruns the progressive loop on/shoe-selection.add_shoe_to_sessionadds an identified shoe.set_foot_measurementsets the foot length.get_recommendationcomputes a target-shoe recommendation.
What you build vs what GetSize provides
| You (MCP server) | GetSize (Public API) |
|---|---|
| MCP server process | Closed-world shoe validation |
| OAuth to the MCP client | Per-key rate limiting |
| Tenant provisioning UX | Session isolation (per key) |
| Per-tenant quotas (if splitting further) | Structured error envelope |
| Conversation-to-session binding | OpenAPI 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.