Skip to main content
Glama
dpdanpittman

mcp-server-quint

by dpdanpittman
README.md
# mcp-server-quint

MCP server for the [Quint](https://github.com/informalsystems/quint) formal specification language. Wraps the Quint CLI to make formal verification accessible to any LLM-powered workflow.

## Quick Start

### 1. Install Quint CLI

```bash
npm i -g @informalsystems/quint
```

### 2. Add to Claude Code

```bash
claude mcp add quint -- npx @dpdanpittman/mcp-server-quint
```

That's it. You now have 6 formal verification tools available in Claude Code.

### Other MCP Clients

Any MCP-compatible client can use this server over stdio:

```bash
npx @dpdanpittman/mcp-server-quint
```

### With Supergateway (HTTP transport)

```javascript
{ name: 'quint', command: 'node', args: ['/path/to/mcp-server-quint/index.js'] }
```

## Tools

### `quint_typecheck`

Type-check a Quint specification. Provide either `source` (inline .qnt code) or `file_path`.

### `quint_run`

Simulate a Quint spec with random execution. Optionally check an invariant. Returns a counterexample trace if violated.

| Parameter              | Description                        |
| ---------------------- | ---------------------------------- |
| `source` / `file_path` | Spec to simulate                   |
| `init`                 | Init action name (default: "init") |
| `step`                 | Step action name (default: "step") |
| `invariant`            | Invariant to check                 |
| `max_samples`          | Number of runs (default: 10000)    |
| `max_steps`            | Steps per run (default: 20)        |
| `seed`                 | Random seed for reproducibility    |

### `quint_test`

Run named test definitions (`run` statements). Optionally filter by `match` regex.

### `quint_verify`

Exhaustive model checking via Apalache. Checks ALL reachable states, not just random samples. Requires Java 17+ and [Apalache](https://apalache-mc.org/).

### `quint_parse`

Parse a spec and return the intermediate representation (IR) as JSON.

### `quint_docs`

Quick reference for Quint syntax. Topics: `sets`, `maps`, `lists`, `actions`, `temporal`, `types`, `modules`, `testing`, or `all`.

## Example

```quint
module bank {
  var balances: str -> int
  val ADDRS = Set("alice", "bob")
  action init = balances' = ADDRS.mapBy(_ => 100)
  action transfer(sender: str, receiver: str, amt: int): bool = all {
    balances.get(sender) >= amt,
    balances' = balances.set(sender, balances.get(sender) - amt)
                        .set(receiver, balances.get(receiver) + amt)
  }
  action step = {
    nondet sender = ADDRS.oneOf()
    nondet receiver = ADDRS.oneOf()
    nondet amt = 1.to(balances.get(sender)).oneOf()
    transfer(sender, receiver, amt)
  }
  val no_negatives = ADDRS.forall(a => balances.get(a) >= 0)
}
```

## Environment Variables

| Variable        | Default  | Description              |
| --------------- | -------- | ------------------------ |
| `QUINT_CMD`     | `quint`  | Path to Quint CLI binary |
| `QUINT_TIMEOUT` | `120000` | CLI timeout in ms        |

## License

[PolyForm Noncommercial 1.0.0](LICENSE)

TDQS

A4.1/5.0

Scored across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: quint_docs provides syntax reference, quint_parse handles AST inspection, quint_run performs random simulation, quint_test executes named tests, quint_typecheck validates types, and quint_verify does exhaustive model checking. The descriptions clearly differentiate their specific functions within the Quint specification workflow.

Naming Consistency5/5

All tools follow a perfect 'quint_verb' pattern consistently throughout, using lowercase with underscores. The verbs (docs, parse, run, test, typecheck, verify) are all action-oriented and descriptive, creating a highly predictable and readable naming convention.

Tool Count5/5

Six tools is ideal for a Quint specification server, covering the complete lifecycle from documentation reference to parsing, testing, simulation, type checking, and verification. Each tool earns its place without redundancy, providing a well-scoped surface for working with Quint specifications.

Completeness5/5

The toolset provides comprehensive coverage for Quint specification workflows: documentation lookup, parsing, simulation, testing, type checking, and exhaustive verification. There are no obvious gaps—agents can perform the full CRUD-like lifecycle from inspection to validation and verification, with clear fallback behavior where appropriate.

Maintenance

ActivityInactive
ResponsivenessNo issues