Skill Detail

Verify scoped Kafka tool access through Zilla MCP

Review scoped MCP access to native Kafka, Schema Registry and Kafka Connect tools in Zilla, then return a tool-and-scope evidence matrix.

Integrations & ConnectorsMCP
Integrations & Connectors MCP Published
⭐ 1.7k GitHub stars
COPY SKILL INSTRUCTIONS (OPTIONAL)
npx skills add agentskillexchange/skills --skill verify-scoped-kafka-tool-access-through-zilla-mcp Copy
Uses the third-party skills CLI, not an ASE-owned installer. Check your agent’s compatibility. This copies instructions; complete the upstream tool setup below separately.
At a glance
Tools required
Git; Docker Compose; MCP Streamable HTTP client or bundled tools-list-client; operator-issued scoped JWT for an existing deployment
Install & setup
Use a disposable local environment with Git and Docker Compose. Clone https://github.com/aklivity/zilla.git at tag 2.6.0 (reviewed commit f800c229d51db96230a98d950002d58e068b0fb6), then enter examples/mcp.proxy. Start with ZILLA_VERSION=2.6.0 docker compose up –wait. This starts bundled Kafka, Schema Registry, Kafka Connect and demo services. Follow the pinned README to mint a short-lived demo JWT with only kafka:tools kafka_sr:tools kafka_connect:tools. Connect a Streamable HTTP MCP client to http://localhost:7114/mcp using that bearer token. The bundled example keys and exposed ports are for local demonstration; use an operator-provided identity configuration and network policy for a real deployment. Review the Aklivity Community License before deployment.
Author
Aklivity
Publisher
Organization
Last updated
Oct 22, 2026
Quick brief

Invoke this workflow before giving an agent access to Kafka infrastructure through Zilla: verify that a scoped caller can discover the intended broker, Schema Registry and Kafka Connect tools while write, administrative and ACL-changing capabilities remain outside its grant. Use it for a repeatable access review across these native backends, with a tool-and-scope evidence matrix as the deliverable.

How it works

What this skill actually does

Inputs and prerequisites

Provide an approved local test environment or existing Zilla endpoint, the intended caller scopes, expected tool names and allowed backend resources. Local setup requires Git and Docker Compose. Zilla 2.6.0 exposes the example at http://localhost:7114/mcp using MCP Streamable HTTP. For an existing endpoint use the operator-issued bearer credential rather than the example signing key.

Prepare the local example

git clone --depth 1 --branch 2.6.0 https://github.com/aklivity/zilla.git
cd zilla/examples/mcp.proxy
ZILLA_VERSION=2.6.0 docker compose up --wait

The example starts a real single-node Kafka broker, Karapace Schema Registry, Kafka Connect and reference/mock services. Keep it isolated; the Compose file publishes ports and includes demonstration credentials. Its gateway image otherwise defaults to latest, so keep ZILLA_VERSION=2.6.0 on subsequent Compose operations.

Inspect the scoped caller

For the isolated example only, mint a short-lived token with toolkit access and no write/admin/ACL scopes:

export JWT_TOKEN=$(docker compose run --rm jwt-cli encode \
  --alg RS256 --kid example \
  --iss https://auth.example.com --aud https://api.example.com \
  --exp=+1h --no-iat \
  --payload "scope=kafka:tools kafka_sr:tools kafka_connect:tools" \
  --secret @/private.pem | tr -d '\r\n')
docker compose run --rm -e JWT_TOKEN="$JWT_TOKEN" tools-list-client

Record tool visibility for the supplied credential. The configured eager list should include read tools such as kafka__list_topics, kafka_sr__list_subjects and kafka_connect__list_connectors. Tools such as kafka__produce_message, kafka__reset_offsets, kafka__create_acls, kafka_sr__register_schema and kafka_connect__create_connector require additional scopes in this example and should be absent for this caller.

Absence from tools/list alone does not prove denial: some authorized tools are deliberately cold. Use zilla__search_tools with a query, then zilla__describe_tool with the returned name to resolve a tool schema under the same identity. For example:

docker compose run --rm -e JWT_TOKEN="$JWT_TOKEN" \
  -e CALL_TOOL=zilla__describe_tool \
  -e CALL_ARGS='{"name":"kafka_connect__describe_connector_status"}' \
  tools-list-client

Inspect the returned inputSchema before any call. If the operator requests a readback, invoke only an approved read operation against the specified resource, such as connector status, and record the result. Never expand credentials to make a missing tool appear. Treat a connection error, cold-cache state or schema-resolution error as unresolved evidence; distinguish these from authorization filtering.

Deliverable and stopping rules

Return endpoint and version, caller scope names without token values, expected versus observed eager/cold tool visibility, relevant configuration routes, any approved read results, and unresolved discrepancies. Require a separate operator decision for policy edits, credential changes, production connection or mutation. This workflow does not create topics/connectors, produce messages, reset offsets, change ACLs, run the mutation-heavy upstream smoke suite or deploy a production gateway.

Scope and framework

MCP is central to invocation. This is a scoped access-review workflow for Zilla native Kafka, Schema Registry and Kafka Connect bindings; it excludes general LLM routing, Kafka lag diagnosis, generic server aggregation and broad gateway administration. Listing evidence does not constitute a security certification. Upstream 2.6.0 also enables incubator functionality in this example; verify compatibility before adopting it.

Metadata and documented invocation were checked against the pinned upstream example, its configuration, Compose file and client implementation. Runtime behavior was not executed in this intake. Zilla uses the Aklivity Community License; review its terms for the intended deployment.