TL;DR: PraisonAI shipped praisonai-mcp v0.0.2, the full-featured MCP server host in their package family. The write-up's real value is clarifying that there are *three* separate MCP layers in this ecosystem (client, light server, heavy host) that people keep conflating, plus a genuinely solid auth/security section (OAuth 2.1 + PKCE, scoped API keys, default-deny tool lists on the recipe bridge).

The three-layer confusion this actually solves

If you've touched PraisonAI's MCP tooling before, you've probably hit this: multiple packages expose an mcp subcommand or similar-looking functionality, and it's not obvious which one you're actually running. The article lays it out plainly:

- Client — praisonaiagents/mcp/, connects your agents *out* to external MCP servers, handles OAuth token storage. pip install "praisonaiagents[mcp]".
- Light server — praisonai-code, config-driven basic tool hosting, no extra install. praisonai serve mcp.
- Heavy host — praisonai-mcp itself. Full server, adapters, recipe bridge, HTTP auth. praisonai mcp serve.

The light server literally uses a different underlying object (ToolsMCPServer from the agents SDK) than the heavy host (MCPServer), which explains why capabilities differ so much between the two even though the CLI commands look similar.

![PraisonAI GitHub repository README overview](https://mer.vin/wp-content/uploads/2026/07/github-readme-snapshot-1.png)

Transports: STDIO and Streamable HTTP

Two transports are supported:

- STDIO — JSON-RPC over stdin/stdout, used by Cursor/Claude Desktop. Worth noting for anyone rolling their own MCP server: logs must go to stderr, not stdout, or you corrupt the protocol stream. Classic first-timer bug.
- HTTP-stream — implements Streamable HTTP per MCP protocol version 2025-11-25, not legacy standalone SSE. Needs the [server] extra (Starlette + Uvicorn). Non-localhost binds require --api-key or --keys-file — you can't accidentally expose this to the network without auth.

I checked the official MCP spec pages, and this tracks: the [2025-11-25 authorization spec](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) requires OAuth 2.1 with mandatory PKCE (S256) for HTTP-based transports, and explicitly says STDIO implementations should skip this flow and pull credentials from the environment instead — which matches the article (no auth story in the STDIO section, full auth story in the HTTP section).

Auth stack — this is more thorough than most MCP hosts I've seen

- API keys, including a scoped keys file (JSON array mapping key → name → scopes like tools:read or *)
- OAuth 2.1 + PKCE
- OIDC discovery
- Scope enforcement
- Origin validation / session IDs handled by a shared security module in praisonaiagents

That's a real least-privilege model, not just "here's an API key, good luck."

The recipe → MCP bridge, and default-deny tools

You can turn any PraisonAI "recipe" into its own scoped MCP server:

```
praisonai mcp serve-recipe support-reply --transport stdio
praisonai mcp validate-recipe support-reply
`

with allow/deny lists and a safe mode. By default, destructive tools — shell.exec, file.delete, eval, etc. — are denied. Given how much of the current agentic-tooling anxiety is about exactly this failure mode (LLM invokes a tool, tool deletes something or runs arbitrary code), having deny-by-default baked into the bridge rather than left as an integrator responsibility is a good call.

![PraisonAI repository README preview showing project structure](https://mer.vin/wp-content/uploads/2026/07/github-readme-snapshot-1-768x1283.png)

Dependency structure — how they avoided circular installs

Seven packages, published in this order:

`
praisonaiagents → praisonai-code → praisonai-bot → praisonai-train → praisonai-browser → praisonai-mcp → praisonai
`

Cross-package calls go through three named "bridges" instead of direct imports that would create cycles:

- _mcp_bridge (code → mcp)
- _code_bridge (mcp → code)
- _wrapper_bridge (mcp → wrapper)

Plus backward-compat shims so old import paths (praisonai.mcp_server.*) still resolve via lazy re-export. This is the kind of plumbing detail that usually isn't documented, and I think it's genuinely useful if you're trying to understand why a package behaves differently standalone vs. co-installed with the wrapper.

Honest caveats

- v0.0.2. This is early-stage. No mention of test coverage or stability/breaking-change policy in the article, so if you're thinking about this for anything auth-gated in production, do your own diligence first.
- No benchmark or feature comparison against other MCP server frameworks (official Python/TS SDKs, FastMCP, etc.) — you'll need to evaluate that yourself if you're choosing between options.
- The GitHub README screenshots included are generic repo-preview images, not architecture diagrams specific to the claims above — don't read anything into them beyond "here's the repo."

Who this is actually for

If you're already on praisonaiagents as an MCP *client* and now need to *host* your own tools/resources/prompts with real auth, this is the natural next package. If you just need basic config-driven tool hosting, the light praisonai serve mcp path avoids the extra dependency weight ([server]/[auth]` extras) entirely.

Media source (Article): https://github.com/MervinPraison/PraisonAI

---

[Read more on mer.vin](https://mer.vin/2026/07/praisonai-mcp-praisonai-mcp-server-host-client-config-in-depth/)

PraisonAI MCP (praisonai-mcp) — Server Host & Client Config In-Depth