Asynthetic
OfficialAsynthetic provides ground truth migration intelligence for AI coding agents, giving them verified, curated information about breaking changes between library versions instead of relying on potentially outdated training data.
get_migration: Retrieve a hand-curated migration map between two versions (or SemVer ranges) of a package, including ordered breaking changes with before/after code examples, deprecation timelines, source-citation URLs,last_verifieddate,verification_level(high/medium/low), and SemVer range resolution details. Returnsfound: falsewith an explicit no-guessing instruction when data doesn't exist.get_breaking_changes: Look up all breaking changes introduced in a specific version or major version range of a package, matched against curated migration maps, with citations and verification metadata.list_available_maps: Discover what migration maps exist, filterable by package name or ecosystem, showing package, version range, status (draft/verified/stale), and last verified date — useful before callingget_migration.check_peer_compatibility: Perform a static SemVer check to determine whether two specific package versions are compatible (e.g.,next@15+react@18.2), returningtrue,false, orunknownwith cited reasoning from curated peer data.check_compatibility(planned): A future project-aware cross-package compatibility analysis tool; currently returnsimplemented: falseand explicitly instructs agents not to infer anything from its response.
Provides migration maps for Next.js upgrades (e.g., 14 to 15), including breaking changes with before/after code, deprecations, and peer compatibility requirements.
Planned: provides migration maps for React version upgrades (e.g., 18 to 19), detailing breaking changes and peer dependencies.
Provides migration maps for the Vercel AI SDK (package 'ai') upgrades (e.g., 4.x to 5.0), including breaking changes and peer dependencies.
Planned: provides migration maps for Zod version upgrades (e.g., 3 to 4), detailing breaking changes and schema changes.
Asynthetic
Ground truth for AI coding agents.
Your agent's knowledge froze on a date. Asynthetic tells it exactly what changed — every breaking change between library versions, cited and tested.
claude mcp add --transport http asynthetic https://asynthetic.up.railway.app/mcp// agent asks: get_migration("ai", "^4.0.0", "^5.0.0")
{
"found": true,
"verification_level": "medium",
"migration": {
"breaking_changes": [
{
"title": "maxTokens renamed to maxOutputTokens",
"before_code": "generateText({ model, maxTokens: 1024, prompt })",
"after_code": "generateText({ model, maxOutputTokens: 1024, prompt })",
"source_url": "https://ai-sdk.dev/docs/migration-guides/migration-guide-5-0"
}
// …22 more, every one cited
]
}
}Models improve every month. Their knowledge still ends on a date.
Every coding agent ships with a knowledge freeze date. The libraries it writes against don't.
So agents do what the training data taught them: they write maxTokens into AI SDK 5 (removed), synchronous params into Next.js 15 (now a Promise), LangChainAdapter imports from a package that no longer exports them. The code looks right. The agent is confident. The build breaks — or worse, it doesn't, and the bug ships.
Tools that fetch current documentation tell agents what the API looks like today. That's half the problem. An upgrade needs the diff: what changed, what replaced it, and what silently behaves differently. No amount of "current docs" contains that.
Asynthetic is that missing half. Ask it about an upgrade, and it returns a hand-curated migration map: ordered breaking changes with before/after code, deprecation timelines, peer-version requirements, and a citation for every claim. Retrieval, never generation — the same question gets the same verified answer every time.
Related MCP server: Vibgrate AI Context
Before / after
Without Asynthetic — the agent "upgrades" your AI SDK app from memory: keeps result.usage for billing (now silently counts only the final step), leaves temperature unset (v5 removed the implicit 0 — output turns nondeterministic), renames nothing because v4 syntax was correct when the model trained.
With Asynthetic — one tool call returns all 23 breaking changes for that exact version window, including the three above, each with the fix and the official source. The agent applies facts. You review a diff instead of debugging a regression.
That's the product: the difference between an agent that remembers and an agent that knows.
What a map gives your agent
Migration Maps | Hand-curated upgrade intelligence per version window: 40 breaking changes across 2 live maps ( |
Citations | Every map cites official sources and carries a |
Verification Levels | Every response self-reports confidence: |
Field Notes | Where reality diverges from docs, maps say so — e.g. Turbopack doesn't actually enforce the |
SemVer Resolution | Ask with ranges ( |
Peer Checks | Static compatibility answers ( |
Honest Misses | No data means |
The next 14→15 map is Asynthetic's first verification_level: high: every entry tested against real builds on 14.2.35 and 15.5.20, across Turbopack and Webpack, dev and production.
Install
Hosted (nothing to install):
claude mcp add --transport http asynthetic https://asynthetic.up.railway.app/mcpLocal (offline, bundled data):
claude mcp add asynthetic -- npx -y asyntheticAny MCP client works — Cursor, Claude Code, Windsurf, or your own agent:
{ "mcpServers": { "asynthetic": { "url": "https://asynthetic.up.railway.app/mcp" } } }Then upgrade something. The agent calls get_migration before it edits.
Tools
Tool | Answers |
| "What breaks between these versions, and how do I fix each one?" |
| "What does this version break?" |
| "Do these two versions work together?" — |
| "What does Asynthetic know?" |
Full response shape, transports (Streamable HTTP + stdio + legacy SSE), and self-hosting: see docs below.
Why trust it
Asynthetic's founding rule: a wrong map is worse than no map. Everything follows from that.
Curated exclusively from official changelogs, migration guides, and releases — with the URL attached to every entry.
verifiedstatus is earned empirically, not editorially: real projects, both bundlers, dev and production, on pinned versions. The process regularly finds things the docs get wrong — those findings ship in the maps.Confidence is machine-readable (
verification_level,source_count, pre-release warnings), so agents can weigh answers instead of trusting blindly.Unknown is a first-class answer. The server tells agents when it doesn't know and instructs them not to invent.
Narrow and deep, on purpose: fast-moving AI and JavaScript frameworks first, correctness over coverage always.
Self-hosting
git clone https://github.com/asyntheticai/asynthetic.git
cd asynthetic && npm install && npm run build && npm startZero-config serves the bundled maps over stdio. Set PORT for HTTP mode (/mcp, legacy /sse, health at /). Set SUPABASE_URL + SUPABASE_ANON_KEY to serve from Postgres (schema/schema.sql, then npm run seed). Missing config never crashes — it falls back and says so on stderr.
data/maps/ the maps (source of truth, JSON, Zod-validated)
src/server.ts MCP tools
src/store/ Postgres + local backends, SemVer resolver
scripts/smoke.ts 23-check end-to-end suite across every transportContributing a map
Official sources only. Changelogs, release notes, migration guides. Record every URL. Blog posts can start a hunt; they can't finish one.
Follow the schema in
src/types/migration-map.ts— validation rejects anything malformed before it can ever be served.New maps enter as
draft.verifiedis earned by testing snippets on real builds of the pinned versions. Retired maps becomestale— excluded from serving, kept as record.npm run smokemust pass. Don't guess versions or API names: if it's not in an official source, flag it in the PR instead.
Status
Free public beta — hosted endpoint and npm package open to everyone. Next: more maps (Tailwind 3→4, React 18→19, Zod 3→4, AI SDK 5→6), more high-verification promotions, project-aware compatibility analysis. Details will be announced.
Security
Read-only by construction: every tool is a lookup over curated data. No code execution, no request-time fetching, no access to your project or filesystem. The hosted endpoint sees only tool arguments (package names, version strings); sessions are ephemeral, in-memory, and isolated. Report issues via GitHub security advisories.
License
Source-available under BSL 1.1: self-hosting for your own use — personal, team, company-internal — is always permitted; reselling it as a competing hosted service isn't. Converts automatically to Apache 2.0 on July 4, 2030.
Built with TypeScript, the official MCP SDK, Zod, and Supabase. Serving live at asynthetic.up.railway.app/mcp.
Available Tools
5 toolscheck_compatibilityCheck cross-package compatibility (not yet implemented)ARead-only
PLANNED: project-aware compatibility analysis. Currently returns implemented=false and no data. Do not infer compatibility (or incompatibility) from this response. For a static SemVer check between two known package versions, use check_peer_compatibility instead.
Inputs: package_a (required), package_b (required), version_a (required), version_b (required), +1 more.
check_peer_compatibilityCheck peer compatibility between two package versionsARead-only
Static SemVer check of two known package versions against curated compatible_with peer data from migration maps. Purely declarative — no filesystem access or project inspection (that is the scope of the separate, unimplemented check_compatibility). Returns compatible: true | false | "unknown". Treat "unknown" as absence of curated data, never as evidence of incompatibility.
Inputs: package_a (required), package_b (required), version_a (required), version_b (required), +1 more.
get_breaking_changesGet breaking changes in a versionARead-only
Returns the breaking changes introduced when upgrading TO the given version of a package (matched by major version against curated migration maps), with source citations and last_verified dates. Accepts concrete versions or SemVer ranges ("15", "^15.0.0", "15.x"); resolution is disclosed via match_type/resolved_via. If found=false, no verified data exists — do not guess.
Inputs: package (required), version (required), ecosystem.
get_migrationGet migration mapARead-only
Returns the verified migration map for upgrading a package between two versions: ordered breaking changes with before/after code, deprecations, source-citation URLs, and a last_verified date. Accepts concrete versions or SemVer ranges (e.g. "^14.2.0", "~14.1.0", "15.x"); non-exact lookups resolve to the covering map and disclose how via match_type/resolved_via/match_note. If found=false, no verified data exists — do not guess.
Inputs: package (required), to_version (required), from_version (required), ecosystem.
list_available_mapsList available migration mapsARead-only
Lists every migration map in the store: package, ecosystem, from_version, to_version, status (draft/verified/stale), last_verified. Optional filters: ecosystem, package. Use this to discover coverage before calling get_migration.
Inputs: package, ecosystem.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 5 tools
Each tool has a clearly distinct purpose: listing maps, retrieving migration maps, getting breaking changes, static peer compatibility check, and a planned project-aware check. Descriptions provide clear boundaries and guidance to avoid confusion.
All tools follow a consistent verb_noun pattern with snake_case (check_, get_, list_). The naming is predictable and descriptive, with no mixed conventions.
With 5 tools covering migration map queries, static compatibility, and breaking changes, the count is well-scoped for the domain. Each tool earns its place without being excessive or insufficient.
The set covers core operations for package migration analysis: listing, retrieving maps, and checking static compatibility. The unimplemented check_compatibility indicates a planned feature for project-aware analysis, which is a minor gap, but the current surface is functional for its stated scope.
Maintenance
Related MCP Connectors
An MCP server that gives your AI access to the source code and docs of all public github repos
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Capability registry for the agentic economy. Semantic search over verified MCP server listings.
Find, compare, and audit software for AI agents. Scored registry of tools and MCP servers.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that provides tools to fetch live, version-accurate documentation, changelogs, examples, and method signatures for npm and PyPI packages, preventing AI coding agents from hallucinating stale APIs.7 npmISC

Vibgrate AI Contextofficial
AlicenseNot gradedqualityBmaintenanceLocal-first MCP server that gives AI assistants codebase intelligence—code graph, drift analysis, vulnerability attribution, and version-correct library docs—all from the user's machine.1,063 npm6Apache 2.0- FlicenseNot gradedqualityBmaintenanceA local-first MCP server that gives AI coding agents durable project memory, dependency graphs, and impact analysis to answer team knowledge and cross-file change questions before editing.31 npm1-
- AlicenseAqualityDmaintenanceAn MCP server that inspects AI-generated code and returns a deterministic list of structural and safety violations, so an AI coding agent can fix its own output before the code lands.2MIT