Skip to main content
Glama
Sign In
gowin-mcp

gowin-mcp

by Papipapito
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Compare builds

gowin_compare
Read-onlyIdempotent

Compare two Gowin EDA builds to report resource deltas, fMax changes, introduced, fixed, or persisting violations, and bitstream body match. Use it to see what a change cost.

Instructions

Diff two builds: resource deltas, fMax change per clock, which violations were introduced, fixed, or persist, and whether the two .fs bitstreams have the same body. Use this to see what a change actually cost. Builds on different devices are reported but not classified (safe is null).

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": {
      "before": "<before>",
      "after": "<after>"
    },
    "name": "gowin_compare"
  }
}

Input Schema

NameRequiredDescriptionDefault
afterYesNew build path.
beforeYesBaseline build path.
formatNoOutput format. Default text: a compact rendering, returned as the only content. json: the full JSON as text and as structuredContent.
afterNameNoWhen several builds share one impl/pnr/, pick this one by name (the <name> of <name>.rpt.txt). Default: the most recent, with the others listed under siblings.
beforeNameNoWhen several builds share one impl/pnr/, pick this one by name (the <name> of <name>.rpt.txt). Default: the most recent, with the others listed under siblings.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.2.2
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / properties / afterName
      Added value: +{
+  "description": "When several builds share one impl/pnr/, pick this one by name (the <name> of <name>.rpt.txt). Default: the most recent, with the others listed under siblings.",
+  "type": "string"
+}
    • addedInput schema / properties / beforeName
      Added value: +{
+  "description": "When several builds share one impl/pnr/, pick this one by name (the <name> of <name>.rpt.txt). Default: the most recent, with the others listed under siblings.",
+  "type": "string"
+}
    • changedInput schema / properties / format / description
      Previous value: -"Output format. Defaults to text, which is far more compact."New value: +"Output format. Default text: a compact rendering, returned as the only content. json: the full JSON as text and as structuredContent."
  2. First observedv0.1.0-beta.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive/closed-world, so the bar is lower; the description adds substantive semantics beyond that, namely the violation taxonomy (introduced/fixed/persist) and the important edge case that cross-device comparisons are reported but leave safe as null. It doesn't cover error behavior for missing or unreadable build paths.

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, densely front-loaded: the comparison contents come first, the intended use second, and the cross-device caveat last. Every clause carries information an agent needs at selection time.

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?

With no output schema, the description carries the burden of describing what comes back, and it does list the diff categories well. It stops short of describing the overall response shape or how the text vs json format differs in content, though the format parameter's schema description partially compensates.

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 baseline is 3; the schema already documents before/after, format, and the afterName/beforeName sibling-selection behavior in detail. The description only implicitly reinforces the two-build relationship and says nothing about afterName/beforeName naming or the text/json format switch, so it adds little 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?

Names a specific verb (diff) and resource (two builds), then enumerates exactly what the delta covers: resource deltas, fMax change per clock, violation classification, and bitstream body equality. This distinguishes it cleanly from siblings like gowin_summary, gowin_timing, and gowin_resources, which report on a single build.

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?

"Use this to see what a change actually cost" gives a clear motivating context, and the cross-device caveat signals when the classification will be unavailable. However, it doesn't explicitly name alternative tools (e.g., gowin_summary for viewing a single build) for an agent that has no before/after pair to compare.

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

Deploy Server

Other Tools