Connect once. Every session shares the same memory.

Integrated AI is a remote MCP server. Any MCP-speaking client works the same way: point it at the server, sign in once through your identity provider, and every tool call after that is scoped to your org.

Connect a client

Add it to your MCP client's server config. In Claude Code, that's ~/.claude.json (or a project-level config) under mcpServers:

{
  "mcpServers": {
    "integrated-ai": {
      "type": "http",
      "url": "https://mind-api.dfens.ai/mcp"
    }
  }
}

The first connection pops a browser for sign-in through your organization's identity provider and auto-creates your user record. Every tool call still returns "forbidden" until an org owner or admin adds you as a member — see orgs & roles.

Don't have an organization yet? OIDC sign-in above is for joining one that already exists. The quickest way to create your own is the customer portal — sign in, name your org, and you're through in minutes, with Team available as a hosted Odoo checkout from the same dashboard. Automating the bootstrap instead (CI, a provisioning script)? Two plain HTTP calls (not MCP tool calls — there's no credential yet) get you a live api_key to put in the config above:

// 1. Create your organization (free Individual plan by default)
curl https://mind-api.dfens.ai/v1/organizations \
  -d '{"name":"Acme Inc","contact_email":"you@acme.com"}'
// → {"org_id": "…", "status": "pending_verification"}

// 2. Check your email for a code, then verify
curl https://mind-api.dfens.ai/v1/organizations/<org_id>/verify \
  -d '{"code":"123456"}'
// → {"status": "active", "plan_id": "individual", "api_key": "sk_live_…"}

Put that api_key into the config above as a bearer token, and you're live. Ready for a team? start_checkout(org_id, plan_id) is a real MCP tool call once you're signed in — it returns a hosted Odoo checkout link, and card details never touch us directly.

Authentication

Sign-in federates through one or more standards-compliant OIDC providers — Google, Okta, Microsoft Entra, or a self-hosted identity provider — configured per deployment. With exactly one provider configured, sign-in goes straight to it; with more than one, an email-first page routes you by domain, or shows a picker. Where no provider is mapped to your domain, you can also sign in with an email address and password (verified by emailed code, with self-service password reset). Invited members get an invite email and can set their own password.

Behind that federated login, Integrated AI runs its own minimal OAuth 2.1 authorization server, so MCP clients get standard dynamic client registration and an authorization-code + PKCE flow. It mints its own RS256-signed JWTs as the access/refresh tokens your client actually uses — your identity provider's tokens never leave the login exchange.

Tools

Every tool below is a plain MCP tool call. Every one except list_contexts requires a context id — there's no default, and passing the wrong one silently returns empty results rather than an error, so always resolve it from list_contexts() first.

Org-admin tools (admin_list_org_members, admin_add_org_member, admin_create_api_key, admin_create_context, admin_grant_context, and similar) sit behind an owner/admin role check — any authenticated user can see them listed, but calling one without the role returns a permission error.

Context model

Every thought lives inside a context: an opaque id belonging to exactly one organization, with one of two visibilities.

• org (the default) — every member of the org has access, no separate grant needed.
• restricted — only members holding an explicit grant can access it. Every user also gets one automatic personal context on joining an org: always restricted, always private to them, and unlike any other restricted context, it can never be shared.

A context also carries a human-readable name and description — not necessarily unique — that a caller uses to pick the right id from a list_contexts() result. Optional instructions (when and how to read or write the context) and keywords (explicit trigger words) help an agent choose.

On Enterprise, admin_grant_context(context, user_email, access_level?) takes access_level write (the default) or read, for view-only access that can search and browse but not capture, edit or delete.

Orgs & roles

Roles are owner, admin, and member. Every role gets access to every org-visibility context, plus any restricted one they hold a grant on. owner/admin additionally manage membership, create and edit contexts, and grant or revoke access to restricted ones. A plain member gets the same self-serve context-creation ability by being flagged a poweruser. An org always keeps at least one owner.

Skills

One canonical, org-owned skill every AI tool your team runs can pull — Claude, or any other MCP-speaking harness — instead of every tool keeping its own drifting copy. Versioned skill storage (create_skill/get_skill/list_skills/ update_skill/delete_skill), scoped to a context, with optional bundled files beyond plain-text instructions (list_skill_files/get_skill_file).

Works identically from a signed-in human session or an org API key, so an unattended harness can pull a skill on its own — no human needs to be signed in. Owners and admins can mint and revoke named API keys for more harnesses themselves, from the customer portal or with admin_create_api_key.

Making a skill runnable, not just stored

The tools above are storage — pulling a skill into a session is still up to your harness. Most MCP clients, Claude Code included, only discover skills from SKILL.md files scanned off local disk once at session start; none of them know about a remote skill store on their own. Bridge that once and every skill your team keeps in DFENS Mind becomes runnable without a matching local file — no per-skill setup, and no redeploy when someone edits one.

Manually — save a small permanent loader as a local skill. In Claude Code that's a file at ~/.claude/skills/dfens-mind-skills/SKILL.md; other harnesses that support local skills use an equivalent path.

---
name: dfens-mind-skills
description: Resolves and runs skills stored in the DFENS Mind MCP
  knowledge base. Use whenever a requested skill isn't available locally.
---

1. Call list_contexts, then list_skills on every context returned —
   merge the results into one registry keyed by skill name.
2. Match the request against each result's description field, the
   same way a local SKILL.md's frontmatter description is matched.
3. Once matched, treat its instructions field as that skill's full
   body and follow it exactly. If has_files is true, fetch each one
   first with list_skill_files / get_skill_file.

Via global instructions — for a harness with no local-skill mechanism, or to make the check automatic rather than needing the loader invoked by name, add the same rule to your harness's persistent global config instead (Claude Code's ~/.claude/CLAUDE.md, or whatever plays that role for your client):

If a requested skill isn't found locally, check DFENS Mind before
assuming it doesn't exist: call list_contexts, then list_skills on
each context, and match the request against every result's
description field. Follow the matched skill's instructions field
as its full body, in place of these instructions.

Either way, this is a one-time setup per harness install, not per organization or session.

Data source connectors

Enterprise orgs can connect data sources, including Google Drive, SharePoint and OneDrive, and sync their content into memory instead of capturing it by hand. A synced file is split into chunks, embedded in your org's region, and stored as ordinary thoughts, so search_thoughts and browse_recent find it with no new tools. Edits, moves and deletions at the source are picked up on the next sync, and content the connector can no longer read is removed from search.

• Google Drive — shared drives or individual folders. A Workspace admin authorises our service account for read-only Drive access (domain-wide delegation). No per-user tokens are stored.
• Microsoft 365 — SharePoint sites (every document library on the site) and OneDrive. A tenant admin grants consent, ideally scoped to named sites (Sites.Selected). No per-user tokens are stored.

Owners and admins add sources from the Connectors page of the customer portal, can pause a source or trigger a sync, and see run history. Each source maps to exactly one context in your org.

What gets searched

Plain text, Markdown, CSV, JSON, HTML, Google Docs, Slides and Sheets (first tab only), and Word, PowerPoint and Excel files. PDFs and unsupported types are recorded as skipped rather than failing the sync; PDF text extraction is not available yet.

Results from a synced file include a source object (provider, url, document_id, chunk_index, version, synced_at). update_thought and delete_thought refuse these thoughts, since the connector owns the content.

AI distillation and credits

Optionally, per organization, a connector can distil each document into focused notes with topics and people instead of storing raw chunks. This is off by default. It uses AI model calls, which are metered per organization and debited from a prepaid credit balance (1 credit = £1). When the balance reaches zero, distillation pauses and resumes once credits are added; plain chunk syncing is never affected. Credits are currently added by our team on request. Each org also has a monthly cap on synced chunks and a cap on the number of sources.

Data residency

Set per organization at creation, and fixed after that:

• europe-west1
• us-central1
• asia-northeast1

Each is a genuinely separate deployment, not a latency fan-out — the same three regions our sibling product at dfens.ai uses.