Hi @Forest Mars, this was a very thoughtful breakdown of MCPâs limits, especially around context bloat, registry sprawl, entitlements, and tool-selection overhead.
I agree that a CLI-first approach can be highly effective for localized, single-principal, discrete tasks. In fact, from a CodeSherlock.ai perspective, our code review/validation capability could often fit that model well.
But where Iâm less convinced is in broader agentic software-development workflows. We expose a small number of capabilities through our MCP Server, and in isolation those could be invoked via CLI. However, when multiple agents and MCP servers are orchestrated together across a development pipeline, planning, coding, validation, remediation, compliance, a pure CLI pattern can start to feel too local and too task-bound.
In that kind of workflow-centric environment, MCP seems to offer something CLI does not: a more composable, protocol-level way to participate in chained, multi-step agent interactions.
So the question I keep coming back to is: where is the middle ground?
Is the answer something like Code Mode MCP, where MCP remains the governance / entitlement / workflow envelope, while generated code or runtime execution handles the implementation layer underneath?
Said differently: for products like CodeSherlock that can be used both as a discrete validation tool and as part of a larger agentic development pipeline, do you see the future as:
CLI for local execution,
MCP for orchestration and trust boundaries,
Code Mode as the bridge between them? ( Disclaimer: I still need to understand fully how Code Mode works and is implemented, however I do get the general idea )
Iâd be curious how you think about that from an architectural standpoint.
@CodeSherlock. The âmiddle groundâ isnât a compromise between tool-calling and tool-generation. (That's the mistake Anthropic's PTC made which left the door open for Code Mode.) Itâs a separation of concerns. I had intended to make that clearer in my post; an early draft had a section entitled "Candide's Compromise" which made it more explicit.
The trust boundary in a multi-agent pipeline is exactly where the passport earns its keep. MCP handles the who. CodeSherlock stays a CLI tool. A **SKILL.md** teaches the agent to invoke it correctly inside the chain.
Code Mode generates the sandboxed invocation at runtime, zero schema overhead. Port of Context benchmarked this last week across 12 real Stripe tasks (nice timing, Iâd say): raw MCP burns 12 LLM turns where Code Mode burns 4, at 56% lower cost. Every extra turn is the registry doing the implementation layer's job. Itâs great to see someone provided the receipts.
The layer separation pays for itself. Your CFO goes home happy.
Hi @Forest Mars, this was a very thoughtful breakdown of MCPâs limits, especially around context bloat, registry sprawl, entitlements, and tool-selection overhead.
I agree that a CLI-first approach can be highly effective for localized, single-principal, discrete tasks. In fact, from a CodeSherlock.ai perspective, our code review/validation capability could often fit that model well.
But where Iâm less convinced is in broader agentic software-development workflows. We expose a small number of capabilities through our MCP Server, and in isolation those could be invoked via CLI. However, when multiple agents and MCP servers are orchestrated together across a development pipeline, planning, coding, validation, remediation, compliance, a pure CLI pattern can start to feel too local and too task-bound.
In that kind of workflow-centric environment, MCP seems to offer something CLI does not: a more composable, protocol-level way to participate in chained, multi-step agent interactions.
So the question I keep coming back to is: where is the middle ground?
Is the answer something like Code Mode MCP, where MCP remains the governance / entitlement / workflow envelope, while generated code or runtime execution handles the implementation layer underneath?
Said differently: for products like CodeSherlock that can be used both as a discrete validation tool and as part of a larger agentic development pipeline, do you see the future as:
CLI for local execution,
MCP for orchestration and trust boundaries,
Code Mode as the bridge between them? ( Disclaimer: I still need to understand fully how Code Mode works and is implemented, however I do get the general idea )
Iâd be curious how you think about that from an architectural standpoint.
@CodeSherlock. The âmiddle groundâ isnât a compromise between tool-calling and tool-generation. (That's the mistake Anthropic's PTC made which left the door open for Code Mode.) Itâs a separation of concerns. I had intended to make that clearer in my post; an early draft had a section entitled "Candide's Compromise" which made it more explicit.
The trust boundary in a multi-agent pipeline is exactly where the passport earns its keep. MCP handles the who. CodeSherlock stays a CLI tool. A **SKILL.md** teaches the agent to invoke it correctly inside the chain.
Code Mode generates the sandboxed invocation at runtime, zero schema overhead. Port of Context benchmarked this last week across 12 real Stripe tasks (nice timing, Iâd say): raw MCP burns 12 LLM turns where Code Mode burns 4, at 56% lower cost. Every extra turn is the registry doing the implementation layer's job. Itâs great to see someone provided the receipts.
The layer separation pays for itself. Your CFO goes home happy.
Thanks for the response Forest- will look into it further