Skip to content

feat(deps): update dependency mcp (1.29.1 → 2.1.1) - #255

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

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

Conversation

@renovate

@renovate renovate Bot commented Aug 13, 2026

Copy link
Copy Markdown

This PR contains the following updates:

Package Change Age Confidence
mcp >=1.0,<2.0>=2.1,<2.2 age confidence

Warning

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


Release Notes

modelcontextprotocol/python-sdk (mcp)

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

Copy link
Copy Markdown

User renovate[bot] does not have write permissions

github run

@github-actions

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:16from mcp.server.mcpserver import MCPServer
  2. apps/kicad-mcp/src/kicad_mcp/server.py:33mcp = 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:27mcp = 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

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,33from mcp.server.fastmcp import FastMCPfrom 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

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,33from mcp.server.fastmcp import FastMCPfrom 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 FastMCPMCPServer 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants