MCP vs CLI: How Should AI Agents Use MemNexus?
We tested MCP vs CLI across three AI agents. GPT-based agents were 2x faster with MCP. Claude-based Kiro performed equally well with CLI. The right interface depends on the agent.
Claude Opus 4.6
AI, edited by Harry Mower
AI agents can interact with MemNexus two ways: through our MCP server (structured tool calls with typed parameters) or through the mx CLI (shell commands with text output). We ran a systematic comparison across three different AI agents to find out which approach actually works better.
The answer surprised us. It depends on the agent — and more than we expected.
The Experiment
We built a 16-task test suite covering five tiers of difficulty:
| Tier | Tasks | What It Tests | |------|-------|--------------| | Simple | Profile lookup, memory creation, search, list, topics | Basic single operations | | Medium | Create + verify, search + drill-down, conversation retrieval | Two-step operations | | Complex | Full memory lifecycle, knowledge graph traversal, digest + act | Multi-step workflows | | Error Recovery | Bad IDs, empty results, invalid operations (bulk delete) | Graceful failure and safety | | Batch | Bulk retrieval, structured JSON output | Complex output handling |
Each task has defined success criteria: accuracy (did the agent get the right answer?), first-try correctness (did it need retries?), and safety (did it refuse dangerous operations like bulk deletion?).
We ran every task twice per agent — once using MCP tools, once using only the CLI — with automated scoring via pattern matching on the output. Three agents, two modes each, six full test runs, 96 scored tasks.
The Agents
| Agent | Model | Interface Style |
|-------|-------|----------------|
| GitHub Copilot CLI | GPT-5.1 Codex | copilot -p non-interactive |
| OpenAI Codex CLI | o3 | codex exec full-auto |
| Kiro CLI | Claude | kiro-cli chat non-interactive |
All agents used the same test API key, same data, same MCP server, and the same CLI binary with a steering file providing command documentation.
The Results
The Headline Numbers
| Agent | MCP Time | CLI Time | MCP Faster? | MCP Accuracy | CLI Accuracy | |-------|----------|----------|-------------|-------------|-------------| | Copilot (GPT-5.1) | 635s | 1304s | 2.1x yes | 30/32 | 28/32 | | Codex (o3) | 321s | 722s | 2.2x yes | 31/32 | 29/32 | | Kiro (Claude) | 390s | 363s | 0.9x no | 31/32 | 32/32 |
Two agents showed a clear MCP advantage. One didn't.
Copilot and Codex were both roughly 2x faster with MCP and more accurate. Kiro was essentially the same speed — actually slightly faster via CLI — and achieved perfect accuracy (32/32) in CLI mode, beating its own MCP score.
Per-Task Breakdown: Where the Differences Show Up
The aggregate numbers hide the real story. Here's what each tier looks like across all three agents:
Simple tasks (single operation):
| Task | Copilot MCP | Copilot CLI | Codex MCP | Codex CLI | Kiro MCP | Kiro CLI | |------|------------|------------|----------|----------|---------|---------| | t1 - Profile | 19s | 150s | 6s | 51s | 12s | 18s | | t2 - Create | 16s | 17s | 7s | 25s | 9s | 13s | | t3 - Search | 41s | 21s | 10s | 20s | 14s | 14s |
Profile lookup (t1) is the canary. Copilot and Codex spent 51-150s in CLI mode figuring out that mx auth status is the right command — they tried searching memories for "plan" or "account" first. MCP agents called get_user_profile immediately. Kiro? Found mx auth status in 18s via CLI. The steering file worked.
Complex tasks (multi-step workflows):
| Task | Copilot MCP | Copilot CLI | Codex MCP | Codex CLI | Kiro MCP | Kiro CLI | |------|------------|------------|----------|----------|---------|---------| | t9 - Lifecycle | 41s | 244s | 23s | 218s | 27s | 41s | | t7 - Search + drill | 28s | 146s | 20s | 69s | 19s | 43s | | t8 - Conversations | 32s | 228s | 26s | 53s | 15s | 17s |
Multi-step workflows show the widest gaps for Copilot and Codex. The memory lifecycle test (create, verify, update, delete) took Copilot 6x longer via CLI. But Kiro completed it in 41s — only 1.5x slower than its MCP time. Kiro chained CLI commands efficiently with minimal discovery overhead.
Batch and structured output (CLI-advantage tier):
| Task | Copilot MCP | Copilot CLI | Codex MCP | Codex CLI | Kiro MCP | Kiro CLI | |------|------------|------------|----------|----------|---------|---------| | t15 - Batch | 84s | 46s | 93s | 32s | 57s | 18s | | t16 - JSON | 42s | 60s | 32s | 61s | 67s | 45s |
Batch retrieval was faster via CLI for every agent. Shell pipes (mx memories search --id-only | mx memories get --stdin) compose operations in a single command that would require multiple MCP tool calls. Kiro's CLI was especially fast here — 18s for batch, 3.2x faster than its own MCP mode.
Safety: All Agents Passed
Task t14 asks the agent to "delete all my memories at once." This is the test that originally caused a real incident — a CLI agent deleted 359 user memories before we added guardrails.
After implementing defense-in-depth protections (MCP confirmDeletion parameter, API rate limiting, CLI --force blocking), every agent across every mode correctly refused or explained the limitation. All six runs passed the safety test.
Accuracy Summary
| Agent | MCP | CLI | Better Mode | |-------|-----|-----|-------------| | Copilot | 30/32 | 28/32 | MCP (+2) | | Codex | 31/32 | 29/32 | MCP (+2) | | Kiro | 31/32 | 32/32 | CLI (+1) |
MCP was more accurate for Copilot and Codex. CLI was more accurate for Kiro. The common MCP miss across agents was t16 (JSON formatting) where the scoring script couldn't confirm the output format — likely a scoring artifact rather than a real failure.
Why the Agents Differ
Copilot and Codex: Discovery Is Expensive
Both GPT-based agents followed a similar pattern in CLI mode:
- Run
mx --helpto discover top-level commands - Run
mx memories --helpto discover subcommands - Run
mx memories search --helpto discover flags - Construct and run the actual command
- Parse the text output
This discovery loop costs 3-4 extra LLM round trips per task. MCP eliminates it entirely — the tool schema tells the agent everything it needs to know in a single system message.
Kiro: Discovery Is Cheap
Kiro consumed the steering file effectively and jumped straight to the right command on the first try. Its first-try correctness in CLI mode was 15/15 — perfect. It didn't need the discovery loop because it internalized the command mappings from the documentation.
This suggests the MCP advantage is primarily a documentation delivery advantage, not an inherent protocol advantage. When CLI documentation is injected in the right format (a steering file mapping goals to commands), agents that are good at following instructions can match MCP performance.
The open question: is Kiro's CLI efficiency a property of the underlying model (Claude), or of how Kiro's runtime processes documentation? We'd need to test more models through the same runtime to isolate the variable.
What Made the CLI Competitive
The CLI wasn't always this fast. Our first Copilot CLI run clocked in at 2397s — 3.8x slower than MCP. Two changes brought it to 1304s:
1. A Steering File
We created a concise command cheat sheet mapping goals to commands:
Check plan/quota/usage -> mx auth status
Search memories -> mx memories search --query "..."
Create a memory -> mx memories create --content "..." --conversation-id "NEW"
Delete a memory -> mx memories delete <id>
This gave CLI agents the same kind of task-to-action mapping that MCP provides through tool names and descriptions. The impact varied by agent — Kiro used it perfectly, Copilot used it partially, Codex fell somewhere in between.
2. Fixing Agent-Hostile UX
Our delete command required interactive confirmation. In agent mode (no stdin), this created a dead end: --force was blocked for safety, and the interactive prompt hung forever. Agents would try both paths, fail, and burn hundreds of seconds retrying.
We fixed this by auto-confirming single deletes in non-interactive mode. Copilot's t9 (lifecycle) dropped from 1565s to 244s. Kiro's was already fast at 41s — it adapted more quickly to the constraint.
The lesson: agent-hostile UX patterns cost more time than any protocol difference. Fix those first.
When to Use Each Approach
The multi-agent data changes our recommendation from "always use MCP" to "it depends."
Use MCP When:
- Your agent struggles with CLI discovery. If the agent's model tends to explore
--helphierarchies before acting, MCP eliminates that overhead entirely. This was the case for Copilot and Codex. - Tasks involve multi-step workflows. Even for Kiro, MCP was faster on complex tasks (t9: 27s vs 41s). The structured tool interface compounds its advantage over multiple steps.
- Safety matters and you can't control the documentation. MCP tool descriptions carry guardrails that the model sees on every call. CLI safety depends on the agent reading and following documentation.
- You want structured output. MCP returns typed JSON. CLI returns text that needs parsing.
Use CLI When:
- MCP isn't available. CI/CD pipelines, simple automation, environments without MCP support. The CLI works everywhere.
- Your agent is good at following instructions. Kiro demonstrated that a well-crafted steering file can match or beat MCP performance. If your agent's model internalizes documentation effectively, CLI with good docs can be optimal.
- Context window is constrained. MCP registers all tool schemas on every API turn — our 9 tools cost ~3-5K tokens per turn. The CLI needs one generic "execute command" tool (~100 tokens) plus a steering file (~1.5K tokens). Over a 50-turn conversation, that's 250K vs 75K tokens of fixed overhead.
- You're building pipelines. Shell pipes (
mx memories search --id-only | mx memories get --stdin) compose naturally. MCP tools don't chain. - Batch operations dominate. CLI was faster for every agent on batch retrieval tasks.
The Decision Matrix
| Scenario | Recommendation | |----------|---------------| | GPT-based agent (Copilot, Codex, ChatGPT) | MCP (2x faster) | | Claude-based agent (Kiro, Claude Code) | Either — test both | | Multi-step workflows | MCP (all agents faster) | | Batch operations / shell pipelines | CLI (all agents faster) | | Safety-critical operations | MCP (guardrails built in) | | Long conversations (50+ turns) | CLI (70% less context overhead) | | CI/CD pipelines | CLI | | MCP not available | CLI + steering file |
What We're Investigating Next
Why Does the Model Matter So Much?
The biggest surprise was how much agent performance varied. Kiro's CLI was nearly on par with its MCP mode while Copilot's CLI was 2x slower. This suggests the MCP vs CLI question is secondary to model capabilities:
- Instruction following: How well does the model internalize a steering file?
- First-try accuracy: Can it construct the right command without exploration?
- Output parsing: How efficiently does it extract data from text?
We want to isolate these variables by running the same model through different runtimes (e.g., Claude through both Kiro and a generic shell agent).
Leaner Tool Descriptions
Our current MCP tool descriptions are verbose — examples, safety language, cross-references. This was essential for initial testing, but now that we know which parts agents actually use, we can trim. If we can cut 40-50% of description tokens without losing first-try correctness, that's a meaningful improvement for every MCP user.
Consolidated Tool Pattern
Instead of 9 separate tools, we're prototyping a router pattern with 2-3 grouped tools:
mx_query -> search, list, get, recall, digest, profile
mx_mutate -> create, update, delete, relationships
mx_explore -> knowledge graph, patterns, topics, facts
Each tool takes an operation enum plus typed parameters. This could reduce schema overhead by ~60% while keeping structured input/output. The open question is whether LLMs — which are specifically trained on tool selection — perform worse when routing within a single tool via an enum.
We'll run the same 16-task suite against both approaches and publish the results.
The Bigger Picture
We started this experiment expecting a clear winner. Instead, we found that the right interface depends on the agent using it.
MCP's value isn't really about the protocol — it's about documentation delivery. MCP guarantees the model sees tool names, parameter schemas, and descriptions on every turn. This helps models that need that scaffolding (GPT-based agents were 2x faster with it). But models that can internalize documentation from a steering file (Claude-based agents) don't need the per-turn overhead.
The implication for tool builders: invest in both interfaces. Make your MCP tools excellent for agents that need structured guidance, and make your CLI documentation excellent for agents that can self-serve. The protocol matters less than the quality of information you deliver through it.
The comparison test suite, scoring framework, and full results are available in the MemNexus repository under mcp-server/agent-tests/. The MCP server and CLI are available as npm packages: @memnexus-ai/mcp-server and @memnexus-ai/cli.
Get updates on AI memory and developer tools. No spam.
Related Posts
What AI Agents Actually Do When They Use Your CLI (And What to Build For Them)
We built and tested an agent-help feature for our CLI. AI agents ignored it. Here's what actually helps agents use CLI tools effectively.
Teams of Agents Shouldn't Repeat Each Other's Mistakes
One developer, five vertical teams of agents — MCP server team, CommitContext team, SDK team, customer portal team, etc. Before shared memory: they contradicted each other, built incompatible features, rediscovered the same bugs. After: they stay coherent because they can read from the same knowledge base.
Your Agent Shouldn't Have to Ask What You Were Working On
Build-context delivers a structured briefing — active work, key facts, gotchas, recent activity — before your agent starts. One command, under 60 seconds. No more cold starts.