For AI agents to operate real-time data infrastructure safely, securely, and at scale, they need two things: a way to reach the platform, and the expertise to use it correctly. We've been writing about that picture for a year, and shipping it for almost as long. The connectivity half is now done.
The StreamNative MCP Server gave AI agents typed access to Apache Pulsar and Apache Kafka through the Model Context Protocol. snctl 1.0 collapsed our legacy CLIs into one unified developer surface for StreamNative Cloud, and a point release after that folded the MCP server back into the CLI so snctl mcp stdio starts a fully-configured agent endpoint with a single command. In February, we announced the Public Preview of the StreamNative Remote MCP Server — a managed, hosted endpoint that any organization can enable from the Console, with no local installation required. Across local and remote modes, any compatible agent can now reach StreamNative Cloud through MCP.
We're launching StreamNative Agent Skills — seven official agent skills that teach any agent skills compatible AI agent how to operate StreamNative Cloud through snctl or MCP server. If our MCP work gave your agent connectivity to Apache Pulsar and Apache Kafka on StreamNative Cloud, Agent Skills give your agent the expertise to use that connectivity correctly the first time.
Turning coding agents into streaming experts
What we learned in the months that followed is the lesson every data-infrastructure team learns once it actually puts an agent in front of a customer environment: connectivity is necessary, but it is not sufficient. Agents are remarkably fluent in code, and remarkably ignorant of the platform-specific patterns that separate a working stream from a 3 AM page. We watched four kinds of mistakes recur, across the agents our engineering team built internally and the ones our customers were running against the MCP servers:
- Wrong instance kind. A user asks for a Kafka cluster. The agent reaches for Pulsar resources because it knows StreamNative is a Pulsar company. But Kafka clusters on StreamNative Cloud are governed by a different top-level kind — the new shared Instance resource introduced alongside our API Key V2 service contexts — with a different controller and different admission rules.
- Missing feature gates. The agent confidently runs
snctlcreate kafkacluster against an organization that doesn't have API Key V2 enabled, and gets a cryptic admission error. There is no way for the agent to know, from snctl's help alone, that KafkaCluster admission requires the Instance feature flag and the API Key V2 organizational feature both flipped on. - Missing manifest fields. The agent writes a KafkaCluster YAML by hand and omits spec.poolMemberRef.
snctlcreate kafkacluster would have resolved the pool member from --location automatically — but a raw apply-fwon't, and admission rejects the manifest. - Skipping the BYOC substrate. A user says "set up BYOC against my AWS account." The agent races to create a Pulsar instance of type byoc before any
CloudConnection,CloudEnvironment, or pool member exists in the org — the operator-managed substrate that BYOC clusters are bound to. The instance never reaches Ready, and nobody knows why.
These are not bugs in snctl. They are the predictable consequence of asking a generalist agent to operate a platform whose admission rules, deployment-type branches, and prerequisite checks have evolved over years of customer experience. Agents are generalists by design; they don't inherently know the best practices and design patterns that real-world production systems demand. Connectivity gave them a door into StreamNative Cloud. What they need next is a map of the building.
Scaling agentic engineering on streaming infrastructure
StreamNative Agent Skills is our answer. Seven domain skills, fifty-five guided workflows, thirty-six reference docs, twenty-two starter YAML manifests, and eight end-to-end smoke walkthroughs — each packaged as a self-contained agentskills bundle and distributed as the streamnative-agent-skills plugin.
Every manageable resource kind is owned by exactly one skill:
| Skill | Workflows | Covers | Activates on |
|---|---|---|---|
| cloud-core | 7 | Install, auth, config, context, API resources, logs | "install snctl", "log in", "switch org" |
| byoc-infrastructure | 6 | Cloud connections, environments, tiered-storage volumes | "BYOC", "my AWS/GCP/Azure account", "VPC CIDR" |
| pulsar-clusters | 6 | Pulsar instance / cluster / gateway across serverless, dedicated, BYOC, BYOC Pro | "create cluster", "PulsarInstance", "scale brokers" |
| kafka-clusters | 7 | Kafka Instance / KafkaCluster across dedicated, BYOC, BYOC Pro, AuthV2 contexts | "KafkaCluster", "throughput unit", "Kafka service context" |
| identity | 7 | Users, service accounts, roles, API keys, secrets, OIDC, identity pools | "grant access", "API key", "OIDC", "federated login" |
| pulsar-admin | 8 | Tenants, namespaces, topics, subscriptions, Pulsar Functions | "tenant", "namespace", "topic", "produce/consume" |
| kafka-admin | 7 | Kafka topics, groups, partitions, Schema Registry, Kafka Connect | "Kafka topic", "consumer group", "schema registry" |
With the plugin installed, you don't pick a skill — the right one activates automatically from the description match. The same natural-language requests that previously needed a human translator now route end-to-end:
- "Create a serverless Pulsar instance named events in us-east-1."
- "Give me a service account with admin access and export its key."
- "Create a 3-partition Kafka topic user-events and produce 10 test messages."
- "Set up BYOC to my AWS account 123456789012 with a VPC in eu-west-1."
- "Deploy a Pulsar Function from word-count.jar that reads from topic in and writes to out."
Each of those prompts maps to a different owning skill, and each skill ships a deployment-type decision tree, a prerequisite check, and the exact snctl workflow that ends in a Ready resource. When a Kafka cluster request hits an org without API Key V2 enabled, kafka-clusters skill catches it before admission does. When a BYOC request arrives without a cloud connection, kafka-clusters or pulsar-clusters skill knows to open byoc-infrastructure first, lay the substrate, and then circle back. The skill does the platform reasoning the agent can't do on its own.
Skills give your agent expertise; MCP gives it actions
The most important thing to understand about Agent Skills is what they are not: they are not a new API surface. The StreamNative Remote MCP Server already gives your agent typed actions — schema-backed function calls for Kafka, Pulsar, and the StreamNative Cloud control plane, hosted and ready to enable from the Console. Agent Skills give your agent expertise — when to call which action, with which flags, in which order, for which deployment type, with which prerequisites checked first. MCP answers whether the agent can do something. Skills answer whether it should, and how.
Skills don't grant any new permissions; they make agents use the permissions they already have correctly. The skill body loads only when the agent's request matches the skill's description, and reference files load only when the body points to them — progressive disclosure that keeps the token cost of "create a Kafka topic" closer to a hundred tokens than a hundred thousand. Agent Skills compose with whatever other agentskills bundles your team already runs: the streaming-platform skills activate when the request points at streaming, and stay out of the way the rest of the time.
How to get started
The fastest path is the Claude Code plugin:
/plugin marketplace add streamnative/streamnative-agent-skills
/plugin install streamnative-agent-skills
That registers all seven skills at once. For any other agentskills-compatible runtime — Cursor, Gemini CLI, OpenCode, Goose, Codex — clone the repository and point your agent at the relevant skills/<name>/ directory:
git clone https://github.com/streamnative/streamnative-agent-skills.git
Each skills/<name>/ directory is a self-contained agentskills package — you can install the full set or copy a single skill into your tool's skills directory if you only need, say, kafka-admin.
Prerequisites depend on how your agent connects. StreamNative Cloud skills support both execution paths: the snctl CLI and the StreamNative Cloud remote MCP server.
With snctl, install the CLI (curl -fsSL https://downloads.streamnative.cloud/snctl/install.sh | sh or brew install streamnative/streamnative/snctl), authenticate with snctl auth login for interactive use or snctl auth activate-service-account --key-file <key.json> for automation, and select the target organization.
With remote MCP, connect your agent runtime to the StreamNative Cloud MCP server and enable the required access in StreamNative Cloud. Org-level MCP covers organization/session context, resource discovery, schemas, and control-plane operations. For Pulsar and Kafka data-plane work, the same org-level session can switch to a target cluster with sncloud_context_available_clusters and sncloud_context_use_cluster; the target cluster must have cluster-level MCP enabled. Fixed cluster-level MCP endpoints are also supported when you want the agent pinned to a single cluster.
The cloud-core skill understands both routes. It verifies the available path first (snctl auth whoami for CLI, sncloud_context_whoami for MCP), guides the user through any missing prerequisites, and falls back to snctl when a workflow isn't yet covered by MCP.
This launch closes out the second beat of the agentic data-infrastructure story we started with the Remote MCP Server. The third — tighter integration with the Orca Agent Engine, so that agents running on StreamNative can use these same skills to operate the streams they're built on top of — is already in motion. We'll have more to share soon.
Until then: ship faster, more reliable streaming apps with StreamNative Agent Skills. Install the plugin for Claude Code, Cursor, Gemini CLI, OpenCode, Goose, or Codex, browse the skills on GitHub, and tell us what your agent should have known. The era of agentic streaming infrastructure is just beginning — let's build it together.
