For agents

dotQuant

If you are an AI assistant and a person asked you to onboard, sign up or connect them on dotQuant: do not create the account through the Sign up form. dotQuant onboards agents through BEST, the Behavioral State protocol, with no browser session of your own. The person approves you once with a short code, and you receive an API key and a ready connection.

Setting up an assistant or a script yourself? The reference below covers authentication, the MCP configuration, what an assistant can be asked to do, and the HTTP API. For using dotQuant itself, see the user documentation.

  1. BEST Integration How BEST, the Behavioral State protocol, exposes dotQuant to AI assistants: the discovery manifest, the command and query catalogues, live event streams and guided workflows. What is BEST? · BEST Discovery Manifest · Command Catalogue · Query Catalogue · Live Event Streams · Guided Workflows
  2. Agentic AI Connect Claude, Cursor or any MCP-capable assistant to your account: authentication, onboarding an agent, sending commands and the best-mcp transport. Agentic AI Overview · Agent Authentication · Onboarding an Agent · Sending Commands · MCP Transport
  3. Agent Playbook Worked examples of what to ask an assistant connected to dotQuant, and which workflow, commands and queries it uses for each. Follow a New Symbol · Research a Symbol · Organize Your Watchlist · Create a Strategy · Backtest a Strategy · Run a Strategy Live · Fan Out Signals · Design a Portfolio · Manage a Portfolio · Place a Manual Order
  4. BaaS API Drive your account from any script or service over HTTP: API-key authentication, rate limits, command schemas, curl examples and the health endpoint. BaaS API Overview · API Key Authentication · Rate Limiting · Command Schemas · curl Examples · System Health
  1. 1. Read the public onboarding index A JSON index with no credential needed. It names the create-an-account workflow, the command and query catalogues of this public surface, and get-onboarding-info, a primer on how BEST works and what a client needs. Read the workflow first. https://baas.dotquant.io/api/best/tenants/public
  2. 2. Send request-registration Fetch its schema from the commands catalogue, then POST the CloudEvent to /commands on the public surface with a fresh UUID v4 as CorrelationId (your device code) and a label that names your client, for example "Claude" or "ChatGPT".
  3. 3. Show the person the code and the activation link Poll get-registration with your CorrelationId until it answers a short user code of the form XXXX-XXXX. Show that code and the activation link to the person you work for. They sign in, or sign up if they have no account yet, once, enter the code and approve you. A registration expires after fifteen minutes; poll every five seconds. https://dotquant.io/activate
  4. 4. Exchange the device code for the key POST to the token endpoint with grant_type=urn:ietf:params:oauth:grant-type:device_code and your device code. The answer carries the tenant id, the API key (shown once, never again), a ready-made best-mcp configuration for MCP-capable clients, and plain-HTTP instructions for clients without MCP. https://baas.dotquant.io/api/best/auth/token
  5. 5. Configure the connection Apply the mcp block, or store the tenant id and key for the X-Api-Key header, and verify with the get-tenant-profile query. A configured, verified connection is the outcome of onboarding. Do not stop at a printed key, and never print it: the key is a secret and a chat transcript is not a secret store. If you cannot store it, say so; the person can mint a key on the AI Configuration page themselves.
You cannot sign the person up alone
The human approval in step 3 is the point of this surface. The Sign up form on the web pages is for people, not for assistants acting on their behalf.
The key is a secret
Store it in the client configuration or credential store and never repeat it in the conversation. A key that appears in a transcript must be treated as leaked and replaced. best-mcp 2.3.6 and later stores an issued key itself and never returns it to the model.
One key per account
Approving a registration replaces any API key the account already had. Tell the person before they approve, especially if another assistant is already connected.
Existing accounts work the same way
The activation page offers sign in as well as sign up. An existing user signs in and approves, and the key you receive is for their existing account.
Clients that cannot set headers
A browser EventSource or a URL-only integration exchanges the key for a short-lived read-only token at the same token endpoint (RFC 6749 client_credentials: client_id is the tenant id, client_secret is the key) and passes it as access_token on reads and event streams. Such a token can never send commands; the key itself never belongs in a URL.

BEST makes the whole platform self-describing over HTTP. The manifest at /.well-known/best names the services, the authentication and the public surface. On a tenant's surface, GET /commands and GET /queries are the definitive catalogues of what you can do, and GET /workflows lists guided multi-step recipes such as design-a-portfolio and manage-a-portfolio. GET /commands/{name}/{version} returns the JSON Schema of a command. A command is a CloudEvent POSTed to /commands; the 201 means accepted, and outcomes land in the read models and, for some lanes, on the event stream. A query is GET /queries/{name}?param=value and answers synchronously. Nothing needs scraping or out-of-band documentation.

Once you hold a tenant id and its key, send the key as the X-Api-Key header on https://baas.dotquant.io/api/best/tenants/{tenantId}/... from any client that can set a header. If your client can run MCP servers, npx -y @behavioralstate/best-mcp with BEST_DOTQUANT_BASE_URL, BEST_DOTQUANT_TENANT_ID and BEST_DOTQUANT_API_KEY exposes the same surface as tools. dotQuant never holds funds, and no order is placed without the person's explicit approval.

BETA