Skip to content

feat(deps): update dependency mcp (1.30.0 → 2.3.0) - #255

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/mcp-2.x
Open

feat(deps): update dependency mcp (1.30.0 → 2.3.0)#255
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/mcp-2.x

Conversation

@renovate

@renovate renovate Bot commented Aug 13, 2026 •
edited
Loading

Copy link
Copy Markdown

This PR contains the following updates:

Package Change Age Confidence
mcp >=1.0,<2.0 → >=2.3,<2.4 age confidence

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

Release Notes

modelcontextprotocol/python-sdk (mcp)

v2.3.0

Compare Source

pip install -U mcp. Docs: https://py.sdk.modelcontextprotocol.io/

Mostly fixes, plus three new options. A few things behave differently, so skim these first:

Behaviour changes

httpx2>=2.10.0 is now required (#​3600)

  • It was >=2.5.0. The new max_sse_event_size option needs it.
  • Nothing to do unless you pin httpx2 below 2.10.

A tool with an invalid x-mcp-header annotation fails at registration (#​3620)

  • @mcp.tool(), add_tool and Tool.from_function raise InvalidSignature, naming the tool and the problem.
  • Until now the server started, and 2026-07-28 clients silently dropped the tool from their listing.
  • Refused: anything other than a plain str, int or bool parameter (so also str | None, float, lists and enums), a header name that isn't a valid token, and two names that differ only by case.
  • For an optional header parameter, give the schema directly: Annotated[str | None, WithJsonSchema({"type": "string", "x-mcp-header": "Region"})] = None.

Empty _meta and params are no longer sent (#​3628)

  • On 2025-11-25 and earlier connections, 2.x sent "_meta": {} on every request. Some servers reject that. It is now left out, as in v1.
  • ping and list requests without a cursor go out with no params member.
  • On the receiving side ctx.meta is None rather than {}, and middleware sees ctx.params as None for a request without params.
  • 2026-07-28 connections are unchanged.

initialize leaves out experimental when none is configured (#​3614)

  • It used to send "experimental": {}. server/discover already left it out.
  • Client code reading capabilities.experimental on a legacy connection should handle None.

Mcp-Param-* validation looks the tool up by name (#​3630)

  • MCPServer no longer runs tools/list for every tools/call, so middleware no longer sees that extra request.
  • The registered schema is what gets checked. Middleware that filters or rewrites tools/list no longer affects it.

An interactive OAuth login no longer counts against request timeouts (#​3635)

  • The timeout pauses while OAuthClientProvider waits on redirect_handler and callback_handler.
  • This fixes Client(mode="auto") settling on 2025-11-25 when the login took longer than 10 seconds.
  • A request timeout no longer ends a login nobody finishes. Put a limit inside callback_handler if you need one.

New

  • max_sse_event_size= on streamable_http_client and StreamableHttpParameters. The default stays 1 MiB per SSE event; raise it, or pass None, for larger tool results (#​3600).
  • MCPServer(subscriptions=False) stops serving subscriptions/listen and advertises listChanged and subscribe as false (#​3626).
  • Server(get_tool_input_schema=...) lets a low-level server supply a tool's schema for header validation without running its tools/list handler (#​3630).
  • Client.call_tool re-lists the tools and retries once after a HeaderMismatch (-32020) rejection (#​3627).

Fixes

  • ctx: Context[AppState] works on prompts and resource templates, not only on tools (#​3624).
  • An explicit "structuredContent": null is checked against the output schema instead of being treated as missing (#​3621).
  • A progress_callback that raises no longer fails the call on an in-process Client(server) (#​3623).
  • Client OpenTelemetry spans record JSON-RPC error responses. With mode="auto", connecting to a server without server/discover now shows one ERROR span for the probe (#​3629).
  • stdio_client resolves the executable off the event loop on Windows (#​3510).

Docs

What's Changed

Full Changelog: modelcontextprotocol/python-sdk@v2.2.0...v2.3.0

v2.2.0

Compare Source

pip install -U mcp. Docs: https://py.sdk.modelcontextprotocol.io/

A few defaults changed in this release. If you run a server or client on 2.x, skim these first:

Behaviour changes

HTTP client redirects are only followed within the endpoint's origin (#​3397)

  • Client("https://..."), streamable_http_client and sse_client follow a redirect only if it stays on the same scheme, host and port (or upgrades http to https on the same host).
  • A redirect anywhere else is not followed: the call fails with MCPError and the session stays usable (an SSE connect fails with httpx2.HTTPStatusError). If that other URL is the server you meant, use it as the endpoint URL.
  • The follow_redirects setting on an httpx2.AsyncClient you pass in is no longer used for MCP requests, so you don't need it for the trailing-slash redirect any more.
  • The OAuth providers apply the same rule to their own requests.

Idle Streamable HTTP sessions now expire (legacy <=2025-11-25 spec( (#​3395)

  • A stateful session with nothing in flight for 30 minutes is closed. The client's next request gets a 404 and it has to initialize again.
  • Clients that keep the GET stream open (the SDK's Client does) are not affected. Neither are stateless servers or 2026-07-28 connections.
  • A server also holds at most 10 000 sessions at once; beyond that, new sessions get a 503.
  • To turn either off: mcp.run(transport="streamable-http", session_idle_timeout=None, max_sessions=None) (also on streamable_http_app() and run_streamable_http_async()).

The OAuth client checks the authorization server's issuer on the legacy path too (#​3398)

  • For servers without protected resource metadata, authorization server metadata whose issuer isn't the server's own origin is now rejected with OAuthFlowError: Authorization server metadata issuer mismatch. The protected-resource-metadata path has done this since 2.0.
  • A 403 that isn't an insufficient_scope challenge is returned to the caller instead of retried.
  • If protected resource metadata can't be fetched because of a 5xx/429, the flow now stops instead of falling back to the legacy endpoints.

Two new MCPDeprecationWarnings (#​3435, #​3447)

  • ClientCredentialsOAuthProvider / PrivateKeyJWTOAuthProvider without issuer=. Pass your authorization server's issuer URL; 3.0 will require it.
  • AuthSettings with resource_server_url set but validate_token_resource unset. Set it to True or False; 3.0 defaults it to True.
  • Both keep working as before in 2.x; this mostly matters if your tests turn warnings into errors.

New

  • AuthSettings.validate_token_resource: only accept tokens your TokenVerifier reports as issued for this server (#​3447).
  • issuer= on ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider (#​3398).
  • session_idle_timeout= and max_sessions= on the Streamable HTTP server entry points (#​3395).

Fixes

  • A client DELETE frees its session immediately, and a refused opening request no longer leaves a session behind (#​2455, #​3228, #​3300).
  • $refs in a tool's outputSchema resolve within that schema only; an unresolvable one surfaces as RuntimeError: Invalid schema for tool ... (#​3394).

Known gaps

The tasks extension (SEP-2663), DPoP (SEP-1932) and the jwt-bearer grant are not implemented yet; https://github.com/modelcontextprotocol/python-sdk/blob/main/ROADMAP.md tracks them.

What's Changed

Full Changelog: modelcontextprotocol/python-sdk@v2.1.1...v2.2.0

v2.1.1

Compare Source

What's Changed

Full Changelog: modelcontextprotocol/python-sdk@v2.1.0...v2.1.1

v2.1.0

Compare Source

Highlights

  • Client accepts StdioServerParameters directly: Client(StdioServerParameters(command="uv", args=["run", "server.py"])) (#​3321).
  • Prompt messages accept Image and Audio, prompt functions may return bare content blocks, and Message / UserMessage / AssistantMessage are exported from mcp.server.mcpserver (#​3320).
  • The 4 MiB request body limit now also covers the SSE transport and the OAuth endpoints; SseServerTransport and MCPServer.sse_app() take max_request_body_size, and the SSE message endpoint answers 405 to non-POST requests (#​3336).

Behaviour changes to be aware of

  • Handler exceptions (#​3314): an unexpected exception from a tool, resource or prompt handler is logged once at ERROR with its traceback, and the client now sees only Error executing tool <name> (or the resource/prompt equivalent) rather than the exception text. Raise ToolError / ResourceError when the message is meant for the model; those still reach the client and are logged at INFO without a traceback.
  • Content-block return annotations (#​3320): a tool annotated to return TextContent, EmbeddedResource, Image, Audio, or lists/unions of them no longer advertises outputSchema or returns structuredContent; its content is unchanged. Pass structured_output=True to keep the previous shape.

Fixes

  • TypedDict tool results: NotRequired keys are omitted instead of serialized as null, and registration no longer fails on Python 3.10 (#​3224, #​3227); recursive return types get an object-rooted outputSchema that pre-2026 clients accept (#​3337).
  • 2026-07-28 over HTTP: a POSTed notification such as notifications/cancelled is acknowledged with 202 instead of rejected with 400 (#​3324).
  • Pre-2026 sessions ignore cache-hint fields from later revisions instead of failing list_tools() (#​3223), and accept boolean sub-schemas in tool schema properties (#​3353).
  • mcp install reads and preserves a Claude Desktop config containing non-ASCII text on any Windows code page (#​3296).

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/python-sdk@v2.0.0...v2.1.0

v2.0.1

Compare Source

One off backport of the FastMCP import warning for 2.0.x, this is due to a lot of people running into this error and making issues on other repos about it. Ideally either pin mcp<2 or upgrade to 2.

What's Changed

Full Changelog: modelcontextprotocol/python-sdk@v2.0.0...v2.0.1

v2.0.0

Compare Source

MCP Python SDK v2 Stable Release

This is v2.0.0, the stable v2 release of the MCP Python SDK. It supports the 2026-07-28 revision of the Model Context Protocol and serves every earlier revision from the same server. pip install mcp now installs 2.x.

pip install "mcp[cli]"

# or
uv add "mcp[cli]"
Documentation Rewrite

The documentation has the full tutorial and API reference. Coming from v1? What's new in v2 is the tour of what changed and why, and the migration guide lists every breaking change with before-and-after code.

V1 Maintenance mode

v1.x is in maintenance mode and will only receive security fixes from now on The 1.x line lives on the v1.x branch, continues to receive critical bug fixes and security patches, and is documented at https://py.sdk.modelcontextprotocol.io/v1/. If your project is not ready to migrate, keep a <2 upper bound on your requirement (for example mcp>=1.28,<2).

Highlights

One SDK, both protocol eras

v2 speaks the 2026-07-28 revision (stateless requests with no handshake, server/discover, subscriptions/listen, multi-round-trip requests) and still serves every 2025-era client from the same MCPServer, over Streamable HTTP and stdio, with nothing to configure. Client(target) negotiates the version automatically.

FastMCP is now MCPServer, and there is a first-class Client

The decorator API is unchanged; the low-level Server is rebuilt around a shared dispatcher engine, and one Client object replaces v1's transport-plus-ClientSession-plus-initialize() layering. It connects to a URL, a stdio subprocess, a custom transport, or straight to a server object in memory for tests.

Multi-round-trip requests and resolver dependency injection

At 2026-07-28 the server can no longer call the client, so tools return the question instead. A Resolve(fn) parameter is filled by your function invisibly to the model and can put a question to the user; one tool body serves both eras.

Extension APIs, OpenTelemetry, and a standalone types package

Servers and clients compose protocol extensions through pluggable extension APIs (MCP Apps built in); OpenTelemetry tracing ships on by default; every protocol type is its own package, mcp-types (imported as mcp_types), published in lock-step with mcp.

Hardened stdio and auth

stdio servers keep handler subprocesses and stray prints off the wire, and stdout is diverted to stderr while serving. OAuth adds RFC 9207 issuer validation, the SEP-990 identity-assertion flow, and the client-credentials extension.

Coming from a v2 pre-release

Since the last release candidate: the per-version wire packages are private (mcp_types._v*), mcp.types is a permanent alias for mcp_types, the auth registration request model is split from the registered-client record, cancelled requests are no longer answered, and log notifications are gated on the per-request log-level opt-in at 2026-07-28. Since the betas: Client(cache=False) is now cache=None with CacheConfig() the default; Context.client_id, RFC7523OAuthClientProvider, and OAuthClientProvider(timeout=) are removed; the client-credentials providers take scope=; message_handler receives notifications and exceptions only; FileResource(is_binary=) becomes encoding; MCP_* env vars are gone with pydantic-settings; Streamable HTTP servers reject bodies over 4 MiB with HTTP 413. The migration guide covers all of it.

Known gaps

The tasks extension (SEP-2663) is not part of this release. On the client, the DPoP proof binding (SEP-1932) and the workload-identity jwt-bearer grant are not implemented; both are additive and can land in 2.x.

Feedback

Something rough, confusing, or broken? Open an issue or find us in #python-sdk-dev on the MCP Contributors Discord.

Full Changelog: modelcontextprotocol/python-sdk@v2.0.0rc1...v2.0.0

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate Bot added the type/major label Aug 13, 2026
@renovate

renovate Bot commented Aug 13, 2026

Copy link
Copy Markdown
Author

⚠️ Artifact update problem

Renovate failed to update artifacts related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

  • any of the package files in this branch needs updating, or
  • the branch becomes conflicted, or
  • you click the rebase/retry checkbox if found above, or
  • you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: undefined
Post-upgrade command 'helm-docs --chart-search-root=. --log-level=warn' has not been added to the allowed list in allowedCommands
File name: undefined
Post-upgrade command 'helm-schema --chart-search-root . --skip-auto-generation required,additionalProperties --append-newline' has not been added to the allowed list in allowedCommands

@github-actions

github-actions Bot commented Aug 13, 2026

Copy link
Copy Markdown

User renovate[bot] does not have write permissions

github run

@github-actions github-actions Bot mentioned this pull request Aug 15, 2026
Closed
@github-actions

github-actions Bot commented Aug 15, 2026

Copy link
Copy Markdown

Renovate PR Analysis

Update Summary

Release Changes

  • v2.0.0 stable: supports the 2026-07-28 protocol revision while still serving 2025-era clients from the same server; stdio + Streamable HTTP only.
  • FastMCP renamed to MCPServer; all mcp.server.fastmcp.* submodules moved to mcp.server.mcpserver.*. Decorator API (@mcp.tool()) unchanged.
  • New first-class Client, Resolve() dependency injection for multi-round-trip requests, pluggable extension APIs (MCP Apps), OpenTelemetry tracing on by default, protocol types split into mcp-types (exact-pinned).
  • Dependency changes: httpx/httpx-sse dropped in favor of httpx2 (system trust store via truststore instead of certifi); floors raised (pydantic >=2.12, anyio >=4.9, typing-extensions >=4.13, sse-starlette >=3.0).
  • Hardened stdio: protocol streams on private descriptors, stray stdout diverted to stderr; OAuth adds RFC 9207 issuer validation.
  • v1.x is now in maintenance mode (security fixes only).

Breaking Changes

Affecting this repo directly:

  1. from mcp.server.fastmcp import FastMCP fails on v2 (ModuleNotFoundError — verified: src/mcp/server/fastmcp/ exists at tag v1.29.0, absent at v2.0.0, replaced by mcpserver/). Used at:

    • apps/kicad-mcp/src/kicad_mcp/server.py:16
    • apps/opengist-mcp/src/opengist_mcp/server.py:17

    Both servers crash at startup; supergateway's stdio child (python3 -m kicad_mcp / python3 -m opengist_mcp) would exit immediately.

  2. The existing tests would NOT catch this: both tests.yaml files only run import kicad_mcp / import opengist_mcp, which loads __init__.py (docstring + __version__) and never imports server.py.

  3. Dockerfiles not updated by this PR: apps/kicad-mcp/Dockerfile:89 and apps/opengist-mcp/Dockerfile:44 still pin "mcp[cli]>=1.0,<2.0" in pip3 install. As-is, the images keep installing mcp 1.x regardless of the pyproject.toml change — the PR alone changes nothing at runtime, and after fixing the code it would actively conflict.

Not affecting our usage (verified): mcp.run(transport="stdio") remains valid (transport params moved to run(), which is how we call it); no MCP_* env vars in use (grep -r MCP_ apps/ → no matches); sync def tools now run on worker threads, but kicad-mcp's sync tools (list_kicad_projects, open_project, list_kibot_configs, health) don't touch asyncio; our own httpx usage (opengist-mcp client, kicad-mcp Dockerfile) is a direct dependency and co-installs fine alongside mcp v2's httpx2; we don't use Streamable HTTP, OAuth, WebSocket transport, or mcp.types field names.

Code Changes Required

Yes — this PR must not merge without them:

  1. apps/kicad-mcp/src/kicad_mcp/server.py:16 → from mcp.server.mcpserver import MCPServer
  2. apps/kicad-mcp/src/kicad_mcp/server.py:33 → mcp = MCPServer("kicad-mcp")
  3. apps/opengist-mcp/src/opengist_mcp/server.py:17 → same import change
  4. apps/opengist-mcp/src/opengist_mcp/server.py:27 → mcp = MCPServer("opengist-mcp")
  5. apps/kicad-mcp/Dockerfile:89 → "mcp[cli]>=2,<2.1" (keep in sync with pyproject.toml)
  6. apps/opengist-mcp/Dockerfile:44 → "mcp[cli]>=2,<2.1"
  7. Recommended: add a command test to both tests.yaml (e.g. python3 -c "from kicad_mcp import server") so a broken SDK import fails CI instead of only failing at runtime.
  8. Note: kicad-mcp co-installs unpinned kibot/skidl/kiutils — watch pip resolution against the new pydantic >=2.12 floor during the build.

Security Impact

Positive overall: hardened stdio (stray prints/handler subprocesses kept off the wire), OAuth issuer validation, stricter protocol validation. Not directly on our threat surface (stdio transport, in-cluster, no inbound auth). No known CVE against 1.29.0; v1.x continues to receive security fixes, so staying on 1.x short-term carries no immediate risk.

Recommendation

Requires code changes — MCP SDK is an explicit no-auto-merge category (tool call parsing), and this major bump breaks both servers at startup (ModuleNotFoundError on mcp.server.fastmcp) while the PR only touches pyproject.toml. The Dockerfile pins would keep the images on 1.x anyway, so the PR is also internally inconsistent as-is. Apply the import/pin changes above (plus a server-import smoke test), rebuild with task local-build-kicad-mcp / task local-build-opengist-mcp, then merge as a coordinated change. Keeping the <2 upper bound and closing this PR is a valid alternative while v1 remains in security maintenance.

@renovate
renovate Bot force-pushed the renovate/mcp-2.x branch from f8991fc to 76b3e9e Compare August 20, 2026 13:48
@github-actions

github-actions Bot commented Aug 20, 2026

Copy link
Copy Markdown

Renovate PR Analysis

Update Summary

  • Dependency: mcp[cli] — MCP Python SDK (modelcontextprotocol/python-sdk)
  • Version: >=1.0,<2.0 → >=2,<2.1 (effective 1.29.0 → 2.0.0)
  • Type: major
  • Files changed: apps/kicad-mcp/src/kicad_mcp/pyproject.toml, apps/opengist-mcp/src/opengist_mcp/pyproject.toml (only)

Release Changes

v2.0.0 is the stable v2 release, supporting the 2026-07-28 protocol revision while still serving 2025-era clients from the same server over stdio and Streamable HTTP (release notes, migration guide):

  • FastMCP renamed to MCPServer (from mcp.server.mcpserver import MCPServer); new first-class Client
  • mcp-types split into a standalone exact-pinned package; mcp.types remains a permanent alias
  • httpx/httpx-sse replaced by httpx2 — mcp no longer installs httpx
  • New required deps: httpx2>=2.5.0, opentelemetry-api>=1.28.0 (OTel tracing on by default), mcp-types==<mcp version>; floors raised: anyio>=4.9, pydantic>=2.12, sse-starlette>=3.0, typing-extensions>=4.13
  • Hardened stdio: protocol streams kept on private descriptors; stray stdout diverted to stderr while serving
  • Stricter wire validation: handler results validated against the protocol schema; unknown methods return -32601; Streamable HTTP bodies >4 MiB rejected with 413
  • OAuth hardening (RFC 9207 issuer validation, SEP-990 identity assertion, client-credentials) — not used by our servers
  • v1.x enters maintenance mode: security fixes only

Breaking Changes

Yes — directly affecting this repo:

  1. Both servers import the removed module: apps/kicad-mcp/src/kicad_mcp/server.py:16 and apps/opengist-mcp/src/opengist_mcp/server.py:17 use from mcp.server.fastmcp import FastMCP. On mcp 2.x this raises ModuleNotFoundError: No module named 'mcp.server.fastmcp' at startup (listed in the migration guide as the first symptom almost every project hits). Both containers crash-loop; opengist-mcp's pytest suite (from opengist_mcp import server) fails too.
  2. The PR is internally inconsistent: the images do not install from pyproject.toml — the Dockerfiles pip-install the pin directly (apps/kicad-mcp/Dockerfile:89, apps/opengist-mcp/Dockerfile:44, both still "mcp[cli]>=1.0,<2.0") and only COPY the package source. Merged as-is, built images keep mcp 1.x while pyproject.toml claims v2.
  3. httpx removal by mcp: verified non-issue — both apps declare httpx as their own direct dependency (pyproject + Dockerfile pip lines), so it stays installed for their own client code.

Verified compatible surfaces (migration guide "What is unchanged on MCPServer"): @mcp.tool() decorator arguments and handler signatures, tool return wrapping, and run(transport="stdio") all carry over. Both servers pass explicit names, so the default-name change doesn't apply. Sync tool handlers now run on worker threads — the kicad-mcp handlers are sync subprocess calls, which is compatible.

Code Changes Required

  1. apps/kicad-mcp/src/kicad_mcp/server.py:16,33 — from mcp.server.fastmcp import FastMCP → from mcp.server.mcpserver import MCPServer; mcp = FastMCP("kicad-mcp") → mcp = MCPServer("kicad-mcp")
  2. apps/opengist-mcp/src/opengist_mcp/server.py:17,27 — same rename, MCPServer("opengist-mcp")
  3. apps/kicad-mcp/Dockerfile:89 and apps/opengist-mcp/Dockerfile:44 — "mcp[cli]>=1.0,<2.0" → "mcp[cli]>=2,<2.1" so the images actually pick up v2 (otherwise the pin change is metadata-only)
  4. Validate: run pytest src/opengist_mcp/tests/ locally, then task local-build-kicad-mcp / task local-build-opengist-mcp (build + container-structure-test). Consider adding a structure-test command asserting python3 -c "from mcp.server.mcpserver import MCPServer" so import breakage is caught at test time
  5. No toolchain bump needed: both images run Python 3.13, supported by v2; new transitive deps (httpx2, mcp-types, opentelemetry-api) resolve via pip

Security Impact

v2 hardens stdio (stray output can no longer corrupt the protocol stream — directly relevant to the supergateway stdio bridge both images use) and tightens wire validation. The OAuth/RFC 9207 changes don't apply (in-cluster, no MCP-level auth). No CVEs cited. Staying on v1.x is viable short-term (maintenance mode, security fixes only) but is a dead end for features.

Recommendation

Needs manual review — do not merge as-is. This is a major bump of the MCP SDK powering both MCP servers (excluded from auto-merge: LLM/AI tooling affects tool call parsing), the v1→v2 rename guarantees a startup crash of both servers the moment the Dockerfile pins are aligned, and the PR currently updates only pyproject.toml while the actual image install pins in both Dockerfiles remain <2.0. Migrate per "Code Changes Required" above as a dedicated change with build + test validation, then let this PR (or its successor) carry the pin.

@renovate
renovate Bot force-pushed the renovate/mcp-2.x branch from 76b3e9e to bdb70df Compare August 29, 2026 05:31
@renovate renovate Bot changed the title feat(deps): update dependency mcp (1.29.0 → 2.0.0) feat(deps): update dependency mcp (1.29.1 → 2.1.1) Aug 29, 2026
@github-actions

github-actions Bot commented Aug 29, 2026

Copy link
Copy Markdown

Renovate PR Analysis

Update Summary

  • Dependency: mcp[cli] — MCP Python SDK (modelcontextprotocol/python-sdk)
  • Version: >=1.0,<2.0 → >=2.1,<2.2 (effective 1.29.1 → 2.1.1)
  • Type: major
  • Files changed: apps/kicad-mcp/src/kicad_mcp/pyproject.toml:13, apps/opengist-mcp/src/opengist_mcp/pyproject.toml:13 (only)
  • Note: re-analysis of a previously reviewed PR — the pin moved from >=2,<2.1 (2.0.0) to >=2.1,<2.2 (2.1.1) since the last report; v2.1.x additions are folded in below.

Release Changes

v2.0.0 is the stable v2 rewrite (2026-07-28 protocol revision, 2025-era clients still served from the same server over stdio/Streamable HTTP):

  • FastMCP renamed to MCPServer; first-class Client; decorator API carried over
  • mcp-types split into a standalone exact-pinned package (mcp.types remains an alias); new deps: httpx2, opentelemetry-api (tracing on by default), floors raised (pydantic>=2.12, anyio>=4.9)
  • mcp.server.fastmcp removed — 2.1.1 makes the module a pointer to the migration guide
  • Hardened stdio (stray stdout diverted to stderr while serving — directly relevant to the supergateway stdio bridge both images use); Streamable HTTP bodies >4 MiB → 413
  • v1.x is in maintenance mode (security fixes only)

v2.1.0 additions (release):

  • Client accepts StdioServerParameters directly; prompt messages accept Image/Audio
  • 4 MiB request limit extended to SSE transport and OAuth endpoints; SSE message endpoint answers 405 to non-POST
  • POSTed notifications (e.g. notifications/cancelled) acknowledged with 202 on the 2026-07-28 HTTP entry
  • Fixes: TypedDict tool results (NotRequired keys omitted, Python 3.10 registration), recursive return types get object-rooted outputSchema, pre-2026 session cache-hint/boolean sub-schema compatibility

Breaking Changes

Yes — directly affecting this repo:

  1. Both servers import the removed module: apps/kicad-mcp/src/kicad_mcp/server.py:16 and apps/opengist-mcp/src/opengist_mcp/server.py:17 use from mcp.server.fastmcp import FastMCP. On mcp 2.x this raises an import error pointing at the migration guide — both containers crash-loop the moment the images actually install v2; opengist-mcp's pytest suite (imports server) fails too.
  2. The PR is internally inconsistent: the images do not install from pyproject.toml — both Dockerfiles pip-install the pin directly (apps/kicad-mcp/Dockerfile:89, apps/opengist-mcp/Dockerfile:44, both still "mcp[cli]>=1.0,<2.0") and only COPY the source (PYTHONPATH=/app). Merged as-is, built images keep mcp 1.x while pyproject.toml claims 2.1.
  3. v2.1.0 behavior change (handler exceptions): unexpected exceptions are logged once at ERROR and the client sees only Error executing tool <name>. Both servers already wrap tool bodies in except Exception and return JSON error payloads, so their wire contract is unaffected — but any future code path that lets an exception escape loses its message.

Code Changes Required

  1. apps/kicad-mcp/src/kicad_mcp/server.py:16,33 — from mcp.server.fastmcp import FastMCP → from mcp.server.mcpserver import MCPServer; mcp = FastMCP("kicad-mcp") → mcp = MCPServer("kicad-mcp")
  2. apps/opengist-mcp/src/opengist_mcp/server.py:17,27 — same rename, MCPServer("opengist-mcp")
  3. apps/kicad-mcp/Dockerfile:89 and apps/opengist-mcp/Dockerfile:44 — "mcp[cli]>=1.0,<2.0" → "mcp[cli]>=2.1,<2.2" so the images actually pick up v2 (otherwise this PR is metadata-only)
  4. Validate: pytest under apps/opengist-mcp/src/, then task local-build-kicad-mcp / task local-build-opengist-mcp (build + structure tests). Consider a structure-test command asserting python3 -c "from mcp.server.mcpserver import MCPServer" so import breakage is caught at test time
  5. No toolchain bump needed: both images run Python 3.13 (Ubuntu 24.04 / python:3.13-alpine), supported by v2; new transitive deps resolve via pip

Per the migration guide, @mcp.tool() decorator arguments, handler signatures, tool return wrapping, and run(transport="stdio") are unchanged on MCPServer, so the tool surface itself ports mechanically.

Security Impact

v2 hardens stdio (stray output can no longer corrupt the protocol stream — relevant to the supergateway bridge) and tightens wire validation; v2.1.0 extends the 4 MiB body limit across SSE/OAuth endpoints (DoS hardening). The OAuth/RFC 9207 additions don't apply (in-cluster, no MCP-level auth). No CVEs cited. Staying on v1.x remains viable short-term (security fixes only) but is a dead end.

Recommendation

Needs manual review — do not merge as-is. This hits two never-auto-merge exclusions: a major bump with breaking changes relevant to this repo, and an LLM/AI SDK (MCP servers affect tool call parsing). The PR updates only pyproject.toml while the actual image install pins in both Dockerfiles remain <2.0, and the v1→v2 import rename guarantees a startup crash of both servers once the pins are aligned. Apply the changes in "Code Changes Required" as a dedicated change with build + test validation, then let this PR (or its successor) carry the pin.

@renovate
renovate Bot force-pushed the renovate/mcp-2.x branch from bdb70df to 8bdce7d Compare September 2, 2026 22:45
@github-actions

github-actions Bot commented Sep 2, 2026

Copy link
Copy Markdown

Renovate PR Analysis

Update Summary

  • Dependency: mcp (PyPI — official Model Context Protocol Python SDK, modelcontextprotocol/python-sdk)
  • Version: >=1.0,<2.0 → >=2.1,<2.2 (effective resolution 1.29.1 → 2.1.1)
  • Type: major
  • Files changed: apps/kicad-mcp/src/kicad_mcp/pyproject.toml, apps/opengist-mcp/src/opengist_mcp/pyproject.toml

Release Changes

  • v2.0.0 (stable v2): supports the 2026-07-28 protocol revision while still serving 2025-era clients from one server; FastMCP renamed MCPServer; new first-class Client object replacing ClientSession layering; Resolve() dependency injection for multi-round-trip requests; extension APIs (MCP Apps); OpenTelemetry tracing on by default; protocol types split into standalone mcp-types package (mcp.types stays as alias); hardened stdio — stdout diverted to stderr while serving; OAuth RFC 9207 issuer validation, SEP-990 identity assertions, client-credentials extension; MCP_* env vars removed; Streamable HTTP bodies >4 MiB rejected with 413. v1.x is now in maintenance mode (security fixes only).
  • v2.0.1 / v2.1.1: imports of mcp.server.fastmcp now raise/point at the migration guide (added because many users hit this exact breakage). Migration guide: https://py.sdk.modelcontextprotocol.io/migration/
  • v2.1.0: Client accepts StdioServerParameters directly; prompt messages accept Image/Audio; 4 MiB body limit extended to SSE + OAuth endpoints; behavior changes — handler exceptions are logged server-side and the client only sees Error executing tool <name> (raise ToolError for model-facing messages); tools annotated to return content-block types no longer advertise outputSchema/structuredContent (opt back in with structured_output=True); various interop fixes for pre-2026 clients.

Breaking Changes

Directly affecting this repo — the servers will not start on mcp 2.x:

  1. Both servers import the removed symbol: from mcp.server.fastmcp import FastMCP at apps/kicad-mcp/src/kicad_mcp/server.py:16 and apps/opengist-mcp/src/opengist_mcp/server.py:17, then instantiate FastMCP("...") (server.py:33 / :27). In v2 this import fails with a pointer to the migration guide; the class is MCPServer. The stdio child (python3 -m kicad_mcp / python3 -m opengist_mcp, spawned by supergateway per the ENTRYPOINTs) crashes at import time → both containers become unusable at runtime.
  2. The PR is internally inconsistent: the built images install mcp from the Dockerfiles, not from pyproject — apps/kicad-mcp/Dockerfile:89 and apps/opengist-mcp/Dockerfile:44 both pin "mcp[cli]>=1.0,<2.0". Source is COPY'd to /app and run via PYTHONPATH=/app (no pip install of the package), so merging this as-is leaves pyproject declaring 2.1.x while the images still ship 1.29.x.
  3. Behavioral (after migration): tool errors raised as raw exceptions would surface to the LLM as Error executing tool <name> instead of exception text — both servers currently catch exceptions themselves and return JSON strings, so impact is limited, but worth reviewing during migration. The @mcp.tool() decorator API is unchanged per the release notes.

Code Changes Required

Required before this bump can merge (a maintainer must apply — read-only checkout here):

  1. apps/kicad-mcp/src/kicad_mcp/server.py:16 and apps/opengist-mcp/src/opengist_mcp/server.py:17 — migrate FastMCP → MCPServer per the v2 migration guide (import path and constructor).
  2. Verify mcp.run(transport="stdio") (server.py:270 / server.py:428) against the migration guide; the decorator API is documented as unchanged, but the run/transport surface should be confirmed.
  3. Update the Dockerfile constraints to match: apps/kicad-mcp/Dockerfile:89, apps/opengist-mcp/Dockerfile:44 (mcp[cli]>=1.0,<2.0 → >=2.1,<2.2), otherwise image and pyproject diverge.
  4. Strengthen tests so CI catches this class of break: both tests.yaml only run import kicad_mcp / import opengist_mcp, which import __init__.py only and never server.py — that's why kicad-mcp's Build check passed green on this PR despite the fatal incompatibility. Add a command test like python3 -c "import kicad_mcp.server" (same for opengist_mcp).
  5. Unrelated but merge-blocking for this app: Build opengist-mcp / Build (linux/amd64) fails on a pre-existing metadata mismatch — apps/opengist-mcp/Dockerfile:61 sets USER app:app while apps/opengist-mcp/tests.yaml:29 expects user: "app". Both files are unchanged since the app's introduction in feat: add opengist-mcp — MCP server for Opengist #243, so this fails on main too and blocks any opengist-mcp PR until the test (or USER directive) is fixed.

Security Impact

No CVE driving urgency. Long-term: v1.x is maintenance-mode (security fixes only), so remaining on 1.x accumulates risk. v2 hardening is net-positive for this deployment: keeping stray stdout off the stdio wire protects the supergateway JSON-RPC stream, and OAuth hardening applies if auth is ever added (currently in-cluster, no auth). Python compatibility is fine: opengist-mcp base python:3.13-alpine3.21, kicad-mcp Ubuntu 24.04 python3 (3.12) — both satisfy mcp 2.x and the apps' requires-python >=3.11; no toolchain bump needed.

Recommendation

Requires code changes — do not merge. Both MCP servers fatal at startup on mcp 2.x (FastMCP import removed), the PR's pyproject bump diverges from the Dockerfiles' <2.0 pins so images would keep shipping 1.x anyway, and CI cannot detect the break because the structure tests never import server.py. This also falls under the repo's never-auto-merge exclusions (major bump of an LLM/AI SDK powering the kicad-mcp and opengist-mcp tool surfaces). Either close this PR and keep the <2.0 pin until a migration PR lands the five changes above, or supersede it with a combined migration PR.

@renovate
renovate Bot force-pushed the renovate/mcp-2.x branch from 8bdce7d to fbba466 Compare September 7, 2026 23:49
@renovate renovate Bot changed the title feat(deps): update dependency mcp (1.29.1 → 2.1.1) feat(deps): update dependency mcp (1.30.0 → 2.2.0) Sep 7, 2026
@github-actions

github-actions Bot commented Sep 8, 2026

Copy link
Copy Markdown

Renovate PR Analysis

Update Summary

  • Dependency: mcp (MCP Python SDK, modelcontextprotocol/python-sdk) — used by both MCP server images
  • Version: >=1.0,<2.0 (resolved 1.30.0) → >=2.2,<2.3 (2.2.0)
  • Type: major (crosses the v1→v2 rewrite: 1.30.0 → 2.0.0 → 2.1.0 → 2.1.1 → 2.2.0)
  • Files changed: apps/kicad-mcp/src/kicad_mcp/pyproject.toml, apps/opengist-mcp/src/opengist_mcp/pyproject.toml

Release Changes

v2.0.0 is a full rewrite: FastMCP renamed to MCPServer (mcp.server.fastmcp → mcp.server.mcpserver); new first-class Client; 2026-07-28 protocol revision support; httpx/httpx-sse replaced by httpx2; mcp.types split into mcp-types; OpenTelemetry on by default; hardened stdio (stdout diverted to stderr while serving).
v2.1.x: handler exceptions no longer leak tracebacks to clients; content-block return annotations no longer emit outputSchema; SSE/OAuth endpoints get the 4 MiB body limit.
v2.2.0: client redirects only followed within the endpoint origin; idle Streamable HTTP sessions expire after 30 min and sessions cap at 10 000; OAuth issuer validation on the legacy path; new MCPDeprecationWarnings.

Breaking Changes

Directly breaking for this repo — both servers crash at startup under mcp 2.x:

  • apps/kicad-mcp/src/kicad_mcp/server.py:16 — from mcp.server.fastmcp import FastMCP raises ModuleNotFoundError: No module named 'mcp.server.fastmcp' on 2.x (the module now points at the migration guide)
  • apps/opengist-mcp/src/opengist_mcp/server.py:17 — same import, same failure
  • Both __main__.py files do from .server import main, so python3 -m kicad_mcp / python3 -m opengist_mcp (spawned by the supergateway ENTRYPOINT) die before serving. The image still builds — CI cannot see this because the structure-test import checks only import the package __init__ (import kicad_mcp; print(kicad_mcp.__version__)), which never loads server.py
  • opengist-mcp's own httpx>=0.27,<1.0 dependency is unaffected (it imports httpx directly in client.py; httpx and httpx2 co-install)

Code Changes Required

Mechanical migration (per the official migration guide; the @mcp.tool()/@mcp.tool(description=...) decorator API and run(transport="stdio") are unchanged in v2):

  1. apps/kicad-mcp/src/kicad_mcp/server.py — line 16: from mcp.server.mcpserver import MCPServer; line 33: mcp = MCPServer("kicad-mcp")
  2. apps/opengist-mcp/src/opengist_mcp/server.py — line 17: from mcp.server.mcpserver import MCPServer; line 27: mcp = MCPServer("opengist-mcp")
  3. Neither server uses Context, resources, or prompts — the rename is the entire server-surface migration
  4. Recommended: extend the structure-test import checks to import kicad_mcp.server / import opengist_mcp.server so this class of breakage is caught in CI
    Separate pre-existing blocker surfaced by this PR's CI run (not caused by it): Build opengist-mcp fails its Metadata Test because apps/opengist-mcp/tests.yaml:30 expects user: "app" while apps/opengist-mcp/Dockerfile:61 sets USER app:app. Align these (kicad-mcp and xianscan use app:app) before or alongside merging, or CI stays red.

Security Impact

v2 hardens stdio (stray prints kept off the wire), validates handler results against the protocol schema, and tightens OAuth issuer checks. None of the changes reduce security here; both servers are unauthenticated stdio-behind-supergateway, which is unchanged. No CVE listed.

Recommendation

Requires code changes — merging as-is ships images that build cleanly but crash-loop at startup with ModuleNotFoundError: No module named 'mcp.server.fastmcp'. Apply the two-line MCPServer migration in both server.py files (plus the opengist-mcp user metadata test fix), then validate with task local-build-kicad-mcp and task local-build-opengist-mcp. Per repo policy this is also an excluded auto-merge category (major + LLM/AI SDK affecting tool call parsing): requires maintainer review of the migrated images before merge. The v1 line still receives security fixes if the migration needs to wait.

@renovate
renovate Bot force-pushed the renovate/mcp-2.x branch from fbba466 to 2dfbd56 Compare September 20, 2026 00:36
@github-actions

github-actions Bot commented Sep 20, 2026

Copy link
Copy Markdown

Renovate PR Analysis

(Re-analysis: previous comments predate this PR's latest update.)

Update Summary

  • Dependency: mcp (MCP Python SDK, modelcontextprotocol/python-sdk)
  • Version: >=1.0,<2.0 (1.30.0) → >=2.2,<2.3 (2.2.0)
  • Type: major
  • Files changed: apps/kicad-mcp/src/kicad_mcp/pyproject.toml:13, apps/opengist-mcp/src/opengist_mcp/pyproject.toml:13

Release Changes

v2.0.0 (stable), v2.0.1, v2.1.0, v2.1.1, v2.2.0 — highlights:

  • FastMCP renamed to MCPServer; the mcp.server.fastmcp import path is gone (imports raise and point at the migration guide)
  • One SDK for both protocol eras (2026-07-28 revision + all 2025-era clients from the same server); first-class Client
  • Multi-round-trip requests (Resolve dependency injection), extension APIs, OpenTelemetry on by default, mcp-types split out as an exact-pinned package
  • Hardened stdio (stray prints kept off the wire, stdout diverted to stderr while serving) and auth (RFC 9207 issuer validation, SEP-990)
  • Dependency floors raised: pydantic >=2.12, anyio >=4.9, sse-starlette >=3.0, typing-extensions >=4.13; new required deps: httpx2, opentelemetry-api, mcp-types; httpx/httpx-sse removed from the SDK
  • v2.2.0 behaviour changes: client redirects followed only within the endpoint origin; idle Streamable HTTP sessions expire after 30 min (legacy spec only) with a 10 000 session cap; OAuth issuer validation on the legacy path; two new MCPDeprecationWarnings

Breaking Changes

Yes — this PR as-is does not actually update the images, and updating later breaks both servers:

  1. The built images get their SDK from the Dockerfiles, not pyproject: apps/kicad-mcp/Dockerfile:89 and apps/opengist-mcp/Dockerfile:44 still pin "mcp[cli]>=1.0,<2.0" and are untouched by this PR. Merged alone, images keep shipping mcp 1.x while pyproject declares 2.2 — an inconsistent state.
  2. Both servers import the removed v1 path: from mcp.server.fastmcp import FastMCP (apps/kicad-mcp/src/kicad_mcp/server.py:16, apps/opengist-mcp/src/opengist_mcp/server.py:17). Under mcp 2.x this raises ModuleNotFoundError: No module named 'mcp.server.fastmcp' — the servers die at startup under supergateway.

Code Changes Required

  1. apps/kicad-mcp/src/kicad_mcp/server.py:16 and apps/opengist-mcp/src/opengist_mcp/server.py:17: from mcp.server.fastmcp import FastMCP → from mcp.server.mcpserver import MCPServer; constructors at server.py:33 / server.py:27: FastMCP("kicad-mcp") → MCPServer("kicad-mcp"). The decorator API and mcp.run(transport="stdio") are unchanged per the v2 migration guide ("What is unchanged on MCPServer").
  2. apps/kicad-mcp/Dockerfile:89 and apps/opengist-mcp/Dockerfile:44: bump "mcp[cli]>=1.0,<2.0" → "mcp[cli]>=2.2,<2.3" so the images match pyproject.
  3. Keep opengist-mcp's explicit httpx dependency (client.py imports it; the SDK no longer pulls it in — side-by-side install is supported, we never hand httpx objects to the SDK).
  4. Fix the pre-existing opengist-mcp CI failure that currently blocks this PR: Build opengist-mcp / Build (linux/amd64) fails on Metadata Test — Image user app:app does not match config user: app (apps/opengist-mcp/tests.yaml:30 expects user: "app"; the Dockerfile sets USER app:app at line 61). Unrelated to mcp, but it fails every opengist-mcp PR.
  5. Recommended: extend the CST commandTests to import the server modules (python3 -c "import kicad_mcp.server" / opengist_mcp.server) — today only the package __init__ is imported, which is why CI stays green even when the SDK import path breaks.

Python floor: both images run Python 3.12 (ubuntu 24.04) / 3.13 (python:3.13-alpine3.21); the v2 migration guide's dependency table branches on Python <3.14 vs >=3.14, i.e. both are inside the supported range.

Security Impact

v2 hardens stdio transport and OAuth; no CVEs cited. This SDK directly affects MCP tool-call parsing for both MCP servers — security-sensitive by definition per repo policy.

Recommendation

Requires code changes — LLM/AI SDK major (never auto-merge). The mechanical migration is small (two imports, two constructor calls, two Dockerfile pins) but the PR is incomplete without it, and the unrelated opengist-mcp metadata-test failure needs fixing before CI can validate anything.

@renovate
renovate Bot force-pushed the renovate/mcp-2.x branch from 2dfbd56 to b66288d Compare September 25, 2026 04:01
@github-actions

github-actions Bot commented Sep 25, 2026

Copy link
Copy Markdown

Renovate PR Analysis

Update Summary

  • Dependency: mcp (Python MCP SDK, modelcontextprotocol/python-sdk) — used by both MCP server apps
  • Version: >=1.0,<2.0 → >=2.2,<2.3 (resolved 1.30.0 → 2.2.0)
  • Type: major (v1 → v2)

Release Changes

  • v2.0.0: supports the 2026-07-28 protocol revision while still serving 2025-era clients from one server; FastMCP renamed to MCPServer (new module mcp.server.mcpserver); first-class Client; hardened stdio (handler subprocesses kept off the wire, stdout diverted to stderr while serving); OAuth gains RFC 9207 issuer validation; 4 MiB HTTP request body cap; MCP_* env vars removed; v1 enters maintenance mode (security fixes only)
  • v2.1.0: unexpected handler exceptions are logged server-side but the client now only sees Error executing tool <name> (no exception text — raise ToolError for model-facing messages); tools annotated to return TextContent/Image/etc. no longer advertise outputSchema/structuredContent (pass structured_output=True to keep); SSE message endpoint answers 405 to non-POST
  • v2.1.1 / v2.0.1: mcp.server.fastmcp import redirected to the migration guide — v2 released specifically because "a lot of people" hit the removed-import error
  • v2.2.0: HTTP redirects followed only within the endpoint's origin; idle Streamable HTTP sessions expire after 30 min and servers cap at 10 000 sessions (HTTP transports only); OAuth issuer validated on all discovery paths; two new deprecation warnings

Breaking Changes

Directly affecting this repo (empirically verified by installing mcp==2.2.0 on python:3.13-alpine3.21):

  • from mcp.server.fastmcp import FastMCP — used at apps/kicad-mcp/src/kicad_mcp/server.py:16 and apps/opengist-mcp/src/opengist_mcp/server.py:17 — raises ModuleNotFoundError under 2.2.0. The servers crash at startup. The error message itself gives the migration path: from mcp.server.mcpserver import MCPServer, or pin mcp<2
  • The rest of our usage is v2-compatible (verified): MCPServer("name") constructor, @server.tool() / @server.tool(description=...) decorators, and .run(transport="stdio") all work unchanged; all our tools return plain str, so the v2.1.0 outputSchema/structuredContent change does not apply
  • Inconsistent pinning: this PR updates only the two pyproject.toml files. Both Dockerfiles independently install the SDK at runtime: apps/kicad-mcp/Dockerfile:89 and apps/opengist-mcp/Dockerfile:44 still pin "mcp[cli]>=1.0,<2.0". Merged as-is, images keep shipping v1 while pyproject declares v2 — dev installs from pyproject break, and the container/tests.yaml would stay green (the CST import kicad_mcp/import opengist_mcp command tests never import .server, verified — so CI cannot catch the broken server module)

Code Changes Required

Do not merge as-is. A complete update needs, in one PR:

  1. apps/kicad-mcp/src/kicad_mcp/server.py:16 → from mcp.server.mcpserver import MCPServer; server.py:33 → mcp = MCPServer("kicad-mcp")
  2. apps/opengist-mcp/src/opengist_mcp/server.py:17 → same import; server.py:27 → mcp = MCPServer("opengist-mcp")
  3. apps/kicad-mcp/Dockerfile:89 → "mcp[cli]>=2.2,<2.3"
  4. apps/opengist-mcp/Dockerfile:44 → "mcp[cli]>=2.2,<2.3"
  5. After migration, run a stdio smoke test (python3 -m kicad_mcp / python3 -m opengist_mcp under the built image, or an e2e MCP client call) — current structure tests cannot detect a broken server import; consider adding a commandTest that imports kicad_mcp.server / opengist_mcp.server
  6. Note for reviewers: v2.1.0 changed error semantics — unexpected tool exceptions no longer reach the LLM client (only Error executing tool <name>). Tools that want to surface an error message must return it as content (ours already do, via JSON {"ok": false, ...}) or raise ToolError

Security Impact

v2 hardens the SDK surface: stdio servers keep stray prints/subprocesses off the protocol wire, exception details are no longer leaked to clients, OAuth issuer validation, and a 4 MiB request body cap on HTTP transports. Our deployments are stdio servers behind supergateway (in-cluster, no inbound auth), so the HTTP-transport changes don't apply. Staying on 1.x carries maintenance-mode risk (security fixes only), so migrating is advisable — but deliberately, not via this half-update.

Recommendation

Requires code changes — merging as-is ships images that still run mcp 1.x (Dockerfiles untouched) while pyproject.toml declares a v2 range whose runtime import path breaks both servers (mcp.server.fastmcp removed in v2; verified empirically). Additionally this is a major bump of the MCP SDK — tool call parsing surface — which repo policy keeps out of auto-merge regardless. Apply the six changes above in a combined PR, then verify with a stdio/e2e smoke test before merging this dependency update.

@renovate
renovate Bot force-pushed the renovate/mcp-2.x branch from b66288d to 49fb77f Compare October 6, 2026 03:13
@renovate renovate Bot changed the title feat(deps): update dependency mcp (1.30.0 → 2.2.0) feat(deps): update dependency mcp (1.30.0 → 2.3.0) Oct 6, 2026
@github-actions

github-actions Bot commented Oct 6, 2026

Copy link
Copy Markdown

Renovate PR Analysis

Update Summary

  • Dependency: mcp (MCP Python SDK, modelcontextprotocol/python-sdk)
  • Version: 1.30.0 → 2.3.0 (constraint >=1.0,<2.0 → >=2.3,<2.4)
  • Type: major (LLM/AI SDK — MCP server dependency; excluded from auto-merge by policy)

Release Changes

v2.0.0 is a full rewrite (2026-07-28 protocol revision, both eras served from one server). Key changes through 2.3.0:

  • FastMCP renamed to MCPServer; the mcp.server.fastmcp import path now raises with a pointer to the migration guide — v2.0.1 and v2.1.1 were backport/point releases specifically for this import breakage
  • New first-class Client; Resolve dependency injection for multi-round-trip requests; extension APIs + OpenTelemetry on by default; types split into mcp-types
  • 2.1.0: handler exceptions no longer leak exception text to clients (client sees Error executing tool <name>); content-block return annotations drop outputSchema; 4 MiB body limit on SSE/OAuth endpoints
  • 2.2.0: HTTP redirects followed same-origin only; idle Streamable HTTP sessions expire after 30 min and max 10 000 sessions; OAuth issuer validation on all paths
  • 2.3.0: httpx2>=2.10.0 required; invalid x-mcp-header annotations fail at registration; empty _meta/params omitted; Mcp-Param-* validated from registered schema; interactive OAuth login pauses request timeouts
  • v1.x is maintenance-mode (security fixes only)

Breaking Changes

Yes, if 2.x were actually installed — but as-is this PR does not change what the images ship:

  • Both Dockerfiles install mcp independently of pyproject.toml: apps/kicad-mcp/Dockerfile:89 and apps/opengist-mcp/Dockerfile:44 pin "mcp[cli]>=1.0,<2.0" inline. The Renovate-edited pyproject.toml files are copied into the image as inert metadata. The built images still ship mcp 1.x after merging this PR.
  • The server code still uses the removed v1 API: from mcp.server.fastmcp import FastMCP at apps/kicad-mcp/src/kicad_mcp/server.py:16 and apps/opengist-mcp/src/opengist_mcp/server.py:17. Installing 2.x without migrating these imports breaks both servers at startup.
  • Current tests cannot catch this: both tests.yaml only run import <pkg>; print(__version__) against __init__.py, which does not import server.py, and never boot the MCP server.

Code Changes Required

To actually adopt mcp 2.x (not part of this PR):

  1. apps/kicad-mcp/src/kicad_mcp/server.py:16,33 and apps/opengist-mcp/src/opengist_mcp/server.py:17,27 — replace from mcp.server.fastmcp import FastMCP / FastMCP(...) with the v2 MCPServer API per https://py.sdk.modelcontextprotocol.io/migration/ (decorator API is unchanged)
  2. apps/kicad-mcp/Dockerfile:89 and apps/opengist-mcp/Dockerfile:44 — bump the inline pins to match the pyproject constraint
  3. Strengthen tests: make the import test exercise server.py (or boot the stdio server) so an SDK break fails CI
  4. Review LLM-visible behavior changes: tool error text masking (2.1.0), outputSchema changes for content-block returns, 4 MiB limits — these affect tool-call ergonomics for agents

Security Impact

v1.x now receives security fixes only; v2 hardens stdio (stray prints off the wire, stdout diverted to stderr — beneficial for the supergateway stdio wrapping), OAuth issuer validation, and body-size limits. Staying on 1.x has a slowly growing security-gap risk, which argues for scheduling the v2 migration — but via a reviewed code-change PR, not this constraint-only bump.

Separate pre-existing failure surfaced by this PR's CI (present on main 5ecf0d4, unrelated to this diff): apps/opengist-mcp Metadata Test fails with Image user app:app does not match config user: app — apps/opengist-mcp/Dockerfile:61 sets USER app:app while apps/opengist-mcp/tests.yaml:30 expects user: "app". One of the two needs correcting independently of this PR.

Recommendation

Needs manual review — do not merge as-is. This is a major LLM/AI SDK bump (repo exclusion list). The PR itself is inert for image builds (Dockerfiles carry their own 1.x pins) but would commit the repo to a >=2.3 declaration while the code still imports the removed FastMCP API and the Dockerfiles install 1.x — a three-way version skew. Prefer closing this in favor of a dedicated migration PR implementing the changes above, or rebasing it to include them.

@github-actions

github-actions Bot commented Oct 7, 2026

Copy link
Copy Markdown

Renovate PR Analysis

Update Summary

  • Dependency: mcp (modelcontextprotocol/python-sdk, PyPI) — used by both MCP server images in this repo
  • Version: 1.30.0 → 2.3.0 (constraint >=1.0,<2.0 → >=2.3,<2.4)
  • Type: major (1.x → 2.x)

Release Changes

All versions between old and new (from upstream release notes in the PR body and the v1→v2 migration guide at py.sdk.modelcontextprotocol.io/migration/):

  • v2.0.0: stable v2; speaks the 2026-07-28 protocol revision and serves every 2025-era client from the same server; FastMCP renamed to MCPServer; first-class Client; hardened stdio (stray prints kept off the protocol wire, stdout diverted to stderr while serving); OpenTelemetry on by default; new exact-pinned mcp-types dependency; httpx/httpx-sse replaced by httpx2; stricter protocol validation
  • v2.0.1: backported import warning for mcp.server.fastmcp pointing at the migration guide
  • v2.1.0: 4 MiB body limit extended to SSE + OAuth endpoints; handler exceptions no longer leak exception text to clients (generic Error executing tool <name>; use ToolError for model-visible messages); content-block return annotations no longer advertise outputSchema
  • v2.1.1: mcp.server.fastmcp imports point at the migration guide
  • v2.2.0: HTTP redirects followed only within the endpoint's origin; idle stateful Streamable HTTP sessions expire after 30 min; OAuth issuer validation on the legacy path; two new MCPDeprecationWarnings
  • v2.3.0: httpx2>=2.10.0 required; invalid x-mcp-header annotations fail at tool registration; empty _meta/params no longer sent; Mcp-Param-* validation looks the tool up by name (no hidden tools/list per call)

Breaking Changes

Directly affecting this repo:

  • from mcp.server.fastmcp import FastMCP raises ModuleNotFoundError on 2.x — used at apps/kicad-mcp/src/kicad_mcp/server.py:16 and apps/opengist-mcp/src/opengist_mcp/server.py:17
  • mcp no longer installs httpx (replaced by httpx2). opengist-mcp imports httpx directly (src/opengist_mcp/client.py:20) but declares its own httpx>=0.27,<1.0 dependency and never passes httpx objects to the SDK, so a side-by-side install works — no change needed there
  • Unexpected tool-handler exceptions now reach the client as a generic error string instead of the exception text — affects debugging behaviour of both servers, not registration
  • New transitive dependency floors (anyio>=4.9, pydantic>=2.12, sse-starlette>=3, opentelemetry-api, mcp-types exact-pinned, httpx2>=2.10) — no conflicting pins exist in the two Dockerfiles; pip resolves freely

Code Changes Required

This PR alone changes nothing in the shipped images: both Dockerfiles install dependencies via an explicit pip3 install "mcp[cli]>=1.0,<2.0" (apps/kicad-mcp/Dockerfile:89, apps/opengist-mcp/Dockerfile:44); the pyproject.toml edited here is COPY'd into the image but never installed from. To actually move to mcp 2.x:

  1. apps/kicad-mcp/Dockerfile:89 and apps/opengist-mcp/Dockerfile:44 — change the pip pin to "mcp[cli]>=2.3,<2.4" in lockstep with the pyproject
  2. apps/kicad-mcp/src/kicad_mcp/server.py:16,33 and apps/opengist-mcp/src/opengist_mcp/server.py:17,27 — from mcp.server.fastmcp import FastMCP → from mcp.server.mcpserver import MCPServer; FastMCP("kicad-mcp") → MCPServer("kicad-mcp") (same for opengist). The @mcp.tool() decorator surface and mcp.run(transport="stdio") are unchanged per the migration guide
  3. Retest tool-call parsing end-to-end through supergateway (supergateway@3.4.3 wraps the stdio child; v2 claims 2025-era client compatibility, but this must be verified with a live tools/list + tools/call, e.g. the health tool)
  4. Unrelated pre-existing failure that blocks a green build: opengist-mcp CI fails its Metadata Test with Image user app:app does not match config user: app — apps/opengist-mcp/Dockerfile:61 sets USER app:app while apps/opengist-mcp/tests.yaml:30 expects user: "app". Both files are untouched by this PR and unchanged since the app was introduced (feat: add opengist-mcp — MCP server for Opengist #243), so this failure exists on main; align the test with the Dockerfile (or vice versa) separately

Security Impact

Positive: hardened stdio (stray prints/subprocess output kept off the protocol wire), OAuth RFC 9207 issuer validation, stricter schema validation, httpx2 validating against the system trust store. Neither server uses the SDK's OAuth surface (in-cluster, no inbound auth; opengist auth is a bearer token applied in its own httpx client), so the auth changes don't alter our threat surface. Nothing negative.

CI Status

  • Build kicad-mcp / Build (linux/amd64): pass — but only because the Dockerfile pin keeps the image on mcp 1.x
  • Build opengist-mcp / Build (linux/amd64): fail — Metadata Test user mismatch (see item 4 above), pre-existing and unrelated to this PR
  • renovate/artifacts: fail — Renovate-internal, no lockfiles exist in this repo

Recommendation

Needs manual review — this is a major bump of an LLM/AI SDK (MCP servers affect tool-call parsing; explicit never-auto-merge exclusion), and the import-path breakage means it requires the code changes listed above before it can merge. Per policy this PR is never auto-merged.

@github-actions

github-actions Bot commented Oct 7, 2026

Copy link
Copy Markdown

Renovate PR Analysis

Update Summary

  • Dependency: mcp (modelcontextprotocol/python-sdk, PyPI)
  • Version: >=1.0,<2.0 (1.30.0) → >=2.3,<2.4 (2.3.0)
  • Type: major (crosses the v1→v2 boundary; v1 is now maintenance-mode, security fixes only)

Files changed: apps/kicad-mcp/src/kicad_mcp/pyproject.toml, apps/opengist-mcp/src/opengist_mcp/pyproject.toml

Release Changes

Spanning 1.30.0 → 2.3.0 (v2.0.0, 2.0.1, 2.1.0, 2.1.1, 2.2.0, 2.3.0):

  • v2.0.0: FastMCP renamed to MCPServer (new module mcp.server.mcpserver); first-class Client; low-level Server rebuilt on a shared dispatcher; multi-round-trip requests (Resolve dependency injection); extension APIs (MCP Apps); OpenTelemetry tracing on by default; hardened stdio (handler subprocesses and stray prints kept off the wire, stdout diverted to stderr while serving); OAuth adds RFC 9207 issuer validation; protocol types split into exact-pinned mcp-types package; MCP_* env vars removed; Streamable HTTP 4 MiB body limit.
  • v2.0.1 / 2.1.1: mcp.server.fastmcp import raises with a pointer to the migration guide (backported because many users hit it).
  • v2.1.0: handler exceptions logged once at ERROR and clients see only Error executing tool <name> (raise ToolError for client-visible messages); tools annotated to return content blocks no longer emit outputSchema/structuredContent; Client accepts StdioServerParameters directly; 4 MiB body limit extended to SSE + OAuth endpoints.
  • v2.2.0: HTTP redirects followed only within the endpoint's origin; idle stateful Streamable HTTP sessions expire after 30 min and are capped at 10 000 per server; OAuth issuer validation on the legacy path; two MCPDeprecationWarnings (OAuth providers without issuer=, AuthSettings.validate_token_resource unset) — 3.0 will require them.
  • v2.3.0: httpx2>=2.10.0 required; tools with invalid x-mcp-header annotations rejected at registration (InvalidSignature); empty _meta/params omitted from requests; Mcp-Param-* validation looks tools up by registered schema instead of running tools/list; max_sse_event_size option; MCPServer(subscriptions=False); interactive OAuth login no longer counts against request timeouts; assorted fixes (TypedDict results, Context[AppState] on prompts/templates, null structuredContent validation).

Breaking Changes

Directly affecting this repo:

  1. from mcp.server.fastmcp import FastMCP fails under 2.x — used at apps/kicad-mcp/src/kicad_mcp/server.py:16 and apps/opengist-mcp/src/opengist_mcp/server.py:17. v2 raises ModuleNotFoundError: No module named 'mcp.server.fastmcp' followed by a pointer to the migration guide. Both servers crash at import time under mcp 2.3.
  2. httpx/httpx-sse no longer installed by mcp (replaced by httpx2). opengist-mcp's own client imports httpx, but it declares httpx>=0.27,<1.0 explicitly in both pyproject.toml and its Dockerfile pip install, so the import survives; the two packages coexist side by side. Only objects handed to the SDK would need to be httpx2 types — none are.
  3. Sync tool handlers now run on worker threads (RuntimeError if they touch the event loop). The sync tools here (list_kicad_projects, health, all opengist list/get/create tools) do file I/O and sync httpx calls only — no event-loop usage found on inspection. Low risk, but worth a live check.
  4. New required transitive deps: httpx2, opentelemetry-api, mcp-types (exact-pinned), plus raised floors on anyio/pydantic/sse-starlette/typing-extensions. Image size grows slightly; pip resolution handles the floors.
  5. Handler exception text no longer reaches clients (v2.1.0) — not an issue here: every opengist-mcp tool catches exceptions itself and returns a JSON error string; kicad-mcp tools validate inputs before running.

Not affected: @mcp.tool() decorator API and mcp.run(transport="stdio") are unchanged in v2; v2 serves all 2025-era protocol revisions over stdio from the same server, so the supergateway@3.4.3 stdio wrapping keeps working (verify with a live handshake anyway).

Code Changes Required

The PR as posted is inconsistent: it bumps pyproject.toml but leaves the code and Dockerfiles on v1.

  1. apps/kicad-mcp/src/kicad_mcp/server.py:16,33 — from mcp.server.fastmcp import FastMCP → from mcp.server.mcpserver import MCPServer; mcp = FastMCP("kicad-mcp") → mcp = MCPServer("kicad-mcp").
  2. apps/opengist-mcp/src/opengist_mcp/server.py:17,27 — same rename for MCPServer("opengist-mcp").
  3. apps/kicad-mcp/Dockerfile:89 — pip3 install "mcp[cli]>=1.0,<2.0" → "mcp[cli]>=2.3,<2.4" (currently missed by this PR; the image installs mcp from this line, not from pyproject — PYTHONPATH=/app, package never pip-installed).
  4. apps/opengist-mcp/Dockerfile:44 — same pin update.
  5. Re-run task local-build-kicad-mcp / task local-build-opengist-mcp + container-structure-test, and exercise a real tools/list + tools/call through supergateway against a v2 server before merge.

Note: merged as-is, the images keep installing mcp 1.x from the Dockerfile pins (pyproject.toml is inert inside the image), so structure tests keep passing — the breakage only appears for anyone installing from pyproject (e.g. pip install -e .[dev] to run the opengist-mcp pytest suite, which imports opengist_mcp.server and would hit the ModuleNotFoundError).

Security Impact

v2 hardens several surfaces: stdio keeps stray prints and handler subprocesses off the wire, OAuth gains RFC 9207 issuer validation and stricter client auth at /token and /revoke, Streamable HTTP bodies are capped, and the redirect-following restriction (v2.2.0) prevents cross-origin redirects. None of the release notes cite a CVE; these servers run stdio-only behind in-cluster supergateway with no OAuth flows, so the security-relevant surface change is mainly the stdio hardening. v1 remains in maintenance receiving security fixes, so staying on 1.x short-term carries no immediate exposure.

Recommendation

Needs manual review — this is an LLM/AI SDK update (MCP servers kicad-mcp and opengist-mcp affect tool call parsing) and a major bump with verified breaking changes against code in this repo (mcp.server.fastmcp import removed). It is on the never-auto-merge exclusion list. Merging only the pyproject bump would leave the repo internally inconsistent; a maintainer should apply the FastMCP → MCPServer migration and the matching Dockerfile pin updates from the "Code Changes Required" section (ideally via /implement), then verify a live stdio handshake through supergateway before merging.

@github-actions

github-actions Bot commented Oct 8, 2026

Copy link
Copy Markdown

Renovate PR Analysis

Update Summary

  • Dependency: mcp (PyPI — modelcontextprotocol/python-sdk), runtime dependency of the MCP servers in apps/kicad-mcp and apps/opengist-mcp
  • Version: >=1.0,<2.0 → >=2.3,<2.4 (1.30.0 → 2.3.0)
  • Type: major (SDK rewrite; LLM/AI tool-call layer — repo exclusion list applies)

Release Changes

v2.0.0 → v2.3.0 highlights (from upstream release notes in the PR body; verified against upstream README and PyPI):

  • 2.0.0: full v2 rewrite — FastMCP renamed to MCPServer, one Client object replaces the transport/ClientSession/initialize() layering, protocol types split into the mcp-types package, MCP_* env vars removed, Streamable HTTP request bodies capped at 4 MiB, stdio hardened (stray prints kept off the wire; stdout diverted to stderr while serving). v1.x is in maintenance mode — security fixes only.
  • 2.1.x: handler exception details no longer reach the client; content-block return annotations become unstructured; 4 MiB limit extended to SSE/OAuth endpoints
  • 2.2.0: HTTP client redirects followed only within the endpoint origin; idle Streamable HTTP sessions expire after 30 min (legacy spec); OAuth issuer validation on all paths
  • 2.3.0: httpx2>=2.10.0 required; empty _meta/params no longer sent; invalid x-mcp-header tool annotations fail at registration; max_sse_event_size option
  • Python requirement: >=3.10 (verified via PyPI metadata) — our images run Python 3.13 / 3.12, no toolchain bump needed

Breaking Changes

Fatal for both apps as-is — verified empirically (mcp 2.3.0 in python:3.13-alpine):

>>> from mcp.server.fastmcp import FastMCP
ModuleNotFoundError: No module named 'mcp.server.fastmcp'. This is mcp 2.x, where
FastMCP was renamed to MCPServer ...
  • apps/kicad-mcp/src/kicad_mcp/server.py:16 and apps/opengist-mcp/src/opengist_mcp/server.py:17 both do from mcp.server.fastmcp import FastMCP — on any image that actually installs mcp 2.x, python3 -m <pkg> dies at startup, the supergateway stdio child never comes up, and no tools are served.
  • However, this PR changes only src/*/pyproject.toml, and neither Dockerfile installs from pyproject: they hardcode pip3 install "mcp[cli]>=1.0,<2.0" (apps/opengist-mcp/Dockerfile:44, apps/kicad-mcp/Dockerfile:89) and merely COPY the source. The PR is a no-op for the shipped images — they would still install mcp 1.x — but it leaves pyproject and Dockerfile pins contradictory.

Code Changes Required

A maintainer must do this in one coordinated change (this checkout is read-only):

  1. Port both servers to SDK v2: apps/kicad-mcp/src/kicad_mcp/server.py:16,33 and apps/opengist-mcp/src/opengist_mcp/server.py:17,27 — from mcp.server.mcpserver import MCPServer + MCPServer("...") (decorator API is unchanged per upstream); audit the rest of each server against https://py.sdk.modelcontextprotocol.io/migration/
  2. Align the image pins: apps/opengist-mcp/Dockerfile:44 and apps/kicad-mcp/Dockerfile:89 → "mcp[cli]>=2.3,<2.4"
  3. Fix the pre-existing opengist-mcp test failure that is blocking this PR's CI: Metadata Test — Image user app:app does not match config user: app. The mismatch is between USER app:app (apps/opengist-mcp/Dockerfile:61) and user: "app" (apps/opengist-mcp/tests.yaml:30), both present since the app landed (commit e524326); it went unnoticed because release builds skip app tests (.github/workflows/app-builder.yaml:141). Make them consistent (either app:app in tests.yaml or USER app in the Dockerfile).

Security Impact

v1.x receives security fixes only (maintenance mode), so staying pinned has diminishing returns. v2 hardens stdio transports (keeps stray output off the protocol wire) — relevant here since supergateway bridges stdio to an in-cluster HTTP/SSE endpoint. No CVE drives this update; the MCP SDK is the LLM tool-call parsing layer, which is why this PR must not be auto-merged regardless.

Verification Performed

  • CI on this PR (run 37407974011, head 49fb77f): kicad-mcp Build SUCCESS — but its structure tests only run import kicad_mcp (tests.yaml), which never touches server.py, so the FastMCP break is invisible to CI; opengist-mcp Build FAILURE from the unrelated pre-existing metadataTest user mismatch quoted above
  • Reproduced the v1 import failure on mcp 2.3.0 directly (ModuleNotFoundError, above)
  • Confirmed the Dockerfiles hard-pin mcp[cli]>=1.0,<2.0 and never install pyproject (read apps/opengist-mcp/Dockerfile:43-56, apps/kicad-mcp/Dockerfile:86-96)
  • PyPI metadata for 2.3.0: requires_python >=3.10, new deps (httpx2>=2.10.0, mcp-types==2.3.0) — opengist-mcp's own httpx>=0.27,<1.0 is a separate package and coexists

Recommendation

Requires code changes — never auto-merge (LLM/AI SDK exclusion). As written the bump is a metadata-only no-op that contradicts the Dockerfile pins, and if the pins were aligned without porting the code both MCP servers would crash at startup on the removed FastMCP import (reproduced above). Apply the three changes listed above in a coordinated PR; opengist-mcp's CI is additionally blocked by a pre-existing tests.yaml user mismatch that should be fixed first.

@renovate
renovate Bot force-pushed the renovate/mcp-2.x branch 2 times, most recently from 7b7b8ed to acd3cf0 Compare October 16, 2026 02:40
@renovate
renovate Bot force-pushed the renovate/mcp-2.x branch from acd3cf0 to d7e8712 Compare October 26, 2026 21:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

app/kicad-mcp app/opengist-mcp area/apps type/major

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants