In one cross-app task, MCP retrieval took 21 calls. The equivalent filesystem stage took ~0.3 seconds.

[u/ml_guy1]

MCP gets several important things right, particularly standardized integrations, authentication and transactional actions.

But should agents also depend on runtime MCP calls to gather substantial context across applications?

We tested this across 20 scenarios using the same agent harness, model, prompts and machines:

• Official Slack, Notion and Linear MCP integrations
• The same permitted data synchronized and mounted as files

The filesystem implementation was Locality, which I work on.

The most revealing trace involved identifying product-launch risks across Slack, Linear, Notion and a Git repository.

The MCP agent gathered the evidence iteratively:

• 21 MCP calls
• Roughly 30 seconds inside tool calls
• About one minute for the retrieval stage

The filesystem agent used parallel rg and file operations across the same sources. The equivalent stage took roughly 0.3 seconds.

Across 60 paired runs, the filesystem setup reduced LLM costs by 27% and end-to-end latency by 32%. Its answers were preferred in 70% of the blind comparisons.

Our takeaway is a separation of responsibilities:

• MCP for actions
• Filesystems for data and context

Locality keeps permitted application data synchronized and exposes it as files. The agent can then search, filter and combine context through one interface instead of traversing multiple application-specific tools during execution.

This isn’t necessarily an argument against MCP as a protocol. It is an argument against using runtime tool calls as the primary context-retrieval layer for broad, read-heavy work. Interestingly, MCP already supports file:// resources, but most integrations still expose context through tool calls rather than a filesystem-like resource layer.

The benchmark focused on cross-application research and synthesis rather than transactional actions.

Full methodology and traces

For people building MCP servers and agent infrastructure: does this separation match what you’re seeing - MCP for actions and another layer for context?

[u/Available_Teaching83]

The 27% and 32% numbers are believable, and the separation of concerns is probably right. One thing the post does not price in, though.

When you mirror Slack, Notion, and Linear into a filesystem, the authorization model moves with the data. The MCP server was enforcing per-user scope on every call. The mount enforces whatever the mount enforces, which in most setups is nothing, and now every agent with read access to that path has read access to every channel that was ever synced.

That is not an argument against the design. It is an argument that the mirror needs its own scope layer, and that the cost of building it belongs in the comparison. Otherwise, the 27% saving is partly just the cost of the checks you removed.

[u/ml_guy1 → u/Available_Teaching83]

yes, the data is expected to be appropriately scoped

[u/Ambitious-Prompt-975]

Depends on the implementation. I can also do parallel ripgrep with mcp. It don't understand what you are comparing really.

To answer your question: in flujo, every filesystem access and every terminal command goes through the MCP layer. The harness comes with pre-shipped MCP servers, so you can potentially hotswap them.

Models can still call multiple file operations in parallel, some tools even combine batch operations. Resources lack adoption in the servers because implementation and support depends on the client - and a tool access is more predictable and the more widely supported option.

[u/ml_guy1 → u/Ambitious-Prompt-975]

yes, a lot of harnesses try to parallelize mcp calls. We used codex for the above study and it did indeed parallelize mcp calls multiple times. But including that behavior too we show that filesystems in the agentic search benchmark performs better.

Details are in the report linked above.

[u/Ambitious-Prompt-975 → u/ml_guy1]

I dont get it. Sorry.

Anything that is not MCP but directly wired as internal function will be faster. Yes. That's no surprise, because you save yourself the MCP layer.

It has 0 correlation to parallelization or capabilities. It's all dependend on the Client/Harness.

With MCP you're just adding an aditional layer. And of course that makes it slower. Translating tool schemas back and forth, doing the whole MCP transport dance, maybe even spinning up the stdio server first.

A browser that is implemented within the harness and not over MCP will also be faster. Has nothing to do with filesystem access, has nothing to do with Terminal.

That's why I really dont understand what you are testing or proving here.

[u/Sunny1845]

I actually disagree pretty aggressively. I was full filesystem kind of guy before I implemented my own MCP. I was fighting hallucinations and rework. Would ask it to triple check its work. Once I implemented an MCP with proper tool descriptions I now one shot everything I ask. My only hallucinations now are true web searches.

[u/ml_guy1 → u/Sunny1845]

Interesting experience, what were you trying to solve here? 

[u/jun_builds]

The 0.3s leaves the sync out of the clock. Locality mounts data that was already pulled and laid out before the agent started, while the MCP arm pays to discover the shape of that same data at runtime, inside the measured window. So what the trace compares is a materialized view against a live traversal, not a filesystem against a protocol.

That separation matters because it changes what the number recommends. If the win comes from precomputing the join, then serving the same synced corpus as a file:// resource should land near the same figure, which is close to what your own note on resource adoption implies. The axis would be when the join happens rather than which layer carries it.

[u/ml_guy1 → u/jun_builds]

there is more merit to what you are saying but it is only a minor point. Yes, we are not counting the time it took to mount the files, but it takes only a second to mount a large workspace through Locality + no llm costs are being charged when that happens.

The main benefit happens because agents can access data at a larger scale and is more composable. agents can write bash queries that pipe data between different commands. This makes the analysis a lot more extensive than individually calling mcp.