Protoship

Check an ESP32 project

check_project

Read-onlyIdempotent

Reads an ESP32 project from a public GitHub repo (or a folder or file in it, or a raw file link) or from files you pass inline, and returns: the board and chip, firmware type, the modules it uses, every GPIO it assigns with findings (flash pins, strapping pins, input-only pins, the board's own display/touch/SD pins, octal PSRAM pins), power notes, whether there is a custom PCB, BOM or enclosure files, whether the build fits Finish my build, and next steps. Free, read-only, stores nothing.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_project"
  }
}

Input Schema

Name	Required	Description	Default
`url`	No	https link to a public GitHub repo, a folder (…/tree/branch/path) or a file, or any raw file URL.
`files`	No	Project files inline instead of url: ESPHome YAML, platformio.ini, sketch (.ino/.cpp/.h), KiCad schematic, BOM CSV. Up to 12 files, 200 kB each.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description still adds meaningful behavior beyond that: 'Free, read-only, stores nothing' reassures on data retention, and it discloses the analytic depth of the scan (flash/strapping/input-only/octal PSRAM pin checks). It does not mention rate limits or failure modes for private/nonexistent repos, which keeps it at 4.

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

Conciseness4/5

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

The payload list is long but front-loaded after the verb and phrased as a single scannable enumeration; nothing is padding, and the closing 'Free, read-only, stores nothing.' is a compact trust signal. The very dense single sentence packs a lot together, which slightly taxes parsing but wastes no words.

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?

With no output schema, the description carries the return contract itself and does so thoroughly — enumerating every finding category the agent can expect. Inputs, limits, and behavioral guarantees are all covered, so an agent could invoke this correctly without further information.

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

Parameters3/5

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

Schema description coverage is 100% and both parameters are documented there, including the 12-file/200 kB limit. The description largely restates the source types already in the schema ('raw file link' vs 'url', 'files you pass inline'), adding only the framing that the two are alternatives. Baseline 3 is appropriate.

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?

The description opens with a specific verb and resource ('Reads an ESP32 project') and immediately narrows the accepted sources (public GitHub repo, folder, file, raw link, or inline files). It then enumerates exactly what is returned (board/chip, firmware type, modules, GPIO findings, power notes, PCB/BOM/enclosure, build fit, next steps), which distinguishes it from siblings like estimate_build and match_parts.

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

Usage Guidelines4/5

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

It gives clear context for when this tool applies — you have a repo, a path inside a repo, a raw file, or up to 12 inline files — and signals a relationship to 'Finish my build'. However, it never explicitly routes the agent between this tool and siblings such as estimate_build, and states no exclusions or prerequisites beyond 'public GitHub repo'.

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

All Protoship tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?