How do I use hwcontract?

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., "@hwcontract Can you check the WS2812 signal against the WS2812B contract?" 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.

hwcontract

by MohibShaikh

Overview Schema Related Servers Score Discussions

Python

Hybrid

hwcontract

Your firmware is correct on paper and wrong on the wire.

Coding agents write WS2812 drivers, ESC bitstreams, and boot logs that pass review and then fail the moment the signal hits a real chip. hwcontract closes that loop. It captures what the hardware actually did and returns a verdict you can act on:

pass: within spec
marginal: in spec but too close to a rail. Works on your bench, dies on a cold board in the field. It fails the verdict: the judge will not ship it.
fail: out of spec, with the measured value and how far off it is

Two things a green verdict gives you beyond the table:

Every pulse is judged, not just the median. Captures carry the full pulse distribution; a glitchy tail that a median hides comes back as marginal or fail, with the violating-pulse count in the hint.
Evidence on every verdict: contract hash, capture hash, capture parameters, tool version, timestamp. A green build in CI traces back to the exact bytes that produced it.

No hardware in your hand? The demo below runs the whole thing on a real recorded signal, so you can see exactly what you get before wiring anything up.

hwcontract judging a real WS2812B capture, a DMA-broken SPI trace, and a serial boot log

See it work in 30 seconds

pip install hwcontract
python3 -m hwcontract.judge --demo

That judges a real 24-LED NeoPixel capture against two contracts. Same signal, two verdicts:

measured on the real WS2812B signal (300000 samples @24MHz):
  T0H 333 ns   T1H 833 ns   T1L 417 ns   T0L 917 ns   RESET 992250 ns

=== generic WS2812 contract -> FAIL ===
  T0H     350   333  PASS
  T0L     800   917  MARGINAL  only 33ns from max; nudge toward typ 800
  T1H     700   833  MARGINAL  only 17ns from max; nudge toward typ 700
  T1L     600   417  FAIL      183ns short (typ 600)
  RESET 50000    -  PASS

=== matching WS2812B contract -> PASS ===
  (all five edges PASS)

Same hardware, two contracts: the generic one fails, the chip-specific one passes. A WS2812B isn't a WS2812. Measure the real signal, hold it to a spec, and match the contract to the actual chip.

Related MCP server: agent-gate

See the temporal engine catch a DMA bug

python3 demo/spi_dma_temporal.py

100 synthesized SPI frames as raw CS/SCK/MOSI waveforms at 100MHz, reduced to pin edges and judged against the bundled spi-frame contract. Frame 77 has the Zephyr LPSPI DMA fault: chip-select asserts after the clock starts. Frame 42 settles MOSI 10ns before the sampling edge. Both come back with exact timestamps, and the same broken edges are re-imported as sigrok-style B/E jsontrace annotations:

cs-precedes-first-clock  800  1  FAIL  trigger at 1540310ns: no gpio.cs.falling
                                          in [1530310ns, 1540310ns] (first of 1)
mosi-setup               800  1  FAIL  forbidden spi.mosi.* at 843300ns is 10ns
                                          before spi.sck.rising at 843310ns

The data is perfect in all 100 frames; a loopback test passes. The ordering is broken in two, and only a cross-signal assertion notices.

What you get

28 bundled contracts for the parts people actually use: WS2812/WS2813/ SK6812 NeoPixels, DShot ESCs (150/300/600/1200), servos, I2C, NEC IR remotes, DS18B20, DHT11/DHT22, HC-SR04, A4988/DRV8825 stepper drivers, PWM fans, plus serial boot logs for ESP32, ESP8266, Zephyr, MicroPython, Raspberry Pi, U-Boot, and STM32 bootloaders. Each one has the datasheet's real min/typ/max numbers.
Temporal assertions between decoded events. SVA-style cross-signal checks (ordering, setup windows, forbidden states) on sigrok jsontrace output, judged for every occurrence with latency percentiles and first-failure timestamps.
Add a protocol by dropping in one YAML file. No code change.
An MCP server your agent can call, or plain CLI commands you can run by hand.
Evidence on every verdict: contract hash, capture hash, capture parameters, tool version, timestamp. A green build traces back to the exact bytes.
Reasonable by default: timing edges are all measured in nanoseconds, serial contracts are Python regex, verdicts come back with the measured value and the delta so an agent knows exactly what to fix.

Install

pip install hwcontract              # judge + logic-analyzer adapter
pip install "hwcontract[serial]"    # + live serial capture (pyserial)
pip install "hwcontract[untrusted]" # + google-re2 (ReDoS-immune, for untrusted contracts)
pip install "hwcontract[all]"       # everything

Live logic-analyzer capture (check_ws2812 / check_dshot) also needs sigrok-cli on PATH. Judge-only tools (judge_contract, judge_serial) need nothing extra.

Wire it into an agent

One stanza per client, add it once. After install, the hwcontract command is on your PATH.

Claude Code

claude mcp add hwcontract -- hwcontract

Codex CLI: ~/.codex/config.toml

[mcp_servers.hwcontract]
command = "hwcontract"

opencode / Cursor / Gemini / any stdio MCP client

{ "mcpServers": { "hwcontract": { "command": "hwcontract" } } }

Transport is stdio by default (local, no auth surface). For remote-only clients (e.g. ChatGPT connectors), run hwcontract --http 8791 and expose it via a tunnel with HWCONTRACT_TOKEN set for bearer auth.
Speaks MCP 2026-07-28, the stateless revision: per-request _meta, server/discover, no handshake. Clients that still open with initialize get the old shape back. Each request picks its own era, so nothing to configure.

If the client can't find `hwcontract` (PATH issues)

GUI apps and some agents don't inherit your shell PATH, so a bare hwcontract can fail with "command not found". Two robust fixes:

Use the absolute path: which hwcontract → put that full path in command.
Or invoke via Python (no PATH lookup for the script): command: "python3", args: ["-m", "hwcontract.server"]. Works from any directory once installed.

Contract paths: pass an absolute contract_path, or set HWCONTRACT_ROOT to your contracts folder. Relative paths resolve against it, defaulting to the process's working directory, which the client controls and may not be your project. Paths outside the root are rejected. Bundled examples install with the package under hwcontract/examples/.

The tools

Tool	Hardware?	What it does
`judge_contract`	no	Judge given observations against a timing contract. Replay / testing.
`judge_serial`	no	Judge a given log string against a serial contract's expect/forbid.
`judge_events`	no	Judge decoded events against temporal assertions (when/require/within, forbid/while/before).
`check_ws2812`	yes	Capture a live WS2812 line and judge it, one call.
`check_dshot`	yes	Same, for a DShot600 ESC signal.
`capture_ws2812`	yes	Just capture → observations (no judging).
`check_serial`	yes	Read a serial port for N seconds and judge the log.

Event contracts are the SVA-style layer: relationships between decoded events, checked for every occurrence, with latency distributions and first-failure timestamps. Feed them sigrok-cli --protocol-decoder-jsontrace output and judge from the CLI:

python3 -m hwcontract.temporal spi-frame.contract.yaml trace.json

The bundled spi-frame.contract.yaml catches the Zephyr LPSPI class of bug (CS asserting after SCK starts, MOSI setup collapse) that loopback tests cannot see.

Prefer plain pytest over MCP? pytest-hwcontract is a plugin that turns verdicts into tests: a FAIL, MARGINAL or MISSING edge fails the test with the verdict table in the message, JUnit included.

Gate CI on it

The repo ships a GitHub Action, so captures checked into the repo get judged on every PR:

- uses: MohibShaikh/hwcontract@action-v0
  with:
    timing: "ws2812b=captures/strip.csv"     # contract=capture-glob, bundled names work
    serial: "boot=logs/boot.log"
    samplerate: 24000000                     # for CSV captures (0/1 per line)
    junit: hwcontract-junit.xml              # shows in the tests tab

A FAIL, MARGINAL or MISSING edge fails the step, annotates the failing line, and writes JUnit. The action self-tests on every push to this repo with one clean and one deliberately broken capture.

How it fits together

  observers (capture)                  judge (this repo)
  ─────────────────────                ─────────────────
  logic analyzer  ─ pulse widths ─┐
  serial port     ─ log text ─────┼─►  contract × observation  ─►  pass/marginal/fail
  sigrok jsontrace ─ events ──────┘         (judge.py / temporal.py)

judge.py. The pure judge for timing and serial, plus contract validation. No hardware, no framework, cached.
temporal.py. Cross-event temporal assertions: selectors, signed windows, latency distributions, first-failure timestamps.
jsontrace.py. Imports sigrok-cli's Google Trace Event JSON into normalized events.
sigrok_adapter.py. Turns a logic-analyzer capture into pulse-width distributions for WS2812 and DShot.
serial_adapter.py. Captures a serial log, or replays a saved one.
server.py. The MCP server, stdio and HTTP JSON-RPC, stdlib only.
*.contract.yaml. What "correct" looks like. Human-editable, and they double as regression tests.

The contract format

Timing (ws2812.contract.yaml, dshot.contract.yaml): pulse widths in ns

contract: ws2812
headroom_pct: 20         # in-spec but within 20% of a rail => "marginal"
edges:
  - {name: T0H, min: 200, typ: 350, max: 500}   # '0' bit high time

Serial (boot.contract.yaml) uses Python regex:

contract: boot
kind: serial
expect: ["IMU init OK", "boot v\\d+"]
forbid: ["panic", "Guru Meditation", "\\bnan\\b"]

Events (spi-frame.contract.yaml) assert relationships between decoded events — SVA-style temporal checks on raw pin edges or sigrok annotations:

contract: spi-frame
kind: events
assertions:
  - {name: cs-precedes-first-clock, when: spi.sck.rising,
     require: gpio.cs.falling, within: [-10us, 0ns]}
  - {name: mosi-setup, when: spi.sck.rising,
     forbid: spi.mosi.*, before: 20ns}

Add a protocol = drop a new YAML. No code change for another timing signal.

Kill switch

Instantly disable every hardware-touching tool (captures) while leaving the pure judge tools working:

export HWCONTRACT_SAFE=1          # env, or:
touch /home/tsd/projects/hardware/KILLSWITCH   # file next to server.py

Security

Every tool argument is treated as hostile, since the caller is an LLM that can be prompt-injected. Contract paths are confined to the server dir, HWCONTRACT_ROOT overrides that. driver/channel/port are charset-validated, samples/seconds/samplerate are clamped, sigrok-cli runs with a timeout, YAML is safe_load. Do not expose this server over the network without adding authentication.

Self-tests: no hardware, run from anywhere

hwcontract --selftest                       # full MCP round-trip
python3 -m hwcontract.judge --demo
python3 -m hwcontract.sigrok_adapter --demo
python3 -m hwcontract.serial_adapter --demo
pytest                                      # the tests/ suite; pip install -e .[dev]

CI runs the suite on every push and PR, and the PyPI publish job waits for it.

Available Tools

6 tools

capture_ws2812A

Capture the WS2812 data line via sigrok and return measured pulse-width observations (T0H/T1H/...).

ParametersJSON Schema

Name	Required	Description	Default
`driver`	No
`channel`	No
`samples`	No
`samplerate`	No

TDQS

A3.5/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 discloses that the tool captures data and returns observations, implying a read-only operation. However, it lacks explicit safety details, prerequisites (e.g., sigrok setup, hardware requirements), and possible side effects, leaving some transparency gaps.

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, well-structured sentence that front-loads the main action and purpose. It avoids redundancy and every part contributes meaning, making it highly concise.

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

Completeness2/5

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

With 4 parameters, no output schema, and no annotations, the description is insufficient for the agent to fully understand how to use the tool. It does not explain parameter semantics, return format details (units, structure), or any prerequisites, leaving significant gaps for a tool of this complexity.

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

Parameters1/5

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

Schema description coverage is 0% and the description does not mention any parameter details. The parameter names (driver, channel, samples, samplerate) are self-explanatory to some extent, but the absence of units, allowed values, or relationships means the agent gains no additional meaning from the description.

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's function: capturing the WS2812 data line via sigrok and returning measured pulse-width observations (T0H/T1H/...). The verb 'Capture' and specific resource (WS2812 data line) distinguish it from sibling tools like check_ws2812 which likely validate rather than capture raw data.

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 gives a clear context: use this when you need to capture WS2812 signals for pulse-width analysis. It does not explicitly exclude alternatives or name sibling tools, but the specific context (capture vs. check/judge) implies a distinct use case, earning a score slightly below 5.

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

check_dshotB

Capture a live DShot600 ESC signal AND judge it against a contract in one call.

ParametersJSON Schema

Name	Required	Description	Default
`driver`	No
`channel`	No
`samples`	No
`samplerate`	No
`contract_path`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose side effects and prerequisites. It reveals the combined capture-and-judge behavior but omits any mention of hardware requirements, permissions, or failure handling, leaving a significant transparency gap for a tool combining two operations.

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 concise sentence that front-loads the key actions and resource, with no filler. Every word contributes to the purpose, making it highly efficient.

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

Completeness2/5

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

Given the complexity of a combined capture-and-judge tool with five parameters and no output schema, the description is insufficient. It does not explain the required contract_path, the role of driver/channel/samples/samplerate, or the format of the judgment result, leaving major operational gaps.

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

Parameters1/5

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

With 0% schema description coverage, the description is fully responsible for explaining the five parameters, but it only mentions DShot600 and contract without detailing driver, channel, samples, samplerate, or contract_path. This leaves all parameters unspecified and does not compensate for the schema's lack of descriptions.

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 captures a live DShot600 ESC signal and judges it against a contract, combining two actions in one call. The specific verb+resource ('capture...AND judge...DShot600 ESC signal') distinguishes it from separate capture-only or judge-only sibling tools.

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 'in one call' phrasing implies it is used when both capture and judgment are needed at once, suggesting an alternative to separate operations. However, it does not explicitly state when not to use it or name alternatives like judge_contract, though the sibling context provides this implication.

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

check_serialB

Read a serial port for N seconds AND judge its log against a contract's expect/forbid patterns.

ParametersJSON Schema

Name	Required	Description	Default
`baud`	No
`port`	Yes
`seconds`	No
`contract_path`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It mentions reading for N seconds and judging, but omits critical details such as blocking behavior, return format, pass/fail semantics, or any side effects. This is a significant transparency gap for a hardware-interfacing tool.

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 concise sentence with no filler. The core action ('Read a serial port') is front-loaded, and the compound purpose is communicated efficiently.

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

Completeness2/5

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

Given the tool has no annotations, no output schema, and 0% parameter documentation, the description is too sparse. It fails to specify return values, error behavior, or how the contract 'judgment' is reported, leaving the agent without enough context for reliable invocation.

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

Parameters2/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 compensate. It indirectly clarifies 'port', 'seconds', and 'contract_path' but completely ignores 'baud', which is a necessary serial configuration parameter. The partial coverage leaves the meaning of 'baud' ambiguous and the overall parameter semantics incomplete.

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's verb and resource: it 'Read[s] a serial port for N seconds' and 'judge[s] its log against a contract's expect/forbid patterns.' This distinguishes it from siblings like judge_serial (which likely only judges) by explicitly combining capture and judgment.

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

Usage Guidelines2/5

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

The description provides no explicit guidance on when to use this tool versus alternatives like judge_serial or capture_ws2812. 'Read AND judge' implies a combined use case, but no clear prerequisites, exclusions, or alternative references are given.

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

check_ws2812A

Capture a live WS2812 signal AND judge it against a contract in one call. The one-shot an agent reaches for.

ParametersJSON Schema

Name	Required	Description	Default
`driver`	No
`channel`	No
`samples`	No
`samplerate`	No
`contract_path`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries full burden for behavioral disclosure. It indicates the combined operation (capture+judge) but does not disclose potential side effects, whether it blocks, or return format. Some transparency is present, but depth is lacking.

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 short sentences, immediately front-loaded with the core action. Every word earns its place, conveying purpose and usage without fluff.

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

Completeness2/5

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

The tool has 5 parameters, no annotations, and no output schema, yet the description only covers its overall purpose. Missing are parameter prerequisites, contract format, return values, and any setup requirements, making it incomplete for confident invocation.

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

Parameters1/5

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

Schema description coverage is 0% and the description mentions no parameter names or meanings. Parameters like 'samples' and 'samplerate' lack units or context, and 'contract_path' is not explicitly connected to the contract mentioned in the description.

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 captures a live WS2812 signal and judges it against a contract in one call. This combines the functionality of sibling tools capture_ws2812 and judge_contract, making its purpose distinct and specific.

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 'The one-shot an agent reaches for' implies this is the preferred combined tool, suggesting it should be used when both capture and judgment are needed. However, it does not explicitly name alternatives or state when to use separate tools.

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

judge_contractA

Judge observations against a contract -> pass/marginal/fail. No hardware; use for replay or when an adapter already captured.

ParametersJSON Schema

Name	Required	Description	Default
`observations`	Yes
`contract_path`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description must carry transparency. It discloses non-hardware nature and replay use case, but omits side effects, permissions, or error behavior. As a judging tool, it implies non-destructive but is not explicit.

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 concise sentences, front-loaded with the core verb and outcome. The arrow notation efficiently communicates the result, and every word contributes.

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 tool with two parameters and no output schema, the description conveys purpose, usage context, and output categories. It lacks parameter detail but the names are self-explanatory, making it largely complete.

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

Parameters2/5

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

Schema coverage is 0% and the description adds no parameter-level detail. The names 'contract_path' and 'observations' are somewhat intuitive but no format or type information is provided beyond 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?

Description clearly states the tool judges observations against a contract and outputs pass/marginal/fail. It distinguishes from hardware-capture siblings by noting 'No hardware', but does not explicitly name judge_serial as an alternative.

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?

Provides clear context: use for replay or when an adapter already captured, and excludes hardware usage. Does not name alternative tools explicitly but gives strong situational guidance.

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

judge_serialA

Judge a captured serial log against expect/forbid patterns. No hardware; use for replay or logs another tool already captured.

ParametersJSON Schema

Name	Required	Description	Default
`log`	Yes
`contract_path`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description discloses that the tool does not require hardware, which is a key behavioral trait. However, it does not explicitly state read-only behavior or side effects, leaving some ambiguity for the agent.

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 two sentences, front-loaded with the core action, and contains no unnecessary information.

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?

The tool is simple with two string parameters and no output schema. The description conveys the purpose and usage context but does not specify the return value or output format, which could leave an agent uncertain about how to interpret the results.

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?

The schema has no descriptions (0% coverage). The description mentions 'serial log' and 'expect/forbid patterns', which gives partial meaning to the `log` and `contract_path` parameters, but it doesn't explain their format or relationship clearly.

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's function: judging a captured serial log against expect/forbid patterns. It also distinguishes itself from hardware-related tools by noting 'No hardware', making it stand out among siblings like capture_ws2812 and check_serial.

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 explicitly specifies when to use this tool: for replay or logs already captured, and states it is not for hardware. This gives clear guidance on when to invoke it, though it doesn't explicitly name alternative tools like check_serial for live use.

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.2Jul 31, 2026
- First observedcapture_ws2812
- First observedcheck_dshot
- First observedcheck_serial
- First observedcheck_ws2812
- First observedjudge_contract
- First observedjudge_serial

Install Server

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

TDQS

A3.5/5.0

Disambiguation4/5

Tools are mostly distinct: check_* does live capture+judge, judge_* does offline judging, and capture_ws2812 is capture-only. However, judge_contract and judge_serial could be confused for serial logs, and capture_ws2812 vs check_ws2812 requires careful reading.

Naming Consistency3/5

Naming mixes three verb prefixes (judge_, check_, capture_) and inconsistently references protocols (ws2812, dshot, serial) vs the generic 'contract'. The pattern is readable but not fully consistent.

Tool Count5/5

Six tools are well-scoped for hardware contract testing: one generic judge, one capture, and four protocol-specific live/offline checks. This is within the ideal 3-15 range and each tool serves a distinct purpose.

Completeness4/5

The core workflow of capture and judge is covered for WS2812, serial, and DShot (via live check). Missing a DShot capture-only tool and a dedicated judge_dshot, but judge_contract fills the gap, so only minor dead ends exist.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

anotherai
dev.anotherai
MCP server for building and testing AI agents with multi-model experimentation and insights.
Agent Orchestration Autonomous Agents Testing & QA Tools
2
mcp AOAuth
io.scorecard
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
RAG Systems Monitoring Testing & QA Tools
3
MCP Verification Gate: conformance and disclosure checker for MCP servers A
io.github.ogasurfproject-jpg
Conformance checker for MCP servers. Free, no key, verdicts recomputable and re-measured daily.
Developer Tools Testing & QA Tools API Testing
511
Agenda Intelligence MD A
io.github.vassiliylakhonin
Evidence-readiness MCP server: validate, audit, and score briefs, memos, and evidence packs.
Legal & Compliance Research & Data
116

Related MCP Servers

multivon-mcpofficial
AI & Machine Learning Testing & QA Tools
multivon-ai
A
license
A
quality
B
maintenance
MCP server that gives AI coding agents direct access to evaluation tools.
Updated 17 days ago (2026-08-19 19:01 UTC)
22
Apache 2.0
agent-gate
Autonomous Agents Agent Orchestration
Jott2121
A
license
B
quality
B
maintenance
An MCP server that enforces fail-closed deterministic checks, independent refute-first review, and tamper-evident hash-chained receipts for AI agent outputs before claiming completion.
Updated 18 days ago (2026-08-19 12:07 UTC)
4
3
MIT
mcp-gauge
Testing & QA Tools Developer Tools Code Analysis
sogawa-yk
A
license
A
quality
D
maintenance
An MCP server that enables coding agents to autonomously test, evaluate, and tune other MCP servers by acting as a proxy and providing linting, trace recording, evaluation, comparison, and reporting tools.
Updated 6 months ago (2026-02-26 05:08 UTC)
7
MIT
oscilloscope-mcp
Testing & QA Tools Embedded system
masahiro-999
A
license
Not graded
quality
C
maintenance
MCP server that lets an AI agent operate a bench oscilloscope over LAN/SCPI to observe physical pin behavior, bridging RTL simulation and hardware testing.
Updated 2 months ago (2026-06-28 13:28 UTC)
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/MohibShaikh/hwcontract'

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

hwcontract

See it work in 30 seconds

See the temporal engine catch a DMA bug

What you get

Install

Wire it into an agent

If the client can't find hwcontract (PATH issues)

The tools

Gate CI on it

How it fits together

The contract format

Kill switch

Security

Self-tests: no hardware, run from anywhere

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

multivon-mcpofficial

Latest Blog Posts

MCP directory API

If the client can't find `hwcontract` (PATH issues)