fix: MCPCをvendored fork化しMCP準拠と接続安定性を改善

- Git submoduleを廃止してMCPCを直接管理
- Windowsで254リクエスト付近に発生する切断を修正
- JSON-RPC 2.0エラー応答を標準化
- tool schemaとruntimeの必須・任意引数を一致
- 1000回連続呼び出しの回帰テストを追加

1 files changed, 197 insertions, 0 deletions

diff --git a/third_party/mcpc/README.org b/third_party/mcpc/README.org
new file mode 100644
index 0000000..893f38d
--- /dev/null
+++ b/third_party/mcpc/README.org
@@ -0,0 +1,197 @@
+#+title: mcpc
+#+options: toc:1 num:nil
+
+* Overview
+:PROPERTIES:
+:CUSTOM_ID: overview
+:END:
+
+mcpc is a <b>M</b>odel <b>C</b>ontext <b>P</b>rotocol library in modern <b>C</b>. Its major goals are:
++ Provide the *most native* bridge between low-level infrastructure
+  and AI models
++ Explore the maximum capability of the *most recent* C programming language
+
+* MCP Features
+:PROPERTIES:
+:CUSTOM_ID: features
+:END:
+
+| Features        | Server | Client |
+|-----------------+--------+--------|
+| Tool            | ✅     | 🔨     |
+| Resource        | ✅     | 🔨     |
+| Prompt          | ✅     | 🔨     |
+| Completion      | ✅     | 🔨     |
+| STDIO Transport | ✅     | 🔨     |
+| HTTP Transport  | 🔨     | 🔨     |
+| Others          | 🔨     | 🔨     |
+
+
+* Supported Platforms
+:PROPERTIES:
+:CUSTOM_ID: platforms
+:END:
+
+|       | Linux | Windows | macOS |
+|-------+-------+---------+-------|
+| Linux | ✅    | ✅      | ✅    |
+
+Note: this table roughly shows the state of supporting on some platforms,
+for more detailed information, check the /Modern C Support/.
+
+
+
+* Modern C Support
+:PROPERTIES:
+:CUSTOM_ID: modernc
+:END:
+
+Since mcpc claims to implement everything with the most modern C
+possible, its building process becomes a little different than many
+existing building systems or process, the major
+difference is that: **we try to support as many C compilers as possible,
+even on one platform**.
+
+Ideally mcpc will be implemented fully in C23(currently the newest
+standard), but if a full C23 is missing on a platform, we
+either downgrade the C standard, or give up the support.
+
+This approach certainly has some benefits and consequences:
+
+1. The library can launch on as many platforms as possible, and be
+   able to compiled by as many C compilers as possible.
+2. There must be a minimum fallback version of C standard that the
+   library targets, currently it is C11.
+3. C23 features that are not patchable, or require non-trivial amount
+   of effort to patch, will not be used, e.g., [[https://open-std.org/JTC1/SC22/WG14/www/docs/n2508.pdf][N2508]], [[https://open-std.org/JTC1/SC22/WG14/www/docs/n2645.pdf][N2645]], etc.
+4. All safety checks and performance optimization will only focus on the
+   platforms with full C23 support.
+
+** Support Matrix
+
+=✅✅= : /implemented in C23/
+
+=🔨✅= : /implemented in C11~C17/
+
+=-= : /the platform does not exist, or work in progress/
+
+Linux:
+
+|          | GLIBC 2.31       | GLIBC 2.36       | GLIBC 2.40       |
+|----------+------------------+------------------+------------------|
+| GCC 10   | 🔨✅ (Debian 11) | -                | -                |
+| GCC 12   | -                | 🔨✅ (Debian 12) | -                |
+| GCC 13   | -                | -                | -                |
+| GCC 14   | -                | -                | ✅✅ (Fedora 41) |
+| Clang 14 | -                | -                | -                |
+| Clang 16 | -                | -                | -                |
+| Clang 18 | -                | -                | -                |
+| Clang 19 | -                | -                | ✅✅ (Fedora 41) |
+
+
+Windows:
+
+|          | CMD/PS | Cygwin | MinGW |
+|----------+--------+--------+-------|
+| MSVC 19  | 🔨✅   | -      | -     |
+| Clang 19 | -      | -      | -     |
+| GCC 14   | -      | ✅✅   | ✅✅  |
+
+
+macOS:
+
+|          | macOS 13 | macOS 14 | macOS 15 |
+|----------+----------+----------+----------|
+| Clang 14 | 🔨✅     | -        | -        |
+| Clang 16 | -        | 🔨✅     | 🔨✅     |
+| GCC 14   | 🔨✅     | -        | -        |
+
+
+* Building
+:PROPERTIES:
+:CUSTOM_ID: building
+:END:
+
+** Building (Linux, Cygwin, MSYS2, macOS, etc.)
+
+Prerequisites:
+- GNU Make
+ 
+Then
+#+begin_src
+cd mcpc
+make && make tst && make install
+#+end_src
+
+** Building (Windows CMD/PS/VS)
+
+Prerequisites:
+- Visual Studio
+- GNU Make (=winget install ezwinports.make=)
+
+Two options to build:
+
+*** 1. Build in CMD/PS
+
+Open "x64 Native Tools Command Prompt", then
+
+#+begin_src
+cd mcpc
+make && make tst
+#+end_src
+
+*** 2. Build in Visual Studio:
+
+"File" - "Open" - "CMake", "Build" - "Build All"
+
+#+begin_quote
+This approach is only for the better debugging experience on Windows,
+/"Build in CMD/PS"/ takes priority over this one.
+#+end_quote
+
+
+* Development
+:PROPERTIES:
+:CUSTOM_ID: development
+:END:
+
+API reference can be found at [[./misc/api.md][api.md]].
+
+Dependencies:
+- [[https://github.com/cesanta/mjson][mjson]] (already in-tree)
+
+** Code Contributing
+
+Despite we claim to use modern C, as standard as possible, and as
+modern as possible, we have some extra conventions, in order to render
+our code more readable, inclusive and scalable:
+
+1. Unless mentioned explicitly, we follow GNU C [[https://www.gnu.org/prep/standards/html_node/Writing-C.html][coding style]].
+2. Prefer functions over macros, use macros only if necessary.
+3. The type of variables should be reflected in the source code. Use of
+   keyword =auto= is thus forbidden.
+4. Names of defined variables that are exposed publicly should be in
+   uppercase, otherwise in lowercase.
+
+
+* FAQ
+
+** Should I prefer mcpc over other SDKs?
+
+It depends on your use case. Roughly speaking, if
+1. you prefer your MCP servers or clients to perform tasks in the most
+   native way (e.g. manually manage memory allocation, equipped with
+   competitive performance, etc.).
+2. you wish your MCP servers or clients are distributed with minimum
+   software requirements (i.e. you don't want to force users to
+   have Python, Node.js or similar things installed on their machines) 
+then mcpc is for you. Otherwise I would strongly recommend you consider
+Python, Javscript or other SDKs, they have more intuitive and
+easy-to-use high-level APIs for MCP protocol.
+
+* License
+:PROPERTIES:
+:CUSTOM_ID: license
+:END:
+
+#+include: "LICENSE" src