llmx-rs/mcp-types/Cargo.toml

[package]
edition = "2024"
name = "mcp-types"
version = { workspace = true }

[lints]
workspace = true

[dependencies]
serde = { workspace = true, features = ["derive"] }
serde_json = { workspace = true }
ts-rs = { workspace = true, features = ["serde-json-impl", "no-serde-warnings"] }
schemars = { workspace = true }
feat: introduce mcp-types crate (#787) This adds our own `mcp-types` crate to our Cargo workspace. We vendor in the [`2025-03-26/schema.json`](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/05f204513641c05bd78d056791af99c6c84520fa/schema/2025-03-26/schema.json) from the MCP repo and introduce a `generate_mcp_types.py` script to codegen the `lib.rs` from the JSON schema. Test coverage is currently light, but I plan to refine things as we start making use of this crate. And yes, I am aware that https://github.com/modelcontextprotocol/rust-sdk exists, though the published https://crates.io/crates/rmcp appears to be a competing effort. While things are up in the air, it seems better for us to control our own version of this code. Incidentally, Codex did a lot of the work for this PR. I told it to never edit `lib.rs` directly and instead to update `generate_mcp_types.py` and then re-run it to update `lib.rs`. It followed these instructions and once things were working end-to-end, I iteratively asked for changes to the tests until the API looked reasonable (and the code worked). Codex was responsible for figuring out what to do to `generate_mcp_types.py` to achieve the requested test/API changes. 2025-05-02 13:33:14 -07:00			`[package]`
Auto format toml (#1745) Add recommended extension and configure it to auto format prompt. 2025-07-30 18:37:00 -07:00			`edition = "2024"`
feat: introduce mcp-types crate (#787) This adds our own `mcp-types` crate to our Cargo workspace. We vendor in the [`2025-03-26/schema.json`](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/05f204513641c05bd78d056791af99c6c84520fa/schema/2025-03-26/schema.json) from the MCP repo and introduce a `generate_mcp_types.py` script to codegen the `lib.rs` from the JSON schema. Test coverage is currently light, but I plan to refine things as we start making use of this crate. And yes, I am aware that https://github.com/modelcontextprotocol/rust-sdk exists, though the published https://crates.io/crates/rmcp appears to be a competing effort. While things are up in the air, it seems better for us to control our own version of this code. Incidentally, Codex did a lot of the work for this PR. I told it to never edit `lib.rs` directly and instead to update `generate_mcp_types.py` and then re-run it to update `lib.rs`. It followed these instructions and once things were working end-to-end, I iteratively asked for changes to the tests until the API looked reasonable (and the code worked). Codex was responsible for figuring out what to do to `generate_mcp_types.py` to achieve the requested test/API changes. 2025-05-02 13:33:14 -07:00			`name = "mcp-types"`
Update submodules version to come from the workspace (#850) Tie the version of submodules to the workspace version. 2025-05-07 10:08:06 -07:00			`version = { workspace = true }`
feat: introduce mcp-types crate (#787) This adds our own `mcp-types` crate to our Cargo workspace. We vendor in the [`2025-03-26/schema.json`](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/05f204513641c05bd78d056791af99c6c84520fa/schema/2025-03-26/schema.json) from the MCP repo and introduce a `generate_mcp_types.py` script to codegen the `lib.rs` from the JSON schema. Test coverage is currently light, but I plan to refine things as we start making use of this crate. And yes, I am aware that https://github.com/modelcontextprotocol/rust-sdk exists, though the published https://crates.io/crates/rmcp appears to be a competing effort. While things are up in the air, it seems better for us to control our own version of this code. Incidentally, Codex did a lot of the work for this PR. I told it to never edit `lib.rs` directly and instead to update `generate_mcp_types.py` and then re-run it to update `lib.rs`. It followed these instructions and once things were working end-to-end, I iteratively asked for changes to the tests until the API looked reasonable (and the code worked). Codex was responsible for figuring out what to do to `generate_mcp_types.py` to achieve the requested test/API changes. 2025-05-02 13:33:14 -07:00
Workspace lints and disallow unwrap (#855) Sets submodules to use workspace lints. Added denying unwrap as a workspace level lint, which found a couple of cases where we could have propagated errors. Also manually labeled ones that were fine by my eye. 2025-05-08 09:46:18 -07:00			`[lints]`
			`workspace = true`

feat: introduce mcp-types crate (#787) This adds our own `mcp-types` crate to our Cargo workspace. We vendor in the [`2025-03-26/schema.json`](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/05f204513641c05bd78d056791af99c6c84520fa/schema/2025-03-26/schema.json) from the MCP repo and introduce a `generate_mcp_types.py` script to codegen the `lib.rs` from the JSON schema. Test coverage is currently light, but I plan to refine things as we start making use of this crate. And yes, I am aware that https://github.com/modelcontextprotocol/rust-sdk exists, though the published https://crates.io/crates/rmcp appears to be a competing effort. While things are up in the air, it seems better for us to control our own version of this code. Incidentally, Codex did a lot of the work for this PR. I told it to never edit `lib.rs` directly and instead to update `generate_mcp_types.py` and then re-run it to update `lib.rs`. It followed these instructions and once things were working end-to-end, I iteratively asked for changes to the tests until the API looked reasonable (and the code worked). Codex was responsible for figuring out what to do to `generate_mcp_types.py` to achieve the requested test/API changes. 2025-05-02 13:33:14 -07:00			`[dependencies]`
chore: unify cargo versions (#4044) Unify cargo versions at root 2025-09-22 18:47:01 +02:00			`serde = { workspace = true, features = ["derive"] }`
			`serde_json = { workspace = true }`
			`ts-rs = { workspace = true, features = ["serde-json-impl", "no-serde-warnings"] }`
Generate JSON schema for app-server protocol (#5063) Add annotations and an export script that let us generate app-server protocol types as typescript and JSONSchema. The script itself is a bit hacky because we need to manually label some of the types. Unfortunately it seems that enum variants don't get good names by default and end up with something like `EventMsg1`, `EventMsg2`, etc. I'm not an expert in this by any means, but since this is only run manually and we already need to enumerate the types required to describe the protocol, it didn't seem that much worse. An ideal solution here would be to have some kind of root that we could generate schemas for in one go, but I'm not sure if that's compatible with how we generate the protocol today. 2025-10-20 11:45:11 -07:00			`schemars = { workspace = true }`