Your coding agent can write a PyTorch DataLoader, reason about worker counts, and spot that your batches are starving the GPU. Then it stops, because the fix is infrastructure: you need a bucket, a regional gateway, and a mount. So you alt-tab to a cloud console, click through six screens, copy some credentials back, and lose the thread.

The Training Pipes plugin closes that gap. It's an agent plugin for Cursor, Claude Code, and Codex that bundles five skills and a Model Context Protocol (MCP) server, so the same agent that wrote the data pipeline can provision the storage under it.

What's in the plugin

Two halves, and they're useful independently.

Five skills — diagnostic guidance the agent pulls in when the conversation warrants it. These are just Markdown; they need no account and no API key.

An MCP server — 15 tools over Streamable HTTP at https://api.trainingpipes.com/v1/mcp, covering projects, buckets, file systems, objects, and usage. These need an API key.

Install it

The plugin lives at github.com/training-pipes/training-pipes-plugin. Install it from cursor.directory, or add the MCP server by hand to ~/.cursor/mcp.json for a global install or .cursor/mcp.json for one project:

{
  "mcpServers": {
    "training-pipes": {
      "type": "http",
      "url": "https://api.trainingpipes.com/v1/mcp",
      "headers": {
        "Authorization": "Bearer ${TRAINING_PIPES_TOKEN}"
      }
    }
  }
}

Claude Code reads the same config from .mcp.json, and both ship in the repo. Create an API key under Settings → API Keys; it starts with tp_.

Then quit and reopen your editor — a reload isn't always enough — and ask for something:

list my Training Pipes projects

The five skills

The first two are the point. They fire on problems you have, not on our product's name, which means they're useful before you've ever heard of us.

Skill	Fires when
`diagnosing-dataloader-io-bottlenecks`	Training is slow, GPU utilization is low or sawtoothing, reads from object storage drag
`choosing-ml-training-storage`	Comparing EFS, FSx for Lustre, s3fs, Mountpoint for S3, JuiceFS, local NVMe, or a caching gateway
`mounting-object-storage-for-training`	Actually setting up a file system, or trying the no-account example mount
`reducing-cross-region-egress-costs`	Egress and data-transfer charges are higher than expected
`connecting-training-pipes`	Wiring up MCP, the CLI, the SDK, or an API key

What the tools can do

Fifteen tools, grouped by what they touch:

Projects — list_projects, get_project, create_project, delete_project
Buckets — list_buckets, get_bucket, create_bucket, delete_bucket
File systems — list_file_systems, get_file_system, create_file_system, update_file_system, delete_file_system
Objects — list_bucket_objects
Usage — get_usage

Every tool declares readOnlyHint, openWorldHint, and destructiveHint accurately, which is what lets a client decide on its own whether to just run something or stop and ask you first. The tools that create real cloud infrastructure and cost real money are marked so your agent confirms before spending. create_bucket provisions an actual bucket and IAM user; create_file_system provisions an actual EC2 gateway. Those are not dry runs.

Why the skills matter more than the tools

An MCP server is a remote control. It's only useful once you already know what to build.

The interesting failure in ML data loading is that most teams reach for a filesystem mount when the real fix is free. Your dataset is 400,000 small files and resharding into WebDataset tarballs fixes it. Your num_workers is 2 on a 32-core box. You're decoding JPEGs on the CPU while the GPU idles. None of that needs us.

So the skills are written to be useful when Training Pipes is not the answer. diagnosing-dataloader-io-bottlenecks spends most of its length on profiling and on fixes that cost nothing, and names the product only in the branch where a regional cache is genuinely the structural fix. choosing-ml-training-storage lists the cases where EFS or FSx or plain local NVMe is the right call.

A skill that reads like an advert gets the whole plugin uninstalled, which costs more than the mention was worth.

What it won't do

NFS is the supported protocol. There's no SMB, no matter what an older comparison table may have implied — a packed file system is read out of object storage inside Ganesha with no directory tree on the gateway's disk, so there's nothing for Samba to serve. Mounts reach the gateway through a WireGuard tunnel rather than a public NFS endpoint. Mounts are read-only by default, and a file system has to be packed before it can be mounted.

The plugin also won't pretend a compute-bound job is an I/O problem. If your GPUs are busy, more storage throughput buys you nothing, and the diagnostic skill will tell you that before it recommends anything.

Try it without an account

The lowest-friction path skips the plugin entirely. Install the CLI and mount a public example dataset — no signup, no key:

npm install -g bucketfs
sudo bucketfs mount-example

That gives you a real NFS mount backed by object storage, on macOS or Linux, in about a minute. If it feels like a local disk, the rest of the product is the same trick with your data.

For the background on why this is harder than it sounds, we've written about what POSIX actually requires of object storage, when to use NFS versus S3 for training, and why s3fs breaks in production.

Create a bucket and mount it →

Provision Training Storage from Cursor: The Training Pipes MCP Server and Skills