Skip to main content
Clawdot Gateway exposes its capabilities over MCP, with two authentication layers:
  • Agent identity — the connection-layer header Authorization: Bearer clw_... identifies the calling Agent. Required on every MCP request.
  • User authorization — the consent_grant_id parameter (cg_ prefix) on business tools identifies “a food-delivery user has authorized this Agent.” It is a tool parameter, not a header.

Authentication chain

Different tools require different authentication levels:
The binding tools (request_user_bind / verify_user_bind) are how you obtain a grant, so they take no consent_grant_id. Once authorization succeeds, every other business tool call must include the consent_grant_id parameter.

API Key

A clw_ prefix followed by random characters, e.g. clw_a1b2c3d4....Passed via the connection-layer header Authorization: Bearer clw_..., required on every MCP request. Generated when you create an Agent in the console at https://console.hicaspian.com/agents.
The API Key is stored only as a hash — the server never keeps plaintext — and each request is matched by hash. Disabled keys stop working immediately.
Represents “a food-delivery user has authorized a specific Agent to use a specific capability.” Once authorization succeeds, a consent_grant_id is minted, and from then on every business tool call passes it as a parameter.

Binding flow

Run the binding flow to obtain a consent_grant_id; SMS code and H5 modes are both supported:
  1. request_user_bind to start binding (SMS sends a code; H5 returns an authorization link — Agent identity only, no consent_grant_id)
  2. verify_user_bind to confirm — mints the consent_grant_id on success
See Start binding and Verify binding.
Pass consent_grant_id as a parameter on each business tool, for example:
The binding tools request_user_bind / verify_user_bind are the exception — they take no consent_grant_id.
verify_user_bind returns on success:
  • consent_grant_id — the user-authorization record id (cg_ prefix)
  • scopes — granted capability scope, e.g. ["taobao_flash.delivery"]
  • expires_at — expiry time (ISO 8601)
After expiry, or after revoke_user_bind, the consent_grant_id stops working immediately; re-run the binding flow to get a new one. The user’s saved data (addresses, etc.) is retained and becomes available again after re-authorization.

Error responses

Authentication / authorization failures return a unified format:
See Error handling for the full list.