Connect
Providers and connections
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:
- Open Connections.
- Enter a name and the server’s HTTPS MCP URL.
- Select Add MCP server.
- Approve access on the server’s authorization page.
- 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.