{"slug": "understanding-the-v2-3-0-mcp-server-release-and-its-granular-controls", "title": "Understanding the v2.3.0 MCP Server Release and Its Granular Controls", "summary": "The Model Context Protocol servers repository published release v2.3.0 on November 4, 2026, adding opt-in operational controls and new Git tools across its filesystem, fetch and git packages. The filesystem server gains a server-wide `--read-only` flag that registers only tools annotated `readOnlyHint: true`, while the fetch server adds repeatable `--allowed-hosts` allowlisting and a configurable timeout settable via per-call `timeout_ms`, the `--timeout-ms` flag or the `FETCH_TIMEOUT_MS` environment variable, with a 30-second default and accepted values from 100 to 600,000 milliseconds. The Git server adds `git_merge`, which is fast-forward-only by default and requires a clean working tree, plus a read-only `git_remote` listing that redacts URL userinfo credentials; the release does not add push or pull operations.", "body_md": "## A Modular Approach to Server Configuration\n\nThe [official GitHub release](https://github.com/modelcontextprotocol/servers/releases/tag/v2.3.0) of the [Model Context Protocol (MCP)](https://forkast.news/glossary/mcp-security/) servers, versioned as v2.3.0 and published on November 4, 2026, introduces targeted operational controls and Git tools. Rather than a blanket lockdown, it adds opt-in filesystem and fetch settings alongside separate Git operations.\n\nOperators should be aware of the package versioning landscape in this release. While the repository is tagged v2.3.0, the individual packages follow their own versioning: the @modelcontextprotocol/server-filesystem npm package is at 2.2.0, while the mcp-server-fetch and mcp-server-git packages on PyPI are versioned 2026.11.4. The pull requests describe these additions as non-breaking overall while documenting specific compatibility caveats for callers using particular command-line or positional-argument patterns.\n\n### Filesystem Tool Filtering\n\nThe filesystem server now includes an optional `--read-only` flag, detailed in the [filesystem PR](https://github.com/modelcontextprotocol/servers/pull/5359). When enabled, the server registers only tools annotated `readOnlyHint: true`. Write-capable tools therefore do not appear in `tools/list`, and a call to an omitted tool fails as unknown. The setting applies server-wide, not as a separate read-only switch for each directory. Per-directory read-only functionality is not currently supported; the flag is strictly a server-wide toggle. Without the flag, the server behaves as before. The change was designed to make the server, rather than a client-side display preference, decide which tools are available.\n\n### Fetch Server Allowlisting and Timeouts\n\nThe fetch server adds repeatable `--allowed-hosts` entries, as outlined in the [allowlist PR](https://github.com/modelcontextprotocol/servers/pull/5392). When configured, requests must match the allowlist, including requests made for redirects and `robots.txt`. The check works alongside the server’s existing private-address guard; allowlisting an internal host does not itself disable that separate guard. Entries can be exact hostnames, wildcard subdomains such as `*.example.com`, or IP literals; schemes, ports, and paths are rejected. A wildcard subdomain entry does not include the base domain, which must be listed separately. If no allowlist is set, the prior behavior remains.\n\nThe HTTP request timeout is also configurable, as described in the [timeout PR](https://github.com/modelcontextprotocol/servers/pull/5372). It is configurable at three levels: a per-call `timeout_ms` argument, the server-wide `--timeout-ms` flag, or the `FETCH_TIMEOUT_MS` environment variable. The most specific value wins. With none set, the default remains 30 seconds; accepted values range from 100 to 600,000 milliseconds. This timeout is a request-level HTTP setting that bounds the connection phase, each read operation, and each write operation individually, rather than limiting the duration of an entire transfer. The `robots.txt` check retains the HTTP library’s separate five-second default, and the Readability extraction subprocess uses a separate timeout setting.\n\n### Git Adds Both a Merge and a Read-Only Listing\n\nThe Git server adds `git_merge`, detailed in the [merge PR](https://github.com/modelcontextprotocol/servers/pull/5363), which operates on the currently checked-out branch and is fast-forward-only by default. Setting `fast_forward_only=false` allows a merge commit. The tool requires a clean working tree and aborts a merge that fails or stops on conflicts. Separately, `git_remote` lists configured remotes and their fetch and push URLs, redacting URL userinfo credentials before returning them, as noted in the [remote PR](https://github.com/modelcontextprotocol/servers/pull/5373). The latter is a read-only listing tool; the release does not add push or pull operations. It would be misleading to describe the whole Git server as read-only simply because this one new tool is. Both tools are additive and neither changes existing configuration.\n\n### What an Upgrade Changes and What It Does Not\n\nThe release uses a repository tag and independent package versions, so operators should check the version of the package they actually install instead of assuming every component is numbered 2.3.0. The cited pull requests say the new filesystem mode and fetch settings are opt-in and leave prior behavior intact when omitted; the Git additions do not alter existing configuration. That makes the defaults legible: no flag means no new filesystem filter or fetch allowlist, and no timeout setting means the existing 30-second fetch timeout.\n\nWhile these updates are generally non-breaking, two specific scenarios require attention. First, the filesystem CLI parser now interprets `--read-only` and `--` as options; if a directory is named exactly `--read-only` or `--`, it must be provided after an option terminator (`--`). Second, in the Fetch Python library, the addition of the `allowed_hosts` parameter changes the function signature; callers currently passing `use_readability_js` as a positional argument must update their code to use it as a keyword argument. These adjustments are limited to these specific configurations and do not necessitate a broad migration for all installations.\n\nThe practical point is that the release adds controls at distinct boundaries: which filesystem tools a server exposes, which hosts a fetch server may contact, how long a request may wait, and which Git operations are available. They are configurable capabilities, not evidence that an installation adopted them or that a deployment is secure by default. Operators still need to select and review settings that match their own execution environment.", "url": "https://wpnews.pro/news/understanding-the-v2-3-0-mcp-server-release-and-its-granular-controls", "canonical_source": "https://forkast.news/understanding-the-v2-3-0-mcp-server-release-and-its-granular-controls/", "published_at": "2026-11-05 21:27:03+00:00", "updated_at": "2026-11-05 21:52:14.775320+00:00", "lang": "en", "topics": ["agent-protocols", "ai-agents", "ai-tools", "developer-tools"], "entities": ["Model Context Protocol", "@modelcontextprotocol/server-filesystem", "mcp-server-fetch", "mcp-server-git", "GitHub"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/understanding-the-v2-3-0-mcp-server-release-and-its-granular-controls", "markdown": "https://wpnews.pro/news/understanding-the-v2-3-0-mcp-server-release-and-its-granular-controls.md", "text": "https://wpnews.pro/news/understanding-the-v2-3-0-mcp-server-release-and-its-granular-controls.txt", "jsonld": "https://wpnews.pro/news/understanding-the-v2-3-0-mcp-server-release-and-its-granular-controls.jsonld"}}