AI Extensions: safer MCP defaults do not replace narrower permissions

AI EXTENSIONS · 30 SEP 2026

Today’s selection connects two different boundaries: the client that transports MCP requests and the server that can act on repositories. Both repositories are maintained, but neither a popular SDK nor a read-only switch makes returned text trustworthy. This is a source review, not a package installation test or a leaderboard.

MCP Python SDK: transport and authorization defaults

The official Python SDK provides MCP clients and servers. The current latest release record is v2.2.0, published September 7, not a release today. Its notes make HTTP redirects stay within the endpoint origin, with a same-host HTTP-to-HTTPS upgrade exception; redirects elsewhere fail rather than silently moving the connection. OAuth issuer checking extends to the legacy discovery path. Legacy stateful Streamable HTTP sessions idle for 30 minutes expire, and the default session cap is 10,000; stateless and 2026-07-28 connections are not affected by that idle-session rule. These scoped defaults should not be advertised as universal prevention of credential leakage or denial of service. The release also notes tasks extension, DPoP and jwt-bearer grant gaps. The README’s setup is uv add "mcp[cli]" or pip install "mcp[cli]"; pip install mcp now chooses 2.x, and users remaining on v1 should keep an explicit <2 constraint. Pinning and testing the selected version is my recommendation, not proof of compatibility. The source LICENSE is MIT; dependencies and any connected service have separate terms. Public GitHub metadata checked September 30 shows last push September 29 at 19:11:26 UTC, 24,440 stars and 3,991 forks. Push time is activity, not proof of a stable package release or a security audit.

python-sdk · v2.2.0 · LICENSE

GitHub MCP Server: a repository operation is an effect

GitHub’s official server exposes repository and collaboration capabilities to AI clients. Latest release metadata shows v1.12.2 on September 16, adding an issue-comment update tool and granular reaction-removal tools. Those are writes with social and operational consequences, not just extra context. The README offers the hosted https://api.githubcopilot.com/mcp/ route with client-supported authentication, or a local Docker/binary route. For local use, the documented --read-only flag removes write tools even if explicitly requested; --toolsets narrows groups and --tools allows individual tools. I recommend starting with only the needed read tools and a narrowly scoped credential on a disposable repository. Read-only still permits private code to flow into the model context. Issues, comments and code can contain hostile instructions, so returned content must remain data rather than permission to act. The repository LICENSE is MIT; that does not license private repository content or settle hosted service terms. Public metadata checked September 30 shows last push September 30 at 06:14:08 UTC, 33,296 stars and 5,065 forks. Popularity signals attention, not correctness, endorsement or safety.

github-mcp-server · v1.12.2 · LICENSE · server-configuration.md

A small integration test before broad access

For the SDK, use a local fixture endpoint with synthetic tool results. Check a same-origin redirect, a different-origin redirect, an unavailable metadata endpoint and an expired legacy session. Confirm failure modes rather than enabling fallback paths merely to make the demo work. For GitHub MCP, use a repository you own containing fake issues, no secrets and no production workflows. Enumerate the exposed tools under read-only mode, ask for a harmless issue summary, and verify that an attempted write is absent or blocked. Repeat after changing tool configuration. The schematic below is an original integration plan, not a claim that these tests were run. Client logs must redact credentials. Pin package or binary versions, review dependency changes, and keep human approval outside the returned text. No package, container or server was installed or executed for this digest.

Analysis: select the boundary, not the star count

My selection criterion is a visible, testable boundary: origin and issuer checks at transport, scope and write exclusion at operations. These are useful changes and configurations, but they do not prove a model understands who owns a repository or whether a comment author has authority. A smaller tool list also reduces exposed capabilities; it does not authenticate the text it returns. Prefer documented failure to a connection that quietly acquires broader reach. The dated counts and push times are disclosed so readers can inspect maintenance signals, not to invent a "hottest" ranking. No traffic or download growth was verified.

Source review checked September 30, 2026. Versions and counts are snapshots, not recommendations based on popularity. MIT licenses verified in the original component LICENSE files. No hands-on installation.

Choose the boundary, not the star count.