Quick Start
The Skills Platform uses MCP (Model Context Protocol) as its integration protocol. Clawdot Gateway exposes 24 delivery MCP tools over Streamable HTTP — covering the whole chain: authorization, shops, addresses, ordering, and payment. Configure the gateway as a remote MCP server and your Agent can auto-discover and call these tools.MCP (recommended)
For clients that support MCP like Claude Desktop and Cursor, and any Agent framework that can connect to a remote MCP server. Streamable HTTP, automatic tool discovery, zero boilerplate.
Self-built wrapper (Function Calling)
Platform doesn’t support remote MCP yet? Register the tools as function tools in your framework against the same tool contract (tool name + parameters), and forward each call to MCP in the function implementation.
This is a narrative getting-started guide. Whichever way you integrate, it sits on one contract: 24 delivery MCP tools with the same tool names, parameters, and response shapes. For full field tables see MCP Overview; for the end-to-end ordering sequence see Order Flow.
MCP Protocol
MCP (Model Context Protocol) is the standard protocol released by Anthropic, enabling client applications like Claude Desktop and Cursor to easily integrate with the Skills Platform. Clawdot Gateway exposes its MCP interface over Streamable HTTP.Step 1: Get API Key
Create your Agent in the Clawdot Console:- Sign in to the console and open Agent Management
- Click Create New Agent, enter a name and description
- The system auto-generates an API Key (starting with
clw_) - Copy the API Key to a safe location
The API Key is only displayed once at creation. If lost, regenerate it in the console. See Authentication.
Step 2: Configure MCP Server
The Gateway’s public MCP endpoint ishttps://eleme-gateway.hicaspian.com/mcp/v1 (Streamable HTTP). Agent identity is passed at the connection layer via the Authorization: Bearer clw_... header.
Configure it in any client that supports remote Streamable HTTP MCP:
Step 3: User Authorization (consent grant)
The API Key only identifies the Agent. To act on behalf of a user, you also need that user’s authorization (consent grant). The first time a user uses your Agent, run a binding flow once to obtain aconsent_grant_id:
An H5 authorization mode is also supported (
auth_type="h5", request_user_bind returns an authorization link). For full fields and callback behavior see Start Binding and Confirm Binding.Step 4: Call Gateway Skills
Through the MCP protocol, your Agent can auto-discover and call all Gateway tools. The MCP client displays all available tools in its toolbar. When calling, pass theconsent_grant_id from the previous step as a parameter on each tool (not a header).
Example conversation:
User: I want to order food nearby Claude: I can help you search for nearby restaurants. First, please tell me your location or address. User: No. 1 Zhongguancun Avenue Claude: [Calling Gateway toolOrdering is a stateful chain: quote → select address → preview → create → sign and pay, with cross-step IDs minted by the gateway and passed through verbatim. For the full tool list and ordering chain see MCP Overview and Order Flow.search_shops(withconsent_grant_id)] Searching for restaurants near Zhongguancun Avenue… … returns recommendation list
Self-built Wrapper (Function Calling)
If your platform does not yet support remote MCP, you can register the tools as function tools in your framework (OpenAI Function Calling, LangChain, LlamaIndex, etc.) against the same tool contract, and forward each call to MCP in the function implementation. The tool names, parameters, and response shapes are identical to MCP — all you wrap is the “call channel”; the business semantics are unchanged.Step 1: Get API Key
Same as above (create an Agent in the Console).Step 2: User Authorization
Same as above; run a binding flow once to obtain aconsent_grant_id.
Step 3: Register Function Tools Against the Tool Contract
Register Gateway tools as your framework’s function tools. Tool names and parameters mirror the tool contract exactly — so the tool calls the model produces can be forwarded to the gateway without translation:Step 4: Function Implementation — Forward to MCP
Each function forwards the arguments the model produced (plus the current user’sconsent_grant_id) to the corresponding tool through your MCP client. Agent identity is carried by the API Key at the MCP connection layer; consent_grant_id is passed as a tool parameter:
Tool names, parameters, and response shapes are identical to MCP — the wrapper only “forwards the model’s tool calls to the gateway.” Full fields: Quote Cart · Preview Order · Create Order.
Comparison and Selection
Recommendation:
- MCP: The recommended path. When your client/framework supports remote MCP, configure one server and tools are auto-discovered with zero boilerplate.
- Self-built wrapper (Function Calling): Only when your platform doesn’t support remote MCP yet. Declare function tools against the same tool contract and forward to MCP in the implementation; you can switch smoothly to MCP once the platform supports it.

