Migrating from the TypeScript SDK

Migrate one client contract at a time. Record tool names, input schemas, results, resource URIs and refused requests before moving code. FrontMCP adds structure around the protocol; it does not make every SDK middleware, transport or schema choice a drop-in match. For a small stable server, staying with the SDK may be the simpler decision.

Compare two implementations

Download the contract fixtures. Their README includes the SDK migration check. It runs an official TypeScript SDK server and a FrontMCP server against the same synthetic records. Both expose two tools, a resource and the same result shape. The checks compare successful calls, a missing record, an unauthorized operation and resource content.

In this checkout:

node scripts/check-migration.mjs

The official SDK transport is in memory; FrontMCP uses its in-process entry. This check compares client-visible application contracts. HTTP routing, OAuth and deployment require the additional endpoint checks below. The output names the actual installed package versions.

Move shared services into a provider

Keep your API client independent of the transport. Register it as a provider; replace module globals or ad hoc request wiring with explicit tool dependencies. Move tools into an app and register the app on the server. Preserve public names and resource URIs rather than exposing new class names to existing clients.

Use the tool reference, providers, resources and testing. The reporting download demonstrates complete local registration and test adaptation.

Choose auth explicitly

The default FrontMCP endpoint is public. Select an auth mode before migrating protected data. Verify issuer, audience, expiry and scope behavior; map tenant claims from trusted identity and enforce record access at the API. Static test keys are not a substitute for a real identity-provider flow.

Retain negative cases. A call being absent from discovery is different from the server refusing it. Test direct calls to restricted names too. For destructive operations, distinguish authorization from user approval.

Verify the endpoint before switching clients

Keep the existing endpoint available while the replacement runs in preview.
Test the exact endpoint path, selected protocol revision, initialize/session behavior where applicable, tool schemas and resource reads.
Check missing, expired and wrong-audience tokens plus two callers with different access.
Compare representative success/error results and any widget/resource metadata the client consumes.
Build for the actual target, configure secrets/state, then make the same requests against preview.
Move a small client cohort, observe failures, and keep the previous deployment available for rollback.

The deployment guide owns target constraints. An in-memory contract pass does not establish a hosted deployment or prove OAuth equivalence. Keep unsupported middleware or client features on the original path until their behavior has a checked replacement.