Skip to main content
Glama
siliconsmith-mcp

siliconsmith-mcp

by RFingAdam

synthesize

Destructive

Convert RTL into sky130 logic gates, catch lint issues, and report cell count, area, and estimated tile utilization to confirm the design fits.

Instructions

Turn the design into real chip gates and say how big it is. Synthesis is the step where a program (Yosys) replaces your RTL with the small ready-made logic gates and flip-flops of the sky130 chip library, the same way Tiny Tapeout's own flow does. The tool first runs the same checks as emit_verilog (a lint problem stops it, with file and line), then synthesizes with the clock from spec.yaml recorded as Tiny Tapeout does (this recipe optimizes for small area, so the clock does not change the gates; timing is checked at layout). The summary gives the number of cells (flip-flops, which store bits, and logic gates), the total cell area in um^2, the most used cell types, and the estimated utilization: how much of your tile's usable area the cells would fill. Utilization is an ESTIMATE; real placement (layout, milestone M2) gives the real number, and it needs headroom (above 90% is risky, above 100% will not fit). The tile size comes from tiles in spec.yaml (default 1x1); a design far too big for it is stopped early with a "too big" message and what to do: make the design smaller, or ask the owner about a bigger tile (it costs money, so the owner decides). ok is false for a lint or Yosys error, a combinational loop, a signal driven twice, an undriven output, a cell that Tiny Tapeout does not allow, a design that is too big, or a time-out (900 s). A latch you wrote on purpose (always_latch) is reported as a warning with file and line. A clock above 66 MHz also warns: Tiny Tapeout's pins cannot go that fast. The netlist is saved in build/synth/ (a convenience copy of the latest run that wrote one; the ledger's netlist_sha256 records what was synthesized). Usually takes seconds to a minute.

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": {
      "project": "<project>"
    },
    "name": "synthesize"
  }
}

Input Schema

NameRequiredDescriptionDefault
projectYes

Output Schema

NameRequiredDescriptionDefault
okYes
detailsNo
summaryYes
artifactsNo
next_hintsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations (readOnlyHint=false, destructiveHint=true) only signal a write; the description explains exactly what is written (build/synth/ netlist, ledger netlist_sha256) and why. It enumerates failure modes (lint, Yosys error, combinational loop, double-driven signal, undriven output, disallowed cell, too big, 900 s timeout), warnings (intentional latch, clock >66 MHz), and cautions that utilization is an estimate with a 90%/100% risk threshold.

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?

Front-loaded with the action and the outcome, then progressively details behavior. The block is long and some clauses (the cell-type/library aside) could be tightened, but nearly every sentence carries operational information, so little is pure waste.

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?

The tool is complex (full synthesis run with many failure classes) and the description covers inputs' source (spec.yaml tiles), runtime expectation, output meaning, and error surface. An output schema exists, yet the extra explanation of utilization and headroom is genuinely useful risk context rather than redundant.

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?

Only `project` exists and schema description coverage is 0%, so the description would need to define it, but it never mentions the parameter at all. The name is self-explanatory enough that an agent can infer it, but no format, default, or constraint is added.

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?

States a concrete verb and resource ('Turn the design into real chip gates') and immediately names the underlying engine (Yosys) and library (sky130), plus what it reports (size). It is clearly distinct from siblings like emit_verilog, whose checks it explicitly re-runs.

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?

Places the tool in the flow implicitly ('the step where...') and ties it to emit_verilog ('first runs the same checks as emit_verilog'), and to layout/M2 for the real number. It never states a hard precondition such as 'call after emit_verilog passes' or a when-not, so guidance is clear but not exhaustive.

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