What’s new in Postman: Kafka, MCP tests, RAML

Most systems don’t speak one protocol. A checkout flow might start with an HTTP call, publish an event to a Kafka topic, and end with an AI agent calling a tool on an MCP server. Testing that flow has meant a different client for each hop and a lot of glue in between.

This week we’ve shipped updates that bring those hops into one place. Kafka is now a request type in Postman, MCP requests support scripts and tests, and Spec Hub handles RAML 1.0 and OpenAPI 3.2. Here’s what changed and how to use each one.

Kafka in Postman

Apache Kafka is now a request type in Postman, turned on for every user. You can produce and consume messages, script and test them, and run Kafka requests in the same collection as the HTTP calls that trigger them. You don’t need a JVM, a framework or a self-hosted console.

Produce and consume from topics

When you produce a message, you set the key, the partition and the headers. When you consume, you choose where to start: the earliest or latest offset, a specific offset, or a timestamp. Bounded consume stops a read on its own, so a request finishes instead of waiting on the topic.

Connect to your cluster

Postman connects with SASL, AWS IAM or mTLS. Set authentication once at the collection or folder level and every Kafka request inside inherits it. Use the connection test before you send your first message.

Generate a Kafka collection from AsyncAPI

If you describe your events with AsyncAPI, you don’t have to build requests by hand. In Spec Hub, generate a Kafka collection from an AsyncAPI 2.x or 3.x spec. The collection stays in sync as the spec changes, and schemas map to topics so you can write contract tests against them. This also works in Local Mode.

Run Kafka next to HTTP

Add pre-request scripts and tests to produced and consumed messages, with variables, the Console and History. Agent Mode can write the scripts for you. The Collection Runner runs Kafka steps alongside HTTP and other protocols, with datasets, and values pass between steps. One run can call an API and then check the event it produced.

The same collection runs in your pipeline with the Postman CLI:

postman collection run 12345678-abcd-4e5f-9a0b-1c2d3e4f5a6b \
  --environment 98765432-staging

Kafka requests are free on every plan. Running Kafka in the Collection Runner or the Postman CLI is available on the Solo, Team and Enterprise plans.

Scripts and tests for MCP requests

If you build or depend on a server that follows the Model Context Protocol, you can now test it the way you test an HTTP API. MCP requests support scripts and tests on every plan, including Free and Consumption Pricing. Set up a connection, check what the server exposes, test each tool call, prompt and resource read, then run all of it in the Collection Runner next to your HTTP requests.

Four script hooks, in order

Four hooks run across an MCP session:

1. Before connect sets the URL, headers, auth or STDIO command, or skips the connection entirely.
2. After connect checks the server name, protocol version and capabilities, and confirms the tools you need exist with the input schemas you expect.
3. After response runs on each tool call, prompt and resource read. Check results, errors, structured content and response time, and save values for later calls. Edits apply on the next send, so you don’t reconnect.
4. After disconnect runs when the session closes.

Inherit scripts from a collection or folder

Add mcp:beforeConnect, mcp:afterConnect, mcp:afterResponse and mcp:afterDisconnect scripts once at the collection or folder level, and every MCP request inside inherits them. A shared connection check lives in one place instead of being pasted into each request.

Read the results by phase

The new Test Results tab groups a session’s tests into Connection, one group per call, and Disconnection. When a tool call fails, you see which phase it belongs to without scrolling through a flat list. In the Collection Runner, MCP requests run with their tests in the same run as HTTP and other Multiprotocol Requests, and they pass values between steps.

RAML 1.0 and OpenAPI 3.2 in Spec Hub

Two spec formats are now first-class in Spec Hub.

RAML 1.0

Teams with RAML APIs can design and manage them in Spec Hub and generate collections from them without converting to OpenAPI first. This ships in v12.34.4.

• Create a RAML 1.0 spec from the spec menu, or import RAML files and folders. Spec Hub finds the root file in a multi-file import on its own.
• !include and uses: libraries work, and supporting files can be .raml, .yaml, .yml, .json, .xsd, .xml, .md or .txt.
• RAML specs get the outline and validation pane.
• Generate a collection from the spec and sync spec changes to it.

A multi-file spec like this imports as is:

#%RAML 1.0
title: Orders API
version: v1
baseUri: https://api.example.com/{version}
uses:
  common: libraries/common.raml
types:
  Order: !include types/order.raml
/orders:
  get:
    responses:
      200:
        body:
          application/json:
            type: Order[]

RAML support is available on the Free, Solo, Team and Enterprise plans.

OpenAPI 3.2

You can also create and manage OpenAPI 3.2 specifications in Spec Hub on the Free, Solo, Team and Enterprise plans. Import your spec and author it with outline snippets, validation and live preview. Generate collections from the spec, or generate an OpenAPI 3.2 spec from a collection with two-way sync. Governance linting runs in the app or with the Postman CLI, so the same rules apply in your pipeline.

Multi-team domain capture across regions

Enterprise customers with Advanced Security Administration can now capture a domain to multiple teams across the US and EU. Add teams from the other region to a domain’s allowlist, and users whose email matches the domain can reach any allowed team in either region. Existing single-region, single-team and cross-region single-team setups behave as before. The feature routes users to the right team and doesn’t move their data.

Try it this week

• Import an AsyncAPI spec into Spec Hub, generate a Kafka collection, and add one test that checks a consumed message against its schema.
• Point an MCP request at a server you use, add an After connect script that checks for the tools you rely on, and run it in the Collection Runner next to your HTTP requests.
• Import a RAML project into Spec Hub and generate a collection from it.

Chain the three and you can follow one request from an HTTP call through a Kafka event to an MCP tool call, all in one run.

Resources

• Postman Docs
• Spec Hub overview
• The Postman CLI
• Apache Kafka documentation
• AsyncAPI documentation
• Model Context Protocol
• RAML 1.0 specification
• OpenAPI 3.2.0 specification