Cline 3.5 dropped this week. The release brings two notable changes: an in-tool MCP server marketplace (browse and install servers without leaving the editor) and a per-server permissions model that addresses a real concern about giving MCP servers blanket access.
What MCP is, briefly
Model Context Protocol is the spec for connecting language models to external services — databases, APIs, file systems, custom tools. An MCP server exposes capabilities the model can invoke. Cline has supported MCP for several months, but the ecosystem has been hard to navigate.
The marketplace
Cline 3.5 adds an MCP marketplace tab. From within Cline:
- Browse available servers (Postgres, Filesystem, GitHub, Slack, custom registries)
- Read about each server’s capabilities and permissions
- Install with one click (Cline manages the npm install or equivalent)
- Configure with a UI rather than editing JSON
The marketplace is curated by the Cline team. Servers go through review before listing, addressing the concern that “any npm package can be an MCP server” creates a supply chain risk.
For the previously-painful task of finding, vetting, and installing MCP servers, this is a meaningful UX improvement. Going from “I want to add Postgres support” to “Postgres is added” used to take 15-30 minutes. Now it’s 2 minutes.
Per-server permissions
The bigger change, in my view, is the permissions model.
Previously, an MCP server in Cline had access to the same tool set as Cline itself — file system, terminal, network. This was permissive but practical. The risk: a malicious or buggy MCP server could read sensitive files, run arbitrary commands, or make network calls.
In 3.5, each MCP server runs in a sandbox with explicit permissions:
- Filesystem: read-only, read-write, or no access; scoped to specific paths
- Network: allowlist of domains; default deny
- Process: can launch subprocesses or not; no access by default
- Environment: can read env vars or not
When you install an MCP server from the marketplace, you see what permissions it requests. You can deny some, restrict scope, or accept as-is.
This is the security model that should have been in place from MCP’s launch. It’s good that it’s here now.
The default permissions per server type
The marketplace ships with reasonable defaults for common server types:
- Postgres MCP: network access to your DB only; no filesystem; no process
- Filesystem MCP: read-write on a specified directory; no network; no process
- GitHub MCP: network access to api.github.com only; read-only filesystem on the repo
- Slack MCP: network access to slack.com domain; no filesystem; no process
For users who want tighter restrictions, the UI lets you adjust each one. For users who don’t want to think about it, the defaults are reasonable.
What this enables
Several use cases that were previously friction-laden become realistic:
Database-aware coding. Install Postgres MCP, point at your dev database, ask Cline questions about your schema or have it write queries against your real data. The permission scoping means you don’t worry about Cline doing destructive things to your DB.
Codebase-aware research. Install the Filesystem MCP scoped to your monorepo, ask cross-cutting questions about the codebase. The MCP exposes file operations that go beyond Cline’s defaults — searching, batch reading, etc.
External API integration. Install GitHub MCP, ask Cline about your repos, issues, PRs. Useful for tasks like “what changed in the last week?” or “find PRs that mention X.”
Custom internal tools. Companies can write internal MCP servers for their bespoke tools (deploy commands, internal API gateways, etc.) and add them to a private marketplace.
What’s still rough
A few rough edges:
Permission UI is dense. Configuring permissions for a complex MCP server (e.g., one that needs network + filesystem + processes) is fiddly. The UI has all the controls but the cognitive load is high. Most users will accept defaults.
Marketplace is sparse. The launch marketplace has ~20 servers. Many useful patterns aren’t available yet (most internal tools, niche databases, specific cloud providers). Expect this to grow.
Permission revocation is manual. If you accidentally grant too much, you have to manually adjust per server. A “review all permissions” view would help.
No org-level marketplaces yet. Companies can’t publish private marketplaces. The roadmap mentions this; it’s not in 3.5.
Comparison to other tools
Cursor doesn’t have native MCP support; Cursor’s extensions go through VS Code’s plugin system. Cursor’s chat can use tools but not arbitrary external integrations.
Windsurf has limited MCP support; less extensive than Cline’s.
Aider doesn’t use MCP; aider is single-process.
For users who want an editor-integrated way to give the model access to external services, Cline 3.5 is meaningfully ahead.
The security story
The permissions model addresses a real concern but doesn’t fully solve it. Things to keep in mind:
Trust the marketplace. Cline’s review process helps but isn’t perfect. A malicious server that passed review and got popular would be a problem. Periodic review of installed servers is healthy paranoia.
Sandbox isn’t perfect. The process sandbox is OS-level. On Mac, Cline uses macOS’s sandbox APIs. On Linux, it’s seccomp. On Windows, it’s less mature. The protection is real but not absolute against a determined attacker.
Permissions can be too broad in defaults. “Network access to slack.com” is a specific scope; “network access” without scope is broader. Read what you grant.
For teams worried about security, the right setup is to install only servers you trust, audit the permissions you grant, and re-audit periodically. Cline 3.5 makes this possible; it doesn’t make it automatic.
Worth updating to?
Yes. The marketplace and permissions are both meaningful improvements. There’s no downside to updating — the 3.5 release is backwards-compatible with existing configs (if you have MCP servers configured, they keep working under default permissions until you adjust).
For users who haven’t tried MCP, the 3.5 marketplace is the right time to start. The friction is much lower than it was a few months ago. Try the Postgres or Filesystem servers; both add real capability without much setup time.
The MCP ecosystem is finally accessible. That’s been a long time coming.
