crosspad-mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

crosspad_build

Destructive

Build CrossPad for PC, ESP32-S3, or STM32G0, managing environment setup, build modes (incremental, clean, reconfigure), and error parsing.

Instructions

[PC | ESP | STM HW] Build CrossPad for the given platform. • platform='pc' → CMake + Ninja host simulator. PREFER THIS over cmake --build build (picks right MSVC env on Windows, parses errors/warnings, streams progress). • platform='idf' → idf.py build for ESP32-S3 firmware. PREFER THIS over raw idf.py build (sources IDF env, auto-fullcleans when new apps detected, parses errors/warnings). Follows the board revision resolved by tools/crosspad_board.py — passes -B build_ -DSDKCONFIG=sdkconfig.; refuses if no revision is known. • platform='stm' → CMake + Ninja + arm-none-eabi for STM32G0 firmware (CrossPad r20). Uses CMakePresets (Debug/Release); output is build//CrossPad_STM32_r20.elf. Mode×platform compatibility: • incremental → all (default) • clean → all (wipes build dir, then builds) • reconfigure → PC & STM (re-runs cmake without wiping cache) • fullclean → IDF only (runs idf.py fullclean, then builds)

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	No	Build mode. Compatibility: incremental & clean = all platforms; reconfigure = PC & STM; fullclean = IDF only. Pick incremental for normal iteration; clean if you suspect stale artifacts; fullclean (IDF) after adding new apps; reconfigure (PC/STM) after editing CMakeLists/presets.	incremental
`board`	No	IDF only. Board revision. Default: the connected board (hardware revision from the STM bridge), else the last choice (tools/crosspad_board.py).
`platform`	Yes	Target platform: 'pc' = host simulator, 'idf' = ESP32-S3 firmware, 'stm' = STM32G0 firmware (CrossPad r20).
`build_type`	No	CMake build type — PC & STM (ignored for IDF; ESP32 build type comes from sdkconfig). STM maps to the Debug/Release preset (RelWithDebInfo→Release). Only honored on mode=clean\|reconfigure (incremental keeps existing cache).	Debug

Output Schema

TableJSON Schema

Name	Required	Description	Default
`tail`	No
`error`	No
`errors`	No
`success`	Yes
`warnings`	No
`board_rev`	No
`build_dir`	No
`output_path`	No
`warnings_count`	No
`duration_seconds`	No
`auto_reconfigured`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv10.3.0Sep 24, 2026

addedInput schema / properties / board

Added value: +{
+  "description": "IDF only. Board revision. Default: the connected board (hardware revision from the STM bridge), else the last choice (tools/crosspad_board.py).",
+  "enum": [
+    "v1",
+    "v2"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / board_rev

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedOutput schema / properties / build_dir

Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}

First observedv9.2.0Aug 4, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes far beyond the destructiveHint/readOnly annotations by disclosing environment sourcing (MSVC env, IDF env), auto-fullclean when new apps are detected, refusal behavior when no board revision is known, build-dir wiping for clean mode, and STM preset mapping (RelWithDebInfo→Release). The destructive actions described ('wipes build dir', 'runs idf.py fullclean') align with destructiveHint=true — no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose line, then organizes per-platform behavior in bullets and mode compatibility in a compact table. Every sentence carries distinct information — build system choice, preference rationale, output path, or mode constraint. No filler, despite covering a complex 3-platform × 4-mode matrix.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 platforms × 4 modes plus board-revision and build-type logic, the description covers all decision axes: which commands run, which flags are passed, when builds are refused, what gets wiped, and where output lands. Return values are covered by the existing output schema, and environment prerequisites are discoverable via siblings (crosspad_doctor, crosspad_toolsets). Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all four parameters, setting a baseline of 3. The description adds value on top: concrete flags passed for IDF (-B build_<rev> -DSDKCONFIG=sdkconfig.<rev>), board revision resolution via tools/crosspad_board.py, and the exact STM output path (build/<preset>/CrossPad_STM32_r20.elf). These enrich platform, board, and build_type semantics beyond what the schema alone provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with an explicit verb+resource statement — 'Build CrossPad for the given platform' — then disambiguates three platform targets (pc/idf/stm), each with its own build system (CMake+Ninja, idf.py, arm-none-eabi). This clearly differentiates it from build-adjacent siblings like crosspad_flash and crosspad_repo_status. No ambiguity about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'PREFER THIS over `cmake --build build`' and 'PREFER THIS over raw `idf.py build`' with concrete reasons (correct MSVC env, error parsing, progress streaming, env sourcing). The Mode×platform compatibility table tells the agent exactly which modes work on which platforms and when to pick each (incremental for normal iteration, fullclean after adding apps, reconfigure after editing CMakeLists). This is textbook when/when-not guidance with named alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server