Skip to main content
Glama
Hachimeder

maxplus2-mcp

by Hachimeder
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Simulate and verify

simulate_and_verify
Idempotent

Automate MAX+PLUS II simulation verification: run headless, parse the .tbl result table, and check outputs against expected values.

Instructions

Run the Simulator headless and return the parsed result table, then optionally check expected output values. This is how simulation verification is automated: MAX+PLUS II writes a plain-text .tbl containing the simulated outputs, so a design can be checked without a human reading a waveform. Note a successful simulation may exit 1 — the verdict comes from the success banner plus the table artifact.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scfNoStimulus file. Defaults to <project>.scf if present.
tblNoWhere to write the result table. Defaults to <project>.tbl.
rootNoMAX+PLUS II installation root, for example C:\maxplus2. Defaults to MAXPLUS2_ROOT, then a scan of common paths.
asyncNoRun in the background and return a jobId immediately instead of blocking. Use for any compile or simulation that may outrun the client timeout: a client timeout does NOT stop the child process, so a blocking call that is abandoned keeps running with nobody holding the result. Poll with job_status.
expectNoExpected values, as { "<time>": { "SIGNAL": value } }. Values may be numbers or hex strings like "80". Outputs and buried nodes are both checkable.
projectYesProject name (for example "top") or an absolute path to its .acf file. A bare name is resolved against workspace, and is rejected as ambiguous if several projects share it.
timeoutMsNoHard timeout in milliseconds. A client timeout is wall-clock and progress does not extend it, so keep this below the client budget.
toleranceNoTime tolerance in table units when matching expectations (default 0.05).
workspaceNoDirectory that a relative project name is resolved against. Defaults to MAXPLUS2_WORKSPACE, then the server working directory.
previewRowsNoHow many leading trace rows to return (default 12).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.3

TDQS

A4.3/5.0
Behavior5/5

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

Adds a genuinely non-obvious behavioral fact that annotations cannot convey: a successful simulation may exit 1, and the verdict comes from the success banner plus the .tbl artifact. That single disclosure prevents an agent from mis-classifying a good run as a failure. It also explains the .tbl output artifact the run produces.

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?

Three sentences, front-loaded with the action and the artifact, and the critical exit-code caveat placed last as a warning. The middle explanatory sentence about why this matters is slightly discursive but still earns its place by justifying the tool's existence.

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 10-parameter, mutation-capable tool with no output schema, the description supplies the essential missing context: what artifact is produced and how to interpret success. It does not describe the shape of the parsed table or pagination/preview interaction, which leaves a modest gap.

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 description coverage is 100%, with defaults, ranges and formats (e.g. expect as {"<time>":{"SIGNAL":value}}, root fallback chain) all documented in the schema. The description adds only the high-level notion of optional expectation checking, which is the baseline 3 when the schema already does the heavy lifting.

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?

A specific verb+resource combination ('Run the Simulator headless and return the parsed result table') plus the optional expectation checking, which cleanly separates it from parse_tbl and the generic maxplus2_run. An agent can identify the tool's job without opening the schema.

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?

States the context clearly ('This is how simulation verification is automated... a design can be checked without a human reading a waveform'), which tells the agent when this beats a manual waveform workflow. It stops short of naming the sibling alternatives (parse_tbl, maxplus2_run) or stating exclusions, so no explicit when-not.

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