# Zektor (npm · zektor)

Managed Postgres and Valkey hosted in Germany. Agents can create a trial database with no signup.

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

## Components

- npm · `zektor`: 79/100 (this document), [markdown](https://verifymcp.io/servers/m-akcan-zektor/zektor.md), [page](https://verifymcp.io/servers/m-akcan-zektor/zektor)

## Channel facts

- Registry: `npm`
- Package: `zektor`
- Version: `1.7.1`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, 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-04.

- **Supply Chain Security**: 98/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - No install/post-install scripts declared.
  - 30 of 93 dependencies flagged as unhealthy.
- **Provenance & Transparency**: 45/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 26 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 75/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2261 tokens (~119/item across 19 items; 19 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 67/100
  - Stability observed for 20 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% 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 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 20 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.

## Install

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

Zektor runs locally as an npm package, launched with npx -y zektor. 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 m-akcan-zektor -- npx -y zektor
```

### Cursor

```json
{
  "mcpServers": {
    "m-akcan-zektor": {
      "command": "npx",
      "args": [
        "-y",
        "zektor"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "m-akcan-zektor": {
      "command": "npx",
      "args": [
        "-y",
        "zektor"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add m-akcan-zektor -- npx -y zektor
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "m-akcan-zektor": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "zektor"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add m-akcan-zektor --command npx --arg -y --arg zektor
```

### Hermes

```yaml
mcp_servers:
  m-akcan-zektor:
    command: "npx"
    args: ["-y", "zektor"]
```

### Netclaw

```json
{
  "McpServers": {
    "m-akcan-zektor": {
      "Transport": "stdio",
      "Command": "npx",
      "Arguments": [
        "-y",
        "zektor"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add m-akcan-zektor -t stdio -c npx -a -y zektor
```

### Other

```json
{
  "mcpServers": {
    "m-akcan-zektor": {
      "command": "npx",
      "args": [
        "-y",
        "zektor"
      ]
    }
  }
}
```

## 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-03 (score 79, +1)

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

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

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

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

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

### 2026-10-27 (score 76, +1)

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

### 2026-10-25 (score 75, +1)

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

### 2026-10-23 (score 74, +1)

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

### 2026-10-22 (score 73, +3)

- [functional improvement] Stability: unverified → 0.23

### 2026-10-15 (score 70, +32)

- [security improvement] Injection markers: unverified → pass
- [security] First check of Judged manipulation: pass
- [security] Stability: Stability not yet verified: not enough scan history yet (needs a 30-day window).
- [functional improvement] Tool coverage: unverified → 100
- [functional improvement] MCP protocol: unverified → pass
- [functional] First check of Schema quality: fail
- [functional] First check of Schema quality: excellent
- [functional] First check of Schema quality: fail
- [functional] First check of Destructive annotations: 100
- [functional] First check of Tool coverage: 100

## MCP tools (19)

### `whoami` (~39 tokens)

Show the authenticated account

Reports which Zektor account the current token belongs to, the API it is talking to, and whether the token came from the environment or the config file.

### `list_instances` (~27 tokens)

List instances

Every database and cache on the account, with id, name, status, engine and plan.

### `get_instance` (~50 tokens)

Get one instance

Full detail for a single instance, including storage and autoscaling where it applies. Does not include credentials — use get_connection for those.

Input parameters:

- `id` (integer, required): Instance id, as returned by list_instances

### `get_action` (~83 tokens)

Check background work

How the background work started by create_instance, scale_instance or resize_storage is going, by the actionId they return. status is "Running", "Success" or "Failure"; on Failure, errorMessage says why. While it is Running, call this again every few seconds.

Input parameters:

- `action_id` (integer, required): actionId from create_instance, scale_instance or resize_storage

### `list_plans` (~71 tokens)

List available plans

The plans an instance can be created on or scaled to, with price, engine, memory, storage and the engine versions each one can run. Call this before create_instance or scale_instance rather than guessing a plan name.

Input parameters:

- `group` (string): Restrict to databases or caches. Omit for both.

### `list_regions` (~35 tokens)

List regions

Regions an instance can be created in. `available` is false where there is no capacity right now; creating there will be refused.

### `get_connection` (~106 tokens)

Get connection details

RETURNS A LIVE CREDENTIAL for caches: the connection string includes the password. Treat the result as a secret and do not repeat it anywhere it would be stored or logged.

For PostgreSQL there is no password to return — one is shown only when a role is created, and the server does not keep it — so the result carries host, port and database. Use create_ephemeral_role to obtain a usable credential.

Input parameters:

- `id` (integer, required): Instance id, as returned by list_instances

### `create_instance` (~203 tokens)

Create an instance

Provisions a database or cache. THIS COSTS MONEY — the plan is billed monthly from creation until the instance is deleted.

Storage is not a parameter: it starts at the plan's included storage; grow it later with resize_storage. Creating runs in the background, so this returns an instance id and an actionId immediately. Poll get_action with the actionId until it reports "Success" (the instance is then "active") or "Failure".

Input parameters:

- `engine` (string): Engine version, e.g. "postgres@17" or just "17". Omit for the default.
- `group` (string, required): database for PostgreSQL, cache for Valkey/Redis
- `name` (string, required): Instance name
- `region` (string, required): Region name (e.g. fsn1) or city from list_regions. Required: there is no default.
- `tier` (string, required): Plan name from list_plans, e.g. AKPG-5

### `scale_instance` (~142 tokens)

Move an instance to another plan

Changes the plan an instance runs on, which changes what it costs. Scaling DOWN reduces memory; storage stays (it never shrinks) and GB above the smaller plan are billed at €0.15/GB/month. If the instance is using more memory than the smaller plan provides, that becomes a problem during the move. Check current usage with get_instance first.

Input parameters:

- `confirm_name` (string, required): The exact instance name, as a guard against acting on the wrong one. Call get_instance first and copy it from there.
- `id` (integer, required): Instance id, as returned by list_instances
- `tier` (string, required): Target plan name from list_plans

### `list_branches` (~51 tokens)

List an instance's branches

The instance's cluster: the default database and every branch forked from it. `isDefault` marks the one promotion would replace.

Input parameters:

- `id` (integer, required): Instance id, as returned by list_instances

### `create_branch` (~223 tokens)

Branch a PostgreSQL database

Creates a copy-on-write clone of a PostgreSQL instance: it has the source's data from the moment of branching, and the two diverge independently afterwards.

THIS COSTS MONEY — a branch is billed hourly like any instance: on its plan, and on what it writes itself above that plan's included storage at €0.15/GB/month, while it is a branch. Once promoted, it is billed on its full size. Pick a smaller plan than the source when the branch is for a test.

Takes about a minute: the clone itself is instant, but a second PostgreSQL has to start. Poll get_instance until status is "active". Branching is refused on instances not using branch-capable storage.

Input parameters:

- `expires_in_days` (integer): Days before the branch is deleted automatically. Defaults to 7.
- `id` (integer, required): Instance id, as returned by list_instances
- `name` (string, required): Name for the branch
- `tier` (string): Plan for the branch, from list_plans. Defaults to the source's.

### `set_branch_expiry` (~138 tokens)

Change when a branch expires

Branches delete themselves after a while, so a forgotten one does not keep costing money. This extends that deadline, or removes it entirely.

Removing it is a real decision, not a convenience: a kept branch holds its source's old blocks, which count against the source's storage. When that fills, growing it (by hand or automatically) is what costs, which is not obvious from looking at the branch.

Input parameters:

- `branch_id` (integer, required): The branch to change
- `expires_in_days` (required): Days from now, or null to keep the branch indefinitely
- `id` (integer, required): Instance id, as returned by list_instances

### `delete_branch` (~115 tokens)

Delete a branch

PERMANENTLY DESTROYS a branch and anything written to it since it was created. The source database is untouched.

Only works on branches — it refuses the cluster's default database, which has to be removed with delete_instance instead.

Input parameters:

- `branch_id` (integer, required): The branch to delete
- `confirm_name` (string, required): The exact instance name, as a guard against acting on the wrong one. Call get_instance first and copy it from there.
- `id` (integer, required): Instance id, as returned by list_instances

### `promote_branch` (~109 tokens)

Make a branch the default

Promotes a branch to be its cluster's default database; the previous default becomes a branch. Nothing is deleted and no data moves — this changes which instance the cluster treats as the original.

Connection details do not follow the promotion: each instance keeps its own host, port and credentials.

Input parameters:

- `branch_id` (integer, required): The branch to promote
- `confirm_name` (string, required): The exact instance name, as a guard against acting on the wrong one. Call get_instance first and copy it from there.

### `create_ephemeral_role` (~167 tokens)

Create a temporary PostgreSQL login

RETURNS A LIVE CREDENTIAL. Creates a PostgreSQL role that stops working by itself after ttl_seconds and is then removed.

This is the way to connect to a PostgreSQL instance: passwords are never stored, so get_connection cannot return one. The expiry is enforced by PostgreSQL itself, so the credential dies on time whether or not anything else is running.

The password is returned once and exists nowhere else. Treat it as a secret and do not repeat it anywhere it would be stored or logged.

Input parameters:

- `id` (integer, required): Instance id, as returned by list_instances
- `name` (string): Label for the role. Defaults to a generated one.
- `ttl_seconds` (integer): How long the credential lives, 60s to 24h. Defaults to one hour.

### `get_storage` (~50 tokens)

Show storage and automatic growth

Size, usage, included storage, what is billed above the plan (net €/month), and automatic growth for a PostgreSQL instance.

Input parameters:

- `id` (integer, required): Instance id, as returned by list_instances

### `resize_storage` (~152 tokens)

Grow storage

Grows the storage of a PostgreSQL instance to size_gb (larger than now, at most 1000 GB). Storage only grows: this can't be undone, not even by moving to a smaller plan. Each GB above the plan's included storage costs €0.15/month net, prorated by the hour; get_storage shows the current figures.

Input parameters:

- `confirm_name` (string, required): The exact instance name, as a guard against acting on the wrong one. Call get_instance first and copy it from there.
- `id` (integer, required): Instance id, as returned by list_instances
- `size_gb` (integer, required): New size in whole GB, larger than now, at most 1000

### `set_autoscale` (~156 tokens)

Configure automatic storage growth

Turns automatic storage growth on or off for a PostgreSQL instance and sets its limit. When on, at 80% full storage grows to the larger of +5 GB or 70% full, never above limit_gb, which is required to turn it on; each grow is permanent and billed like resize_storage. A limit can be raised or lowered but not cleared. Only the fields you pass are sent, so changing one leaves the other alone.

Input parameters:

- `enabled` (boolean): Turn automatic growth on or off
- `id` (integer, required): Instance id, as returned by list_instances
- `limit_gb` (integer): Largest size automatic growth may reach, in GB. Above the current size to turn it on.

### `create_trial_database` (~128 tokens)

Create a free trial database

Creates a PostgreSQL database for the next 60 minutes, with no account or token. Returns a connection string and a claim URL. The connection stops working after connectUntil; the data is deleted after claimUntil unless the user opens the claim URL, signs up and adds a payment method, which moves the data into a database of their own. Give the claim URL to the user: it is shown once. Limits: 200 MB, 3 connections, 30-second statements, no superuser; trusted extensions such as pgcrypto work. At most 3 trials per network per day.

## Diagnostics

Captured diagnostic sections: Provenance, Dependencies. The full working is on the page: https://verifymcp.io/servers/m-akcan-zektor/zektor#diagnostics

## Score history

- 2026-11-04: 79
- 2026-11-03: 79
- 2026-11-02: 78
- 2026-11-01: 78
- 2026-10-31: 77
- 2026-10-30: 77
- 2026-10-29: 76
- 2026-10-28: 76
- 2026-10-27: 76
- 2026-10-26: 75
- 2026-10-25: 75
- 2026-10-24: 74
- 2026-10-23: 74
- 2026-10-22: 73
- 2026-10-21: 70
- 2026-10-20: 70
- 2026-10-19: 70
- 2026-10-18: 70
- 2026-10-17: 70
- 2026-10-16: 70
- 2026-10-15: 70
- 2026-10-14: 38
- 2026-10-13: 38
- 2026-10-12: 38

## Common questions

### What is the Zektor MCP server?

Zektor is an MCP server listed in the public MCP registry as io.github.m-akcan/zektor. Managed Postgres and Valkey hosted in Germany. Agents can create a trial database with no signup. This page covers its npm package (zektor).

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

Zektor scores 79 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 4 November 2026. It declares no install or post-install scripts. 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 Zektor MCP server expose?

Zektor exposes 19 tools: whoami, list_instances, get_instance, get_action, list_plans, and 14 more. Their descriptions and schemas cost roughly 2,045 tokens of context every time the server is loaded.

### Is the Zektor MCP server still maintained?

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

### What licence is the Zektor MCP server under?

Zektor declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- npm package: https://www.npmjs.com/package/zektor
- Socket report: https://socket.dev/npm/package/zektor
- Repository: https://github.com/m-akcan/zektor-cli
- Website: https://zektor.io/
- Changelog RSS feed: https://verifymcp.io/servers/m-akcan-zektor/zektor.xml
- Changelog JSON feed: https://verifymcp.io/servers/m-akcan-zektor/zektor.json
- HTML version of this page: https://verifymcp.io/servers/m-akcan-zektor/zektor