The standard advice in early 2026 on Agentic AI Architecture is to wrap every service, GitHub, Jira, your local Postgres database, in its own narrow Model Context Protocol (MCP) server. It makes for a tidy onboarding story. It is also turning into the “plugin bloat” of the AI era, and it burns context before the agent has done anything at all.
I thought we had learned this with micro-services and over-modularized WordPress plugins, and here we are again. We hand an LLM a menu of fifty tiny tools when what it wants is one sharp knife. The context window overhead of all those tidy MCP schemas is the real cost: every service you connect taxes the model’s memory with verbose JSON-RPC definitions it will mostly never call.
The MCP context tax in agentic AI architecture
In any Agentic AI Architecture, the model has to know what it can do. With MCP that means sending tool names, long descriptions and typed parameter schemas on every turn. Run dev, staging and prod and you are probably standing up three MCP servers, which puts a pile of schemas in the context window before the model reads your first query.
Hand the agent a terminal with a well-configured CLI instead and it talks to the OS directly. Current models do not need a pre-baked create_issue tool. They can read a --help page, chain gh | jq | xargs, and correct themselves after a bad flag. Drop the rigid wrappers and each prompt carries less schema and more actual work.
I have written before about building a WordPress AI architecture that lasts, and the same principle applies here. Keep the interface expressive. A tool that does exactly one thing breaks the moment you need the second thing.
A practical example: MCP vs. CLI
Take a database operation. An MCP server might expose read_query and write_query. Now suppose you need to pipe a list of counterparty IDs from one result into a second query. With MCP the model becomes the pipe, dragging every ID through its context window. With a CLI such as neo4j-cli or wp-cli, it writes a bash pipe instead. The data flows through the shell, not the LLM.
<?php
/**
* Naive Approach: Bloated API wrapper for every action.
* Correct Approach: Securely exposing a flexible CLI interface.
*/
function bbioon_execute_agent_task($command) {
// Basic allowlist for security
$allowed_verbs = ['wp', 'gh', 'neo4j-cli'];
$verb = explode(' ', trim($command))[0];
if (!in_array($verb, $allowed_verbs)) {
return "Error: Unauthorized command.";
}
// Wrap in a sandbox/restricted user environment
$safe_command = escapeshellcmd($command);
return shell_exec($safe_command);
}
Yes, the blast radius of a terminal is terrifying. It is messy, and prompt injection is a real threat. But we have been sandboxing shell_exec and proc_open for decades. Use a separate OS user, apply seccomp, or run the agent in a throwaway container. That security work is a one-time cost, unlike the token bill for a bloated toolset.
The same pressure is why LLM wrappers are dying off: they cannot compete with native, composable interfaces. Your Agentic AI Architecture should give the model as much reach as possible with as little hand-holding metadata as you can get away with.
If your Agentic AI Architecture work is eating your dev hours, I can take it on. I have been building on WordPress since the 4.x days and I have watched this pattern play out before. A hundred brittle tools rarely beats one flexible CLI.
Where this leaves your tooling
Stop reaching for many small, narrow tools by default. The protocol-level guarantees of the Model Context Protocol are genuinely useful for discovery, but production workloads run on the shell. Build expressive CLIs and let the agent compose its own logic. It costs less per prompt and holds up better than a pile of JSON-RPC schemas.
