siliconsmith-mcp

Overview Schema Source Related Servers Discussions Admin

create_project

Create a new Tiny Tapeout chip project folder with a working starter design, wrapper, and cocotb test stub for Verilog, Amaranth, or MyHDL workflows.

Instructions

Create a new chip project folder // shaped like a Tiny Tapeout Verilog project, with a working starter design, a Tiny Tapeout wrapper (tt_um_) and a cocotb test stub.

Arguments: name (lowercase letters, digits and underscores, starting with a letter, at most 31 characters; it becomes the Verilog module name), frontend ('amaranth', 'myhdl' or 'verilog'; optional when the server has a default), author (goes into file headers and info.yaml), description (one line), title (optional, defaults to the name).

The design you write is the 'core' module named . Its ports use the Tiny Tapeout pin names: clk, rst_n (active low), ena, ui_in[7:0], uio_in[7:0] in; uo_out[7:0], uio_out[7:0], uio_oe[7:0] out. Amaranth and MyHDL projects keep their source in hdl/.py; Verilog projects keep it in src/.v. Every other tool takes the project name as its first argument.

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": {
      "name": "<name>",
      "author": "<author>",
      "description": "<description>"
    },
    "name": "create_project"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes
`title`	No
`author`	Yes
`frontend`	No
`description`	Yes

Output Schema

Name	Required	Description	Default
`ok`	Yes
`details`	No
`summary`	Yes
`artifacts`	No
`next_hints`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 14, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the basic safety profile is already known. The description adds substantial behavioral detail: the exact folder shape (<root>/<name>/), the generated starter design, the Tiny Tapeout wrapper, the cocotb test stub, and the expected core module ports. It does not state what happens if the directory already exists or whether files would be overwritten.

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 description is front-loaded with its purpose, then documents arguments, then explains generated design conventions. It is dense and mostly waste-free. It runs fairly long, but nearly every sentence provides invocation-relevant detail, especially given that the schema has no descriptions.

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

Completeness4/5

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

For a multi-file project scaffold, the description covers the generated artifacts, parameter constraints, module port names, and frontend-specific file locations. Because an output schema exists, return values need not be explained. The main missing behavior is overwrite or error semantics when the target project already exists.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must carry the full parameter burden. It does: name constraints are given as lowercase letters, digits, underscores, letter start, at most 31 characters, and the name becomes the Verilog module name; frontend allowed values are listed as 'amaranth', 'myhdl', or 'verilog' and marked optional when the server has a default; author destination, description length, and title default are all explained. This adds meaning far beyond the empty schema property definitions.

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 states a specific verb and resource: create a new chip project folder shaped like a Tiny Tapeout Verilog project, with a starter design, wrapper, and cocotb test stub. This distinguishes it clearly from sibling tools such as write_rtl or write_spec, which operate on existing project files.

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

Usage Guidelines3/5

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

Usage is implied: this is the scaffolding step that creates the project directory and starter files. The note that every other tool takes the project name as its first argument provides workflow context. However, there is no explicit when-to-use or when-not-to-use guidance relative to alternatives, and no stated behavior when a project already exists.

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

Deploy Server