Connector catalog

TechFabric Harness connectors are intentionally modular, and 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:

Discover scaffold and guide recipes from one catalog.

fh add
fh add --json

The JSON form returns stable IDs such as scaffold:channel:slack and guide:mcp:github-mcp, plus the exact command for each entry.

Catalog entries also include declared dependencies. Direct scaffolds install missing dependencies with the detected package manager; use --no-install for manifest-only changes. Guide recipes remain side-effect free unless --install-deps is supplied.

What fh add installs

Named recipes either add a maintained package adapter or generate a project-local connector that uses the provider SDK directly. The command preview lists every dependency and every file it will write before installation, so nothing arrives in your workspace that you have not already read.

fh add slack --print
fh add notion-channel --print
fh add --json

Use the integration catalog to open the provider-specific setup, identity mapping, webhook verification, policy, and validation instructions.

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 is needed, because the file lives in your own 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, which 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, covering 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 and content into a sandbox as files, so agents can use read, grep and glob instead of standing up a retrieval pipeline.

Example:

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

export default defineAgent<{ 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.