Two things happened in the same 72 hours, and they point in opposite directions.
On October 6, OX Security published findings from a sweep of community-published servers across the most popular MCP marketplaces — [15,465 indexed servers](https://thehackernews.com/2026/10/welcome-to-jungle-what-we-found-inside.html), with no marketplace vetting or review process behind them. Among what they catalogued: expired domains and hosts routed through consumer tunnels. The same team had earlier traced critical vulnerabilities in Anthropic's MCP source code, which they note has been downloaded more than 150 million times. Their framing is the honest one: this repeats the GitHub mistake, where developers over-trust what a repository looks like.
Also on October 6, Atlassian announced it had [rebuilt its MCP server](https://atlassian.com/blog/company-news/team26-europe-atlassian-mcp) from the ground up, covering more products and exposing 220+ tools while claiming not to bloat the client's context. It's Atlassian-hosted, secured with OAuth 2.1 and PKCE by default, and every request respects the calling user's existing permissions. Google, meanwhile, has been [wiring Gemini MCP connectors](https://uctoday.com/google-just-wired-gemini-into-everyone-elses-stack) into Asana, Jira, and monday.com through Workspace Studio, with seven new Workspace integrations added in September.
The split that matters
First-party connectors from vendors who own the data are converging on reasonable hygiene: hosted endpoints, per-user OAuth, permission inheritance. The long tail — the servers your engineers actually `npx` into a config file on a Thursday — has none of that. If you're building an internal knowledge base or an agent with memory over company data, those two populations are the same dependency graph as far as your blast radius is concerned.
The practical consequence is that connector inventory belongs in your threat model the way npm dependencies do. Pin versions. Prefer vendor-hosted endpoints over self-published forks. Use per-user OAuth rather than a service account with a superset of everyone's permissions — that pattern quietly turns your retrieval layer into a permission-laundering machine, where the agent can surface documents the asking user was never entitled to. Log every tool call with the identity that triggered it. And test for permission leakage as a first-class eval, not just answer quality.
The second problem is context economy
Atlassian's "220+ tools without bloating your context" is an admission that tool catalogs have become a retrieval problem in their own right. Every tool definition competes with retrieved documents for the same window, and a thousand loaded tools degrade selection accuracy before they degrade latency. The answer most teams land on is lazy loading: a small resident set plus search over the catalog, resolving definitions only when the model commits to a call.
That reframes the 2026 retrieval question. Less which embedding model, more which tools and which scopes are resident at call time — and who vouched for the server behind them.