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.
This server has a remotely hosted endpoint. Open its connector listing for connection details, authentication requirements, and setup instructions:
Connect your AI agents to 1000+ 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.
1000+ 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: Conector
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). A task describes the whole job in general terms, and an ai_model names the model asking; agents are asked to send both with every find, since the task helps tell similar actions apart. 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. A platform no active platform has (clickup for click-up) is not searched: the answer names the platforms it may have meant, closest first, so the agent can ask again with the right one. 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/mcpRequires Node.js 22.23.4+, 24.22.1+ or 26.12.1+. Older Node trusts the compromised eMudhra CA certificates (October 2026), so a network attacker could intercept ONE_SECRET. On an older Node the server still starts, but every tool returns an error with the command that updates Node for how it was installed. If you can't update yet, ONE_ALLOW_UNPATCHED_NODE=1 lets it call One anyway; you remain exposed while it is set.
Add 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 | The request body. JSON by default; encoded as form data when isFormData or isFormUrlEncoded is set. | |
| headers | No | Extra request headers to forward to the upstream platform. | |
| actionId | Yes | The actionId of the action to run, as returned when the action was found (or from the connection's `access` list). | |
| platform | Yes | The kebab-case platform of the connection (e.g. "gmail"), as list_one_integrations names it. | |
| isFormData | No | Encode the body as multipart/form-data. | |
| queryParams | No | Query-string parameters appended to the request. | |
| connectionKey | Yes | The connection key for the caller's connection (from list_one_integrations). | |
| pathVariables | No | Substitutions for {var} / {{var}} placeholders in the action path. | |
| isFormUrlEncoded | No | Encode the body as application/x-www-form-urlencoded. |
| Name | Required | Description |
|---|---|---|
| status | Yes | The platform's HTTP status. A 4xx or 5xx is the platform's answer: read `responseData` for its reason. |
| responseData | No | The platform's response body, whatever its status. |
| requestConfig | Yes | The request as sent, with the One secret redacted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered structurally; the description adds the valuable prerequisite dependency on find_one_actions and a confirmation protocol for uncertain intent. It does not, however, spell out the concrete consequences of a destructive call (mutated or deleted third-party data, irreversibility), which would raise this higher.
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 purpose, then the critical use/exclusion gate, then the required workflow — a sensible priority order. It runs somewhat long with repeated emphasis on EXECUTE versus BUILD, but nearly every clause carries actionable 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?
With 9 parameters, nested objects, and an output schema, the description correctly focuses on intent gating and call sequencing rather than return values. The prerequisite-and-confirmation story is complete, though it stops short of describing what a failed upstream call or missing auth connection looks like.
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 the schema already documents data, headers, pathVariables, queryParams, and the encoding flags. The description contributes no parameter-specific meaning beyond advising confirmation when parameters are uncertain, which is the baseline-3 case.
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 ('Execute a One action to perform actual operations on third-party platforms') and immediately scopes it against the sibling workflow by naming find_one_actions. An agent can distinguish execution from action discovery without opening either 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?
Explicitly names when to call (user intent is to execute a real operation, with concrete examples) and when not to (user wants to build/create code, forms, or apps — stop after find_one_actions). It also prescribes the mandatory prerequisite step and the ask-for-confirmation fallback for ambiguous intent.
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. Send it with every find: it helps tell similar actions apart. Never the chat history. Only with `requests`. | |
| ai_model | No | Your model name as you know it (e.g. "claude-sonnet-5", "gpt-5"), recorded with this find. Send it with every find; leave it out only if you do not know which model you are. | |
| 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?
The description clarifies the operational behavior of the tool, specifically that results come back as a 'digest' initially and that the `load` call is required to retrieve full documents or specific sections, which is behavior not obvious from the schema alone.
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?
The description is dense but highly efficient. It front-loads the core functionality and logically progresses through the usage lifecycle: input -> initial output (digest) -> follow-up behavior (`load`) -> constraints.
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?
The tool definition is comprehensive. Since there is no output schema, the description successfully explains the entire workflow, including the prerequisite calls (`list_one_integrations`) and the required follow-up mechanism (`load`).
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?
Even with 100% schema coverage, the description adds critical semantic rules (e.g., using 'short intent,' 'kebab-case identifier,' and 'general terms' for the task) that help the agent understand the *style* and *nature* of the required input data.
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?
The description clearly defines the tool's purpose: finding API actions a task requires across various platforms. It specifies that the function involves sending requests detailing the operation and receiving documentation/alternatives.
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?
It provides explicit usage guidelines, noting that the process is multi-step: first, call `list_one_integrations` to check connectivity, then send the request, and finally, use the `load` parameter for detailed documentation.
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?
Annotations already cover the safety profile (read-only, idempotent, closed-world, non-destructive), and the description adds useful model semantics: the three shapes of `access` (full, method set, action list) and what an action entry contains. It does not describe pagination or connection-count limits, which is a minor gap given the low-risk read.
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?
The mandatory-call rule is front-loaded in the first two sentences, followed by only the field semantics needed to act on the result. No sentence is filler.
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?
Although an output schema exists, the description still explains how to interpret the `access` field, which is decision-relevant for whether to search or execute. For a zero-param entry-point tool, nothing an agent needs is missing.
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 the baseline is 4. The description correctly spends no words on non-existent inputs and instead documents the output fields the agent must use downstream.
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 connected on One) with named scope. It also ties the output to a sibling by naming `connectionKey for execute_one_action`, so the agent can place it in the tool family without reading schemas.
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?
"ALWAYS call this tool first in any workflow" is an explicit ordering rule relative to the siblings. The closing note that action-scoped connections need no further searching implicitly routes the agent away from `find_one_actions` in that case.
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.3.2execute_one_action10 fields changedInput schema / properties / actionId / descriptionPrevious value: -"The actionId from find_one_actions"New value: +"The actionId of the action to run, as returned when the action was found (or from the connection's `access` list)."Input schema / properties / connectionKey / descriptionPrevious value: -"Key of the connection to use"New value: +"The connection key for the caller's connection (from list_one_integrations)."Input schema / properties / data / descriptionPrevious value: -"Request data (for POST, PUT, etc.)"New value: +"The request body. JSON by default; encoded as form data when isFormData or isFormUrlEncoded is set."Input schema / properties / headers / descriptionPrevious value: -"Additional headers"New value: +"Extra request headers to forward to the upstream platform."Input schema / properties / isFormData / descriptionPrevious value: -"Whether to send data as multipart/form-data"New value: +"Encode the body as multipart/form-data."Input schema / properties / isFormUrlEncoded / descriptionPrevious value: -"Whether to send data as application/x-www-form-urlencoded"New value: +"Encode the body as application/x-www-form-urlencoded."Input schema / properties / pathVariables / descriptionPrevious value: -"Variables to replace in the path"New value: +"Substitutions for {var} / {{var}} placeholders in the action path."Input schema / properties / platform / descriptionPrevious value: -"Platform name"New value: +"The kebab-case platform of the connection (e.g. \"gmail\"), as list_one_integrations names it."Input schema / properties / queryParams / descriptionPrevious value: -"Query parameters"New value: +"Query-string parameters appended to the request."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "requestConfig": {
+ "additionalProperties": false,
+ "description": "The request as sent, with the One secret redacted.",
+ "properties": {
+ "data": {},
+ "headers": {
+ "additionalProperties": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "method": {
+ "type": "string"
+ },
+ "params": {
+ "additionalProperties": {},
+ "type": "object"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "url",
+ "method",
+ "headers"
+ ],
+ "type": "object"
+ },
+ "responseData": {
+ "description": "The platform's response body, whatever its status."
+ },
+ "status": {
+ "description": "The platform's HTTP status. A 4xx or 5xx is the platform's answer: read `responseData` for its reason.",
+ "type": "number"
+ }
+ },
+ "required": [
+ "status",
+ "requestConfig"
+ ],
+ "type": "object"
+}v2.1.1find_one_actions2 fields changedInput schema / properties / ai_model / descriptionPrevious value: -"The AI model you are running as (e.g. \"claude-sonnet-5\", \"gpt-5\"), which helps optimize the documentation returned. Optional."New value: +"Your model name as you know it (e.g. \"claude-sonnet-5\", \"gpt-5\"), recorded with this find. Send it with every find; leave it out only if you do not know which model you are."Input schema / properties / task / descriptionPrevious value: -"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`."New value: +"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. Send it with every find: it helps tell similar actions apart. Never the chat history. Only with `requests`."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 represent distinct steps in one workflow: listing connections, finding actions, and executing actions. Descriptions explicitly order them and warn against execution for build intents, leaving no meaningful overlap.
All names follow a predictable verb_one_noun snake_case pattern: list_one_integrations, find_one_actions, execute_one_action. The singular/plural difference reflects semantic cardinality rather than inconsistency.
Three tools exactly match the minimal workflow needed: discover connections, find relevant actions, and execute an action. Each tool earns its place and there is no redundancy.
The core list-find-execute loop is covered, but the server lacks tools for managing connections or browsing a platform's full action catalog without a targeted intent. These are minor gaps that agents can generally work around through find_one_actions.
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.
