oss-cad-mcp

by ChalkCalliope

Overview Schema Source Related Servers Discussions Admin

Python

Local

cad_fpga_build

Builds iCE40/ECP5 FPGA bitstreams from HDL sources by running synthesis, place-and-route, packing, and timing checks.

Instructions

Build an iCE40/ECP5 bitstream: synthesis, place-and-route, packing, timing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "request": "<request>"
    },
    "name": "cad_fpga_build"
  }
}

Input Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

Name	Required	Description	Default
`ok`	Yes
`job`	Yes
`top`	No
`error`	No
`speed`	No
`device`	No
`family`	Yes
`stages`	No
`timing`	No
`package`	No
`summary`	No
`artifacts`	No
`bitstream`	No
`timing_met`	No
`utilization`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

C2.7/5.0

Behavior2/5

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

Annotations already establish it is a non-read-only, non-destructive, closed-world operation, so the safety profile is covered. The description adds nothing beyond that: it does not say that build artifacts are written to disk, where they land, what happens on synthesis or P&R failure, or how the two escape hatches (allow_timing_fail, allow_unconstrained) change the outcome. For a long-running build tool this is thin.

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?

A single compact sentence with the action front-loaded and zero filler; the stage list is the most informative part. It is efficiently sized, though the terseness comes at the cost of the guidance that is missing elsewhere.

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

Completeness2/5

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

The output schema means return values need not be explained, but for a complex multi-stage build with a 15-field nested request the description should cover the flow selection versus sibling tools, artifact production, and failure semantics. None of that is present, leaving the definition under-specified relative to the tool's complexity.

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

Parameters2/5

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

Schema description coverage is 0% and the single top-level `request` object nests roughly fifteen fields (family, device, package, speed, placer, router, source, constraints, timeout_s, seed, etc.) that the description never mentions. Only the family values are faintly implied by "iCE40/ECP5". The description does not compensate for the coverage gap at all.

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

Purpose4/5

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

States a concrete verb ("Build") and resource ("bitstream") and enumerates the pipeline stages performed (synthesis, place-and-route, packing, timing), plus the supported families iCE40/ECP5. It does not distinguish itself from siblings like cad_synthesize or cad_timing, which cover subsets of the same flow, so an agent cannot tell purely from the text which of these to pick.

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

Usage Guidelines2/5

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

There is no when-to-use or when-not-to-use guidance. Given sibling tools cad_synthesize and cad_timing exist, the description never says that this tool runs the whole flow end-to-end versus invoking stages individually, which is exactly the decision an agent must make. Usage is only implied by the stage list.

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

Deploy Server