# BlockWerk (remote · blockwerk-mcp-worker.blockwerk.workers.dev)

Build, run and analyse block-diagram simulations: PID, Bode, FFT, optimisation and code export.

- Trust score: 75/100 (medium)
- Change this week: +3
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- remote · `blockwerk-mcp-worker.blockwerk.workers.dev`: 75/100 (this document), [markdown](https://verifymcp.io/servers/tech-blockwerk-mcp/blockwerk-mcp-worker.md), [page](https://verifymcp.io/servers/tech-blockwerk-mcp/blockwerk-mcp-worker)

## Channel facts

- Endpoint: `https://blockwerk-mcp-worker.blockwerk.workers.dev/`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.1.2`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Endpoint Security**: 46/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (delete_block).
  - HTTPS check failed: the endpoint is reachable over plaintext HTTP.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 85/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (good).
  - Tool/resource definitions use about 3765 tokens (~87/item across 43 items; 42 tools + 1 resources), lean.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 100/100
  - No destabilizing schema changes in the last 30 days.
- **Tool Coverage**: 96/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 87% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 3 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 44 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.
  - Supports UI / widget rendering.

## Install

### How do I install the BlockWerk MCP server?

BlockWerk is a hosted endpoint at https://blockwerk-mcp-worker.blockwerk.workers.dev/, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http tech-blockwerk-mcp 'https://blockwerk-mcp-worker.blockwerk.workers.dev/'
```

### Cursor

```json
{
  "mcpServers": {
    "tech-blockwerk-mcp": {
      "url": "https://blockwerk-mcp-worker.blockwerk.workers.dev/"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "tech-blockwerk-mcp": {
      "type": "http",
      "url": "https://blockwerk-mcp-worker.blockwerk.workers.dev/"
    }
  }
}
```

### Codex

```toml
[mcp_servers.tech-blockwerk-mcp]
url = "https://blockwerk-mcp-worker.blockwerk.workers.dev/"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "tech-blockwerk-mcp": {
      "type": "remote",
      "url": "https://blockwerk-mcp-worker.blockwerk.workers.dev/",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add tech-blockwerk-mcp --url 'https://blockwerk-mcp-worker.blockwerk.workers.dev/' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  tech-blockwerk-mcp:
    url: "https://blockwerk-mcp-worker.blockwerk.workers.dev/"
```

### Netclaw

```json
{
  "McpServers": {
    "tech-blockwerk-mcp": {
      "Transport": "http",
      "Url": "https://blockwerk-mcp-worker.blockwerk.workers.dev/"
    }
  }
}
```

### Vellum

```bash
assistant mcp add tech-blockwerk-mcp -t streamable-http -u 'https://blockwerk-mcp-worker.blockwerk.workers.dev/'
```

### Other

```json
{
  "mcpServers": {
    "tech-blockwerk-mcp": {
      "type": "http",
      "url": "https://blockwerk-mcp-worker.blockwerk.workers.dev/"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-05 (score 75, 0)

- [security] Stability: 0.97 → pass

### 2026-11-04 (score 75, +1)

No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-01 (score 74, +1)

No change was recorded against any check on this day. Stability & Change Management went from 83 to 87. That category is still filling its 30-day observation window: 25 days of observed history at the previous scan, 26 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-30 (score 73, +1)

No change was recorded against any check on this day. Stability & Change Management went from 77 to 80. That category is still filling its 30-day observation window: 23 days of observed history at the previous scan, 24 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-28 (score 72, +1)

No change was recorded against any check on this day. Stability & Change Management went from 70 to 73. That category is still filling its 30-day observation window: 21 days of observed history at the previous scan, 22 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-26 (score 71, +1)

No change was recorded against any check on this day. Stability & Change Management went from 63 to 67. That category is still filling its 30-day observation window: 19 days of observed history at the previous scan, 20 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-24 (score 70, +1)

No change was recorded against any check on this day. Stability & Change Management went from 57 to 60. That category is still filling its 30-day observation window: 17 days of observed history at the previous scan, 18 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-23 (score 69, +2)

- [functional] The server now declares the “resources” capability
- [functional] First check of Capabilities: pass
- [functional] First check of Schema quality: 100
- [functional] New resource “blockwerk-canvas-viewer”

## MCP tools (42)

### `describe_canvas` (~52 tokens)

Describe canvas

Returns a structured description of all blocks and connections currently on the canvas. Set "compact" to true for a token-efficient summary.

Input parameters:

- `compact` (boolean): If true, returns a minimal description without full parameter details.

### `get_available_blocks` (~165 tokens)

List available blocks

Returns the block types in the library with their descriptions, configurable parameters, and exact input/output port IDs. Without a filter it returns a compact list of all types; with a list of type IDs it returns full details for those types. Example port IDs: Step out "out"; Sum in "in", out "out"; Gain in "in", out "out"; PIDController in "error","reset", out "out"; uPlotDisplay in "signal". Common aliases (e.g. "in" for PID error, "in" for uPlotDisplay signal, "+" / "-" for Subtraction) are resolved automatically.

Input parameters:

- `filter` (array): Optional: List of block type IDs to get full details for. If omitted, returns a compact list of all blocks.

### `add_block` (~71 tokens)

Add block

Add a new block to the canvas. Returns the new block ID.

Input parameters:

- `type` (string, required): Block type from the library, e.g. "PIDController", "Gain", "Integrator"
- `x` (number, required): Horizontal position in canvas pixels
- `y` (number, required): Vertical position in canvas pixels

### `connect_blocks` (~159 tokens)

Connect blocks

Connect an output port of one block to an input port of another. Automatically resolves common port aliases (e.g., "in" -> "signal" for uPlotDisplay, "in" -> "error" for PIDController, "+" / "-" for Subtraction).

Input parameters:

- `fromBlockId` (string, required): ID of the source block
- `fromPortId` (string, required): Output port ID of the source block, e.g. "out" (aliases like "signal", "y" are supported)
- `toBlockId` (string, required): ID of the destination block
- `toPortId` (string, required): Input port ID of the destination block, e.g. "in" (aliases like "signal" or PID "error" are supported)

### `update_params` (~49 tokens)

Update block parameters

Update one or more parameters of an existing block.

Input parameters:

- `blockId` (string, required): ID of the block to update
- `params` (object, required): Key-value pairs of parameter names and their new values

### `delete_block` (~50 tokens)

Delete block

Delete a block and all its connections from the canvas. This is a destructive action that asks the user for approval in the BlockWerk tab.

Input parameters:

- `blockId` (string, required): ID of the block to delete

### `load_diagram` (~233 tokens)

Load diagram

Atomically replaces the entire canvas with a complete diagram defined as a BlockWerk project JSON string. The JSON has a "blocks" array (each block needs a unique "id" and "type"; "x"/"y"/"params" are optional) and a "connections" array (each connection needs a unique "id" plus "fromBlockId", "fromPortId", "toBlockId", "toPortId"; a missing id fails validation of the whole load). Block types and port ids are listed by get_available_blocks. This is a destructive action that asks the user for approval in the BlockWerk tab.

Input parameters:

- `json` (string, required): Full BlockWerk project JSON, e.g. {"blocks":[{"id":"b1","type":"Step","x":100,"y":100,"params":{}},{"id":"b2","type":"Integrator","x":300,"y":100,"params":{}}],"connections":[{"id":"c1","fromBlockId"…

### `export_diagram` (~23 tokens)

Export diagram

Exports the current canvas project as a complete BlockWerk JSON string.

### `get_share_link` (~59 tokens)

Get share link

Returns a link that opens the current diagram on the BlockWerk canvas. The whole project travels compressed inside the URL, so it needs no account and nothing is uploaded. Opening the link in a browser shows the diagram, where the simulation can be run.

### `clear_canvas` (~34 tokens)

Clear canvas

Remove all blocks and connections from the canvas. This is a destructive action that asks the user for approval in the BlockWerk tab.

### `tidy_layout` (~25 tokens)

Tidy layout

Automatically rearrange all blocks on the canvas into a clean, left-to-right flow.

### `batch_commands` (~74 tokens)

Run command batch

Executes multiple canvas manipulation and background job commands in a single round-trip. Use "handle" strings to refer to blocks added earlier in the same batch. When adding TextNote annotations, set "anchors" to the handles/IDs of the described blocks so auto-layout keeps each note next to them.

Input parameters:

- `commands` (array, required)

### `analyze_topology` (~28 tokens)

Analyze topology

Analyzes the block diagram structure: detects feedback loops, signal paths, and system order.

### `get_signal_data` (~48 tokens)

Get signal data

Returns time series data from a Scope block output for analysis.

Input parameters:

- `blockId` (string, required): ID of the Scope block
- `channel` (number): Channel index (default: 0)

### `calculate_metrics` (~61 tokens)

Calculate signal metrics

Calculates step response metrics from signal data: rise time, settling time, overshoot percentage, and steady-state error.

Input parameters:

- `blockId` (string, required): ID of the Scope block
- `setpoint` (number): Target setpoint value (default: 1)

### `get_analysis_measurements` (~43 tokens)

Get analysis measurements

Retrieves the currently active pinned measurements and their computed values across plotted signals in the Analysis panel.

Input parameters:

- `blockId` (string): Optional blockId or signalId filter

### `evaluate_spec_mask` (~156 tokens)

Evaluate spec mask

Evaluates signal data against automated design specifications and tolerance corridors (rise time, settling time, overshoot %, steady-state error, min/max limits).

Input parameters:

- `blockId` (string, required): ID of the Scope or signal source block
- `lowerLimit` (number): Absolute lower bound corridor
- `maxOvershootPercent` (number): Maximum allowable overshoot %
- `maxRiseTime` (number): Maximum allowable rise time (seconds)
- `maxSettlingTime` (number): Maximum allowable settling time (seconds)
- `maxSteadyStateError` (number): Maximum allowable steady-state error
- `setpoint` (number): Target setpoint value (default: 1)
- `upperLimit` (number): Absolute upper bound corridor

### `get_architect_memory` (~19 tokens)

Get architect memory

Returns the persistent memory object of the Architect.

### `update_architect_memory` (~41 tokens)

Update architect memory

Updates the persistent memory of the Architect. Provide a JSON object with keys to update/merge.

Input parameters:

- `updates` (object, required): Keys and values to store

### `validate_engineering_units` (~28 tokens)

Validate engineering units

Checks the consistency of engineering units across the diagram. Detects incompatible connections and missing units.

### `validate_canvas` (~44 tokens)

Validate canvas

Performs pre-flight topological and numerical integrity checks on the canvas. Detects unconnected required input ports, isolated blocks, parameter domain anomalies, and direct algebraic feedthrough loops.

### `get_canvas_preview` (~68 tokens)

Get canvas preview

Captures a visual screenshot preview of the canvas branded with the official BlockWerk watermark badge and returns the live interactive URL to view and edit the diagram online.

Input parameters:

- `type` (string): Which visual region to capture: "canvas", "scope", or "combined" (default: "combined").

### `get_templates` (~119 tokens)

List diagram templates

Lists the built-in, verified BlockWerk diagrams: classic control systems (PID loop, cruise control, inverted pendulum), signal processing, electrical and physics models. Each entry gives an id, what the diagram does, its difficulty and the blocks it uses. Returns metadata only; load_template puts a diagram on the canvas by id.

Input parameters:

- `category` (string): Optional filter by category.
- `interactive` (boolean): If true, only diagrams with live on-canvas controls (sliders, joystick, keyboard) meant to be driven while the simulation runs.

### `load_template` (~109 tokens)

Load diagram template

Replaces the entire canvas with one of the built-in verified diagrams, by id from get_templates. The template carries its topology, parameters and simulation settings. Returns the block and connection counts, the verified simulation settings, and the attribution when the model is based on third-party material. This is a destructive action that asks the user for approval in the BlockWerk tab.

Input parameters:

- `templateId` (string, required): Template id from get_templates, e.g. "inverted_pendulum" or "pid_loop".

### `run_simulation` (~89 tokens)

Run simulation

Triggers a new simulation run with the current canvas state and settings, refreshing the signal data.

Input parameters:

- `duration` (number): Duration in seconds
- `reason` (string): User-facing explanation of why settings were changed (e.g., Nyquist constraint)
- `sampleTime` (number): Optional custom step size (dt) for high frequency or stiff systems (e.g., 0.001)

### `sweep_parameter` (~135 tokens)

Sweep parameter

Runs simulations across a list of values for one parameter, returning control quality metrics (IAE, overshoot, settling_time, steady_state_error) per value. Requires measureBlockId and setpoint.

Input parameters:

- `blockId` (string, required): ID of the block to tune
- `measureBlockId` (string): Scope or Display block ID to read the controlled signal from
- `paramName` (string, required): Parameter key to vary (e.g., "gain", "Kp")
- `setpoint` (number): Expected final value for error calculation (default: 1)
- `values` (array, required): List of values to test

### `optimize_parameters` (~194 tokens)

Optimize parameter

Finds the optimal value for a single parameter using golden-section search. Minimizes IAE (integral absolute error), overshoot, or settling_time within a [min, max] range. Converges in about 10 simulations.

Input parameters:

- `blockId` (string, required): ID of the block containing the parameter to tune
- `max` (number, required): Upper bound of the search range
- `maxIterations` (number): Maximum simulations to run, 3–20 (default: 10)
- `measureBlockId` (string, required): Scope or Display block ID to read the controlled signal from
- `min` (number, required): Lower bound of the search range
- `objective` (string): Metric to minimize (default: iae)
- `paramName` (string, required): Parameter key to optimize (e.g., "Kp", "gain")
- `setpoint` (number): Target steady-state value (default: 1)

### `optimize_multi_parameter` (~125 tokens)

Optimize multiple parameters

Optimizes 2–6 parameters simultaneously using Nelder-Mead simplex search, for example Kp, Ki and Kd of a PID controller at once.

Input parameters:

- `maxIterations` (number): Max simulations to run, 5–60 (default: 30)
- `measureBlockId` (string, required): Scope or Display block to read the controlled signal from
- `objective` (string): Metric to minimize (default: iae)
- `setpoint` (number): Target steady-state value (default: 1)
- `targets` (array, required): Parameters to optimize simultaneously

### `auto_tune_pid` (~165 tokens)

Auto-tune PID

Automatically tunes a PID controller using the Ziegler-Nichols ultimate cycle method. Finds the ultimate gain (Ku) and oscillation period (Tu) via binary search, then applies ZN formulas. No prior knowledge of the plant required.

Input parameters:

- `controlType` (string): Controller type to tune for (default: PID)
- `maxGain` (number): Upper bound for Ku search (default: 200)
- `measureBlockId` (string, required): Scope or Display block showing the controlled variable
- `minGain` (number): Lower bound for Ku search (default: 0.1)
- `pidBlockId` (string, required): ID of the PIDController block to tune
- `setpoint` (number): Desired setpoint value (default: 1)

### `identify_fopdt` (~123 tokens)

Identify FOPDT model

Analyzes a step response from a plant to identify its First-Order Plus Dead Time (FOPDT) parameters: Gain (K), Time Constant (tau), and Dead Time (theta). Requires a completed simulation with a step input connected to the plant. Returns the calculated parameters.

Input parameters:

- `blockId` (string, required): Scope or Display block ID showing the plant output
- `stepAmplitude` (number): Amplitude of the step input (default: 1)
- `stepTime` (number): Time when the step input occurred (default: 0)

### `start_optimization` (~80 tokens)

Start background optimization

Start a parameter optimization job in the background.

Input parameters:

- `blockId` (string, required)
- `max` (number, required)
- `maxIterations` (number)
- `measureBlockId` (string, required)
- `min` (number, required)
- `objective` (string)
- `paramName` (string, required)
- `setpoint` (number)

### `get_job_status` (~27 tokens)

Get job status

Check the status and progress of a background job.

Input parameters:

- `jobId` (string, required)

### `cancel_job` (~22 tokens)

Cancel job

Cancel a running background job.

Input parameters:

- `jobId` (string, required)

### `list_jobs` (~17 tokens)

List jobs

List all recent background jobs and their status.

### `explain_simulation` (~87 tokens)

Explain simulation

Analyze the last completed simulation and return a structured diagnosis: signal anomalies (NaN, divergence, oscillation), solver health (rejection rate, efficiency), algebraic loops, and optional stability margins. Returns JSON with severity-tagged findings and actionable suggestions.

Input parameters:

- `stabilityMargins` (object): Optional pre-computed stability margins from a Bode sweep. If omitted, stability analysis is skipped.

### `get_bode_data` (~138 tokens)

Get Bode data

Computes magnitude and phase frequency response (Bode data) between two blocks. Traces path backwards from outputBlockId. Returns analytic response if the path contains only linear blocks, otherwise runs numerical sweep.

Input parameters:

- `endFreq` (number): End frequency in rad/s (default: 100)
- `inputBlockId` (string, required): ID of the input source block
- `outputBlockId` (string, required): ID of the output measurement block
- `pointsPerDecade` (number): Number of points per decade (default: 10)
- `startFreq` (number): Start frequency in rad/s (default: 0.1)

### `get_fft_data` (~53 tokens)

Get FFT data

Computes FFT (frequency spectrum) of a Scope signal. Returns frequencies and magnitudes.

Input parameters:

- `blockId` (string, required): ID of the Scope block
- `channel` (number): Channel index (default: 0)

### `get_engine_status` (~30 tokens)

Get engine status

Returns the simulation engine status, including supported solvers, active background jobs, and compilation/WASM capabilities.

### `generate_code` (~133 tokens)

Generate code

Generates standalone production code (C++, Python, Rust) from the current canvas diagram. Returns structured code files, interfaces (inputs/outputs), execution order, and diagnostics.

Input parameters:

- `encapsulateSubsystems` (boolean): Whether to generate encapsulated subsystem classes (default: false)
- `modelName` (string): Name of the generated model class/module (e.g., "MotorController", default: "BlockWerkModel")
- `sampleTime` (number): Optional custom step size in seconds (default: current canvas sampleTime)
- `target` (string): Filter code generation to a specific target language (default: "all")

### `undo_last_ai_action` (~31 tokens)

Undo last AI action

Undoes the last canvas modification made by the AI (add block, connect, delete, update parameter).

### `redo_last_ai_action` (~18 tokens)

Redo last AI action

Redoes the last undone canvas modification.

### `get_ai_history` (~27 tokens)

Get AI action history

Returns the list of recent canvas operations performed by the AI, showing what can be undone.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/tech-blockwerk-mcp/blockwerk-mcp-worker#diagnostics

## Score history

- 2026-11-05: 75
- 2026-11-04: 75
- 2026-11-03: 74
- 2026-11-02: 74
- 2026-11-01: 74
- 2026-10-31: 73
- 2026-10-30: 73
- 2026-10-29: 72
- 2026-10-28: 72
- 2026-10-27: 71
- 2026-10-26: 71
- 2026-10-25: 70
- 2026-10-24: 70
- 2026-10-23: 69
- 2026-10-22: 67
- 2026-10-21: 67
- 2026-10-20: 67
- 2026-10-19: 66
- 2026-10-18: 66
- 2026-10-17: 65
- 2026-10-16: 65
- 2026-10-15: 64
- 2026-10-14: 64
- 2026-10-13: 63
- 2026-10-12: 63
- 2026-10-10: 62
- 2026-10-09: 61

## Common questions

### What is the BlockWerk MCP server?

BlockWerk is an MCP server listed in the public MCP registry as tech.blockwerk/mcp. Build, run and analyse block-diagram simulations: PID, Bode, FFT, optimisation and code export. This page covers its hosted endpoint (https://blockwerk-mcp-worker.blockwerk.workers.dev/).

### Is the BlockWerk MCP server safe to use?

BlockWerk scores 75 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the BlockWerk MCP server expose?

BlockWerk exposes 42 tools: describe_canvas, get_available_blocks, add_block, connect_blocks, update_params, and 37 more. Their descriptions and schemas cost roughly 3,252 tokens of context every time the server is loaded.

### Does the BlockWerk MCP server require authentication?

No. We connected to BlockWerk without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the BlockWerk MCP server still maintained?

BlockWerk is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What did VerifyMCP test on the BlockWerk MCP server?

VerifyMCP ran 14 checks on BlockWerk, covering TLS certificate, Authorization, HTTPS, HSTS header and 10 more. Supply Chain Security and Provenance & Transparency do not apply to a hosted endpoint, so they were not tested. The score does not measure everything, and the scoring documentation lists what it leaves out.

## Links

- Remote endpoint: https://blockwerk-mcp-worker.blockwerk.workers.dev/
- Website: https://blockwerk.tech/connect-ai
- Changelog RSS feed: https://verifymcp.io/servers/tech-blockwerk-mcp/blockwerk-mcp-worker.xml
- Changelog JSON feed: https://verifymcp.io/servers/tech-blockwerk-mcp/blockwerk-mcp-worker/changelog.json
- Trust report (JSON): https://verifymcp.io/servers/tech-blockwerk-mcp/blockwerk-mcp-worker.json
- HTML version of this page: https://verifymcp.io/servers/tech-blockwerk-mcp/blockwerk-mcp-worker