n8n-workflows-esp is 10,000 n8n workflows with Spanish descriptions

What the fork actually adds over the original collection

The repository describes itself as a fork of an initiative that gathers n8n workflows from various sources, specifically the official n8n site and its community forum, plus examples shared publicly on GitHub, blogs and other websites. The stated purpose is to offer a consolidated resource for inspiration, for learning, and for reusing workflows in your own n8n projects.

On top of that base, the fork lists four changes. A workflow search tool was built and linked so the collection can be browsed quickly. Every `.json` file was analysed and given a clear Spanish description based on the actions it performs. The unique hash of each file was checked so duplicate workflows could be removed, so that each flow is unique in content. File names were updated to describe their main function more precisely, which is what makes the collection searchable at all.

The four changes are all curation decisions, and that is the honest characterisation of the project. Nothing here changes how n8n runs. The value is that a directory of thousands of files with opaque names becomes a directory of thousands of files with meaningful names, descriptions and a way to look one up.

The listing in the README illustrates the format. Entries are numbered, then named, then described, then given a complexity rating derived from node count, for example a media complexity entry at 24 nodes, a low complexity entry at 8 nodes, and a high complexity entry at 47 nodes.

A directory of JSON files is the entire repository

The top-level entries of the repository are minimal: `workflows/`, the README, an English version of the README named `README-ENGLISH.md`, plus `.gitattributes` and `.gitignore`. There is no package manifest, no build script, no test suite and no application.

That structure tells you how the collection is consumed. There is nothing to install and nothing to compile. A workflow is an n8n export, a JSON document describing nodes and their connections, and you bring it into your instance using n8n's own import function. The directory is a data set with a README, and the primary language recorded for the repository is HTML, which reflects the README and the web search tool rather than any runtime.

The README states a total of 10405 workflows, which is the number the collection is organised around, and the file names are numbered with a five-digit prefix, which preserves an ordering that survives renaming. Some names retain their origin in the name itself, for example a file named for a community contribution that converts Perplexity research into HTML content, and another named for an AI agent handling pet shop appointments. Both carry a high complexity rating, 47 nodes and 187 nodes respectively, so the collection does include large multi-service flows alongside three-node utility flows.

A repository this size is mostly storage. The interesting parts are the small number of directories and files that sit around it.

Importing a workflow, and the step where you take over responsibility

The usage instructions are seven steps, and the fourth one is the important one. Open your n8n instance. Press the import menu, described as the menu with the hamburger icon followed by Importar workflow. Select the desired `.json` file from the `workflows` folder. Review and adjust the credentials or webhook URLs as needed. Save and run the workflow. The sixth point points at a custom GPT that can help locate a flow or troubleshoot one, and the seventh points at a chat endpoint for the repository itself.

Step four is the whole risk. A workflow that came from a forum post may reference a webhook on someone else's server, a credential id that means nothing in your instance, an API endpoint in a service you do not use, or a node that quietly posts data to a third party. The imported JSON carries the structure, not your credentials, so the dangerous part is the URLs and the node types, not the secrets.

The repository states this itself. Every workflow shared there is provided as is, and the notice says that before employing them in a production environment you should inspect and test them in a controlled environment, making sure you fully understand each node, credential and link to avoid errors or security holes. That advice is sound, and it applies more strongly to a catalogue this large than to a single example.

The MCP server turns the catalogue into a searchable knowledge base

The fork exposes the collection through the Model Context Protocol. The README gives the server address for interacting with the database of documented n8n workflows, and links to instructions for using it in Cursor, Claude Desktop, Windsurf, VSCode, Cline or Highlight AI. A separate chat URL is offered for chatting with the repository.

This is the most distinctive thing in the project, and it changes the access pattern. Rather than browsing a directory, an assistant can query the collection for a workflow that matches a described need. The README positions the Custom GPT in the same way, as a way to find the flow you need or to help resolve a problem with n8n.

The value of that is real for discovery. The cost is that the tool now decides which JSON you end up importing, and a description in Spanish plus a filename is a thin basis for choosing a 187-node flow that will call six services. If you use the MCP server to shortlist candidates, the inspection step still has to happen in a text editor, and it has to happen before the import rather than after.

Worth noting for anyone assessing trust: the search tool and the MCP server are hosted outside this repository, on the DragonJAR domain and on gitmcp.io respectively. The repository is the data; the services that serve and query it live elsewhere.

Contribution rules are about naming and attribution, not review

The contribution section is short and prescriptive. If you find an interesting workflow or develop your own, you are asked to keep two things in mind. Choose a descriptive file name that clearly reflects the main function of the workflow. If the workflow comes from another source, include a brief comment at the start of the file indicating its origin. Contributions are proposed by opening a pull request.

The second rule is the one that carries weight, because the collection is assembled from elsewhere and the provenance marker is the only trace of where a file came from. That matters for the reader who opens the JSON to check whether it is safe, and it is a weaker guarantee than a curated source list, but it is the mechanism the project actually has.

The first rule is what keeps the collection usable. Renaming files for accuracy is listed as one of the improvements the fork made, and it only stays true if contributors keep doing it.

One inconsistency is worth flagging. The description of each workflow is generated in Spanish, and the fork is presented as the Spanish version, but a README-ENGLISH.md exists alongside the Spanish README. So the interface is bilingual while the per-workflow descriptions, which is where the useful detail sits, are not.

Licence, release tags and what a fork of a catalogue inherits

The licence situation is the weakest point in this repository, and it is a repository of other people's work, so it deserves a clear statement rather than a general one.

There is no licence file at the top level. The entries are the README, the English README, the workflows directory and the two dotfiles. The repository's licence is recorded as unknown, and the README itself does not claim a licence. For a collection assembled from workflows published on forums, blogs and GitHub by their original authors, that means you cannot assume the rights to those workflows are settled. Each workflow is contributed by someone else, and the fork's own notice says the workflows are provided as is. If you intend to run one in production, the responsibility for checking what you are allowed to do with it sits with you.

The releases are simple tags rather than a semantic version scheme with a changelog attached: a 1.0 tag in January 2026 and a 1.5 tag in April 2026. The repository is not archived, and the last push was on 2026-09-20.

For a data set, maintenance means something slightly different from what it means for a library. Nothing breaks if the repository stops receiving pushes. The workflows are JSON exports, and n8n keeps its own import format. What a stale collection costs you is coverage of newer n8n node types, and what it gives you is ten thousand working starting points for free.

Editorial conclusion

Use n8n-workflows-esp as a catalogue to skim, to learn the shape of a workflow you need, and to find a starting point you will rewrite, not as a library you import into production. The repository's own notice is that every workflow is provided as is and must be inspected and tested in a controlled environment before use, because each file can contain credentials, webhook URLs and third-party calls you did not write. Do not adopt it if you need English descriptions, an audited dependency chain, or a licence your organisation can rely on, since the repository lists no licence file at all. Before importing anything, open the JSON in a text editor, find the node that owns the credentials, and read what each node sends where.

Frequently asked questions

Official sources

1. DragonJAR/n8n-workflows-esp on GitHub
2. Issues
3. README
4. Releases