Skip to main content

​
What an Integration Is

Integrations connect Wolffish to external services. Each integration is a capability (a cerebellum skill with a plugin) that adds tools for interacting with a specific API — Gmail, GitHub, Notion, Brave Search, and more.

​
Design Principles

Stateless

Every integration reads credentials on-demand at tool-call time. No background daemons, no persistent connections, no polling loops.

Optional

Wolffish works fully without any integrations configured. Each one is independent — enable only what you need.

​
How Integrations Work

The integration architecture follows the standard capability pipeline:
  1. You configure credentials in the Settings panel (or edit config.json directly)
  2. The credential is stored in ~/.wolffish/workspace/config.json or as a Variable
  3. When the LLM decides to use an integration tool, the plugin reads the token at call time
  4. The plugin makes the API request and returns a ToolResult
  5. The result flows through motor (execution engine) back to broca (output renderer)
Integration credentials configured in the Settings panel (Notion, GitHub, Brave, Google OAuth, etc.) are never sent to the LLM — plugins read them directly from config.json when a tool executes. The LLM only sees the tool result.
Variables are different. Any value stored in Settings → Variables is included in the system prompt in plaintext on every turn so the agent can reference and use them. If you store a secret as a Variable, the LLM will see it — that’s intentional, since it needs the value to use it in tool calls. Use Variables for credentials the agent needs to act on directly (e.g. passing an API key as a shell argument). Use the integration-specific settings pages for credentials the plugin handles itself.

​
Credential Storage

Integration tokens live in config.json under their respective integration sections:
Like all workspace data, credentials are stored in plain text on your local machine. Wolffish is a personal, local-first app — your workspace is your own. If you version-control your workspace, add config.json to .gitignore.

​
Available Integrations

Browser Extension

Control your real browsers — several at once, profiles included — navigate, click, read, screenshot. 51 tools in your logged-in sessions.

Mobile App

The phone companion — pair once by QR or code, then chat, history, usage, and every settings page over an end-to-end encrypted tunnel.

Phone Notifications

The agent reaches your paired phone when a run finishes, fails, or needs you — a deliberate tool call every time, never an automatic ping.

Video Generation

Make video with MiniMax H3 — text, images, frames, or reference media — with the prompt written by whichever model you’re chatting with.

Google Workspace

Gmail, Drive, Calendar, Contacts, Tasks, and Sheets. OAuth-based multi-account support.

GitHub

Repositories, issues, pull requests, workflows, releases, and gists via personal access token.

Notion

Pages, databases, and knowledge bases. Search, read, create, and query your Notion workspace.

Brave Search

Web search via Brave Search API. Results are returned as structured data for the LLM to summarize.

MCP Servers

Connect any Model Context Protocol server — a local command or a remote URL — and its tools become Wolffish’s tools on your next message.
MCP servers are the open-ended integration. The integrations above are built in and hand-tuned; MCP connections bring in the whole third-party tool-server ecosystem. Unlike the stateless integrations, an MCP connection is a live, managed link — Wolffish keeps it healthy in the background (silent reconnects, health checks, OAuth token refresh). See MCP Servers.

​
Integration vs. Capability

Every integration is a capability, but not every capability is an integration. The distinction: Integrations are plugin capabilities that require external credentials and make network requests to third-party APIs. Pure capabilities like git and shell only use local system resources.

​
Activation

Integrations are discoverable capabilities. Their tool schemas don’t ship on every request — each integration costs one line in the system prompt’s capability index (name, short description, tool count). When a task calls for one, the model activates it with tool_search (or by calling one of its tools directly, which auto-activates the capability) and its tools are callable the same turn. For example, saying “check my email” leads the model to activate the Google capability and call the right tool (gmail_search, gmail_read, etc.) based on your intent. Activation is scoped to the conversation, so a background job loading GitHub never touches your live chat.
Use an integration constantly? Add it to pinnedCapabilities in config.json to ship its tools on every request alongside the built-in core set.
Activation makes an integration’s tools callable, but the plugin still reads its credential at call time — a missing token surfaces as a tool error, not a missing tool. If calls fail, check the credential in Settings first.