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. Search for actions, read 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 4 tools exposed regardless of how many platforms or actions you connect. Actions are search-based, 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 four MCP tools:
Tool | Description |
| List available platforms and active connections, each with the |
| Search for actions on a specific platform |
| Get detailed documentation for an action |
| Execute an API action on a connected platform |
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 four 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 get_one_action_knowledge and provide implementation guidance instead. REQUIRED WORKFLOW: Must call get_one_action_knowledge first. 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 | Action ID from search_one_platform_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?
With no annotations, the description carries the burden of safety and side-effect disclosure. It clearly warns that this tool triggers real platform operations and includes critical safeguards (confirmation, stop-after-knowledge). While it does not detail idempotency, rate limits, or permission specifics, it provides substantial behavioral context beyond the schema.
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 well-structured and front-loaded: main purpose first, then CRITICAL usage guidance, exclusions, and workflow. Each sentence adds necessary value, with no filler or redundancy.
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 has 9 parameters, no output schema, and no annotations, making this a complex execution tool. The description covers workflow, exclusions, and confirmation requirements well, but it omits what the response/return value looks like and does not describe error behavior. This is a minor gap given the strong usage guidance.
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 baseline is 3. The description does not add meaning beyond the schema—it only mentions 'parameters' generically. The schema already documents each parameter adequately; no extra clarity is provided 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?
The description uses a specific verb ('Execute') and resource ('a One action') and clearly states it performs actual operations on third-party platforms. It differentiates this from siblings by framing it as the execution step, with examples like 'read my last Gmail email' and 'create a task in Asana'.
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 criteria are provided with concrete examples, and a strong when-not-to-use boundary is drawn for BUILD/CREATE intents, directing the agent to stop after get_one_action_knowledge. It also mandates the required workflow of calling get_one_action_knowledge first and asking for confirmation when uncertain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive documentation for a specific action including parameters, requirements, and usage examples. MANDATORY: You MUST call this tool before execute_one_action to understand the action's requirements, parameter structure, caveats, and proper usage. This loads the action documentation into context and is required for successful execution. Large documents come back as a digest (the sections needed to build a correct request, plus a list of what was omitted); request an omitted section by name with section, or the whole document with full: true.
| Name | Required | Description | Default |
|---|---|---|---|
| toc | No | 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. | |
| full | No | 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. | |
| section | No | 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. | |
| actionId | Yes | The action ID to get knowledge for (from the actions list returned by search_one_platform_actions). REQUIRED: This tool must be called before execute_one_action to load the action's documentation into context. | |
| platform | Yes | The platform name to get knowledge for (e.g., 'ship-station', 'shopify'). This is the kebab-case version of the platform name that comes from the list_one_integrations tool AVAILABLE PLATFORMS section. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses the digest behavior (large documents return a digest), the ability to request sections by name or full document via 'full: true', and the mandatory nature of the call. This goes beyond simple function description, though it could mention if the call has side effects (it doesn't, but it's implied as read-only). The mandatory language is a strong behavioral cue.
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 moderately long but each sentence earns its place: it starts with the core purpose, then the mandatory requirement, then the digest behavior. It's front-loaded with the most critical information (the mandatory call). No redundant filler; the sentences are information-dense and well-structured.
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?
Given the tool's moderate complexity (5 params, digest behavior) and no output schema, the description covers essential aspects: purpose, mandatory usage, parameter behavior, and digest handling. It omits specific examples of return values, but that's less critical without an output schema. The description is sufficient for an agent to call this tool correctly and handle the digest.
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 schema description coverage is 100%, so parameters are well-documented in the schema. However, the description adds value by explaining the interaction between 'section', 'full', and 'toc' (e.g., 'Ignored when `section` is set') and by providing usage context for 'actionId' (from search_one_platform_actions) and 'platform' (from list_one_integrations). This goes beyond the schema's basic descriptions, enhancing the agent's understanding.
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 states the tool's purpose: 'Get comprehensive documentation for a specific action including parameters, requirements, and usage examples.' It uses a specific verb ('get') and resource ('action knowledge'), and distinguishes itself from siblings by being a prerequisite to execute_one_action and by providing documentation, unlike search_one_platform_actions which lists actions.
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?
The description explicitly mandates that this tool MUST be called before execute_one_action, providing clear when-to-use guidance. It also explains the digest behavior and how to request omitted sections, which is crucial for effective usage. The mention of 'AVAILABLE PLATFORMS' ties to list_one_integrations, giving context on where platform names come from.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available One integrations and platforms. ALWAYS call this tool first in any workflow to discover what platforms and connections are available. This returns the connections that the user has and all available One platforms in kebab-case format (e.g., 'ship-station', 'shopify') which 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 | Summary statistics of connections and available platforms |
| connections | Yes | Array of user's active connections, each with the access the current config confers |
| availablePlatforms | Yes | Array of available platforms that can be connected |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the response structure, including the access field and its possible values, and the implication of action-scoped connections. It does not explicitly state that this is a read-only operation, but 'List' and the context make that clear. It adds meaningful behavioral context beyond the tool name.
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 efficiently structured, with each sentence contributing value: the core action, the usage directive, the output format, and the access field semantics. It avoids redundancy and is appropriately sized for the complexity of the tool.
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?
Given the tool's role as the entry point for discovery, the description fully covers its purpose, output structure, and how the access field informs subsequent actions. It explains when the returned data is sufficient (action-scoped) and does not require further searching. The presence of an output schema reduces the need to itemize every field, but the description already provides key details.
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 has zero parameters, so the baseline is 4. The description correctly omits parameter details, and since there are no inputs, no additional semantic clarification is needed.
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 states 'List all available One integrations and platforms' and provides specific output details (kebab-case format, access field). It distinguishes itself from siblings by explicitly framing it as the initial discovery step, making its role unique among search, knowledge, and execute tools.
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 instructs 'ALWAYS call this tool first in any workflow' and explains when not to search: 'When a connection is action-scoped, its actions are exactly what may run, so you need not search.' This directly informs the agent about when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for relevant actions on a specific platform using a query. Call this after list_one_integrations to find actions that match your intent. Returns the top 5 most relevant actions based on your search query. Use the exact kebab-case platform name from the integrations list.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query to find relevant actions (e.g., 'search contacts', 'create customer', 'send email'). Be specific about what you want to do. | |
| platform | Yes | The platform name to search actions for (e.g., 'ship-station', 'shopify'). This is the kebab-case version of the platform name that comes from the list_one_integrations tool AVAILABLE PLATFORMS section. | |
| agentType | No | The type of agent context: 'execute' if the user wants to execute an action, 'knowledge' if they want to get information or write code. Defaults to 'knowledge' if not specified. |
| Name | Required | Description |
|---|---|---|
| actions | Yes | Array of matching actions (max 5) |
| metadata | Yes | Metadata about the search results |
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 the tool returns the top 5 most relevant actions, requires the platform name exactly as provided by the integrations list, and depends on a prior call to list_one_integrations. It does not cover error handling or explicitly state read-only nature, but these are less critical for a search operation and the core behaviors are clear.
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 three sentences with no fluff. The first sentence states the purpose, the second gives usage guidance, and the third provides a key constraint and output detail. Every sentence earns its place.
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 description is fully sufficient for a search tool given the rich schema and presence of an output schema. It explains the tool's role in the workflow, the input constraints, and the nature of the output (top 5). No missing information is critical for correct usage.
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 schema already provides 100% coverage of parameter descriptions, so the baseline is 3. The description adds meaningful extra context for the platform parameter (exact kebab-case requirement and source from list_one_integrations) and reinforces the workflow ordering. This goes slightly beyond merely 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?
The description clearly states the tool searches for matching actions on a specified platform using a query, and it distinguishes itself from siblings by focusing on searching rather than listing integrations, retrieving action knowledge, or executing actions. It also mentions the top-5 result limit and its position in the workflow after list_one_integrations.
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?
The description explicitly instructs to call this tool after list_one_integrations and gives concrete guidance about using the exact kebab-case platform name. It provides clear context for when to use it, though it does not explicitly mention alternatives or exclusions for when not to use it, so it stops short of a 5.
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.
v1.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 4 tools
Each tool has a clearly distinct role: listing integrations, searching actions, fetching action documentation, and executing an action. The required workflow makes the relationships explicit, so an agent is unlikely to confuse them.
All tool names follow the same verb_one_noun pattern with snake_case: list_one_integrations, search_one_platform_actions, get_one_action_knowledge, execute_one_action. This creates a predictable convention across the entire set.
Four tools is appropriate for a focused integration-execution server. Each tool maps to one stage of the workflow (discover integrations, discover actions, understand an action, execute an action) and no tool feels redundant.
The set covers the full discover-to-execute lifecycle for One integrations. It includes discovery, search, documentation, and execution; the only notable limitation (top-5 search results) is a design choice rather than a dead end.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click 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.
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
