A small Pipelex MCP server exposing four tools — build a pipeline, run a pipeline, list available pipes, and a health check — none of which match the two servers (console pipelex_*, workshop mthds_*) the README documents.
pipe_builder — Turn an untouched natural-language request into a Pipelex pipeline, returning the PLX content and the inputs format needed to run it. The description warns not to modify it.
pipe_runner — Run a Pipelex pipeline from PLX content (optionally naming a specific pipe when the content has no main pipe), with inputs given as a JSON object, string, or null; returns a result object.
list_available_pipes — List all pipes available in the Pipelex library.
health — Simple health check returning string key/value pairs.
Worth flagging: this schema has no pipelex_* (console) or mthds_* (workshop) tools, no file/attachment handling, no save/get/list-methods catalog tools, no views, and no sign-in or API-key surface — so it appears to be a different (likely older or unrelated) server than the Pipelex MCP described in the README.
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., "@Pipelex MCP Server build a pipeline to extract names from receipts"
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.
Pipelex lets you build AI methods with your coding agent and run them anywhere: as an MCP for chatbots, as a webapp for people, or via API for your software. This repository is the Pipelex MCP: it connects your chatbot to your Pipelex account and the methods saved there.
Chatbots — ChatGPT, Claude. Sign up at app.pipelex.com. Add the Pipelex MCP in your chatbot's settings by the address below — in Claude, that is Add custom connector — then sign in with your Pipelex account when asked. Nothing to install and no key: the Pipelex MCP runs on your signed-in session.
https://mcp.pipelex.com/mcpCoding agents — Claude Code, Codex. Install the Pipelex plugin instead: it brings the skills that build methods, and its own Pipelex tools, which run your methods and also work with the method files in your project. Claude Code also loads what you have added to your Claude account, so if you added the Pipelex MCP to Claude, Claude Code has it too. An agent with the plugin does not need the Pipelex MCP, and there is nothing to turn off: when both are present, the Pipelex MCP defers to the plugin's tools.
Then ask your chatbot:
What methods do I have?
Run github.com/Pipelex/methods/invoice_extraction@v0.1.1 on https://raw.githubusercontent.com/Pipelex/pipelex-cookbook/main/assets/extract_proof_of_purchase/restaurant_invoice.pdf
You get a run id straight away, and you can ask for its status, its results or the files it produced at any time.
Your new account comes with one method to try. A published method, such as those in the Pipelex methods repository, runs from its address with nothing to save. Your own methods come from the Pipelex plugin: build one in a coding agent and save it to your account, and your chatbot lists it and runs it by name.
Give the file as a URL the Pipelex MCP can reach. In ChatGPT you can attach it to the conversation instead and ask for a run on it; Claude has no way yet to hand the Pipelex MCP a file you attached.
Other hosts, and the reference for developers, start at Which server, for which host.
Next: what Pipelex is · documentation · your console · Discord
Related MCP server: Model Context Shell
A host needs one of two things, not both: the Pipelex plugin on a coding agent, the Pipelex MCP on a chatbot. The table applies that rule host by host. You don't need both says what happens when the Pipelex MCP added in Claude reaches Claude Code without anyone choosing it.
Host | Tool | How to connect |
Claude Code | Pipelex plugin | |
Codex | Pipelex plugin | |
ChatGPT (web) | Pipelex MCP | A developer-mode app, created by the address above (OpenAI's conditions) |
claude.ai (web + mobile) | Pipelex MCP | Add custom connector, by the address above |
Claude Desktop | Pipelex MCP | Add custom connector, by the address above |
A host that spawns MCP servers but takes no plugin, such as Cursor, can run the plugin's MCP server by hand: Registering the workshop in a host gives its configuration.
This repository is the workshop, the MCP server inside the Pipelex plugin (server name pipelex-plugin): an npm-distributed stdio server (@pipelex/mcp, bin pipelex-mcp) that coding-agent hosts spawn via npx. It wraps the Pipelex API through the @pipelex/sdk PipelexApiClient. Its tools are mthds_*: they find a saved method, validate a method, template its inputs, generate typed code for it, prepare its files, run it, look up the model references it can name, save it to the catalog as a draft and pull it back, and publish the draft as a version when you ask. Its headline feature is the { path } file arm: it reads .mthds files from disk instead of having the model hand-copy their contents. It is tools-first and ships no views on any host, so it reports structured results and text summaries directly.
The Pipelex MCP for chatbots, at mcp.pipelex.com, is the hosted Pipelex connector, a separate product with tools of its own, named pipelex_*: see Chat hosts use the Pipelex connector.
The tools reference gives each tool's input, result and behavior.
Tool | What it does |
List the methods saved in your organization's catalog by name, description and id, never their source. | |
List the model references a pipe can name, or check one before writing it into a method. | |
Validate a method given as files, a published address or a catalog id, return its main pipe's typed signature, and write its flowchart as an HTML page beside files given by path. | |
Return a fill-in template of a pipe's declared inputs. | |
Generate typed TypeScript or Python for a method's concepts, stamped and locked, returned or written straight to disk. | |
Make filled inputs run-ready, uploading local files to Pipelex storage. | |
Start a durable run on the hosted Pipelex API from files, an address or an id, and return its | |
Read a run's lifecycle state by its | |
Fetch a run's outcome, and list for free which of its stored files look like images. | |
Show the pictures a completed run produced, as image content that stays in the conversation. | |
Save a completed run to disk: its output as | |
Validate a bundle and save it as a method's draft in your organization's catalog, linking the directory to the saved method when the bundle was given by path. A save never publishes. | |
Bring a saved method's draft, or one of its published versions, back, to disk or inline. | |
Publish a method's draft as its next version, which callers of its bare id then run, when you ask for a publish. |
MCP tool arguments are generated token-by-token by the host LLM — there is no other channel from the conversation to the server. So submitting a bundle's .mthds contents inline means the model re-emits every file as output tokens (slow on large bundles, re-paid every repair-loop iteration and every tool in the chain, and not guaranteed byte-identical to what's on disk). The workshop sidesteps this: the host spawns it in your workspace, so it can read files from disk given only a path.
The workshop's files-taking tools accept two item forms — inline content or a file path:
type SubmittedFileInput = { content: string; uri?: string | null } | { path: string };The workshop resolves { path } items from disk before invoking the capability — near-constant token cost regardless of bundle size, byte-accurate reads, and real provenance (the resolved item carries uri = the submitted path, so diagnostics locate to files you can open and edit). Inline { content, uri? } items stay accepted, for a bundle the agent holds only in the conversation. An item is one arm or the other; on a malformed item carrying both keys, content wins (first-match union semantics) and path is ignored.
Path trust boundary. { path } values resolve relative to the server's working directory. Each { path } argument is contracted to one extension, .mthds for every bundle argument and .py for mthds_save_method's python, so any other extension is rejected before any filesystem access (a prompt-injected .env or key-file path is never opened), and the resolved target (symlinks followed) must live inside the working-directory subtree. mthds_save_method adds one more bound: every { path } item must sit at or under the directory of its first files item, which must itself be a { path }. A wrong extension, an escape, a missing file and a non-regular file come back as input_domain errors located at the item (files[i].path, or python[i].path).
The workshop is published on npm as @pipelex/mcp. You do not install it: a host spawns it on demand in your project with the command below, and on Claude Code and Codex the Pipelex plugin does that for you. Run by hand, it prints nothing and waits for a host on its standard input.
npx -y @pipelex/mcpIt needs Node.js 24.14.1 or later, and a PIPELEX_API_KEY in its environment, since every tool calls the hosted Pipelex API: a plx_sk_ key, which you create in your console at app.pipelex.com. The directory the host starts it in is the boundary for everything it reads and writes on disk. Registering the workshop in a host gives the configuration for each host, every environment variable the workshop reads, and the rules of that boundary.
ChatGPT, claude.ai and Claude Desktop do not run this server. They add the Pipelex connector, the hosted Pipelex MCP, by its address:
https://mcp.pipelex.com/mcpThere is nothing to install and no key to paste: the host walks you through signing in with your Pipelex account, and your signed-in session authorizes every call the connector makes. If you have no Pipelex account yet, create one at app.pipelex.com before you add the connector, since signing up there also sets up the organization every call works in. The connector is a separate product with its own tools, and this repository does not hold it.
On a coding agent, prefer the workshop, which the Pipelex plugin brings — see Which server, for which host.
A chat host takes the connector, and a coding agent takes the workshop through the Pipelex plugin; no host needs both. The two share no tool name, so a host that has both can tell them apart, and the workshop's instructions tell the model to use its mthds_* tools for all method work whenever the connector's pipelex_* tools are also present, and never to mix the two. The connector runs on your sign-in and the workshop on an API key, and the two can select different organizations: a method saved from the workshop is visible from the connector only when both select the same one.
The way to end up with both without choosing it: the connector added in claude.ai syncs into Claude Code automatically. A user signed into claude.ai with the connector enabled gets its tools in coding sessions beside the workshop's. That is harmless, but it doubles the tool list for no added capability, so you can turn the connector off for those sessions:
In Claude Code, /mcp is the entry point. A connector you haven't signed into is collapsed behind a "Show unused connectors" row (Claude Code v2.1.161+) — expand it to find Pipelex.
For one project, list it under deniedMcpServers in .claude/settings.json.
Avoid disableClaudeAiConnectors: true for this. It turns off the Pipelex connector, but also every other connector on your Claude account, such as Gmail, Google Drive and Calendar, and those are what an agent uses to fetch a method's inputs from your mail or files and to deliver its results.
Tools reference: every tool's input, structured result and behavior.
Registering the workshop in a host: the configuration for Claude Code, Codex, Cursor, Claude Desktop and Mistral Vibe, the environment variables the workshop reads, and the working directory it is bound to.
Developing pipelex-mcp: the layout, the build, the test suites and versioning.
Architecture and Testing: how the workshop and its capability core are built, module by module, and how they are tested, the live drift detectors included.
Client identification: the User-Agent every request to the Pipelex API carries, naming this server and the host behind it.
The specification: the source of truth for the full tool contracts and the verdict discipline.
The changelog, whose versions are the ones on npm, and which also records every release made before the console and the workshop were split.
The repository is one package at its root, @pipelex/mcp, whose sources are under src/: the server and, under src/capabilities/, the capability core it is built on. To work on it, clone it, then, from the root:
make install # install the dependencies
make check # lint, formatting, the text budgets, the build and typecheck
make test # the hermetic test suite, which never touches the networkA coding agent runs make agent-test instead of make test: the same suite, with its output shown only when a test fails. make dev-local runs the workshop from source. Developing pipelex-mcp covers the layout, the live test suites against the Pipelex API, and how the workshop is versioned and released.
@pipelex/mcp is licensed under the Elastic License 2.0 (ELv2), a source-available license. You may run it for your own team or company, on your own infrastructure or in your own cloud account. What the Elastic License 2.0 rules out is offering others a remote MCP server through which they run the methods of their choice, their own or a catalog's. See LICENSE for the full terms, including notices and redistribution, and the license page for how Pipelex reads them.
Simple health check
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. 'Simple health check' provides minimal behavioral detail—does not disclose what the check entails, whether it is idempotent, or what side effects (if any) exist. For a read-only operation, this is acceptable but not informative.
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?
Four words with no extraneous information. Perfectly concise for a simple health check 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 no parameters, an output schema exists, and the tool is a simple health check, the description is sufficient to understand its purpose. The agent can rely on the output schema for return values.
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 and schema coverage is 100%, so the description does not need to explain parameters. Baseline is 4 for zero parameters, and the description adds nothing extra, which is acceptable.
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 'Simple health check' clearly indicates the tool performs a health check operation. It is distinct from sibling tools (list_available_pipes, pipe_builder, pipe_runner) which deal with pipeline management, so an agent can easily differentiate.
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 alternatives. Sibling tools suggest different purposes, but the description offers no explicit context or restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available pipes in the Pipelex library
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It indicates a read-only listing operation, which is obvious, but lacks details on authentication, rate limits, or side effects.
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 a single sentence with no unnecessary words, efficiently communicating the tool's purpose.
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 parameters and no annotations, the description is minimal but functional. Given an output schema exists, it does not need to specify return values, but it could mention what information is returned (e.g., names or IDs).
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 description does not need to add parameter information. Baseline score of 4 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 uses a specific verb 'List' and identifies the resource 'available pipes in the Pipelex library', clearly distinguishing it from sibling tools like 'pipe_builder' and 'pipe_runner'.
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 alternatives; it simply states what it does without context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a Pipelex pipeline from a natural language request, do not modify it
| Name | Required | Description | Default |
|---|---|---|---|
| untouched_user_request | Yes |
| Name | Required | Description |
|---|---|---|
| plx_content | Yes | |
| inputs_format_to_run | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'do not modify it', hinting at a non-modifying behavior but does not disclose side effects, errors, or idempotence. Minimal behavioral info.
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?
Short and to the point, but the 'do not modify it' clause is somewhat confusing. Could be slightly more front-loaded, but overall efficient.
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?
Despite having an output schema, description does not clarify return value or process. Parameter 'untouched_user_request' is unexplained. Insufficient for a tool that builds pipelines from NL.
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 0% and description does not explain the sole parameter 'untouched_user_request'. No hint about what to provide or format. Baseline compensation not met.
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 action: 'Build a Pipelex pipeline from a natural language request'. It uses a specific verb and resource, and is distinct from siblings like 'health', 'list_available_pipes', and 'pipe_runner'.
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 explicit guidance on when to use this tool versus alternatives. The 'do not modify it' part is vague and not helpful for selection. Lacks context such as prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Pipelex pipeline (optionally with PLX content)
| Name | Required | Description | Default |
|---|---|---|---|
| plx_content | Yes | ||
| specific_pipe_code_if_plx_content_has_no_main_pipe | Yes | ||
| inputs_json | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden but only provides a vague action. Contradicts schema about optionality, and no disclosure of side effects, permissions, or outcomes.
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 very short (10 words), but conciseness is undermined by inaccuracy and lack of necessary information. Front-loads purpose but not effectively.
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?
Despite an output schema existing, the description fails to provide essential context for a 3-param tool with required inputs. No behavioral or usage context, and schema contradiction makes it unreliable.
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 0%, and description fails to explain the three required parameters (plx_content, specific_pipe_code_if_plx_content_has_no_main_pipe, inputs_json). The one mention of PLX content contradicts 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 states 'Run a Pipelex pipeline (optionally with PLX content)', but the input schema lists plx_content as required, creating a contradiction. This misleads about whether PLX content is mandatory.
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 siblings like pipe_builder or list_available_pipes. No context about prerequisites or scenarios.
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.7healthlist_available_pipespipe_builderpipe_runnerScored across 4 tools
Each tool has a clearly distinct purpose: health check, listing pipes, building a pipeline, and running a pipeline. No overlap between any pair.
Most tools use snake_case with verb_noun or noun_verb pattern (list_available_pipes, pipe_builder, pipe_runner). 'health' is a single noun without underscore, creating slight inconsistency but still clear.
4 tools is well-scoped for a pipeline management server: health, list, build, run. Each tool serves a necessary function without redundancy.
Covers the core lifecycle: listing available pipes, building a pipeline, and running it. Missing possibly a tool to inspect a specific pipe or delete one, but not essential for basic operation.
Give your AI agents the tools to build, manage, and run automation workflows.
Image and video AI tools and your own pipelines, run from any AI assistant.
Build and run agents and automations across hundreds of apps using natural language.
Build and run visual creative-production workflows from your AI agent.
