Build Your Own Connector

FeynmanLM deliberately ships very few built-in connectors. Any service you can reach with code (Notion, Readwise, RSS, Zotero, Fireflies, a company wiki, …) can feed your library through a connector you build yourself, in minutes, usually by asking an AI assistant to write it for you.

Your connector runs on your side, with your credentials for the service, and pushes sources into FeynmanLM through the same MCP server your AI assistants already use — under a restricted ingest-only permission that keeps it safe even if the code is sloppy or the token leaks.

Why this is safe

When your connector connects, it asks for the mcp:ingest scope instead of full access. An ingest-only connection:

• can add sources, update the sources it added, and check server status;
• cannot read your knowledge base, delete or modify anything else, touch your Projects or Schedule, or use any other tool.

You approve it once, in the same consent flow as any assistant — the approval screen says exactly this in plain words. Every source it adds is labeled with the connector's name, so you can always see what came from where, and one command (remove_connector_sources, from Claude or any full-access assistant) removes everything a connector ever added. Tool calls are metered like all MCP traffic, with a daily cap, so a runaway script runs out of rope quickly.

The recipe (give this to your assistant)

The fastest path: FeynmanLM → Settings → Connectors & MCP → Build Your Own → Copy Setup Prompt — that button copies this exact recipe with your personal MCP URL already filled in. The same pane lists every connector you've approved, with its logo, how many sources it has added, and buttons to remove its access or its sources.

Or copy the prompt from here and fill in the blanks yourself:

Build me a small connector script that syncs [SERVICE — e.g. my Readwise highlights] into FeynmanLM, and set it up to run [SCHEDULE — e.g. once a day].

FeynmanLM exposes an MCP server (Streamable HTTP) at my personal URL, shown in FeynmanLM → Settings → MCP Server. The connector must:

1. Register itself as an OAuth client: POST {my-url}/oauth/register with a JSON body including "client_name" set to a short human name for this connector (this name labels every source it adds), optionally "logo_uri" set to an https icon URL (shown next to the connector in FeynmanLM's Settings), your redirect URI in "redirect_uris", and "token_endpoint_auth_method": "none".
2. Do the OAuth 2.1 authorization-code flow with PKCE (S256) against {my-url}/oauth/authorize and {my-url}/oauth/token, requesting scope=mcp:ingest. I will approve the request in FeynmanLM (or with my pairing code if I'm not at my Mac). Store the refresh token and refresh as needed — the granted scope survives refresh.
3. Speak MCP over POST {my-url}/mcp: initialize first (keep the Mcp-Session-Id response header on later requests), then push content with the add_sources tool. Each item: a stable canonical url (the dedup key — same item must produce the same URL every run), title, source_type (usually "article"), and the full plain-text content. At most 50 items per call and ~1 MB per request; split beyond that.
4. Be idempotent: re-running must not duplicate anything (the server dedups by URL and reports already existed). To refresh something that changed at the service, re-push it with "update_existing": true.
5. Read the per-item results add_sources returns and fail loudly — print anything that reports an error; never swallow failures.
6. Keep my service credentials (API key, cookies) local to the script. They must never be sent to FeynmanLM — FeynmanLM only ever receives the extracted text.

Note: FeynmanLM's MCP URL only responds while the FeynmanLM app is running on my Mac, so handle connection failures by skipping the run and trying again next time, not by erroring the schedule away.

That's the whole contract. The assistant writes the script; you run it on whatever schedule suits the material — a scheduled assistant task, cron, launchd, or just "run it when I ask".

Example use cases

These are worked examples of the recipe above, not product features: FeynmanLM used to ship built-in Google Drive and Read AI connectors and has retired them in favor of this path. Your assistant builds the connector, it runs with your credentials on your side, and you own it — we don't ship or support these as extensions.

Read AI meeting transcripts. Fill the recipe in with: "sync my Read AI meetings into FeynmanLM". Read AI's API uses OAuth 2.1 with rotating refresh tokens (your workspace needs Downloads enabled under Workspace Settings → Reports & Sharing). Have the connector list recent ended meetings, fetch each transcript, and push one source per meeting with source_type: "meeting" semantics via add_sources — a stable URL per meeting id keeps re-runs duplicate-free.

Google Drive meeting folders. Fill the recipe in with: "sync the meeting folder [FOLDER LINK] from my Google Drive". The assistant creates a personal Google Cloud "Desktop app" OAuth client with the drive.readonly scope (no verification needed for a client only you use), lists the folder's transcript and notes files, and pushes each session's text. Re-push changed files with update_existing: true so edits in Drive flow through.

Anything with a feed. Fireflies, Notion databases, Readwise highlights, RSS — the shape is always the same: fetch with your credentials, extract plain text, push with stable URLs. If you can curl it, it can be a connector.

Where your sources land

Connector-added sources appear in your library like any other source, marked with a connector origin and the connector's name. They join Projects, the Schedule, and reviews only when you (or your assistant, at your ask) put them there — a connector can never schedule its own content or push it into an assistant's context.

Removing a connector

Two independent switches, both in Settings → Connectors & MCP → Build Your Own, next to the connector's name:

• Remove Access: the connector's tokens stop working immediately; it would need your approval again to reconnect. Sources it added stay.
• Remove Sources: every source it added is dismissed and archived — and won't come back on its own. (An assistant can do the same via the remove_connector_sources tool.)

FAQ

Does my service password/API key go through FeynmanLM? No. Your connector holds the service credentials and only sends extracted text to FeynmanLM.

What if two connectors use the same name? They'd share a label (and a bulk-remove). Give each connector a distinct client_name.

Can a connector read what's in my library? No. Ingest-only connections can't read anything except the status endpoint and the results of their own pushes (add results include the existing-source id when a URL was already in your library).

Why does it say the connection failed at night? Your FeynmanLM MCP URL is served by the app on your Mac; if the app isn't running, connectors can't reach it. They should simply retry on their next scheduled run.