Find your venue’s MCP target in the introduction and verify that it is live before use. The hosted service requires Authorization: Bearer <apiKey> on every request. It keeps no client key or MCP session as authority.

​
Direct remote client

  1. Start the device grant: call POST /v1/agent-connect/start with clientName and scopes (read, or read and trade). The answer carries a verification URL and a user code.
  2. The account owner opens the URL, signs in and checks the code, scopes and account before approving with a passkey. The agent must not ask for the owner’s passkey or session bearer.
  3. Call POST /v1/agent-connect/complete with the connectCode at the interval the start answer gives. The grant lasts at most ten minutes. A slow_down result adds five seconds to the interval. Approval returns the key once. Store it in a file only you can read.
  4. Configure the client’s secret store to supply the key to every HTTP request. Never put a real key in source control, chat, command-line arguments or logs.
The following is a shape example, not a copy-and-paste credential file. Client configuration syntax varies. Replace the placeholder through the client’s private secret mechanism.
Hosted edel_connect only confirms the supplied key. It never starts a browser grant or writes a key. If the key expires or is revoked, run the device grant again, get a new owner approval and update the remote header. Then call edel_status before trading. See MCP tools for the current tool vocabulary and REST mapping.