FrontMCP vs mcp-framework

This site documents FrontMCP, so read it knowing who wrote it. Every mcp-framework fact below comes from its own documentation, repository and npm entry for 0.2.22, checked on 2026-10-10, and links to them. Every FrontMCP fact links to the page on this site that shows FrontMCP 1.9.4 doing it.

What mcp-framework is

mcp-framework is written by Alex Andru (QuantGeekDev on GitHub), with documentation at mcp-framework.com. The repository's LICENSE is MIT, and its docs say the same; the npm entry has no license field. It's published as mcp-framework, first on 2024-12-08; 0.2.22, the version checked here, is the latest, published on 2026-04-16 (npm). The project is at 0.x and makes no stability claim, and an open issue from June 2025 asks for maintainers.

It's built on v1 of the official MCP TypeScript SDK: it asks for @modelcontextprotocol/sdk ^1.29.0 as a peer dependency, and for Zod 3 (package.json). Its docs describe it as "an independent framework that uses @modelcontextprotocol/sdk" (Why mcp-framework).

On 2026-10-10, mcp-framework had 930 GitHub stars (GitHub API) and 51,963 npm downloads in the week of 2026-10-02 to 2026-10-08 (npm API). FrontMCP had 146 stars and 8,479 downloads of @frontmcp/sdk in the same week. mcp-framework has been released for a year longer and is more widely used.

The same tool in both

One tool, add, that takes two numbers and returns their sum, called with { "a": 2, "b": 3 }.

In mcp-framework

We created a project with the CLI, as the README shows (npx -p mcp-framework@0.2.22 mcp create add-server, and mcp create add-server-http --http --port 3203 for HTTP), added a tool with mcp add tool add, and wrote it like the README's Quick Start:

import { MCPTool, MCPInput } from "mcp-framework";
import { z } from "zod";

const schema = z.object({
  a: z.number().describe("First number to add"),
  b: z.number().describe("Second number to add"),
});

class AddTool extends MCPTool {
  name = "add";
  description = "Add two numbers";
  schema = schema;

  async execute(input: MCPInput<this>) {
    return input.a + input.b;
  }
}

export default AddTool;

The server is the scaffold's src/index.ts, unchanged. For HTTP:

import { MCPServer } from "mcp-framework";

const server = new MCPServer({
  transport: {
    type: "http-stream",
    options: {
      port: 3203
    }
  }});

server.start();

npm run build compiles the project and checks that every schema field has a description, and npm start serves the tools it finds in dist/tools. Over stdio and over HTTP, calling add returned:

{"content":[{"type":"text","text":"5"}]}

In FrontMCP

The same tool as a decorated class, and a server that lists it in an app. The Playground runs it and calls add; the Tests tab runs the checks:

import { Tool, ToolContext, z } from "@frontmcp/sdk";

@Tool({
  name: "add",
  description: "Add two numbers",
  inputSchema: {
    a: z.number().describe("First number to add"),
    b: z.number().describe("Second number to add"),
  },
})
export class Add extends ToolContext {
  async execute({ a, b }: { a: number; b: number }) {
    return { sum: a + b };
  }
}

The two look alike: a class per tool, a name, a description, a Zod schema and an execute() method. mcp-framework finds tool classes by scanning a folder; FrontMCP lists them in an app. FrontMCP uses Zod 4, returns an object as structuredContent with a text copy (Your First Tool), and needs Node 24 or later (Installation); mcp-framework needs Node 18.19 or later.

Side by side

What each does that the other doesn't

What mcp-framework documents and this site doesn't show for FrontMCP:

• Tools found by scanning a folder, so adding a file adds a tool.
• Generators for each kind of component: mcp add tool, mcp add prompt, mcp add resource and mcp add app.
• A check, at build time, that every schema field has a description, so the model never sees an undocumented argument (mcp build, mcp validate).
• stdio and HTTP from one process, each transport with its own auth (Multi-transport).
• Node 18.19 or later. FrontMCP needs Node 24.

What FrontMCP does that mcp-framework's docs don't document:

• MCP 2026-07-28, next to the older revisions, on one endpoint (Error codes).
• A dependency container: providers with scopes.
• Hooks and plugins around every call, with official plugins for caching, memory, approvals and feature flags (Plugins and adapters).
• Agents, jobs and workflows: agents, background jobs and workflows.
• An OAuth server: FrontMCP can issue the tokens itself, with its own sign-in page and your check of the user, or after a sign-in at an upstream provider (Local auth, Remote and proxied auth), and checks per-entry authorities.
• A test library with MCP matchers and fixtures (Testing Your Server).
• Sessions shared between instances through Redis. mcp-framework keeps HTTP sessions in the process, which an open issue says stops it scaling across instances.
• Builds for Vercel and Cloudflare Workers from the CLI (Deploying Your Server).

When to choose mcp-framework

• You want a class per tool, discovered from a folder, with generators and a build that checks your descriptions, and little else to learn.
• You're on Node 18 or 20, and your clients speak MCP 2025-11-25 or earlier.
• You want the more widely used of the two today.

When to choose FrontMCP

• You need MCP 2026-07-28, or Zod 4.
• The server is growing, and you want shared services, several apps, hooks and plugins to organise it (Structuring a Server).
• You want agents, background jobs, workflows or tests from the same framework.
• You run several instances of the server behind a load balancer (Running Several Instances).

How this was checked

On 2026-10-10 we created two mcp-framework 0.2.22 projects with its CLI, one for stdio and one for HTTP, made the fix in the note above, and called add over each. We then sent each server an initialize request for every MCP revision from 2024-11-05 to 2025-11-25, and the 2026-07-28 server/discover and tools/call requests. The four older revisions answered and returned 5. 2026-07-28 didn't: over stdio, server/discover got -32601 Method not found, and over HTTP both requests got 400, No valid session ID provided from the HTTP Stream transport and Unsupported protocol version: 2026-07-28 from the documented handleRequest(). The overview describes the method for every library.