This n8n Assistant server allows you to search and retrieve information from n8n resources:
Search Documentation: Find relevant n8n documentation for specific queries
Search Example Workflows: Find example workflows using "n8n example {query}"
Search Community Forums: Access discussions and solutions for n8n-related issues
Asynchronous Processing: Perform searches efficiently with asynchronous HTTP requests
Extract HTML Content: Use BeautifulSoup to clean web page results
Provides tools for searching n8n documentation, example workflows, and community forums, enabling users to find relevant information about n8n functionality and usage patterns.
Click on "Install 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-asistans show me example workflows for sending automated emails"
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.
This project contains a Multi-Channel Platform (MCP) server used to create an assistant integrated with n8n. The assistant can be used to search for n8n documentation, example workflows, and community forums.
Web Search: Searches n8n documentation, workflows, and community forums based on a specific query.
HTML Content Fetching: Uses BeautifulSoup to extract the main content from search results.
Asynchronous Processing: Performs HTTP requests asynchronously, providing faster response times.
Related MCP server: n8n-MCP
Python 3.7 or higher
httpx library
beautifulsoup4 library
python-dotenv library
To install n8n-assistant for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @onurpolat05/n8n-assistant --client claudeClone this repository:
git clone <repository-url>
cd <repository-directory>Install the required dependencies:
pip install -r requirements.txtCreate a .env file and add the necessary API keys:
SERPER_API_KEY=your_api_key_hereTo start the assistant, run the following command:
uvicorn main:app --reloadThen, you can query the assistant for information related to n8n like this:
await get_n8n_info("HTTP Request node", "docs")This project uses the n8n-asistans MCP server. The server is started with the following command:
{
"mcpServers": {
"n8n-asistans": {
"command": "uv",
"args": [
"--directory",
"/n8n-assistant",
"run",
"main.py"
],
"env":{
"SERPER_API_KEY": "*********"
}
}
}
}If you would like to contribute, please create a pull request or report issues.
This project is licensed under the MIT License.
Search the latest n8n resources for a given query.
Args: query: The query to search for (e.g. "HTTP Request node") resource_type: The resource type to search in (docs, workflows, community) - docs: General n8n documentation - workflows: Example workflows (will search for "n8n example {query}") - community: Community forums for issues and questions
Returns: Text from the n8n resources
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| resource_type | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'latest n8n resources' but lacks details on permissions, rate limits, error handling, or response format beyond 'Text from the n8n resources,' leaving significant gaps for a search tool.
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 with a purpose statement, args section, and returns section, making it easy to parse. It could be slightly more concise by integrating the parameter details more fluidly, but overall it's efficient with minimal 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?
Given no annotations, no output schema, and low complexity, the description covers the basic purpose and parameters adequately. However, it lacks details on behavioral aspects like search limitations or result formatting, making it minimally viable but incomplete for optimal agent use.
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?
With schema description coverage at 0%, the description fully compensates by clearly explaining both parameters: 'query' as the search term with an example and 'resource_type' with detailed options (docs, workflows, community) and their meanings. This adds substantial value beyond the bare 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's purpose as 'Search the latest n8n resources for a given query,' which specifies the verb (search) and resource (n8n resources). However, with no sibling tools provided, it cannot demonstrate differentiation from alternatives, preventing a perfect score.
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 provides no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. It only lists parameters and returns, offering no context for decision-making in usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With only one tool, there is no possibility of ambiguity or overlap between tools, making disambiguation perfect. The tool's purpose is clearly defined as searching n8n resources, and no other tools exist to cause confusion.
Since there is only one tool, naming consistency is inherently perfect with no deviations or mixed conventions to evaluate. The tool name 'get_n8n_info' follows a clear verb_noun pattern, but consistency across multiple tools cannot be assessed.
A single tool for a server named 'n8n-asistans' feels too thin for the apparent scope, as it only offers search functionality without any CRUD operations or broader management capabilities for n8n resources. This is a borderline case leaning toward inadequacy for a typical assistant server.
The tool surface is severely incomplete for an assistant server, as it only provides search functionality without any ability to create, update, delete, or manage n8n workflows or resources. This will likely cause agent failures when trying to perform comprehensive tasks beyond simple queries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Search and query nTop's knowledge base and engineering guides from AI applications.
Know when your n8n workflows, URLs, and AI apps break, before your customers do.
Search recordings, summarize meetings, create clips, and automate workflows from your AI assistant.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/onurpolat05/n8n-Assistant'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
