MongoDB

Runtime persistence

pnpm add @fabric-harness/node mongodb

import { mongodbPersistence } from '@fabric-harness/node';
import { MongoClient } from 'mongodb';

export default async function config() {
  const client = new MongoClient(process.env.MONGODB_URL!);
  await client.connect();
  const collection = client.db('fabric').collection('fabric_harness_snapshots');
  return { persistence: mongodbPersistence({ collection, client }) };
}

The bundle uses _id plus a monotonic version for atomic compare-and-swap, so it works on a standalone server and on replica sets without multi-document transactions. Use majority write concern and retryable writes for production. Payloads are canonical JSON strings, which preserves Fabric's undefined semantics and permits arbitrary tool-result keys without Mongo field-name interpretation.

Each store surface is one snapshot document. This is appropriate for moderate operational state; choose Postgres for high-contention workloads or very large histories.

Governed data tools

Use the collection-bound MongoDB tool. Scaffold the official driver and adapter:

fh add database mongodb

const lookup = mongoFindTool({
  collection: db.collection('accounts'),
  collectionName: 'accounts',
  name: 'lookup_account',
  description: 'Read one tenant-scoped account.',
  filter: ({ tenantId, accountId }) => ({ tenantId, id: accountId }),
  projection: { _id: 0, id: 1, status: 1 },
  maxRows: 1,
});

Host code constructs the filter and projection, so the model cannot submit an arbitrary query document. The adapter applies result/time/byte limits and redacted errors. Writes, indexes, and administration should remain separate approval-gated tools.