How do I use gowin-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gowin-mcp show me the summary of my latest build" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

gowin-mcp

by Papipapito

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

gowin-mcp

Beta. Working and in daily use, but verified against a narrow slice of Gowin output so far — see Beta status before trusting a number that matters. Bug reports with a sample report attached are very welcome.

An MCP server that turns Gowin EDA build reports into structured data.

Gowin EDA writes everything you need after a place & route — resource usage, achieved frequency per clock, the exact register-to-register path that failed setup — and then buries it in a multi-megabyte HTML file nobody opens. This server reads those artifacts and hands back the numbers.

Built for Sipeed Tang boards (GW1N / GW2A / GW5A) but it only cares about the report format, so any Gowin EDA project works.

What it answers

Did this build close timing, and if not, which path failed and by how much?
What is the achieved fMax on each clock domain versus its constraint?
How much of the device am I using — CLS, LUT, ALU, registers, BSRAM, DSP, I/O?
What did my last change cost me? (gowin_compare diffs two builds.)

Related MCP server: forgejo-mcp

Install

git clone https://github.com/Papipapito/gowin-mcp.git
cd gowin-mcp
npm install
npm run build

Then register it. For Claude Desktop, in claude_desktop_config.json:

{
  "mcpServers": {
    "gowin": {
      "command": "node",
      "args": ["C:\\path\\to\\gowin-mcp\\dist\\index.js"]
    }
  }
}

For Claude Code:

claude mcp add gowin -- node /path/to/gowin-mcp/dist/index.js

Tools

Tool	Purpose
`gowin_summary`	Device, resources, fMax and violations in one call. Start here.
`gowin_resources`	Full resource tables, including I/O banks and clock resources.
`gowin_timing`	fMax per clock, total negative slack, worst setup/hold paths.
`gowin_check`	Pass/fail gate — violations only.
`gowin_compare`	Diff two builds: resource deltas, fMax deltas, violations introduced/fixed.
`gowin_list_builds`	Find every Gowin build under a directory tree.

Every tool takes format: "json" if you want the raw structures instead of text.

Paths are forgiving: pass the project directory, its impl/ directory, or the .rpt.txt itself.

Example

Build: project  (GW5AT-60, GW5AT-LV60PG484AC1/I0)
Tool:  V1.9.11.03 Education
Built: Thu Jul 16 20:58:03 2026   PnR 0h 3m 29s   peak 1848MB

Resources
  Logic: 28034/59904 (47%)
    LUT 21883, ALU 3325, ROM16 0
  CLS: 19618/29952 (66%)
  Register: 15014/60780 (25%)
  BSRAM: 73/118 (62%)
  DSP: 10.5/118 (9%)
  I/O Port: 141/297 (48%)

Timing: 3 VIOLATIONS
  setup clk_54m    -1.826 ns  1 endpoint failing setup — worst path -1.826 ns:
                              cpu1/u0/ISet_1_s87/Q -> mem1/ram_busy_s0/CE
  setup clk_hdmi   -0.378 ns  ...
  hold  clk_27m    -0.028 ns  ...

fMax per clock
  clk_54m: 33.548 MHz vs 53.996 MHz constraint (-20.448) [FAIL]
  clk_hdmi: 72.221 MHz vs 74.25 MHz constraint (-2.029) [FAIL]
  clk_108m: 159.744 MHz vs 107.991 MHz constraint (+51.753) [ok]
  ...

And a comparison between two builds of the same design:

Resource changes
  LUT,ALU,ROM16                13361 ->   13450  +89 (+0.67%)
  BSRAM                           33 ->      44  +11 (+33.33%)
  CLS                           8912 ->    8901  -11 (-0.12%)

fMax changes
  clock_54m          50.404 ->    45.284 MHz  -5.12
  clock_audio       411.534 ->     437.8 MHz  +26.266

Violations: 0 introduced, 0 fixed, 1 persisting
  still  setup clock_54m -1.615ns

VERDICT: no regression.

What it reads

File	Used for
`impl/pnr/<name>.rpt.txt`	Device, tool version, resource tables, PnR runtime
`impl/pnr/<name>_tr_content.html`	fMax, total negative slack, setup/hold path tables

<name>.tr.html is only a ~350-byte frameset wrapper — the data is in the _tr_content sibling.

Tables are parsed structurally (tr/td), not by flattening the HTML, so a column layout change between tool versions surfaces as a missing field rather than a silently misaligned number.

Scope

This server reads results. It does not run builds.

A GW5A place & route takes minutes, which does not fit an MCP request, and driving long builds through a tool call hides their output. Keep building with gw_sh, make, or the Gowin GUI as you already do — then point this at the results.

Beta status

What has actually been exercised:

	Verified
Tool versions	V1.9.11.03 Education, V1.9.9 Beta-4 Education
Devices	GW5AT-60 (Tang Console 60K), GW2AR-18 (Tang Nano 20K)
Host	Windows 11

Known gaps, in rough order of how likely they are to bite you:

Only the proprietary Gowin EDA flow. Output from the open-source chain (yosys / nextpnr-himbaechel / apicula) is a completely different format and is not parsed at all. If you build with nextpnr, this server has nothing to read.
GW1N is untested. It should work — the report layout looks family-independent — but nobody has run it.
Report headers have already been seen to drift between releases (PnR Version became Tool Version around 1.9.11). Other fields may drift the same way on versions not listed above.
Only tested against English-language reports.
Power and pin reports (*.power.html, *.pin.html) are written by the tool but not read yet.

Failures should be visible rather than silent: fields that do not parse come back absent instead of wrong. If you get a missing or implausible number, please open an issue with the offending .rpt.txt or _tr_content.html attached.

Notes

Setup and hold violations are taken from the Total Negative Slack summary rather than the path tables, because the path tables are capped by -max_paths at report time and would under-report a design with many failures.
An fMax failure is only reported separately when no setup violation already covers that clock — otherwise it is the same defect counted twice.

License

MIT

Available Tools

6 tools

gowin_checkA

Pass/fail gate. Returns only the timing violations, with the offending path for each. Empty means the build closed timing.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to the build: the project directory, its impl/ directory, or the .rpt.txt itself.
`format`	No	Output format. Defaults to text, which is far more compact.

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description explains the return value: timing violations with paths, and empty meaning timing closed. It could be more explicit about error handling or invalid paths, but it covers the core behavior.

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?

Extremely concise with two sentences; front-loaded with the purpose ('Pass/fail gate'), no redundant information, every sentence earns its place.

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

Completeness3/5

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

While it explains the return value, it lacks context on what constitutes a timing violation, error conditions, or how the gate's output integrates with the build flow. No output schema or annotations to supplement.

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 coverage is 100%, so the schema already describes both parameters. The description adds no additional meaning beyond 'path to the build' and 'output format', so it meets the baseline but doesn't exceed.

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 clearly states it's a pass/fail gate that returns timing violations, distinguishing it from sibling tools like gowin_summary, gowin_resources, and gowin_compare by focusing solely on timing closure.

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?

The description implies use for timing closure checks but does not explicitly state when to use versus alternatives like gowin_timing, nor does it provide when-not-to-use guidance or prerequisites.

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

gowin_compareA

Diff two builds: resource deltas, fMax change per clock, and which violations were introduced, fixed, or persist. Use this to see what a change actually cost.

ParametersJSON Schema

Name	Required	Description
`after`	Yes	New build path.
`before`	Yes	Baseline build path.
`format`	No	Output format. Defaults to text, which is far more compact.

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It describes outputs but doesn't explicitly state the tool is read-only or disclose any side effects. Typical diff behavior is assumed, but not guaranteed.

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?

Two sentences, no wasted words. Front-loaded with action and specific outputs, followed by usage advice.

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?

The description adequately covers purpose and usage for a diff tool. Without an output schema, it hints at output contents but could be more detailed about return format or limitations.

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%, baseline 3. The description adds value by explaining the format parameter's default and compactness, and implies 'before' and 'after' are build paths. This enriches understanding beyond the schema.

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 clearly states the tool compares two builds, listing specific outputs (resource deltas, fMax change, violations). It distinguishes from siblings like gowin_resources (single build) and gowin_timing (single build) by focusing on diffs.

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?

The phrase 'Use this to see what a change actually cost' gives clear usage context. It doesn't explicitly mention alternatives, but sibling names imply when to use other tools.

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

gowin_list_buildsA

Find Gowin EDA builds under a directory tree. Returns project name, device, and when each was built, newest first.

ParametersJSON Schema

Name	Required	Description	Default
`root`	Yes	Directory to search.
`maxDepth`	No	Search depth, default 8.

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses return fields and sort order but omits side-effect information (e.g., is it read-only?), permissions, or error behavior. Basic behavioral details present but not comprehensive.

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?

Single sentence, no redundancies. Front-loaded with key verb and resource. Every word adds value.

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 simple listing tool with two parameters and no output schema, the description covers core functionality, return fields, and sorting. Lacks only minor context like file system access limits or performance hints.

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 covers 100% of parameters with descriptions. The tool description adds no extra semantic value beyond the schema (e.g., 'root' is directory, 'maxDepth' default). Baseline 3 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?

Description clearly states verb ('Find'), resource ('Gowin EDA builds'), and scope ('under a directory tree'). It specifies return fields (project name, device, build time) and sort order (newest first). Unlike sibling tools, it uniquely identifies its function.

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?

Description implies usage for listing builds in a directory but offers no explicit guidance on when to prefer this tool over siblings (gowin_summary, etc.). No 'when not to use' or alternative suggestions.

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

gowin_resourcesA

Full resource usage for one build: logic, CLS, registers, BSRAM, DSP, I/O banks and clock resources.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Path to the build: the project directory, its impl/ directory, or the .rpt.txt itself.
`format`	No	Output format. Defaults to text, which is far more compact.
`includeBanks`	No	Include the I/O bank and clock resource tables.

TDQS

A3.6/5.0

Behavior3/5

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

No annotations provided; the description describes it as a read operation returning resource usage, which is safe. However, it doesn't disclose potential performance or authorization details.

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?

Single, informative sentence with no extraneous text. Front-loaded with the core action and scope.

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?

Given 3 parameters and no output schema, the description sufficiently covers the tool's purpose and key resource types. Lacks detail on output format but format parameter is documented.

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 coverage is 100%, so baseline is 3. The description does not add extra meaning beyond the property descriptions in the schema.

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?

The description clearly states the tool retrieves 'Full resource usage for one build' and lists specific resource types. It distinguishes it from siblings by specifying 'one build' but does not explicitly differentiate.

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?

The description implies use for a single build resource report, but provides no explicit guidance on when to use vs siblings or when not to use. No alternatives mentioned.

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

gowin_summaryA

Headline report for one build: device, resource usage, fMax per clock, and every timing violation. Start here.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to the build: the project directory, its impl/ directory, or the .rpt.txt itself.
`format`	No	Output format. Defaults to text, which is far more compact.

TDQS

A4.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It correctly implies a read-only report (no destructive actions), but does not explicitly state that it is safe or has no side effects. The lack of annotation makes this adequate but not excellent.

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?

The description is a single sentence with no filler. It is front-loaded with the key output contents, making it highly efficient.

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?

Given the tool's simplicity (2 parameters, no output schema), the description fully informs about the return value (device, resource usage, fMax, timing violations). No gaps.

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%, and the description adds value beyond the schema by noting that the 'text' format is 'far more compact.' The path parameter's description is adequate.

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 explicitly states 'Headline report for one build: device, resource usage, fMax per clock, and every timing violation.' and instructs 'Start here.' This clearly distinguishes it from sibling tools like gowin_resources and gowin_timing, which focus on specific aspects.

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?

The description says 'Start here,' implying it should be used first for an overview before diving into specific details. While it doesn't explicitly mention when not to use it or compare with siblings, the context is clear enough for an agent.

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

gowin_timingA

Timing detail for one build: fMax per clock, total negative slack, and the worst setup/hold paths with their endpoints.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Path to the build: the project directory, its impl/ directory, or the .rpt.txt itself.
`format`	No	Output format. Defaults to text, which is far more compact.
`maxPaths`	No	Worst paths to show, default 10.

TDQS

A3.8/5.0

Behavior3/5

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

No annotations exist, so the description carries full burden. It lists outputs but doesn't disclose potential side effects, permissions, or limitations. It mentions 'worst paths' but lacks detail on what constitutes 'worst'.

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?

The description is a single sentence that efficiently front-loads key outputs (fMax, slack, worst paths). No unnecessary words.

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?

No output schema exists, and the description lists output types but doesn't detail structure. For a tool with moderate complexity, it is mostly complete but could benefit from mentioning whether results are per-clock or overall.

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 coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what the schema provides, thus baseline score 3.

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 clearly states the tool provides timing details for a single build, listing specific metrics like fMax, total negative slack, and worst paths. It distinguishes from siblings like gowin_summary and gowin_resources.

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?

The description implies this tool is for one build but provides no explicit guidance on when to use it vs. alternatives like gowin_summary or gowin_compare. No when-not-to-use or prerequisites are mentioned.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0-beta.1Jul 29, 2026
- First observedgowin_check
- First observedgowin_compare
- First observedgowin_list_builds
- First observedgowin_resources
- First observedgowin_summary
- First observedgowin_timing

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct aspect of Gowin EDA builds: listing, summary, resources, timing, pass/fail check, and comparison. No overlap in purposes.

Naming Consistency5/5

All tools follow the consistent pattern 'gowin_<action>', using snake_case throughout.

Tool Count5/5

Six tools cover the full workflow of build analysis without being excessive or insufficient.

Completeness4/5

Covers all major aspects (listing, resources, timing, check, comparison). Minor gap: no tool for raw build metadata or logs, but summary compensates.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748
mcpOAuth
com.bullpenstrategygroup.rotunda
An MCP server that provides congressional transcripts
Government Data Search Open Data
2
PlanExe A
io.github.PlanExeOrg
MCP server for generating rough-draft project plans from natural-language prompts.
Autonomous Agents Developer Tools Project Management
113399
riveterOAuth
io.github.CodyWatters
MCP server for Riveter's enrichment, scraping, and monitoring API
Web Scraping Monitoring Data Platforms
1

Related MCP Servers

Coverity
kriomant
-
license
Not graded
quality
Not graded
maintenance
MCP server for Blackduck Coverity Static Analysis Software.
Updated a year ago (2025-07-09 04:51 UTC)
-
forgejo-mcp
Version Control Developer Tools
raohwork
A
license
Not graded
quality
D
maintenance
An MCP server for managing your repositories on Forgejo/Gitea server.
Updated 10 months ago (2025-10-28 07:59 UTC)
66
Mozilla Public 2.0
openroad-mcp
Developer Tools Software Architecture
The-OpenROAD-Project
A
license
A
quality
A
maintenance
A Model Context Protocol (MCP) server that provides tools for interacting with OpenROAD and ORFS (OpenROAD Flow Scripts).
Updated 2 days ago (2026-09-06 14:19 UTC)
10
17
BSD 3-Clause
vivado-mcp-agent
Embedded system Developer Tools
wangyuxin0707
A
license
Not graded
quality
D
maintenance
MCP server for deterministic Vivado FPGA automation including project scaffolding, simulation, synthesis, implementation, and gated bitstream generation.
Updated 3 months ago (2026-05-27 00:56 UTC)
4
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Papipapito/gowin-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server