MCP Server & Tooling Landscape, September 2026

Public sample, redacted edition. This is a real deliverable with client-identifying details removed (a redaction log is kept). The substance, tables and all 80 citations are unchanged. Everything below is a snapshot as of 2026-09-25. Versions, star counts, CVE status and prices will drift, so re-check anything before you rely on it.

Prepared for: [client name redacted], a small team building local-first agent tooling

Research date: Friday 2026-09-25 (all times PT unless marked). Everything here comes from live sources read on this date. Bracketed numbers like [3] point to the Sources list at the end.

Method: I read spec pages, official blogs, READMEs, docs, NVD/OSV records, and security write-ups directly. GitHub facts (license SPDX, archived flag, stars, latest commit, latest release) were pulled from each repo’s public page and its commits.atom / releases.atom feeds on 2026-09-25 [78]. Commit and release dates are UTC dates. Star counts are a point-in-time snapshot.

0. Executive answer

Adopt now: For new work, target the 2026-07-28 spec (it’s stateless, uses Streamable HTTP + stdio, and moves Tasks into an extension) on the Tier-1 Python (v2.x) or TypeScript (v2.x) SDK or FastMCP 4.x. Run a small, pinned set of mostly vendor-maintained servers locally: Playwright MCP (browser), GitHub MCP server in --read-only mode with trimmed toolsets, MCP Toolbox for Databases / a DuckDB local server (data), and SearXNG MCP pointed at your own SearXNG (search). Put local memory on plain files (basic-memory, or mcp-memory-service with local ONNX embeddings). Run each server in a container through ToolHive or Docker MCP Gateway. For hosts that work with Ollama/vLLM, use opencode, goose (now an AAIF/Linux Foundation project), Zed, or Codex CLI. Codex has the strongest per-tool approval and allow-list controls I found.

Watch: Registry GA (it’s still “preview”), HTTP-over-stdio transport unification, DPoP and agent-identity auth, the tools/call result-shape redesign, and progressive tool discovery. All of these are on the 2026-08-22 roadmap [9].

Avoid: Unmaintained or archived hosts and servers: Continue (repo read-only), Roo Code (archived), mcphost (archived), mcp-router (archived), the self-hosted Browserbase MCP (archived), and the servers-archived reference servers (Puppeteer, SQLite, Postgres, and others). Don’t install random npm MCP packages without pinning and scanning them; the malicious postmark-mcp is the canonical example. Don’t let any tool-bearing server run with broad tokens and auto-approve on. Prompt injection through tool output is an architectural problem that no server patch fixes [63].

1. Top “adopt now” table

2. State of the spec

2.1 Current revision

• Current protocol version is 2026-07-28. Revisions are dated with the date of the last backward-incompatible change [1]. The GitHub releases list shows 2026-07-28 (stable), preceded by an RC, then 2025-11-25, 2025-06-18, 2025-03-26, and 2024-11-05 [4].
• The official blog announced it on July 28, 2026, calling out a stateless core, Multi Round-Trip Requests (MRTR), header-based routing, cacheable list results, authorization hardening, and a formal extensions framework [3].
• Adoption signal from the blog: “close to half-a-billion downloads a month” across Tier-1 SDKs, with TypeScript and Python each past 1 billion total downloads [3]. These are self-reported numbers.

2.2 What changed in 2026-07-28 (primary: changelog [2])

• Stateless. The initialize/initialized handshake is gone. Every request carries its protocol version and client capabilities in _meta. A mandatory server/discover RPC advertises versions and capabilities (SEP-2575) [2].
• No protocol sessions. Mcp-Session-Id has been removed. Servers that need state mint explicit handles and pass them back as tool arguments (SEP-2567) [2].
• MRTR replaces server-initiated requests. Servers return resultType: "input_required", and the client retries with inputResponses. This replaces server-sent elicitation/create, sampling/createMessage, and roots/list (SEP-2322) [2].
• Tasks moved out of core into the io.modelcontextprotocol/tasks extension, now polling-based (tasks/get, tasks/update) (SEP-2663) [2].
• subscriptions/listen replaces the HTTP GET stream and resources/subscribe [2].
• SSE resumability removed. A broken stream means you re-issue the request [2].
• Required Mcp-Method / Mcp-Name headers on Streamable HTTP POSTs, so gateways can route and authorize without parsing bodies (SEP-2243) [2][3].
• Cache hints. ttlMs and cacheScope on list and read results. Tools should be listed in a deterministic order [2].
• Deprecated: Roots, Sampling, and Logging (SEP-2577). The legacy HTTP+SSE transport is now formally deprecated. OAuth Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents (CIMD). Deprecated features stay for at least 12 months [1][2].

2.3 Transports

• There are two standard bindings: stdio (newline-delimited JSON-RPC to a client-launched subprocess) and Streamable HTTP (each message is a POST to a single endpoint, with replies as JSON or a request-scoped SSE stream) [5].
• Roadmap: collapse these into one HTTP model, spoken over stdio for local servers (“HTTP/2 over stdio”), and add ETag caching [9]. That makes stdio vs. HTTP a transport detail rather than a design fork. Good news for local-first setups.

2.4 Authorization

• Authorization is OPTIONAL. When it is implemented, it’s OAuth 2.1 (draft-13), servers MUST publish RFC 9728 Protected Resource Metadata, and clients SHOULD support CIMD. DCR is retained only for backward compatibility [6].
• 2026-07-28 hardening: RFC 9207 iss validation (mix-up defence), a required DCR application_type (this fixes localhost redirect rejections for CLI/desktop clients), and credentials bound to their issuer [2][3].
• Roadmap next: DPoP, workload identity federation, ID-JAG, and RFC 8693 token exchange for agent and sub-agent delegation [9].
• For the client: local stdio servers don’t need OAuth at all. OAuth matters for remote servers you expose (for example on a hosted workspace or at the edge). If you build one, implement CIMD and iss validation from day one.

2.5 Elicitation

• Two modes. Form is flat primitive schemas only. URL is out-of-band, for anything sensitive. Servers MUST NOT use form mode for passwords, API keys, or tokens [7].
• In 2026-07-28, elicitation is delivered inside an InputRequiredResult (MRTR), not as a server-initiated request [7]. URL mode is still flagged as possibly changing in future revisions [7].

2.6 Structured output

• Tools may declare outputSchema. Results can carry structuredContent, which may be any JSON value. Schemas may use any JSON Schema 2020-12 keywords (SEP-2106) [2][8].
• Tool annotations MUST be treated as untrusted unless they come from trusted servers [8].
• Honest caveat: the roadmap says returning both content and structuredContent “has confused server and client authors alike and produced diverging implementations,” and a redesign of tools/call is planned [9]. Expect this surface to change. Don’t over-invest in clever dual-format outputs.

2.7 Registry

• The official MCP Registry is still in preview: “Breaking changes or data resets may occur before general availability” [13]. The API has been frozen at v0.1 since 2025-10-24 [14].
• It’s a metadata registry (it points to npm/PyPI/Docker/remote URLs). It uses reverse-DNS namespaces verified via GitHub, DNS, or HTTP challenge. It delegates security scanning to package registries and downstream aggregators [13]. In other words, being listed ≠ being vetted.
• The official registry codebase is “not designed for self-hosting”. Private registries should implement its OpenAPI spec instead [13].
• Size: I paged the live API (/v0.1/servers?version=latest) and counted 35,953 latest-version server entries at 2026-09-25 06:51 PT [15]. That’s my own count. The API returned an HTTP 500 on one earlier full pass, so treat the figure as approximate.
• Working-group lead is from Stacklok (the ToolHive vendor) [14]. Worth knowing when you weigh ToolHive’s registry features.

2.8 Governance

• Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation, on 2025-12-09. Co-founders were Anthropic, Block, and OpenAI [11][12][80]. The LF says it “will not dictate the technical direction of MCP” [11].
• Technical governance is BDFL-style: two Lead Maintainers (David Soria Parra, Den Delimarsky) with final veto, six Core Maintainers, and membership that is individual rather than per-company [10].
• Licensing is in transition from MIT to Apache-2.0. New contributions are Apache-2.0. Older MIT contributions stay MIT until their authors consent to relicensing [10][20]. That’s why GitHub shows NOASSERTION for many official repos. Practical effect for you: both licenses are permissive, so this isn’t a problem.
• A formal feature lifecycle has been adopted (Active → Deprecated → Removed), with a minimum 12-month deprecation window [1][2].

3. SDKs

Official tiering: Tier 1 needs a 100% conformance pass, new spec features before release, triage within 2 business days, and critical fixes within 7 days. Tier 2 needs 80% conformance and new features within 6 months. Tier 3 is experimental [16].

Recommendation. For a team building local-first servers with a Python/TS split: Use FastMCP 4.x for Python tools you write quickly, and the official TS v2 packages for anything that ships to edge runtimes (TS v2 runs on Node, Bun, and Deno [18]). Build against the 2026-07-28 semantics, but test that hosts still on 2025-11-25 can talk to you. The spec defines backward compatibility for handshake-based versions [1].

4. Clients / hosts, with a focus on local models

Key fact first: Ollama is not an MCP client. A PR adding experimental MCP support to Ollama (#13700) was closed unmerged. The maintainer said they would “keep the surface area small and frozen” and pointed people to Pi instead [33]. So an MCP-aware host always sits between Ollama/vLLM and your servers.

For a single-machine home lab: run the agent host (opencode or goose) on that machine. Point it at Ollama or vLLM’s OpenAI-compatible endpoint. Run stdio servers as child processes of that host, or via ToolHive/Docker for isolation. LM Studio’s docs and Cline’s blog both warn that MCP tool schemas can swamp local-model context [26][28]. Keep your active toolset small per agent (opencode globs, Codex enabled_tools, Zed profiles).

5. Servers worth adopting, by category

Legend: Official = the vendor that owns the product or API. Ref = MCP steering-group reference server. Community = independent.

5.1 Coding / git

5.2 Filesystem

• Reference filesystem server (@modelcontextprotocol/server-filesystem). Symlink escape and prefix-match escape (CVE-2025-53109/53110) were fixed in 0.6.4 / 2025.7.01 [67][68]. It’s fine for scoped local use, but it’s still a reference implementation [20]. Most coding hosts (opencode, Zed, Codex) have built-in file tools, so in a coding host you often don’t need this server.
• DesktopCommanderMCP (community, MIT, v0.2.51, 2026-09-17 [78]) is active, but a shell-plus-filesystem server is maximal blast radius. Only use it inside a container.

5.3 Browser automation

5.4 Search / research

5.5 Memory / knowledge graphs

5.6 Databases

5.7 Local-model bridges

• mcpo (Open WebUI, MIT): wraps a stdio MCP server as an OpenAPI HTTP server [36]. It’s still what Open WebUI points to for stdio [22], but the last commit was 2026-02-27 [78]. Expect lag on 2026-07-28 features.
• ollmcp: see §4.
• mcphost: archived [78]. Don’t adopt it.
• Pattern: prefer a host with a native provider for Ollama/vLLM (opencode, goose, Cline, Zed) over a translation proxy.

5.8 Creative tooling

6. Gateways, proxies, aggregators

With 2026-07-28, gateways can route and authorize on the Mcp-Method/Mcp-Name headers without parsing JSON bodies [3]. Check that any gateway you pick has shipped 2026-07-28 support before relying on that.

7. Security

7.1 Incident / vulnerability classes, with real examples

OWASP’s MCP Top 10 is still at the beta/pilot stage, with items labelled MCP01:2025–MCP10:2025 (token exposure, scope creep, tool poisoning, supply chain, command injection, prompt injection, authn/authz, telemetry, shadow servers, context over-sharing) [64].

7.2 What the spec requires or recommends (Security Best Practices, 2026-07-28 [61])

• Token passthrough is forbidden. Servers MUST NOT accept tokens not issued to them.
• Clients doing OAuth discovery must guard against SSRF: HTTPS only, block private and link-local ranges, validate redirects.
• State handles are not authentication. Bind them to the verified user.
• For local servers: one-click install MUST show the full command and get consent. Clients SHOULD sandbox servers. Servers should prefer stdio, or require auth or use unix sockets if they use HTTP.
• Validate authorization URLs: only http(s), never launch them via a shell.

7.3 Scanners and guards (what they actually do)

7.4 Mitigations mapped to a local-first setup

1. Pin everything. Exact npm/PyPI/container versions, plus tool-description pinning (context-protector) to catch rug pulls [60][62].
2. Containerize servers (ToolHive or Docker Gateway). Mount only the project directory and deny network by default for filesystem and git servers [54][55][61].
3. Separate trust zones per agent. Don’t load an untrusted-content server (web fetch, GitHub issues, Context7) in the same session as a secret-bearing or write-capable server. This is the toxic-flow lesson [63].
4. Least-privilege tokens. GitHub fine-grained PAT scoped to specific repos, --read-only by default, lockdown mode on [37]. Read-only DB roles [48][49].
5. Approval policy. Codex default_tools_approval_mode = "writes", or Zed confirm [24][25]. Never set a global “always allow” on write tools.
6. Keep SDKs patched. Python ≥ 1.27.2 (or v2.x). TS ≥ 1.24.0 (or v2.x). Inspector ≥ 0.14.1 [66][70][71].
7. Turn off vendor telemetry where it exists (Chrome DevTools MCP) [39].

8. Mature vs. worth adopting vs. avoid

Mature (safe to build on): The spec process (dated revisions, a 12-month deprecation policy, conformance-tested tiers) [1][16]. The Tier-1 SDKs [17]. The stdio and Streamable HTTP transports [5]. Vendor-owned servers from Microsoft, Google, and GitHub that ship weekly or monthly releases [78].

Worth adopting, with conditions: FastMCP 4.x (third-party, but fast-moving and well-aligned [3][21]). ToolHive / Docker Gateway for isolation. SearXNG + basic-memory / mcp-memory-service for sovereign research and memory. MCP Toolbox and DuckDB MCP for data.

Not mature yet: The Registry (preview [13]). The tool-result shape (redesign planned [9]). URL-mode elicitation (flagged as possibly changing [7]). Agent-identity auth (roadmap [9]). Tasks (an extension, heading toward core [9]).

Avoid: - Archived or unmaintained hosts and tools: Continue [31], Roo Code [32], mcphost, mcp-router, Browserbase self-host MCP [40], servers-archived (Puppeteer, SQLite, Postgres, and others) [20]. - Stale community bridges or aggregators as critical-path components: metamcp (last release 2025-12-19), lastmile mcp-agent (last commit 2026-01-25), mcpo (last commit 2026-02-27) [78]. - Building new features on deprecated Roots, Sampling, Logging, or HTTP+SSE [2]. - Unvetted registry entries. The registry does not scan code [13].

9. Recommendations tied to the client’s stated priorities

Local-first / sovereign - Default to stdio servers launched by your host, containerized through ToolHive. Expose remote Streamable HTTP only where you need edge access, and put agentgateway or ToolHive’s gateway in front with OAuth + CIMD [6][55][57]. - Search: self-host SearXNG and use mcp-searxng [43]. Memory: basic-memory (Markdown in git) [46]. Data: DuckDB MCP [51]. - Context7 is convenient, but its backend is closed and it carries a 2026 prompt-injection CVE [41][73]. For sovereign docs retrieval, consider indexing docs yourself into basic-memory or mcp-memory-service.

No vendor lock-in - Use servers that are open source and self-hostable: Playwright MCP, GitHub MCP (local), MCP Toolbox, DuckDB, SearXNG, basic-memory, mcp-memory-service, Graphiti. Hosted-only pieces are Context7’s backend, Figma write-to-canvas (future usage-based pricing [53]), and paid search APIs. - Watch licenses. Serena moved to GPL-3.0-or-later in September 2026 [42]. basic-memory and Cherry Studio are AGPL-3.0 [78]. Fine for internal use; review before any product redistribution.

Budget-conscious - Everything in the adopt table is free to self-host. The costs are optional APIs (Brave, Exa, Tavily, Firecrawl cloud), Figma after the beta, and Docker Desktop licensing for the Toolkit UI (Docker’s terms weren’t checked here, so unknown).

Production-grade - Build on 2026-07-28 and a Tier-1 SDK. Add OTel via the _meta trace context conventions [2]. Write explicit handles for state [2]. Keep tool lists deterministic for prompt-cache hits [2]. Make pinning, containerization, and least privilege non-negotiable (§7.4).

By type of work - Agentic coding: opencode or Codex CLI + GitHub MCP (read-only, trimmed toolsets) + reference git server (patched) or host-native git + Serena (mind the GPL) + Playwright MCP for E2E. - Deep research: goose or opencode + mcp-searxng + reference fetch + basic-memory / Graphiti + DuckDB MCP. Isolate this “untrusted content” agent from write-capable coding tools. - Browser + creative: Playwright MCP (--isolated), Chrome DevTools MCP (telemetry off), mcp-for-blender (safe mode), and Figma MCP or Framelink.

10. Risks, unknowns, and things I could not verify

• Rust SDK status conflict. The blog says “beta” for 2026-07-28 support [3]; the SDK page says Tier 1 [17].
• Context7 CVE fix status for the hosted Custom AI Instructions feature: unknown. NVD lists “through 2.1.2”, but the npm MCP package is now 4.1.1 [73][78], and the version schemes may not correspond.
• Registry size. 35,953 is my own API count at 06:51 PT, and one earlier full pass hit an HTTP 500 [15]. There’s no official figure on the pages I read.
• Host-by-host support for 2026-07-28. I didn’t verify which hosts (opencode, goose, Zed, Cline, LM Studio, Open WebUI) have implemented the new stateless protocol vs. 2025-11-25. Open WebUI’s docs still reference session.initialize() timeouts [22], which suggests older-protocol clients.
• Local-model quality with MCP. I found no primary benchmark. Vendors (Open WebUI, LM Studio, Cline) warn about context bloat and weak tool use [22][26][28]. Model recommendations in third-party blogs weren’t used as evidence.
• [Redacted: one client-specific hosting platform] was not researched in this pass. Its MCP support is unknown here.
• mem0/OpenMemory MCP details, browser-use MCP details, comfyui-mcp-server details, exa/tavily/perplexity/jina server specifics: metadata only, not deep-read.
• Pricing for paid APIs and Docker Desktop: not checked.
• agentgateway governance (LF-hosted or not): not verified.
• GitHub star counts are snapshots from 2026-09-25 and are only a popularity signal, not quality.
• The unauthenticated GitHub API was rate-limited in the research environment. Repo metadata came from public HTML pages and Atom feeds instead [78]. License NOASSERTION means GitHub couldn’t classify the license file, not that there is no license.

Appendix A. Repo metadata snapshot (2026-09-25)

Sources

1. MCP Versioning: https://modelcontextprotocol.io/specification/versioning
2. MCP 2026-07-28 Changelog: https://modelcontextprotocol.io/specification/2026-07-28/changelog
3. MCP Blog, “The 2026-07-28 Specification” (2026-07-28): https://blog.modelcontextprotocol.io/posts/2026-07-28/
4. Spec releases on GitHub: https://github.com/modelcontextprotocol/modelcontextprotocol/releases
5. Transports (2026-07-28): https://modelcontextprotocol.io/specification/2026-07-28/basic/transports
6. Authorization (2026-07-28): https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization
7. Elicitation (2026-07-28): https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation
8. Tools (2026-07-28): https://modelcontextprotocol.io/specification/2026-07-28/server/tools
9. MCP Roadmap (updated 2026-08-22): https://modelcontextprotocol.io/development/roadmap
10. Governance and Stewardship: https://modelcontextprotocol.io/community/governance
11. MCP Blog, “MCP joins the Agentic AI Foundation” (2025-12-09): https://blog.modelcontextprotocol.io/posts/2025-12-09-mcp-joins-agentic-ai-foundation/
12. Linux Foundation AAIF press release: https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
13. The MCP Registry (about): https://modelcontextprotocol.io/registry/about
14. Registry repo README: https://github.com/modelcontextprotocol/registry
15. Registry API (own count, 2026-09-25 06:51 PT): https://registry.modelcontextprotocol.io/v0.1/servers?version=latest
16. SDK Tiering System: https://modelcontextprotocol.io/community/sdk-tiers
17. SDK list with tiers: https://modelcontextprotocol.io/docs/sdk
18. TypeScript SDK README: https://github.com/modelcontextprotocol/typescript-sdk
19. MCP Blog index (Ruby SDK 1.0, 2026-07-27): https://blog.modelcontextprotocol.io/
20. Reference servers README + LICENSE: https://github.com/modelcontextprotocol/servers
21. FastMCP releases: https://github.com/PrefectHQ/fastmcp/releases
22. Open WebUI MCP docs: https://docs.openwebui.com/features/extensibility/mcp/
23. opencode MCP servers docs: https://opencode.ai/docs/mcp-servers/
24. Zed MCP docs: https://zed.dev/docs/ai/mcp
25. Codex MCP docs: https://developers.openai.com/codex/mcp
26. LM Studio MCP docs: https://lmstudio.ai/docs/app/mcp
27. Cline, running models locally: https://docs.cline.bot/running-models-locally/overview
28. Cline blog, local models (compact prompt drops MCP): https://cline.bot/blog/local-models
29. Cline MCP overview: https://docs.cline.bot/mcp/mcp-overview
30. goose README: https://github.com/aaif-goose/goose
31. Continue README (read-only notice): https://github.com/continuedev/continue
32. Roo Code repo (archived): https://github.com/RooCodeInc/Roo-Code
33. Ollama PR #13700 (closed, unmerged): https://github.com/ollama/ollama/pull/13700
34. mcp-client-for-ollama (ollmcp): https://github.com/jonigl/mcp-client-for-ollama
35. mcphost (archived): https://github.com/mark3labs/mcphost
36. mcpo README: https://github.com/open-webui/mcpo
37. GitHub MCP Server README: https://github.com/github/github-mcp-server
38. Playwright MCP README: https://github.com/microsoft/playwright-mcp
39. Chrome DevTools MCP README: https://github.com/ChromeDevTools/chrome-devtools-mcp
40. Browserbase MCP (archived): https://github.com/browserbase/mcp-server-browserbase
41. Context7 README: https://github.com/upstash/context7
42. Serena LICENSE and mit-final tag: https://github.com/oraios/serena/blob/main/LICENSE ; https://github.com/oraios/serena/releases/tag/mit-final
43. mcp-searxng README: https://github.com/ihor-sokoliuk/mcp-searxng
44. Firecrawl MCP README: https://github.com/firecrawl/firecrawl-mcp-server
45. Graphiti MCP server README: https://github.com/getzep/graphiti/tree/main/mcp_server
46. basic-memory README: https://github.com/basicmachines-co/basic-memory
47. mcp-memory-service README: https://github.com/doobidoo/mcp-memory-service
48. MCP Toolbox for Databases README: https://github.com/googleapis/mcp-toolbox
49. postgres-mcp README: https://github.com/crystaldba/postgres-mcp
50. Supabase MCP README: https://github.com/supabase/mcp
51. DuckDB/MotherDuck local MCP README: https://github.com/motherduckdb/mcp-server-motherduck
52. MCP for Blender README: https://github.com/ahujasid/mcp-for-blender
53. Figma, Guide to the Figma MCP server: https://help.figma.com/hc/en-us/articles/32132100833559-Guide-to-the-Figma-MCP-server
54. Docker MCP Gateway README: https://github.com/docker/mcp-gateway
55. ToolHive README: https://github.com/stacklok/toolhive
56. IBM ContextForge README: https://github.com/IBM/mcp-context-forge
57. agentgateway README: https://github.com/agentgateway/agentgateway
58. Snyk Agent Scan README: https://github.com/snyk/agent-scan
59. Cisco AI Defense MCP Scanner README: https://github.com/cisco-ai-defense/mcp-scanner
60. Trail of Bits mcp-context-protector README: https://github.com/trailofbits/mcp-context-protector
61. MCP Security Best Practices (2026-07-28): https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices
62. Invariant Labs, Tool Poisoning Attacks (2025-04-01): https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks
63. Invariant Labs, GitHub MCP Exploited (2025-05-26): https://invariantlabs.ai/blog/mcp-github-vulnerability
64. OWASP MCP Top 10: https://owasp.org/www-project-mcp-top-10/
65. NVD CVE-2025-6514 (mcp-remote): https://nvd.nist.gov/vuln/detail/CVE-2025-6514
66. NVD CVE-2025-49596 (MCP Inspector): https://nvd.nist.gov/vuln/detail/CVE-2025-49596
67. NVD CVE-2025-53109 (filesystem symlink): https://nvd.nist.gov/vuln/detail/CVE-2025-53109
68. NVD CVE-2025-53110 (filesystem prefix): https://nvd.nist.gov/vuln/detail/CVE-2025-53110
69. NVD CVE-2025-68143 / 68144 / 68145 (mcp-server-git): https://nvd.nist.gov/vuln/detail/CVE-2025-68143 ; https://nvd.nist.gov/vuln/detail/CVE-2025-68144 ; https://nvd.nist.gov/vuln/detail/CVE-2025-68145
70. NVD CVE-2025-66414 (TS SDK DNS rebinding): https://nvd.nist.gov/vuln/detail/CVE-2025-66414
71. NVD CVE-2026-52869 (Python SDK session authz): https://nvd.nist.gov/vuln/detail/CVE-2026-52869
72. NVD CVE-2026-46519 (mcp-server-kubernetes): https://nvd.nist.gov/vuln/detail/CVE-2026-46519
73. NVD CVE-2026-75130 (Context7 prompt injection): https://nvd.nist.gov/vuln/detail/CVE-2026-75130
74. NVD CVE-2026-73496 (MCP Atlassian path traversal): https://nvd.nist.gov/vuln/detail/CVE-2026-73496
75. OSV MAL-2025-47604 (postmark-mcp): https://osv.dev/vulnerability/MAL-2025-47604
76. The Hacker News on postmark-mcp (2025-09-29): https://thehackernews.com/2025/09/first-malicious-mcp-server-found.html
77. Pi (pi.dev): https://pi.dev
78. GitHub repo pages and Atom feeds (/commits.atom, /releases.atom) for every repo in Appendix A, fetched 2026-09-25. Example: https://github.com/microsoft/playwright-mcp/releases.atom
79. mcp-router (archived, final release): https://github.com/mcp-router/mcp-router
80. Anthropic, Donating MCP and establishing the AAIF: https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation