Provides tools for managing workflows (list, get, activate, deactivate, execute), monitoring executions (list, get, stop), and retrieving instance info from an n8n workflow automation platform.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@n8n MCP Server Show me all my n8n workflows"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides tools for interacting with n8n workflow automation platform. This server enables you to manage workflows, executions, and monitor your n8n instance through MCP-compatible clients.
list_workflows - Get all workflows with their status and metadata
get_workflow - Retrieve detailed information about a specific workflow
activate_workflow - Activate a workflow to start automatic execution
deactivate_workflow - Deactivate a workflow to stop automatic execution
execute_workflow - Manually trigger a workflow execution
list_executions - Get recent workflow executions with optional filtering
get_execution - Get detailed information about a specific execution
stop_execution - Stop a currently running execution
get_instance_info - Get n8n instance information and health status
Related MCP server: N8N MCP Server
Clone this repository:
git clone <repository-url>
cd n8n-thg-serverInstall dependencies:
npm installBuild the project:
npm run buildCreate a .env file or set the following environment variables:
N8N_API_KEY=your_n8n_api_key_here
N8N_BASE_URL=https://your-n8n-instance.comLog into your n8n instance
Go to Settings → API Keys
Create a new API key
Copy the generated key
Add the server to your MCP client configuration:
Add to your MCP settings file (cline_mcp_settings.json):
{
"mcpServers": {
"n8n-thg-server": {
"disabled": false,
"timeout": 60,
"type": "stdio",
"command": "node",
"args": ["/path/to/n8n-thg-server/build/index.js"],
"env": {
"N8N_API_KEY": "your_api_key_here",
"N8N_BASE_URL": "https://your-n8n-instance.com"
},
"autoApprove": []
}
}
}Add to your Claude Desktop configuration (claude_desktop_config.json):
{
"mcpServers": {
"n8n-thg-server": {
"command": "node",
"args": ["/path/to/n8n-thg-server/build/index.js"],
"env": {
"N8N_API_KEY": "your_api_key_here",
"N8N_BASE_URL": "https://your-n8n-instance.com"
}
}
}
}Once the MCP server is configured, you can use it through your MCP client:
"Show me all my n8n workflows"
"List recent workflow executions"
"Execute workflow with ID 123"
"Get details for execution 456"
"Activate workflow 789"
"Show me failed executions from today"
n8n-thg-server/
├── src/
│ └── index.ts # Main server implementation
├── build/ # Compiled JavaScript (generated)
├── package.json # Project configuration
├── tsconfig.json # TypeScript configuration
└── README.md # This filenpm run build - Compile TypeScript to JavaScript
npm run dev - Watch mode for development
npm start - Run the compiled server
npm run buildThis compiles the TypeScript source to JavaScript in the build/ directory.
If your n8n instance is protected by Cloudflare Access (common in enterprise setups), you may need additional configuration:
Ensure your API key has proper permissions
Configure service account authentication if available
Contact your system administrator for API access configuration
The server includes SSL certificate handling for self-signed certificates commonly used in enterprise environments.
Connection Errors: Verify your N8N_BASE_URL and N8N_API_KEY
SSL Certificate Issues: The server automatically handles self-signed certificates
Authentication Errors: Check if your n8n instance requires additional authentication steps
Set environment variable for detailed logging:
DEBUG=true node build/index.jsFork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
MIT License - see LICENSE file for details
For issues and questions:
Check the troubleshooting section above
Review n8n API documentation
Open an issue in this repository
Activate a workflow to start automatic execution
| Name | Required | Description | Default |
|---|---|---|---|
| workflowId | Yes | The ID of the workflow to activate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. 'Activate' is a state mutation, yet the description says nothing about required permissions, idempotency, behavior when already active, or whether the change is reversible. Only the effect ('automatic execution') is conveyed.
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?
A single front-loaded sentence with no filler. Every word contributes to the meaning.
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 simple one-parameter mutation the definition is minimally viable, but with no annotations and no output schema it omits what 'automatic execution' entails (triggers/scheduling), error conditions, and its relationship to execute_workflow and deactivate_workflow.
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% for the single workflowId parameter, which the schema already describes as 'The ID of the workflow to activate.' The description adds no syntax, format, or sourcing detail, so baseline 3 is appropriate.
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 ('Activate') and resource ('workflow'), plus the effect ('start automatic execution'). This subtly distinguishes it from execute_workflow (a one-off run), though it never names the sibling explicitly.
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?
No when-to-use guidance and no reference to alternatives like deactivate_workflow or execute_workflow. The purpose clause hints that it enables automatic execution, but an agent gets no explicit criteria for choosing this over execute_workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deactivate a workflow to stop automatic execution
| Name | Required | Description | Default |
|---|---|---|---|
| workflowId | Yes | The ID of the workflow to deactivate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the effect (halts automatic execution rather than deleting the workflow), implying reversibility, but says nothing about what happens to in-flight executions, required permissions, or idempotency.
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?
A single front-loaded sentence with the action and its consequence, zero filler, and nothing buried.
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 is low-complexity (one param, no output schema) and the effect is stated, but for an un-annotated mutation the description omits the fate of running executions and any permission requirements, leaving real gaps.
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?
One parameter at 100% schema coverage, so the schema already documents workflowId fully. The description adds no format, source, or validity detail beyond it; 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 (deactivate) and resource (workflow) plus the effect (stop automatic execution). It is implicitly the inverse of the sibling activate_workflow, so the operation is easy to place, but the description never names or contrasts with siblings explicitly.
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?
Usage is only implied: use it to stop a workflow from running automatically. There is no guidance on when-not to use it, nor any disambiguation from stop_execution, which is a meaningful sibling distinction an agent could get wrong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manually trigger a workflow execution
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Optional input data for the workflow | |
| workflowId | Yes | The ID of the workflow to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It never says whether the execution is synchronous or asynchronous, whether the call returns an execution ID, whether it is idempotent, or what permissions/rate limits apply — all critical for a mutation trigger.
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?
A single front-loaded sentence with no filler, though it is arguably too terse for a mutation tool and leaves room for one more sentence of substance.
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 side-effecting trigger with no annotations and no output schema, the description omits what the agent most needs: whether execution is async, what gets returned, and how failures surface. The schema covers inputs but nothing covers behavior.
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% and both parameters are documented in-schema, so the baseline of 3 applies. The description adds nothing about the shape or expected content of the optional 'data' object for the workflow.
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 states a specific verb and resource ('trigger a workflow execution') and the word 'Manually' usefully separates it from the sibling activate_workflow/deactivate_workflow toggles. It does not explicitly name an alternative tool, so it stops short of the 5-tier sibling differentiation.
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?
There is no guidance on when to prefer this over activate_workflow, nor any prerequisites or conditions. 'Manually' hints at a contrast with scheduled/automatic runs, but the agent must infer that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific execution
| Name | Required | Description | Default |
|---|---|---|---|
| executionId | Yes | The ID of the execution to retrieve | |
| includeData | No | Include execution data and results (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a read operation via 'Get' but does not state permissions, rate limits, or what 'detailed information' includes; the includeData behavior is left entirely to 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?
Single front-loaded sentence with no wasted words. It is appropriately sized for a simple retrieval 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?
For a simple read tool with full schema coverage and no output schema, the description plus schema is sufficient for correct invocation. It lacks usage guidance, but that gap is captured in the usage guidelines dimension.
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 both parameters are fully documented in the input schema. The description adds no additional parameter meaning, which is the baseline when schema coverage is high.
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 ('Get') and resource ('execution'), and scope ('a specific execution'). It is clear what the tool does, but it does not distinguish itself from the sibling list_executions or explicitly say retrieval is by ID.
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?
Provides no when-to-use or when-not-to-use guidance, and does not name alternatives such as list_executions. Usage is only implied by the word 'specific'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get n8n instance information and health status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Get' implies a safe read, and 'health status' hints at a diagnostic result, but it does not disclose what information is returned, whether any authentication or elevated permissions are required, or any rate limits — acceptable for a zero-argument read tool but thin.
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?
A single front-loaded sentence with no filler. Every word 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?
For a simple zero-parameter read tool this is adequate, but with no output schema the description is the only source of information about what the caller receives, and 'information and health status' stays vague. Slightly more detail on the returned fields would close the gap.
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 are no parameter semantics to document; the baseline of 4 applies. Schema coverage is 100% and trivially complete.
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 ('Get') and a well-defined resource ('n8n instance information and health status'). It is implicitly distinguished from the workflow/execution siblings, which all operate on narrower resources, but the description never says so explicitly.
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?
There is no statement of when to use this tool versus the eight workflow/execution siblings, nor any prerequisite context. The use case (checking instance health) is inferable from the name but never spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific workflow
| Name | Required | Description | Default |
|---|---|---|---|
| workflowId | Yes | The ID of the workflow to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It implies a read operation via 'Get' but omits permissions, error behavior, rate limits, and what 'detailed information' actually contains, and no output schema exists to clarify returns.
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?
Single front-loaded sentence with no wasted words. It is appropriately sized for a one-parameter getter.
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 is simple and schema coverage is complete, but with no output schema the description could define what 'detailed information' includes. No annotations also leave behavioral context thin, making it minimally adequate.
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 workflowId is already fully documented by the schema. The description adds no parameter syntax or constraints beyond that baseline, making 3 appropriate.
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 ('Get') and resource ('workflow'), scoped to a specific workflow, which implicitly contrasts with list_workflows. It does not name alternatives explicitly, but the purpose is clear and distinguishable from sibling action 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?
No guidance on when to use this tool versus list_workflows, get_execution, or other siblings, nor any prerequisites such as permissions. The description only implies usage by saying it retrieves a specific workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent workflow executions with optional filtering
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of executions to return (default: 20, max: 100) | |
| status | No | Filter by execution status (optional) | |
| workflowId | No | Filter by specific workflow ID (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. It does not disclose whether results are ordered, whether pagination exists, what the default limit behavior means for callers, or confirm the read-only nature beyond the verb 'Get'.
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?
A single front-loaded clause with no filler or redundancy. It is efficient, though the brevity borders on under-specification for a filtering API.
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 no annotations and no output schema, the description is the only place behavior could be explained, and it says nothing about return ordering, result shape, or pagination limits. For a three-parameter list tool this leaves meaningful gaps.
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%: the limit bounds/default, the status enum, and workflowId all have inline descriptions. The description's 'optional filtering' merely restates that these filters exist, adding no syntax or semantics 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?
The description names a specific verb ('Get') and resource ('workflow executions') with a scope qualifier ('recent'), so an agent understands it is a list/read operation. It does not explicitly distinguish itself from the sibling get_execution, which is why it falls short of a 5.
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 states that filtering is optional but gives no guidance on when to use this tool versus get_execution (single) or list_workflows, and no prerequisites or ordering context. Usage must be inferred entirely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all workflows with their status and metadata
| Name | Required | Description | Default |
|---|---|---|---|
| active | No | Filter by active status (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says 'all workflows' but does not mention the optional active filter, pagination, result size limits, or ordering, leaving the agent without context on how the listing actually behaves.
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?
A single efficient sentence with no filler and the core action front-loaded. It is arguably too terse rather than padded, so it does not reach 5.
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 simple one-optional-parameter read tool with no output schema, the description is minimally adequate. It omits the existence of the filter and any return-shape hints, which would have been easy to include.
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% and the single 'active' parameter is documented in the schema, so the baseline of 3 applies. The description's phrase 'all workflows' actually omits mention of the filter, adding no meaning beyond 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 has a specific verb ('Get') and resource ('workflows') with scope ('all') plus the payload contents ('status and metadata'). It does not explicitly contrast with the singular sibling get_workflow, so it falls short of the 5-level sibling differentiation.
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?
No indication of when to use this list tool versus get_workflow for a single workflow, nor any prerequisites. The agent must infer the plural/singular distinction from the tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a currently running execution
| Name | Required | Description | Default |
|---|---|---|---|
| executionId | Yes | The ID of the execution to stop |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and mostly fails: it doesn't say whether the stop is graceful or forced, whether it is idempotent, what happens if the execution has already finished, what permissions are required, or what is returned. Only the 'currently running' state hint adds anything.
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?
A single front-loaded sentence with no filler or redundancy. It is arguably too terse for a mutation tool, but the text itself contains no 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?
For a mutating operation with no annotations, no output schema, and no parameter gaps, the description still omits key operational context: effect on the workflow/instance, idempotency, error behavior when the execution is not running, and permission requirements.
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% and the single executionId parameter is fully described in the schema, so the description adds no format, source, or constraint details beyond it. Baseline 3 for a schema-driven parameter.
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 ('Stop') and resource ('execution') with the scope qualifier 'currently running', making it clearly distinct from execute_workflow in the sibling list. It does not explicitly name a sibling, but the action is unambiguous.
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 phrase 'currently running' implies a precondition, but there is no guidance on when to use this versus siblings like deactivate_workflow or execute_workflow, no mention of prerequisites, and no exclusions.
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.
v0.1.0activate_workflowdeactivate_workflowexecute_workflowget_executionget_instance_infoget_workflowlist_executionslist_workflowsstop_executionScored across 9 tools
Each tool targets a distinct resource and action: workflow management (list/get/activate/deactivate/execute), execution management (list/get/stop), and instance info. No two tools overlap in purpose, and descriptions clearly delineate manual execution from activation and stopping a specific execution from deactivating a workflow.
All tool names follow a consistent snake_case verb_noun pattern (e.g., list_workflows, get_workflow, activate_workflow). The single get_instance_info slightly extends to verb_noun_noun but remains fully predictable and readable.
Nine tools is well-scoped for an n8n management server, covering key workflow and execution lifecycle operations without redundancy. Each tool earns its place and the set is neither thin nor heavy.
The surface covers listing, retrieving, activating, deactivating, and executing workflows, plus execution monitoring and instance health. However, it lacks create, update, and delete operations for workflows, which are fundamental for a workflow automation platform and will cause agent failures when trying to build or modify workflows.
The official MCP Server from Mia-Platform to interact with Mia-Platform Console
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Cross-product MCP server for CRM, LeadKit, ProjectKit, Bookio. 10 action types, MIT open spec.
