modelcontextprotocol / modelcontextprotocol/python-sdk

Define and document the public Python SDK API surface

未關閉
#1,701 4 則留言 2 個 reaction 已指派 1 人 在 GitHub 檢視

@felixweinberger 已經在處理了。

開始於 2026年1月16日。

breaking change enhancement P1 ready for work v2
主要語言
Python
星號
24.3k
分支
4k
平均合併
1 天 1 小時
30 天內合併 PR
31

描述

Description

Summary

The Python SDK exposes a variety of classes and functions across packages and submodules. Some are clearly meant to be public, others are internal but not marked as such. Tests and user code sometimes rely on internals (e.g. private attributes).

This makes it hard for users to know what is safe to depend on and hard for maintainers to evolve internals without risking breakage.

Problems

  • Ambiguous boundaries: It’s not always clear which symbols in mcp.* and subpackages are part of the supported public API.
  • Private attribute usage: Some tests/examples access internal attributes (e.g. _mcp_server), which blurs the line between public and internal.
  • Versioning risk: Changes to internal structures can accidentally turn into breaking changes for users who imported them directly.

Proposal

  1. Define an explicit public API

    • Use __all__ and/or a mcp.public (or similar) module to list what is considered stable public API.
    • Document the intended public surface in the README or a dedicated “API Reference”.
  2. Mark internals clearly

    • Move clearly internal modules into an _internal subpackage where possible.
    • Use leading underscores and documentation to indicate non-public attributes.
  3. Gradual tightening

    • Update examples and tests to use only public APIs where feasible.
    • Where users are expected to interact with lower-level constructs, expose them via documented, stable paths.

Why this matters

  • Stability: Users can rely on documented APIs without fear of accidental breakage.
  • Refactorability: Internal changes become safer when the public surface is well-defined.
  • Onboarding: New users can quickly see which APIs are meant for them.

Acceptance criteria

  • A documented list of public, supported APIs for the Python SDK.
  • Internal modules/types are clearly marked (e.g., _internal packages) where appropriate.
  • Examples and tests avoid relying on private attributes when a public alternative exists.
  • Future changes can be evaluated against this public surface for compatibility.
References

No response

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

評估

這個 Issue 還沒有評估資料。

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。