[Feature] Expose the DevToys CLI tools as a Model Context Protocol (MCP) server

What feature or new tool do you think should be added to DevToys?

A new DevToys.MCP executable that exposes the existing DevToys command line tools as a Model Context Protocol (MCP) server over stdio, so an MCP client (an AI assistant, an IDE agent such as Claude Code / Cursor / VS Code, etc.) can discover and run the DevToys tools programmatically.

Why do you think this is needed?

DevToys already ships DevToys.CLI, which runs the ICommandLineTool extensions from a terminal. However there is no way for an AI assistant or IDE agent to discover and invoke those same tools.

MCP has become the de-facto standard for connecting AI assistants to external tools. Exposing the DevToys tools over MCP lets users run trusted, offline, well-tested conversions/encoders/formatters (Base64, JWT, hashing, JSON/YAML, etc.) directly from their AI workflow — instead of relying on the model to do the transformation itself (which is slower and error-prone) or pasting data into a random web tool. It reuses everything DevToys already provides and adds a modern integration surface.

Solution/Idea

I have a working implementation on a branch and would love feedback on whether this is something you'd accept upstream (and on the design) before opening a PR.

• Branch: https://github.com/pierre3/DevToys/tree/feature/devtoys-mcp-server
• Full diff vs main: https://github.com/DevToys-app/DevToys/compare/main...pierre3:DevToys:feature/devtoys-mcp-server

Design summary:

• Reuses the CLI tool model — tools are discovered through MEF exactly like DevToys.CLI (from a Plugins folder next to the executable, or via the EXTRAPLUGIN env var). No changes to the tool model itself.
• Schema generation — each ICommandLineTool becomes one MCP tool named devtoys_<command-name> (e.g. devtoys_base64), with a JSON input schema generated from its [CommandLineOption] properties. OneOf<...> options (e.g. "text or file path") are exposed as a string and parsed at invocation time.
• Invocation — tools/call binds arguments (mirroring the CLI binding, including OneOf), runs the tool, and returns its captured console output plus a structured { stdout, stderr, exitCode } payload. Non-zero exit codes mark the result as an error. Invocations are serialized because the tools write to the process-wide console.
• Build — DevToys.MCP is published per-RID by the Nuke build alongside the CLI, and registered in the Windows/macOS/Linux solutions.
• Tests — xUnit tests added to DevToys.UnitTests (schema generation, argument conversion, OneOf parsing, result formatting).
• Purely additive — no existing runtime code is modified (27 files, +2242 lines). It builds in Release with no warnings and all unit tests pass.
• ModelContextProtocol (Apache-2.0) is added to THIRD-PARTY-NOTICES.md.

Example MCP client configuration:

{
  "mcpServers": {
    "devtoys": {
      "command": "path/to/DevToys.MCP.exe",
      "env": {
        // Optional: load the tools from a specific extension folder.
        "EXTRAPLUGIN": "path/to/DevToys.Tools"
      }
    }
  }
}

The stdout stream is reserved for the MCP protocol; all logs are written to disk only.

Comments

If you're open to this, I'm happy to open a PR (the branch above is already rebased on the latest main and merges cleanly). I'd also welcome guidance on anything you'd want changed first — naming (devtoys_*), where the project should live, packaging/publishing expectations, etc.