Enables building and compiling C/C++ projects, detecting gcc and clang toolchains, and parsing GCC/Clang compiler diagnostics into structured JSON.
Enables building and running Python projects, detecting python3 toolchain, and parsing Python errors into structured JSON diagnostics.
Enables building and compiling Rust projects, detecting rustc and cargo toolchains, and parsing Rust compiler diagnostics into structured JSON.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ToolchainConductor MCP run cargo build in ./backend and return structured JSON errors"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
ToolchainConductor MCP is a polyglot compiler conductor, build runner, and diagnostic parsing sidecar designed for autonomous AI coding agents (Claude Desktop, Cursor, OpenAI Codex, LangGraph).
It enables agents to build hybrid polyglot projects (Python, Rust, Node, C/C++, Go), parse noisy compiler outputs into clean, structured JSON diagnostics, and eliminate ANSI escape code bloat from LLM context windows.
When autonomous AI agents build multi-language or compiled code:
ANSI Compiler Noise: Compilers dump hundreds of lines of colored ANSI escape sequences that pollute LLM context windows without providing structured error coordinates.
Missing Compilers & Incompatible Toolchains: Agents attempt to run cargo or gcc blindly without detecting installed host toolchains and target architectures.
Redundant Re-compilations: Without intermediate artifact caching, agents recompile heavy dependencies repeatedly, exhausting turn limits and CPU quotas.
ToolchainConductor solves this by providing a clean, protocol-native build orchestrator.
Related MCP server: Build Runner MCP Server
🔍 Host Toolchain Discovery: Automatic inspection of installed compilers (rustc, cargo, python3, gcc, clang, node, go).
🧹 Compiler Diagnostic Parser: Strips ANSI escape sequences and extracts structured JSON errors (file, line, col, code, message) for Rust, GCC/Clang, and Python.
⚡ Isolated Build Runner: Executes commands in clean child environments with timeout enforcement.
📦 Zero External Dependencies: Pure Python standard library implementation.
git clone https://github.com/johannschiffer/toolchainconductor-mcp.git
cd toolchainconductor-mcp
pip install -e .Add to your claude_desktop_config.json:
{
"mcpServers": {
"toolchainconductor": {
"command": "toolchainconductor",
"args": ["run"]
}
}
}toolchainconductor detectTool | Parameters | Description |
| (none) | Inspects all installed compilers and versions on host |
|
| Transforms raw compiler logs into structured JSON diagnostics |
|
| Executes build command in clean environment |
| (none) | Returns compiler readiness report |
Need content-addressable build caching, memory safety audits, and automated PyO3 / FFI scaffolding?
The ToolchainConductor Pro Edition adds:
⚡ Deterministic Build Cache (SQLite WAL): Deduplicates compiled artifacts via SHA-256 source and lockfile hashes, skipping redundant builds.
🛡️ Memory-Safety & Linter Hardening: Automatic invocation of cargo audit, cargo clippy, and sanitizers with structured auto-repair recipes.
🔗 Polyglot FFI Scaffolder: Generates production-ready PyO3 (Python-Rust) and CFFI bridge boilerplate.
🐳 Production Docker & Docker Compose multi-stage manifests.
🧪 100% Passing Pytest Suite.
👉 Get ToolchainConductor Pro on Gumroad ($14.99 USD)
MIT © 2026 Johann Schiffer
Inspect all installed compilers on the host (rustc, cargo, python, gcc, clang, node, go).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It implies a read-only inspection and lists what is probed, but says nothing about whether results include versions/paths, whether the scan is expensive, or what happens if a compiler is absent — the traits an agent needs to plan around.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the action and scope front-loaded and a parenthetical enumeration that adds real value. Every element earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, no annotations, and no output schema, the description is small but leaves the return shape undefined — it never says whether the agent gets versions, paths, or booleans. For a simple detection tool this is adequate but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter surface to document and nothing for the description to compensate for. Baseline 4 applies; no parameter semantics are needed or missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb ('Inspect') plus resource ('all installed compilers'), and it enumerates the exact toolchains checked (rustc, cargo, python, gcc, clang, node, go), so an agent knows precisely what is scanned. It does not, however, distinguish itself from the similarly-scoped sibling get_toolchain_status, which is the one ambiguity an agent would face.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus the sibling get_toolchain_status or parse_compiler_errors. The presence of a near-duplicate 'status' tool makes this omission more costly than usual, since the agent must guess which one reports presence versus health.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get quick summary of compiler readiness and supported target architectures.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. 'Get' implies a read-only operation and 'quick summary' suggests a lightweight response, but the description does not explicitly state side-effect safety, permissions, freshness, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence that front-loads the main purpose and adds only relevant scope details. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter status tool with no output schema, the description gives enough context to call it correctly and indicates what the summary will cover. It could be slightly more complete by hinting at the response shape or freshness, but no critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so the baseline score is 4. The description does not need to explain arguments, and it appropriately focuses on the summary content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description has a clear verb ('Get') and resource ('toolchain status'), and specifies the summary covers compiler readiness and supported target architectures. It is distinguishable from parse_compiler_errors and run_isolated_build, but it does not explicitly differentiate itself from the sibling detect_toolchains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'quick summary' hints at a lightweight status check, but there is no explicit guidance on when to use this tool versus detect_toolchains or other siblings. No conditions, exclusions, or alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract clean, structured JSON diagnostics (file, line, col, code, message) from raw compiler output.
| Name | Required | Description | Default |
|---|---|---|---|
| output | Yes | Raw compiler stdout/stderr or log text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the output structure (file, line, col, code, message), but says nothing about statelessness, behavior on unparseable/malformed input, handling of multiple compilers/formats, or failure modes for a parser.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no waste that immediately states verb, resource, and output fields. Nothing redundant or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one simple string parameter, no annotations, and no output schema, the description does compensate by enumerating the returned diagnostic fields. An agent can invoke it correctly, though edge-case behavior (malformed input, unsupported formats) is left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter with 100% schema description coverage ('Raw compiler stdout/stderr or log text'), so the schema already documents it fully. The description adds no syntax, format, or size constraints beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (extract/parse), a specific resource (compiler errors/diagnostics), and the exact shape of the result (file, line, col, code, message). It doesn't differentiate from the sibling tools detect_toolchains/run_isolated_build, but those operate in a clearly different domain, so the risk of confusion is low.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the input is 'raw compiler output,' which signals the situation to apply it, but there is no explicit when-to-use statement, no condition for preferring it over run_isolated_build, and no exclusions. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute build command in isolated environment and return exit code, output, and parsed diagnostics.
| Name | Required | Description | Default |
|---|---|---|---|
| cwd | No | Working directory path. | |
| command | Yes | Build command string (e.g. 'cargo build', 'pytest'). | |
| timeout_sec | No | Maximum execution time in seconds (default: 30.0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does contribute real behavioral context — execution occurs in an 'isolated environment' and returns exit code, output, and parsed diagnostics — but says nothing about sandbox side effects, timeout behavior, or failure modes when the command exceeds the limit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the execution semantics and return values are packed efficiently without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description usefully enumerates the returned fields (exit code, output, diagnostics) and the isolation property. It falls just short on timeout semantics and interaction with the toolchain-detection siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so command, cwd, and timeout_sec are fully documented in the schema itself. The description adds no format or semantic detail beyond it, making the baseline 3 correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('Execute') and resource ('build command') with the added scope of an isolated environment, plus a statement of what is returned. It does not, however, distinguish itself from the sibling parse_compiler_errors, which handles the parsing of diagnostics this tool also mentions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when to prefer this over detect_toolchains, parse_compiler_errors, or get_toolchain_status, nor any prerequisites (e.g. toolchain must be detected first). Usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0detect_toolchainsget_toolchain_statusparse_compiler_errorsrun_isolated_buildScored across 4 tools
detect_toolchains and get_toolchain_status overlap significantly, both reporting compiler availability and readiness. run_isolated_build also returns parsed diagnostics, making parse_compiler_errors partly redundant when used together, though each tool has a distinguishable core purpose.
All tool names follow a consistent snake_case verb_noun pattern (detect_toolchains, parse_compiler_errors, run_isolated_build, get_toolchain_status). There are no deviations in style or convention.
Four tools is well-scoped for a focused toolchain inspection and build-execution server. Each tool covers a distinct stage (detect, parse, run, status), though there is some functional overlap between detect and status.
The surface covers the core lifecycle of detecting toolchains, running isolated builds, parsing errors, and summarizing status. Minor gaps exist around installing or switching toolchains and managing build artifacts, but core workflows are supported.
Build Apps and run code in 30 languages — sandboxed, with persistent sessions for agent loops.
Backend platform for AI agents: one agentstack.execute tool runs batched steps over +700 actions (hosting, storage, auth, payments, CRM, app builder).
Build, validate, and deploy multi-agent AI solutions from any AI environment.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
