One is an MCP server that connects AI agents to 700+ third-party apps (Gmail, Slack, Shopify, HubSpot, Stripe, Linear, QuickBooks, etc.) through a single, OAuth-free proxy — discover, document, and execute platform actions via natural language.
Discover integrations — list_one_integrations returns active connections (each stamped with an access policy: full, allowed methods, or an explicit actions list) plus all available platforms in kebab-case.
Search for actions — search_one_platform_actions finds the top 5 relevant actions on a given platform from a natural-language query, with agent context execute or knowledge.
Read action documentation — get_one_action_knowledge loads an action's params, requirements, caveats, and examples (token-saving digest by default; section, full, or toc for more).
Execute actions — execute_one_action runs real API calls on connected platforms with data, queryParams, pathVariables, custom headers, and multipart/URL-encoded body support.
Build integration code — in knowledge mode, stop after the docs step to generate React forms, dashboards, and paginated tables that call One's passthrough API from application code.
Stay lightweight — only a handful of tools exposed no matter how many platforms are connected, keeping the agent's context window clean.
Control access — env vars ONE_PERMISSIONS (read/write/admin), ONE_ACTION_IDS, ONE_CONNECTION_KEYS, ONE_KNOWLEDGE_AGENT (knowledge-only, removes execute), and ONE_IDENTITY/ONE_IDENTITY_TYPE for per-user/team/org scoping.
Deploy flexibly — run locally with npx @withone/mcp or Docker using ONE_SECRET, or use the hosted remote server at https://mcp.withone.ai/mcp with OAuth consent (no install, no secret).
Secure by default — all third-party calls are proxied through One, so no platform API keys or OAuth tokens are handled, and secrets are redacted from responses and logs.
Note: the README describes the newer 2.x toolset (list_one_integrations, find_one_actions, execute_one_action), in which search_one_platform_actions and get_one_action_knowledge are removed and replaced by find_one_actions; the supplied schema still exposes the older four-tool 1.x set.
Allows reading and sending emails through Gmail, as well as generating email-integrated application code.
Allows interacting with HubSpot's CRM and marketing platform.
Allows managing issues, projects, and teams in Linear.
Allows fetching and displaying invoices and managing accounting data in QuickBooks.
Allows retrieving products and managing store data on Shopify.
Allows sending messages to Slack channels and interacting with Slack workspaces.
Allows processing payments and managing financial data via Stripe.
Connect your AI agents to 700+ apps through a single MCP server. Find the actions a task needs with their documentation, and execute API calls across platforms, without having to manage OAuth tokens or API keys.
npm install -g @withone/cli
one initThat's it. The One CLI will prompt you for your API key (get one from the One dashboard) and configure the MCP server for your environment: Claude Desktop, Cursor, Claude Code, Windsurf, or any MCP-compatible agent.
700+ platforms. Gmail, Slack, Shopify, HubSpot, Stripe, Linear, QuickBooks, and more.
Natural language execution. "read my last gmail email", "send a message to #general on Slack"
Code generation. "build a form to send emails using Gmail", "create a dashboard that lists my Linear projects"
No tool bloat. Only 3 tools exposed regardless of how many platforms or actions you connect. One call finds every action a task needs, across platforms, with its documentation, so your agent's context window stays clean.
Fine-grained access control. Restrict which actions, connections, and permission levels (read, write, admin) your agent has access to.
Secure by default. All requests proxied through One, secrets automatically redacted, no platform API keys to manage.
Related MCP server: 0nMCP
Execute actions directly:
"Get my last 5 emails from Gmail"
"Send a Slack message to #general: 'Meeting in 10 minutes'"
"Get all products from my Shopify store"
Generate integration code:
"Create a React form component that sends emails using Gmail"
"Build a dashboard that displays Linear users and their assigned projects with filtering"
"Create a paginatable table that fetches and displays QuickBooks invoices with search and sort"
The server exposes three MCP tools:
Tool | Description |
| List available platforms and active connections, each with the |
| Find the action for every operation a task needs, across platforms, with its documentation, in one call; |
| Execute an API action on a connected platform |
find_one_actions takes one requests entry per operation, each a kebab-case platform and a short intent naming the operation alone ("send a message to a channel", not the message). An optional task describes the whole job in general terms, which helps choose between similar actions. For each intent, One's decision model picks the action to use; the answer documents it, sets apart a substitute when the model was unsure, and lists a few alternatives. Large documents come back as a digest; call find_one_actions again with load: [{ action_id, section }] for a section it left out, full: true for the whole document, or toc: true for its table of contents. ONE_ACTION_IDS, ONE_PERMISSIONS and ONE_CONNECTION_KEYS apply to every answer: an action they refuse is never offered, and when they refuse the model's pick, the next allowed candidate takes its place.
Upgrading from 1.x: search_one_platform_actions and get_one_action_knowledge are removed. find_one_actions replaces both.
Prefer not to run anything locally? One hosts a remote MCP server at https://mcp.withone.ai/mcp. Point any MCP client that supports remote (HTTP) servers at that URL and authenticate with One via OAuth. There's no npm install and no ONE_SECRET to manage. You approve access in One's consent screen, where you can scope exactly which connections, actions, and permission levels the agent gets. Those choices are surfaced back to the agent through each connection's access field, so it knows what it can run without searching.
Add it to your client's MCP configuration. The endpoint speaks the Streamable HTTP transport:
{
"mcpServers": {
"one": {
"type": "http",
"url": "https://mcp.withone.ai/mcp"
}
}
}Some clients omit type and take the URL alone; UI-based clients (custom connectors) just need the URL itself. On first connect, your client opens a browser to authenticate and authorize with One. After that, the same three tools are available.
One-click install:
The Windsurf link opens One's page in the editor's MCP marketplace, which is served from the official MCP registry where One is published as ai.withone/mcp. Windsurf handles the OAuth sign-in itself once you install from that page.
If you prefer to configure the server manually instead of using one init, install the package directly:
npm install @withone/mcpThen set the required environment variable:
ONE_SECRET=your-one-secret-keyScope connections to a specific identity (e.g., a user, team, or organization):
ONE_IDENTITY=user_123
ONE_IDENTITY_TYPE=userVariable | Description | Values |
| The identifier for the entity (e.g., user ID, team ID) | Any string |
| The type of identity |
|
When set, the MCP server will only return connections associated with the specified identity. This is useful for multi-tenant applications where you want to scope integrations to specific users or entities.
Fine-tune what the MCP server can see and do:
ONE_PERMISSIONS=read
ONE_CONNECTION_KEYS=conn_key_1,conn_key_2
ONE_ACTION_IDS=action_id_1,action_id_2
ONE_KNOWLEDGE_AGENT=trueVariable | Type | Default | Description |
|
|
| Filter actions by HTTP method. |
|
|
| Restrict visible connections and platforms to specific connection keys |
|
|
| Restrict visible and executable actions to specific action IDs |
|
|
| Remove the |
All defaults preserve current behavior. If no access control env vars are set, the server starts with full access and all tools available.
Whatever you configure here is surfaced back to the agent: list_one_integrations stamps each connection with an access field so the agent knows up front what it can run there, without spending a turn searching. It is one of:
| When |
| No action allowlist and |
| No action allowlist, but |
|
|
If you used one init, the configuration below is already done for you. These examples are for reference or manual setups.
npx @withone/mcpAdd the following to your MCP config:
Claude Desktop: MacOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json · Windows: %APPDATA%/Claude/claude_desktop_config.json
Cursor: Open the Cursor menu and select "MCP Settings"
{
"mcpServers": {
"one": {
"command": "npx",
"args": ["@withone/mcp"],
"env": {
"ONE_SECRET": "your-one-secret-key"
}
}
}
}docker build -t one-mcp-server .
docker run -e ONE_SECRET=your_one_secret_key one-mcp-serverAll environment variables listed above can be passed as -e flags.
All requests to third-party platforms are authenticated and proxied through One's API. The MCP server never handles OAuth tokens or platform API keys directly. The ONE_SECRET key is the sole credential required, and it is automatically redacted from all response payloads returned to clients. Sensitive headers are stripped from logged and returned request configurations.
MIT
For support, please contact support@withone.ai or visit https://withone.ai
Execute a One action to perform actual operations on third-party platforms. CRITICAL: Only call this when the user's intent is to EXECUTE an action (e.g., 'read my last Gmail email', 'fetch 5 contacts from HubSpot', 'create a task in Asana'). DO NOT call this when the user wants to BUILD or CREATE code/forms/applications - in those cases, stop after find_one_actions and provide implementation guidance instead. REQUIRED WORKFLOW: Must call find_one_actions first, which returns the action's documentation. If uncertain about execution intent or parameters, ask for confirmation before proceeding.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Request data (for POST, PUT, etc.) | |
| headers | No | Additional headers | |
| actionId | Yes | The actionId from find_one_actions | |
| platform | Yes | Platform name | |
| isFormData | No | Whether to send data as multipart/form-data | |
| queryParams | No | Query parameters | |
| connectionKey | Yes | Key of the connection to use | |
| pathVariables | No | Variables to replace in the path | |
| isFormUrlEncoded | No | Whether to send data as application/x-www-form-urlencoded |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the key behavioral traits: execution causes real side effects on third-party platforms, find_one_actions must be called first, and the agent should ask for confirmation when intent or parameters are uncertain. It omits auth/permission requirements and whether operations are reversible, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, then the critical exclusion rule, then the mandatory workflow — a sensible priority order for a high-stakes tool. It runs slightly long with repeated example phrasing, but every sentence carries decision-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a nine-parameter mutation tool with no output schema and no annotations, the description covers purpose, exclusion criteria, prerequisite workflow, and ambiguity handling. It does not explain failure behavior or what a successful execution returns, which is a minor gap given the schema fully documents inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all nine parameters (including nested objects like headers and pathVariables) are documented in the schema itself. The description adds no format or constraint detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Execute a One action to perform actual operations on third-party platforms') and clearly separates itself from siblings by naming find_one_actions as the required predecessor. An agent can distinguish this execution tool from the discovery/listing tools without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use with concrete examples ('read my last Gmail email', 'create a task in Asana'), explicit when-NOT-to-use ('DO NOT call this when the user wants to BUILD or CREATE code/forms/applications'), and a named alternative path (stop after find_one_actions and give implementation guidance). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this to find the API actions a task needs, on any platforms, in one call: send one requests entry per operation (platform and a short intent) and get back, for each, the action to use with its documentation, plus a few alternatives. Large documents come back as a digest; call again with load for a section it omitted, the whole document, the table of contents, or an alternative's documentation. Results are limited to what this server's settings allow. Call list_one_integrations first to see the connected platforms.
| Name | Required | Description | Default |
|---|---|---|---|
| load | No | More documentation for actions already found (1 to 10): a section the digest omitted, the whole document, the table of contents, or an alternative's documentation. Use instead of `requests`. | |
| task | No | The whole task in one line, in general terms (e.g. "email a report to a contact"): what it does, without names, addresses, IDs or message text. It helps choose between similar actions. Never the chat history. Only with `requests`. | |
| ai_model | No | The AI model you are running as (e.g. "claude-sonnet-5", "gpt-5"), which helps optimize the documentation returned. Optional. | |
| requests | No | What to do, one entry per API operation, on any platforms (1 to 10). Each is the kebab-case platform (e.g. "gmail", "hubspot") and a short intent (e.g. "send an email", "find a contact by email"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that large documents return as a digest, how to retrieve omitted sections, that results are capped by server settings, and that ai_model tunes the returned docs. It omits nothing critical for a read-style lookup, though auth/permission details are unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose and the requests-vs-load split, and every sentence addresses a real decision the agent must make. It is slightly dense and the mid-sentence aside about digests could be tightened, but there is little waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description explains the return shape (action, documentation, alternatives, digest) and the follow-up mechanism, and there are 4 params at full schema coverage. Given no annotations, it is nearly complete, lacking only explicit permission/limit specifics beyond the generic server-settings note.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so a baseline of 3 applies, but the description adds real semantics: it frames `requests` as one entry per operation with platform + short intent, explains `load` as the mutually-exclusive alternative, and reinforces that `task` must omit identifiers and chat history. This goes beyond restating the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource with scope ('find the API actions a task needs, on any platforms, in one call') and clearly separates itself from the execution sibling by describing retrieval of actions plus docs and alternatives. An agent can distinguish this from execute_one_action and list_one_integrations without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use guidance: send `requests` per operation, or call again with `load` for more documentation, and explicitly says to call list_one_integrations first. It names the prerequisite sibling but never explicitly contrasts with execute_one_action, so the when-not-to-use case is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the platforms the user has connected on One. ALWAYS call this tool first in any workflow. Each connection has the kebab-case platform name (e.g., 'ship-station', 'shopify') and the key (the connectionKey for execute_one_action) you'll need for subsequent tool calls. Each connection carries an access field describing what you may run on it: full, a set of allowed HTTP methods, or a specific list of actions (each with actionId, title, method). When a connection is action-scoped, its actions are exactly what may run, so you need not search.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| summary | Yes | Counts of connections (and available platforms in knowledge/code-gen mode) |
| connections | Yes | Array of user's active connections, each with the access the current config confers |
| availablePlatforms | No | Platforms that can be connected. Only listed in knowledge/code-gen mode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does explain the meaningful access-scoping semantics (full / methods / actions), but says nothing about auth requirements, rate limits, or result set size, and the read-only nature is only implied by 'List'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads what it lists, then the mandatory ordering rule, then the field semantics the agent needs downstream. Every sentence earns its place, though the access-field explanation is slightly dense for a single paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so raw return values need no explanation, yet the description still supplies the cross-tool key semantics (platform name and connectionKey) that the agent must carry into execute_one_action. Complete for a zero-parameter discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description instead spends its budget on return-field semantics, which is the right call here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the platforms the user has connected on One') and clearly positions itself as the discovery step that feeds execute_one_action via the connectionKey. Distinguishable from find_one_actions and execute_one_action at a glance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit ordering guidance ('ALWAYS call this tool first in any workflow') plus a routing hint ('its actions are exactly what may run, so you need not search'). No explicit when-not-to-use statement, but the workflow placement is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.0execute_one_action1 field changedInput schema / properties / actionId / descriptionPrevious value: -"Action ID from search_one_platform_actions"New value: +"The actionId from find_one_actions"find_one_actionsget_one_action_knowledgelist_one_integrations4 fields changedOutput schema / properties / availablePlatforms / descriptionPrevious value: -"Array of available platforms that can be connected"New value: +"Platforms that can be connected. Only listed in knowledge/code-gen mode"Output schema / properties / summary / descriptionPrevious value: -"Summary statistics of connections and available platforms"New value: +"Counts of connections (and available platforms in knowledge/code-gen mode)"Output schema / properties / summary / requiredPrevious value: -[
- "connectedCount",
- "availableCount"
-]New value: +[
+ "connectedCount"
+]Output schema / requiredPrevious value: -[
- "connections",
- "availablePlatforms",
- "summary"
-]New value: +[
+ "connections",
+ "summary"
+]search_one_platform_actionsv1.3.0get_one_action_knowledge3 fields changedInput schema / properties / fullAdded value: +{
+ "description": "Return the entire documentation verbatim instead of the token-saving digest. Ignored when `section` is set. Leave unset by default; only set it when you genuinely need every section.",
+ "type": "boolean"
+}Input schema / properties / sectionAdded value: +{
+ "description": "Load specific section(s) of the documentation by name (e.g. 'Response Fields', or comma-separated 'Response Fields, Optional Request Body Fields'). Large docs return a digest first; use this on a follow-up call to pull a section the digest omitted.",
+ "type": "string"
+}Input schema / properties / tocAdded value: +{
+ "description": "Return only the table of contents (every section's id, heading, and size), no bodies. Use it to see everything available when the digest collapsed its list. Ignored when `section` is set.",
+ "type": "boolean"
+}v1.2.1execute_one_actionget_one_action_knowledgelist_one_integrationssearch_one_platform_actionsScored across 3 tools
The three tools map to distinct phases: list connected integrations, discover needed actions, and execute actions. The workflow dependencies and descriptions clearly separate discovery from execution, so an agent should not confuse them.
All names follow a consistent snake_case verb_one_noun pattern: list_one_integrations, find_one_actions, execute_one_action. Minor pluralization differences are natural and predictable.
Three tools form a compact meta-tool layer appropriate for an integration gateway. Discovery and execution can cover many platform operations without needing one tool per action, so each tool earns its place.
The set covers listing connections, discovering action documentation, and executing actions. There are minor gaps such as managing connections or retrieving actions directly by ID, but the core execution lifecycle is largely covered.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Connect any AI agent to 1,000+ apps and 27,000+ actions through one remote MCP server (OAuth).
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
One MCP endpoint for Claude, GPT & Gemini: 100+ tools + no-code connectors + agent workers.
