Postman Now Lets You Test MCP Servers Before Handing Them to AI Agents
Quick Reads
- Postman’s MCP client connects directly to MCP servers over STDIO or Streamable HTTP
- jhipster-mcp is an official, open-source MCP server that exposes JHipster to any MCP client
- The server ships 13 tools, three ready-made prompts, and live project-state resources
- Developers can test each tool with real JSON-RPC, no AI agent or token burn required
- The workflow: connect, call, fix, rebuild, reconnect, fast and repeatable
AI agents are getting better at understanding developer intent. However, turning that intent into a correctly generated Spring Boot application, every single time, is a different challenge. That gap is exactly where the Model Context Protocol (MCP) and a mature CLI tool like JHipster meet, and where Postman now earns a place in the workflow.
Postman published a walkthrough this week showing how developers can test MCP servers in Postman using jhipster-mcp, an official MCP server maintained under the JHipster GitHub organization. The approach matters because MCP tooling is still young, and testing tools before wiring them into production or CI is simply good practice.
MCP is an open standard that allows AI applications to call external tools in a structured way. An MCP server advertises three kinds of capabilities: tools (callable functions), resources (readable data), and prompts (reusable templates). The wire format is JSON-RPC 2.0, so every call produces a predictable request and response, no free-form guessing.
JHipster, on its own, scaffolds production-grade Spring Boot applications with Angular, React, or Vue frontends. Developers describe a domain in JDL (JHipster Domain Language), and the generator writes the entities, REST resources, repositories, database changelogs, and tests. No boilerplate by hand. jhipster-mcp, therefore, becomes the bridge, letting an agent generate and evolve a real project through a stable set of tools.
The server exposes 13 tools covering the full project lifecycle. These include validate_jdl, create_app_from_jdl, add_entity, generate_ci_cd, generate_deployment, and an upgrade_advisor. Beyond tools, it ships three built-in prompts, scaffold_crud_monolith, add_audit_fields, and monolith_to_microservices, alongside live resources like the project’s .yo-rc.json config and an exportable JDL file. Notably, a JDL grammar cheat-sheet is also included as a resource. Handing it to an agent upfront means the agent writes valid JDL on the first attempt, not after several correction loops.
The design also leans on safety. Each operation runs sandboxed to a specific directory, with guardrails that stop the server from writing outside expected project folders. There is no arbitrary shell access, input is validated against JDL injection, and dry-run behavior runs in isolation so nothing touches a working file tree.
This is precisely where Postman’s MCP client becomes useful. Rather than pointing an AI agent at the server and waiting, burning tokens on every exploration loop, Postman connects directly to the MCP server over STDIO, lists every tool, prompt, and resource, and lets developers call each one with full argument control. The raw JSON-RPC response appears on screen. No agent summary, no retry guessing. Postman announced full MCP support earlier this year, and this workflow is a practical demonstration of what that means.
To connect, developers clone the jhipster-mcp repo, run npm install and npm run build, then open a new MCP request tab in Postman. Setting the transport to STDIO and pointing it at the absolute path of dist/index.js is all it takes. After a successful handshake, the Tools, Prompts, and Resources tabs populate automatically.
From there, testing starts with the safest tool: validate_jdl. A small JDL snippet, say, a two-entity bookstore with a Book and Author, goes in as an argument. Postman sends a tools/call message and returns a structured response with a success flag, the resolved entity list, and a filesChanged array. That machine-readable shape is a deliberate design choice in jhipster-mcp, and it shows immediately when reading results in Postman instead of a terminal scrollback.
The development loop itself is equally tight. After editing the server, adding a new prompt, for example, a rebuild with npm run build followed by a reconnect in Postman immediately reflects the change. New prompts show up in the Prompts tab. No agent session needed, no token cost.
A few practical notes worth knowing: always use an absolute path to dist/index.js in the STDIO command, since a relative path resolves against Postman’s working directory and the capability tabs stay empty. Also, reading the warnings array in the tool response matters as much as checking the success flag. A successful exit code only means the command ran, missing environment dependencies, like Docker Compose or a Java runtime, surface in that array.
jhipster-mcp is open source under the Apache-2.0 license and welcomes contributions. The repository includes open issues, a docs/ROADMAP.md, and nine documentation chapters covering tools, resources, prompts, and internals. Developers can also join the Postman Discord community to compare notes on MCP usage and share collections.
For teams evaluating MCP tooling, the approach separates two concerns cleanly: is the tool correct, and is the agent using it well? Postman answers the first question. The agent handles the second.
