Every few months a new acronym shows up promising to make AI agents more capable, and every few months integration teams have to work out whether it is a genuine architectural layer or just a rebrand of something we already had. MCP, Tools and Skills are not the same thing wearing different hats. They solve three different problems, and Kafka is a good platform to explain the difference on, because a Kafka deployment already forces you to separate concerns between infrastructure, operational knowledge and one-off actions.
The three layers, briefly
Tools are the oldest and simplest idea: give a model a JSON schema describing a function, and let it decide when to call that function. A describe_topic or get_consumer_lag call is a tool in this narrow sense. It works, but every tool is bespoke, wired up by hand, with no shared discovery mechanism between applications.
MCP (Model Context Protocol) standardises that wiring. Instead of hardcoding a function definition into your application, you stand up an MCP server that exposes a set of tools (and often resources and prompts) - topics, consumer groups, ACLs, broker metrics - and any MCP-aware client can discover and call them at runtime. It is the plumbing layer: predictable, schema-driven, and increasingly the way vendors expose their platforms to agents at all.
Skills are different again. A Skill is a folder with a markdown file and, optionally, scripts and reference material, describing how an expert would approach a task. Skills do not give a model new capabilities so much as they give it judgement: the sequence of checks a senior Kafka engineer runs before increasing partition count, or the diagnostic order for a consumer lag alert. Skills load progressively - a short description sits in context until the model decides the skill is relevant, then the full instructions load - which keeps the context window lean even with dozens of skills sitting idle.
Where each one earns its place with Kafka
Tools and MCP handle the deterministic, dangerous bits. Creating a topic, adjusting retention, resetting consumer group offsets, or rotating SASL credentials are all actions with clear inputs, clear outputs and real consequences if they go wrong. You want these behind a schema, with the same result every time given the same input, and ideally behind proper authentication rather than a static API key floating around in a prompt. If you have been through IBM Event Streams or Confluent-facing MCP tooling, this is exactly the pattern: an MCP server sitting in front of the Kafka Admin API, translating “increase the partition count on orders.v2 to twelve” into a validated admin call, not into a model improvising against the raw protocol.
Skills handle judgement and process. Kafka administration is full of decisions that are not simply “call this function.” Should this topic be compacted or time-retained. Is a lag spike a genuine problem or a benign batch catch-up window. What is the safe partition-increase procedure that will not break key-to-partition affinity for new messages when consumers rely on ordering guarantees. None of that is a single API call - it is a runbook, and a Skill is a natural home for that runbook, including the “do not do this on a Friday afternoon” wisdom that normally lives in a senior engineer’s head or a wiki page nobody reads.
Plain tools still matter for the small, local stuff. Not every action needs the ceremony of an MCP server. A function that parses a topic name against your organisation’s naming convention, or converts a retention period from a human phrase into milliseconds, is happy living as a simple tool definition with no protocol overhead.
A worked example
Picture an agent asked to “fix the lag on the payments consumer group.” A well-designed system routes this through all three layers. The Skill fires first, because the description matches “consumer lag” - it loads a short diagnostic playbook: check partition count versus consumer instance count, check for a recent deploy, check for a poison-pill message, check broker-side metrics before assuming the consumer is at fault. Following that playbook, the agent calls MCP tools to actually pull consumer group offsets, broker throughput and recent deployment history from wherever that is tracked. If the diagnosis points to under-provisioned consumers, a further MCP call scales the consumer group - a deterministic, auditable action with a defined schema, not a model freelancing kubectl commands.
Strip out any one layer and the picture degrades. Tools alone, with no MCP, means every Kafka integration is a one-off, unreusable outside the application it was built for. MCP alone, with no Skills, means the agent has perfectly good admin access and no idea when using it is a bad idea - it will happily “fix” lag by tripling partition count on a topic where that breaks consumer ordering guarantees, because nothing told it not to. Skills alone, with no MCP or tools behind them, is just a very well-written document that cannot actually touch the cluster.
The practical takeaway
For teams running Kafka - whether that is open source, Confluent, or IBM Event Streams as part of a Cloud Pak for Integration deployment - the sensible architecture treats MCP as the access layer to the platform, Skills as the accumulated operational wisdom about that platform, and plain tools as the connective tissue for anything too small or too local to justify a protocol server. None of the three replaces the others, and the arguments online about which one is “dead” tend to miss that they were never actually competing for the same job.