Daniel's been staring at the Python versus TypeScript question for AI apps and MCP servers, and he's got three things he wants us to actually answer. First: where do these two genuinely overlap, not just on the surface but in the code you write day to day? Second: what are the real reasons to pick one over the other — not the blog post reasons, the ones that bite you at two in the morning. And third: is this whole choice just a question of what you already happen to know, or does it actually matter? He suspects both are first-class citizens and the decision might be a wash. I think he's half right and half about to walk into a wall.
The wall is the interesting half. The overlap is real — both have official MCP SDKs maintained by the same team, both implement the same wire protocol, and if you open the docs side by side the shapes are nearly identical. That's the half he's right about.
And the wall?
The wall is everything around the SDK. The type system, the runtime, the ecosystem gravity, and — this is the part most people miss — which side of the boundary you're building on. MCP servers are glue. Glue should match the materials it's joining.
So let's start by mapping the landscape. Where do these two languages actually stand in the AI world right now?
It's a two-language town, and the division is sharper than most people admit. Python owns the model side — PyTorch, Transformers, the entire training and inference stack. If you're loading a model, fine-tuning it, or running embeddings, you're in Python. TypeScript owns the application side — React, Next.js, serverless backends, anything that touches a browser. MCP servers sit right at the seam between those two worlds, which is why this debate exists in the first place.
And the MCP project itself treats both as equals.
Completely. The MCP docs describe both SDKs as first-class, and they support the same transports — stdio and HTTP. The core primitives are identical: tools, resources, prompts, and the JSON-RPC transport layer. A developer who knows one can read the other's documentation and immediately recognize the same shapes. That's not marketing — the wire protocol is the wire protocol.
So if the APIs are parallel, why doesn't that settle it?
Because the code you write to implement those APIs lives in two very different worlds. Let me give you a concrete example. Say you're building an MCP server that exposes a weather tool — it takes a city name and returns a forecast. In Python, you define a server, you decorate a function with the tool schema, and you connect to stdio. In TypeScript, you create a server, you register a tool handler with a Zod schema for validation, and you connect to stdio. The structure is nearly line-for-line parallel.
That sounds like an argument for "just pick what you know."
It is, until the schema gets complicated. Imagine the weather tool takes a location object with latitude, longitude, and an optional unit preference. In TypeScript, you define that with Zod or a TypeScript interface, and if you get the shape wrong — say you pass a string where the schema expects a number — the compiler catches it before the code ever runs. In Python, you're relying on Pydantic at runtime, or worse, you're writing a docstring and hoping.
So the type system is the first real fork.
It's the first one that bites. TypeScript's types are structural and enforced at compile time. They get erased at runtime — it's still JavaScript under the hood — but that compile step catches an entire category of bugs that Python lets through until the server is actually handling a request. For an MCP server, the tool schemas are a public contract. The AI client is going to call your tools based on those schemas, and if the shapes don't match, you get a runtime error that surfaces as a confusing failure to the user.
And Python's response to that is Pydantic, FastAPI, runtime validation.
Right, and those work. But they're opt-in, and they're only as good as your discipline in using them everywhere. I've seen Python MCP servers where half the tools had proper Pydantic models and the other half were using raw dictionaries because the developer was moving fast. TypeScript makes that kind of drift harder — not impossible, but harder.
The thing about discipline-dependent safety is it fails exactly when you're under pressure. Which is when most MCP servers get written.
But let me be fair to Python here — there's a flip side. Python's dynamic nature means you can iterate faster when you're exploring. If you're prototyping an MCP server that wraps a new model endpoint, you can just... do it. No build step, no type wrangling, just write the function and ship it. TypeScript's compiler is a safety net, but it's also a speed bump.
So the trade isn't safety versus danger. It's compile-time guarantees versus iteration speed.
Yes, and which one matters more depends entirely on what your MCP server does. If it's exposing a stable set of tools to a production AI application, I want the compile-time guarantees. If it's a research prototype that's going to change shape three times this week, Python's flexibility is useful.
Let's talk about the runtime. You mentioned cold starts earlier.
This is where the deployment story diverges. MCP servers in Claude Desktop or similar environments get invoked per-session, which means startup latency matters. Node.js — which is what TypeScript compiles to — generally has faster cold starts than Python. We're talking on the order of tens of milliseconds versus low hundreds, but when a user is waiting for a tool call to resolve, that adds up.
Is that a Node thing or a V8 thing?
It's mostly V8's JIT compiler versus CPython's interpreter. Node has been optimizing for fast startup for years because of the serverless use case. Python's been improving — there's work on subinterpreters and faster startup paths — but it's still behind. For an MCP server that's invoked, does its work, and shuts down, TypeScript has an edge.
But Python wins on the heavy compute side.
By a mile. If your MCP server needs to run a model inference, do document embeddings, or crunch through a large dataset, Python is where the libraries are. PyTorch, Transformers, and the entire scientific computing stack are Python-first. You can call a Python model from Node via a subprocess or an HTTP wrapper, but now you're managing two runtimes and the complexity that comes with that.
Which brings us to the ecosystem question. Where do the libraries actually live?
This is the gravitational argument. Python has LangChain, LlamaIndex, every vector database client, and the entire model ecosystem. If your MCP server needs to embed documents, query a vector store, or chain model calls, the Python tooling is richer and more mature. TypeScript has the web integration story — React, Next.js, serverless platforms, and increasingly edge functions. If your AI app is a web product, TypeScript keeps the whole codebase in one language.
So the choice isn't really about the MCP server itself.
That's the insight. The MCP server is the thinnest part of the stack. It's a protocol adapter — it takes a tool call from an AI client, does some work, and returns a result. The language you write it in matters less for the server code and more for everything the server needs to connect to. If it's calling a Python model, write it in Python. If it's feeding a React dashboard, write it in TypeScript. The server is glue, and glue should match the materials it's joining.
That's a cleaner answer than "it depends," but it's still a version of "it depends."
It's a version of "it depends" with a decision rule attached. Look at what your MCP server talks to. If the answer is mostly models and data pipelines, Python. If the answer is mostly web apps and APIs, TypeScript. If it's both — and this is where it gets interesting — you have a real architectural decision to make.
What does "both" look like in practice?
Imagine a RAG pipeline. You've got document ingestion and embedding on one side — that's Python territory. You've got a chat interface on the other side — that's TypeScript territory. The MCP server sits in the middle, exposing tools that query the vector store and return results to the AI client. Which language do you pick?
I'd pick the one that talks to the vector store, because that's the integration that's going to be the most painful to do cross-language.
I'd make the same call, and for exactly that reason. The vector store client is going to be Python-native, with query syntax and connection management that assumes a Python runtime. You can wrap it in an HTTP API and call it from TypeScript, but now you've added network latency, serialization overhead, and another service to monitor. Sometimes that's the right trade — if the frontend team is all TypeScript and the MCP server needs tight integration with the UI, maybe it's worth it. But it's a cost you should be aware you're paying.
Let's go back to something you said earlier about the MCP ecosystem being young. How much of this is going to change in the next year?
That's the risk. The MCP SDKs are evolving, and the patterns aren't settled yet. Python's SDK has been around longer and has more community examples — if you search for MCP server tutorials, most of them are in Python. TypeScript's SDK is catching up fast, but there's still a gap in the number of worked examples. If you're building something today and you want to copy-paste from a working example, Python has the edge.
But that's a temporary advantage.
It is, and it could flip within six months. The TypeScript community is extremely active in the AI space right now, and the serverless ecosystem is pushing hard into AI workloads. I wouldn't bet on Python's example count staying dominant for long.
So the real risk isn't picking the wrong language. It's picking a pattern that the ecosystem abandons.
Yes. If you build your MCP server today using a pattern that the SDK deprecates next quarter, you're rewriting it either way. The language choice matters less than the architectural choices you make inside it. Keep the server thin, keep the business logic in libraries that are language-appropriate, and don't over-invest in SDK-specific abstractions that might not survive.
I want to push on something. You've been careful not to pick a winner, and I respect that, but if someone put a gun to your head and said you have to standardize on one language for all your MCP servers for the next two years, which one?
For my use case? TypeScript.
Why?
Because the AI apps I build are web products. The MCP servers feed chat interfaces, dashboards, and real-time tools. The integration surface is all TypeScript, and keeping the whole stack in one language reduces the cognitive overhead. I'm willing to pay the cost of wrapping Python models behind HTTP APIs because that boundary is clean and well-understood.
And if you were building model services?
Then Python, no question. If my MCP server's job is to manage model inference, handle embeddings, or orchestrate training jobs, the Python ecosystem is irreplaceable. You'd have to pry PyTorch out of my cold, dead hands.
So the gun-to-your-head answer is still "it depends," just with more words.
It's "it depends" with a framework for deciding. The framework is: trace the integration boundaries. The language that matches the heaviest integration wins.
That's actually testable. If you've got a Python codebase and you're adding an MCP server that mostly calls internal Python services, you write it in Python. If you've got a TypeScript codebase and the MCP server is feeding a web UI, you write it in TypeScript. The choice isn't about the language's abstract merits — it's about friction.
And friction is the thing that kills projects. Not dramatic failures — death by a thousand small impedance mismatches. The extra serialization step, the slightly different error handling, the package that's available in one ecosystem but not the other. Each one is trivial on its own. Together they add up to a codebase that's harder to maintain and harder to onboard new developers onto.
Let's talk about the cultural dimension, because I think it's underrated. Python is the language of the people who write the papers. TypeScript is the language of the people who ship the products.
That's a real split. The AI research community publishes in Python — the model weights, the training code, the evaluation scripts. If you're building on the cutting edge, you're reading Python and you're probably writing Python. The product engineering community builds in TypeScript — the UIs, the APIs, the deployment pipelines. MCP servers are the first time these two tribes have had to share infrastructure.
And they bring different expectations. The Python developer expects to be able to drop into a REPL and inspect a model's outputs interactively. The TypeScript developer expects type checking in CI and a build pipeline that catches errors before deploy. Neither set of expectations is wrong, but they don't naturally coexist.
The MCP server is the water cooler. It's where the model person's tool definition meets the frontend person's API contract, and if those two people have different assumptions about how validation works or what an error looks like, you get friction.
So the language choice is also a team choice. Who's going to maintain this thing?
If your team is mostly Python people, writing the MCP server in TypeScript means they're context-switching every time they need to debug a tool call. If your team is mostly TypeScript people, the reverse is true. The language you pick should be the one your team can support at two in the morning.
Which brings us back to Daniel's third question. Is this mostly about what you already know?
Yes and no. Familiarity is a real factor — it reduces the time to ship and the cost of maintenance. But it's not the only factor, and it shouldn't be the deciding one. If what you know is Python and your MCP server needs to integrate deeply with a Next.js frontend, you should seriously consider TypeScript despite the learning curve. The friction of the wrong language choice compounds over time.
And the learning curve itself — how steep are we talking?
For an experienced developer moving between Python and TypeScript for MCP work? Not steep. The SDKs are similar enough that the concepts transfer directly. The hard part isn't the language syntax — it's the ecosystem. Learning where the packages live, how the build system works, what the deployment patterns are. That's a week of work, not a month.
So the cost of switching is low enough that you shouldn't let familiarity trap you in the wrong choice.
Right. If the integration boundary clearly favors TypeScript, spend the week learning it. The time you'll save on integration friction will pay that back within the first month.
Before we wrap, Hilbert's been making faces behind the console. What's on your mind?
Hilbert: I wrote one of these in 1994.
One of what?
Hilbert: An MCP server. Well, not MCP. It was a protocol adapter for a fax server. Took incoming faxes, routed them to the right department based on the header. The whole thing was in Perl.
Perl.
Hilbert: The billing system spoke one format, the fax hardware spoke another, and the department routing table was a CSV file that got updated by hand every Monday. I wrote a daemon that sat in the middle and translated. Same thing you two have been talking about for twenty minutes.
Glue code.
Hilbert: Glue code. I've been writing glue code since before either of you knew what an API was. The language question — you're both right about the boundary thing, but you're missing the real reason people pick Python for AI.
What's the real reason?
Hilbert: It's the language of the people who write the papers. You said it yourself. The model people publish in Python, the product people ship in TypeScript, and the MCP server is the first time they've had to share a water cooler. That's not a technical problem. That's two tribes who've never had to talk to each other suddenly sharing infrastructure. The technical choice is downstream of the cultural one.
So you're saying the language debate is really a proxy for who owns the integration layer.
Hilbert: I'm saying I watched the same thing happen with Java and C++ in the nineties. The embedded systems people wrote C++, the enterprise people wrote Java, and the middleware sat in between. The language that won was the one the middleware team already knew. The technical merits had nothing to do with it.
That's... actually consistent with what we're seeing. The MCP server teams I know are mostly picking the language their existing stack uses.
Hilbert: Because they're the ones who have to maintain it. The model person isn't going to debug a TypeScript build failure at eleven PM. The frontend person isn't going to debug a Python dependency conflict. The glue team owns the glue, and they pick the language they can support.
So the answer to Daniel's question — does the choice actually matter — is yes, but not for the reasons he probably expects.
Hilbert: It matters because the person who picks the language is the person who gets the phone call when it breaks. Pick the language you want to get woken up for.
That's a remarkably practical heuristic.
Hilbert: I've still got the Perl daemon on a floppy disk in my garage. Ran for seven years without a restart. I could bring it in next week if you want to see it.
I think we're good.
Hilbert: Suit yourself. It's got comments and everything.
I have so many questions about the fax server, but I'm going to save them. Let's pull back to the big picture.
The open question I'm left with is whether this distinction holds. As MCP matures, do the SDKs converge to the point where the choice truly becomes irrelevant, or do the boundary pressures keep them distinct?
I think the boundary pressures are structural. Python is where the models live because the scientific computing ecosystem is Python-native, and that's not changing. TypeScript is where the web apps live because the browser runs JavaScript, and that's not changing either. MCP servers will keep sitting at the seam, and the choice will keep being about which side of the seam you're closer to.
The thing to watch is the next wave of MCP features. If they lean into streaming or real-time communication, TypeScript's event loop might pull ahead — Node was built for that. If they lean into heavy compute or model integration, Python's ecosystem will dominate.
If they do both, the seam gets wider, not narrower. We might end up with MCP servers that are polyglot by design — Python for the compute-heavy tools, TypeScript for the real-time ones, orchestrated by a thin routing layer.
Which is just the glue argument at a higher level of abstraction.
Everything old is new again. Hilbert's fax server was polyglot before polyglot was a word.
If you take one thing from this episode, it's that the Python versus TypeScript choice for MCP servers isn't about the languages themselves — it's about the integration boundary. Trace what your server talks to, and let that decide.
If you're the one who's going to get paged when it breaks, pick the language you want to debug at two in the morning. The technical merits are secondary to the operational reality.
Thanks to Hilbert Flumingtop for producing, and for the fax server story we're all going to be thinking about for the rest of the day.
I want to know if that floppy disk still reads.
This has been My Weird Prompts. Find us at my weird prompts dot com, or email the show at show at my weird prompts dot com. We'll be back soon.
