Skip to content

MCP

  • in MCP
  • 10 min read

How to Compose Multiple MCP Servers Into One Gateway

To compose multiple MCP servers into one gateway, you mount each team's server behind a namespace prefix so an agent connects to a single endpoint and discovers one clean toolbelt — pay_charge, usr_get_user, rpt_revenue — instead of juggling three URLs, three auth handshakes, and three tool lists it has to deduplicate itself. That much is table stakes; several frameworks can prefix-and-merge. The part that actually decides whether a gateway survives contact with production is what happens at the seam: can you filter what each client sees across the composed surface based on who is asking, and can two mounted servers ship different versions of the same tool without a name collision?

  • in MCP
  • 11 min read

FastMCP vs Promptise: The Production MCP Stack Compared

If you are shopping for a fastmcp alternative for production, start by dropping the framing that FastMCP is a toy — it is a genuinely capable MCP server SDK, and the honest question is not whether it works but how much production plumbing you still assemble by hand. FastMCP gets you typed tools, mounting, auth, and a real middleware pipeline. This pillar walks the fastmcp vs promptise decision feature by feature, gives FastMCP full credit for what it already does well, and then marks the four capabilities Promptise Foundry folds into one middleware stack that FastMCP leaves you to bolt together yourself: versioned tool coexistence, per-tool circuit breaking, tenant-qualified rate limits, and an MCP-native durable job queue.

  • in MCP
  • 10 min read

Show Different MCP Tools to Different Clients

To hide MCP tools per client, you stop shipping one flat tool list to everyone and instead tailor the list each caller discovers at list_tools time — the anonymous integration sees search_orders and get_order, while an authenticated operator additionally sees issue_refund and delete_customer. A public MCP server that advertises its destructive admin tools to every caller has already lost the argument: even if a guard stops the call, you have leaked the shape of your privileged surface to anyone who runs discovery, and you have handed a confused agent tools it will eventually try to use. The clean fix is to make the advertised toolset a function of who is asking.

  • in MCP
  • 9 min read

Long-Running MCP Tools Without Client Timeouts

A long-running MCP tool job queue exists because of one hard fact about the Model Context Protocol: a tool call is a single request/response exchange, so a report that takes ten minutes to build times the client out and loses its result long before your handler returns. The agent sends tools/call, the connection holds open waiting for a reply, and somewhere around the 30-, 60-, or 120-second mark — whatever your transport, proxy, or client library decided — the request is abandoned. Your handler may still be running server-side, dutifully finishing the PDF, but there is no longer anyone listening for the answer. The work happened; the result evaporated.

  • in MCP
  • 7 min read

MCP Authentication: JWT, OAuth2 & API Keys

MCP authentication is the part of the Model Context Protocol that the spec deliberately leaves to you — and most tutorials stop at a hard-coded shared secret. That is fine for a laptop demo and dangerous the moment an agent can call a tool that spends money, deletes records, or reads another tenant's data. This guide shows how to do layered, capability-based access properly in Promptise Foundry: transport-level providers (JWT, RS256/ES256, API keys) that verify who is calling, plus per-tool guards that decide what they may do — all in copy-paste code, not theory. By the end you will have a server where a public health check, a scoped read tool, and an admin-only write tool coexist safely.

  • in MCP
  • 5 min read

MCP Client Tutorial: Connect Agents to MCP Servers

Most tutorials teach you to build an MCP server, then stop — but an MCP client is what actually connects your agent to that server, discovers its tools, and calls them. This tutorial covers the side most guides skip: how to connect to one server, fan out across many servers behind a single unified tool list with auto-routing, and convert MCP tools into LangChain tools you can drop into any agent. Everything here uses Promptise Foundry's native MCP client — three small classes, no third-party MCP dependency to audit or update. By the end you'll be able to wire an agent to any MCP server in a few lines of Python.

  • in MCP
  • 5 min read

How to Build an MCP Server in Python (Tutorial)

Building an MCP server Python developers can actually ship usually stalls on one thing: hand-writing JSON Schema for every tool so clients know how to call it. This tutorial skips that entirely. With Promptise Foundry you decorate a normal Python function with type hints, and the framework generates the schema, validates every call, and serves the tool over stdio, streamable HTTP, or SSE. By the end you'll have a typed tool running, exposed over HTTP, and covered by an in-process test — no schema boilerplate, no network mocking.

  • in MCP
  • 9 min read

One Stalled MCP Tool Can Exhaust Your Connection Pool

MCP tool connection pool exhaustion is what happens when one slow downstream API doesn't just fail its own call — its tool keeps handler coroutines and pooled DB or HTTP connections open through every timeout, the shared pool saturates, and unrelated healthy tools start queueing behind it. The failure is sneaky because the sick tool often works, just slowly. By the end of this post you'll be able to reproduce that cascade in-process and cap its blast radius with two composable middlewares, so a single stalled MCP tool can never consume the server's shared capacity.

  • in MCP
  • 6 min read

MCP vs Function Calling: What's the Difference?

The MCP vs function calling debate confuses a lot of teams, because the two are not actually competitors — they operate at different layers. Function calling is how an LLM decides which tool to call and with what arguments. The Model Context Protocol (MCP) is how those tools get packaged, served, and shared. By the end of this post you'll know exactly where the crossover point sits, so you can keep raw function calling while your tools fit in one file and reach for MCP the moment they don't — without paying a token tax as your catalog grows.

  • in MCP
  • 7 min read

Stop Rewriting Your Tools for Claude, Cursor, and ChatGPT

Write one MCP tool every AI client can call — Claude Desktop, Cursor, and ChatGPT included — and you never rewrite the same logic per framework again. That is the whole promise of the Model Context Protocol: a tool is a small server that speaks a standard wire format, and anything that speaks the protocol can discover and invoke it. Yet most agent frameworks quietly break that promise. They ask you to author tools as framework-native Python objects that only their own runtime understands, so the moment you want to reuse tools across AI clients you are back to standing up a separate MCP server anyway. This post shows why that gap exists, and how being MCP-native on both sides — a server SDK to write the tool and a native MCP client to consume it — collapses two artifacts into one.

  • in MCP
  • 7 min read

Turn a REST or OpenAPI API into an MCP Server

Going from OpenAPI to MCP is the fastest way to make an API you already own callable by AI agents — and you can do it without touching a single route handler. If your service already ships a Swagger or OpenAPI document, Promptise Foundry can read that spec and generate one MCP tool per operation, complete with JSON Schema derived from your existing parameter definitions. By the end of this article you'll have an OpenAPI mcp server running that proxies real HTTP calls to your API, and you'll know how to layer authentication, rate limits, and endpoint filtering on top so agents only touch what you allow.

  • in MCP
  • 10 min read

Stop One Tenant Draining a Shared MCP Server's Quota

Per-tenant MCP rate limiting is the difference between a quota that protects each customer and a quota that merely protects your process — and on a shared MCP server, per-client throttling quietly gives you the second while you think you bought the first. The trap is subtle: a token-bucket limiter keyed by "client" looks tenant-aware right up until two of your tenants authenticate a user whose id happens to be the same string. The moment acme's user u-42 and globex's user u-42 collide onto one bucket, one customer's burst starts spending another customer's quota, and neither of them did anything wrong. Worse, a single tenant that spins up many client ids can collectively soak up the shared throughput everyone else depends on, because nothing in a per-client scheme says "this tenant, as a whole, gets this much."

  • in MCP
  • 7 min read

Best Python MCP Server Framework for Production

Shipping a production MCP server is a different job from getting a demo tool to respond once in your terminal. The prototype works because nothing is trying to break it: no untrusted callers, no bursty traffic, no flaky downstream API, no auditor asking who invoked the refund tool at 2 a.m. Cross that line and you inherit a checklist — authentication, rate limiting, failure isolation, tamper-evident logging, multi-tenancy, and health probes your orchestrator can read. This guide lays out what that checklist actually contains, shows how Promptise Foundry ships every item as one composable middleware chain, and is honest about when the raw SDK alone is all you need.

  • in MCP
  • 8 min read

How to Roll Out a Breaking MCP Tool Change Safely

To roll out a breaking MCP tool change safely, you publish the new schema as a new version beside the old one and let each client migrate on its own clock — instead of editing the live tool in place and forcing every connected agent to move the instant you deploy. That second path is the default one, and it is why a one-line schema edit so often turns into an incident. An MCP tool's input_schema is a published contract: agents discovered it, built function calls to match, and will keep sending v1-shaped arguments until they change. Add a required field, rename a property, or tighten a type, and every in-flight caller starts getting rejected before your handler even runs.

  • in MCP
  • 10 min read

How to Secure an MCP Server on the Public Internet

To secure an MCP server on the public internet you have to accept one uncomfortable fact first: the moment your server has a public URL, every tool you registered becomes a callable endpoint for anyone who finds it — not just your agent, but any script, scanner, or rogue MCP client on Earth. A bearer token is table stakes, and it is not hardening. Hardening is what happens after auth: capability checks per tool, limits that survive a burst, breakers that stop a cascade, a trail you can prove wasn't edited, and a human in the loop on the calls that move money. This post wires all of that into one middleware chain you can copy, run offline, and ship.

  • in MCP
  • 6 min read

How to Test MCP Servers Without a Live Server

Testing MCP servers usually means starting a process, waiting for it to bind a port, and firing HTTP or stdio requests at it from a separate test runner. That works, but it is slow, it is flaky in CI, and it turns a two-line assertion into a fixture that manages subprocesses and sockets. This post shows the alternative: run the complete request pipeline — validation, dependency injection, guards, middleware, and your handler — entirely in-process with Promptise Foundry's TestClient, so your tests stay as fast and deterministic as plain function calls. By the end you will be able to test tools, guards, middleware, and error handling without ever opening a network connection.

  • in MCP
  • 8 min read

Why a Small MCP Tool Change Broke Every Connected Agent

To version MCP tools without breaking clients, you have to treat a tool's schema as a published API contract — because that is exactly what every connected agent already assumes it is. An agent does not read your source code. It reads the input_schema your server advertises, builds a function call to match, and trusts that the shape it saw at discovery time is the shape you will accept at call time. Rename one field from customer to customer_id, tighten filters from optional to required, or drop a property some prompt still references, and every agent already in flight starts emitting arguments your handler rejects. Nothing crashed on your side. You just changed the contract out from under callers who never agreed to the new terms.

  • in MCP
  • 6 min read

What Is MCP? Model Context Protocol Explained

If you have ever asked what is MCP and come away with a spec diagram but no running code, this post is the fix. The Model Context Protocol (MCP) is an open standard for connecting language models to tools, data, and prompts in one uniform way — so a tool you build once can be called by any MCP-compatible agent. By the end of this article you will understand the protocol's moving parts and see an agent auto-discover and call a real tool in under ten lines of Python, with zero manual wiring.