Evaluate FrontMCP for production
Covers FrontMCP 1.10.10 as of
FrontMCP is an open-source TypeScript framework for MCP servers with shared services, authentication, tests and background work. To decide whether it fits your production application, test the client contracts and failure cases you depend on. This page collects the available evidence, explains what each check establishes, and identifies the work that still belongs to your application.
Published by FrontMCP's maintainers. These are maintained references and reproducible fixtures, not an independent certification or a report from a customer deployment. For alternatives, start with the framework comparison.
Protocol support is separate from the SDK dependency
FrontMCP 1.10.10 serves MCP 2026-07-28 and the four earlier revisions from 2024-11-05 through 2025-11-25 over Streamable HTTP and stdio. FrontMCP uses the official SDK v1 internally and implements the newer protocol itself. Inspect the protocol reference for request routing, mirrored headers, error codes and transport differences.
The protocol page's runnable examples exercise the request handler, including discovery, unsupported revisions and header mismatches. Its stdio instructions require a Node process. These checks cover named behaviors; they are not a full MCP conformance result. Also check the client: the testing runner uses an older revision than the Playground, so a green test alone does not establish compatibility with your chosen client and protocol.
What you can reproduce
| Evaluation | Evidence available | What it does not establish |
|---|---|---|
| Protocol requests | Protocol examples, fetch handler, and the comparison's recorded probes | Complete specification conformance or compatibility with every hosted client |
| Record authorization | Two-tenant reporting project with permitted, refused and misleading-tenant-argument cases; its Node download adds concurrent calls | A real identity provider's verification, claim mapping or your database's access controls |
| Migration from the official SDK | Runnable contract comparison and dated JSON result | HTTP, OAuth or deployment equivalence; the record names the exact SDK releases used |
| Upgrade behavior | Upgrade procedure and before/after record containing schemas, a successful result and an expected refusal | Every application's upgrade path, all intervening changes or a database migration |
| CodeCall tradeoffs | Controlled evaluation and individual runs, including discovery overhead | Model accuracy, token costs, network latency or performance of other frameworks |
| Deployment | Target-specific instructions, generated artifacts and local endpoint checks | A successful deployment to your provider, account, identity system or storage service |
The records retain their observed dates and versions. A newer documentation release does not rerun or relabel an older measurement. Runnable Playground examples have their own verification scope.
Run the checks locally
Use Node.js 24+ and the documentation repository's lockfile. The commands below run the protocol page's examples, the migration fixture and the controlled CodeCall evaluation:
git clone https://github.com/agentfront/frontmcp.dev.git
cd frontmcp.dev
corepack enable
yarn install --immutable
yarn test:examples content/reference/server/protocol-versions.mdx
yarn test:migration
yarn evaluate:codecall --runs=5Record the checkout's commit with git rev-parse HEAD and keep each command's output. These commands run the installed checkout; they do not reproduce an older JSON record unless you also use its dependency versions and fixture. The reporting download and evaluation download include their own installation and test instructions.
Check authentication and record access separately
Choose an auth mode, configure the identity provider's issuer, audience and keys, then decide which tools and records each caller can access. A tenant name supplied in a tool argument cannot establish that caller's identity. Hiding a tool from discovery is also insufficient: send a direct call to its name and verify that the server refuses it.
The reporting fixture supplies trusted identity in-process for its positive cases. Before using real data, repeat those cases over HTTP with two real identities. Include missing, expired and wrong-audience tokens, a forged tenant argument, concurrent calls and a record owned by the other tenant. Verify the backing API's access checks and inspect logs for credentials or private results. Auth in production and testing authentication explain the configuration and test helpers.
Approval and caching have specific boundaries
The Approval plugin refuses a protected tool call until an approval is recorded for its caller. Your application provides the interaction, records the decision and retries the operation. The plugin does not hold a request open while it asks a person, and approval does not replace authorization to access the record.
The Cache plugin stores tool results. It does not cache a model's generated conversation replies. Choose keys and expiry for the data being returned; sharing a key across callers is appropriate only when those callers are allowed to receive the same result.
Verify the runtime you intend to operate
| Failure or change | Check in your preview environment |
|---|---|
| Dependency stalls or client disconnects | Exercise timeouts and concurrency limits, cancellation and whether the downstream operation actually stops. |
| Process restarts or another instance receives the request | Check shared state, signing secrets, retained jobs and session behavior for the clients you support. |
| Deployment target changes | Build for that target, configure production mode and secrets, then list and call tools through the deployed endpoint. Follow Node, Vercel, Lambda or Cloudflare. |
| Traffic increases | Measure startup, resident memory, latency and error rate under a stated workload. Include slow and refused requests, not just a fast successful tool. |
| An SDK or plugin changes | Preserve the previous lockfile and artifact; compare schemas, access decisions, success/error results and client behavior using the upgrade procedure. |
Dependency count and class-based syntax do not measure runtime overhead. A useful performance report names the workload, hardware or provider, concurrency, warmup, sample count, failures and dependency versions. There is no cross-framework load benchmark in the evidence above.
Assess maintenance and adoption
Read the release history, maintainers and correction routes, security reporting instructions and open issues affecting your workload. A frequent release can be a fix or an addition; inspect the actual changes before treating cadence as instability. The recorded upgrade checks cover their selected fixture only and are not a long-term support commitment.
Ask a team using the framework about its application, client mix, operational failures and upgrade experience. GitHub stars and npm downloads are useful context but do not identify production deployments. The fixtures on this page use synthetic data; they should not be presented as customer adoption evidence.
Make a decision from the same application
Implement one representative tool, one restricted operation and one shared service in each option you are considering. Use the same schemas, data and identity provider. Save discovery, success and refusal outputs, then run the deployment and failure checks above. Record what required application code, what the framework supplied and which constraints remain.
Choose FrontMCP when its shared application structure and supported components reduce work you otherwise need to own. Compare the official SDK when your existing backend supplies those pieces, your server is small or you need another schema library. The architecture chooser links the relevant starting paths.