Browse documentation

Connect

Providers and connections

Choose BYOK, Workers AI, or subscription providers and authorize tools without exposing credentials.

A connection is an authorized provider, MCP, or API account. Connection records are tenant-scoped. Secret values stay encrypted or in Worker secrets; public APIs return only status and safe metadata. Flary keeps provider and tool credentials outside prompts, generated Code Mode, and transcripts.

Model provider choices

The current CLI setup supports these deployment choices:

Choice How it works
Google Gemini, OpenAI, or Anthropic API BYOK. Enter an API key during setup and store it as a Worker secret.
Cloudflare Workers AI Uses the connected Cloudflare account. No separate provider key is needed.
No provider Deploy first and configure a provider in trusted host code later.

The hosted installer is planned but is not in the current release. Use the CLI described in the Quickstart.

The personal dashboard can also authorize OpenAI Codex and Anthropic Claude subscriptions. It uses provider OAuth, encrypts and stores those credentials, and exposes only safe connection metadata. A trusted resolveModel implementation must select a stored subscription before an agent turn uses it. Authorization does not silently replace the deployment provider.

For each turn, Flary stores a safe model pin with provider, model, variant, adapter revision, connection reference, and credential generation. It does not store the credential in the transcript.

Provider switching

One thread can switch providers between turns. Flary converts the same canonical messages, completed tool exchanges, attachments, and compaction lineage for the target provider. Provider-private response IDs, cache keys, and hidden reasoning are never sent to another provider.

There is no silent fallback for an explicit model selection. A revoked or missing credential fails before the turn starts.

Add an MCP server

The personal dashboard uses a URL-first MCP flow:

  1. Open Connections.
  2. Enter a name and the server’s HTTPS MCP URL.
  3. Select Add MCP server.
  4. Approve access on the server’s authorization page.
  5. Return to Flary. The connection becomes ready after Flary checks its tool list.

This works with public MCP servers and servers that use the MCP authorization flow. For OAuth servers, Flary uses authorization-code flow with PKCE. It uses a Client ID Metadata Document when the server supports it, and Dynamic Client Registration as a compatibility fallback. The authorization callback returns directly to the user’s deployed Worker. It does not pass through flary.dev.

Flary accepts only public HTTPS endpoints. It blocks local and private network addresses, unsafe redirects, oversized metadata, and long requests. Access and refresh tokens are encrypted in D1. They do not enter prompts, generated code, transcripts, or public API results.

Each ready connection gets a stable namespace. The dashboard exposes all ready connections through one lazy catalog. The model sees tool schemas only after it searches for and selects a tool.

If a tool needs a key that is not configured, the agent can pause and open a protected credential form. Read Secrets and credentials for the encrypted storage and connector-only access flow.