Connector catalog

Fabric Harness connectors are intentionally modular. The core SDK owns the stable agent/session/tool/sandbox contracts; provider packages and project-local adapters own provider SDKs, credentials, lifecycle, and live compatibility.

There are three connector forms:

Quickstart for any provider

If no pre-built adapter exists, use fh add <url> --category <kind> and pipe to your coding agent:

fh add https://e2b.dev --category sandbox | claude
fh add https://api.notion.com --category data | cursor-agent
fh add https://docs.linear.app --category mcp | codex

The CLI emits the canonical category spec (sandbox.md, mcp.md, or data.md shipped with @fabric-harness/sdk) along with a "build me a connector for this URL" header. The agent reads the provider's docs, follows the spec literally, and writes a single TypeScript file at ./connectors/<provider>.ts. No PR to fabric-harness needed — the file lives in your project.

When fabric-harness ships a first-party recipe for the provider, prefer the named slug:

fh add daytona | claude
fh add linear-mcp | claude

Auto-PR mode

fh add daytona --pr opens a draft GitHub PR with a stub connector file (committed to a connector/<provider> branch) and the canonical spec embedded in the PR body. You (or your coding agent) push commits that flesh out the stub. Requires the gh CLI and a configured remote.

fh add daytona --pr
fh add https://your-provider.example.com --category sandbox --pr --pr-branch=connector/your-provider

Validating connectors

fh doctor --connectors walks connectors/ and .fabricharness/connectors/ and flags files that are missing exports, lack the @fabric-harness/* import, or are otherwise malformed:

fh doctor --connectors
# ✓ connector:daytona.ts: ./connectors/daytona.ts
# ✗ connector:broken.ts: missing @fabric-harness/* import
# ✓ connectors: 1/2 healthy

Install packages

Core connector helpers:

npm install @fabric-harness/sdk @fabric-harness/connectors

Cloud-specific packages:

npm install @fabric-harness/azure
npm install @fabric-harness/databricks

Provider SDKs stay in your app, not in @fabric-harness/sdk:

npm install @daytona/sdk
npm install @e2b/code-interpreter

Sandbox connectors

Sandbox connectors adapt remote execution providers to Fabric's SandboxEnv contract: file operations, shell execution, cwd scoping, cleanup, and optional snapshots.

Daytona example

import { Daytona } from '@daytona/sdk';
import { daytonaSandbox } from '@fabric-harness/connectors';

const client = new Daytona({ apiKey: process.env.DAYTONA_API_KEY });
const remote = await client.create();

const fabric = await init({
  sandbox: daytonaSandbox(remote, { cleanup: true }),
});

Validate any sandbox adapter

import { validateSandboxAdapter } from '@fabric-harness/connectors';

await validateSandboxAdapter(env);

The validator runs a smoke contract: mkdir, writeFile, readFile, exec, and rm.

See Sandbox connectors for the full adapter guide.

MCP connectors

MCP connectors expose remote tools to agents. Use connectMcpServer(name, options) from @fabric-harness/sdk (or /strict if you prefer).

Example:

import { connectMcpServer } from '@fabric-harness/sdk';

const github = await connectMcpServer('github', {
  url: 'https://mcp.github.com/mcp',
  transport: 'streamable-http',
  headers: { Authorization: `Bearer ${process.env.GITHUB_TOKEN}` },
});

try {
  const session = await (await init({ tools: github.tools })).session();
  await session.prompt('Find open issues tagged bug.');
} finally {
  await github.close();
}

Knowledge-base connectors

Knowledge-base connectors mount docs/content into a sandbox as files. Agents then use read, grep, and glob instead of a retrieval pipeline.

Example:

import { agent, fumadocsSource, withFilesystemSources } from '@fabric-harness/sdk';

export default agent<{ question: string }>({
  run: async ({ init, input }) => {
  const sandbox = withFilesystemSources('virtual', [{
    mountAt: '/workspace/docs',
    source: fumadocsSource('./apps/docs/content/docs'),
  }]);
  const session = await (await init({ sandbox })).session();
  return await session.prompt(`Answer using /workspace/docs: ${input.question}`);
},
});

Data connectors

Data connectors should expose narrow tools, not raw credentials or arbitrary network access.

Azure and Foundry connectors

Azure helpers live in @fabric-harness/azure:

See Azure and Foundry Hosted Agents.

fh add

List recipes:

fh add

Print one:

fh add daytona --print
fh add github-mcp --print
fh add postgres --print

Generate from provider docs:

fh add https://example.com/provider/docs --category sandbox --print

Categories:

Live tests

Connector live tests are opt-in. See Live tests for the full matrix.

FABRIC_DAYTONA_TEST=1 DAYTONA_API_KEY=... pnpm --filter @fabric-harness/connectors test
FABRIC_AZURE_FOUNDRY_TEST=1 AZURE_FOUNDRY_PROJECT_ENDPOINT=... AZURE_TOKEN=... pnpm --filter @fabric-harness/azure test
FABRIC_DATABRICKS_TEST=1 DATABRICKS_HOST=... DATABRICKS_TOKEN=... pnpm --filter @fabric-harness/databricks test

Security checklist

• Keep provider credentials in env, managed identity, Key Vault, or secret manager.
• Never put tokens in prompts, payloads, session history, artifacts, or build manifests.
• Prefer read-only credentials for data tools.
• Treat sandbox execution, cloud control-plane actions, and data writes as execute/write effects.
• Gate destructive actions with Fabric policy approvals.
• Add unit tests with fake provider objects and live tests behind env gates.