Zektor
NPM · ZEKTOR
Managed Postgres and Valkey hosted in Germany. Agents can create a trial database with no signup.
Available components
Last scanned (17 hours ago)
Scores higher than 62% of npm servers
Category Databases
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. How we score → Why this is hard to score →
Supply Chain Security98
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- 30 of 93 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency45
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 26 days ago).Pass
- Disclosure check failed: no security disclosure policy was found in the source repository. See how to fix → Fail
Schema Quality & AI Usability75
- AI-judged instruction clarity (excellent).Pass
- 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. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management67
- Stability observed for 20 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 20 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 3 Nov 26 +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.
- 1 Nov 26 +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.
- 30 Oct 26 +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.
- 27 Oct 26 +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.
- 25 Oct 26 +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.
- 23 Oct 26 +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.
- 22 Oct 26 +3
- Stability: unverified → 0.23 ▲ functional
- 15 Oct 26 +32
- 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). security
- Tool coverage: unverified → 100 ▲ functional
- 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 functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 4 Nov 2026 · Analysed npm/zektor@1.7.1
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | npm |
Background: How many MCP packages publish verified provenance →
Dependencies 93 packages
| Packages resolved | 93 |
|---|---|
| Stale | 30 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
create_branch Branch a PostgreSQL database ~223
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.
| Name | Type | Req | Description |
|---|---|---|---|
| expires_in_days | integer | – | Days before the branch is deleted automatically. Defaults to 7. |
| id | integer | yes | Instance id, as returned by list_instances |
| name | string | yes | Name for the branch |
| tier | string | – | Plan for the branch, from list_plans. Defaults to the source's. |
No output schema declared.
No examples provided.
create_ephemeral_role Create a temporary PostgreSQL login ~167
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | integer | yes | 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. |
No output schema declared.
No examples provided.
create_instance Create an instance ~203
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".
| Name | Type | Req | Description |
|---|---|---|---|
| engine | string | – | Engine version, e.g. "postgres@17" or just "17". Omit for the default. |
| group | string | yes | database for PostgreSQL, cache for Valkey/Redis |
| name | string | yes | Instance name |
| region | string | yes | Region name (e.g. fsn1) or city from list_regions. Required: there is no default. |
| tier | string | yes | Plan name from list_plans, e.g. AKPG-5 |
No output schema declared.
No examples provided.
create_trial_database Create a free trial database ~128
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
delete_branch Delete a branch ~115
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.
| Name | Type | Req | Description |
|---|---|---|---|
| branch_id | integer | yes | The branch to delete |
| confirm_name | string | yes | The exact instance name, as a guard against acting on the wrong one. Call get_instance first and copy it from there. |
| id | integer | yes | Instance id, as returned by list_instances |
No output schema declared.
No examples provided.
get_action Check background work ~83
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.
| Name | Type | Req | Description |
|---|---|---|---|
| action_id | integer | yes | actionId from create_instance, scale_instance or resize_storage |
No output schema declared.
No examples provided.
get_connection Get connection details ~106
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.
| Name | Type | Req | Description |
|---|---|---|---|
| id | integer | yes | Instance id, as returned by list_instances |
No output schema declared.
No examples provided.
get_instance Get one instance ~50
Full detail for a single instance, including storage and autoscaling where it applies. Does not include credentials — use get_connection for those.
| Name | Type | Req | Description |
|---|---|---|---|
| id | integer | yes | Instance id, as returned by list_instances |
No output schema declared.
No examples provided.
get_storage Show storage and automatic growth ~50
Size, usage, included storage, what is billed above the plan (net €/month), and automatic growth for a PostgreSQL instance.
| Name | Type | Req | Description |
|---|---|---|---|
| id | integer | yes | Instance id, as returned by list_instances |
No output schema declared.
No examples provided.
list_branches List an instance's branches ~51
The instance's cluster: the default database and every branch forked from it. `isDefault` marks the one promotion would replace.
| Name | Type | Req | Description |
|---|---|---|---|
| id | integer | yes | Instance id, as returned by list_instances |
No output schema declared.
No examples provided.
list_instances List instances ~27
Every database and cache on the account, with id, name, status, engine and plan.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
list_plans List available plans ~71
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.
| Name | Type | Req | Description |
|---|---|---|---|
| group | string | – | Restrict to databases or caches. Omit for both. |
No output schema declared.
No examples provided.
list_regions List regions ~35
Regions an instance can be created in. `available` is false where there is no capacity right now; creating there will be refused.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
promote_branch Make a branch the default ~109
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.
| Name | Type | Req | Description |
|---|---|---|---|
| branch_id | integer | yes | The branch to promote |
| confirm_name | string | yes | The exact instance name, as a guard against acting on the wrong one. Call get_instance first and copy it from there. |
No output schema declared.
No examples provided.
resize_storage Grow storage ~152
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.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm_name | string | yes | The exact instance name, as a guard against acting on the wrong one. Call get_instance first and copy it from there. |
| id | integer | yes | Instance id, as returned by list_instances |
| size_gb | integer | yes | New size in whole GB, larger than now, at most 1000 |
No output schema declared.
No examples provided.
scale_instance Move an instance to another plan ~142
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.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm_name | string | yes | The exact instance name, as a guard against acting on the wrong one. Call get_instance first and copy it from there. |
| id | integer | yes | Instance id, as returned by list_instances |
| tier | string | yes | Target plan name from list_plans |
No output schema declared.
No examples provided.
set_autoscale Configure automatic storage growth ~156
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.
| Name | Type | Req | Description |
|---|---|---|---|
| enabled | boolean | – | Turn automatic growth on or off |
| id | integer | yes | 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. |
No output schema declared.
No examples provided.
set_branch_expiry Change when a branch expires ~138
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.
| Name | Type | Req | Description |
|---|---|---|---|
| branch_id | integer | yes | The branch to change |
| expires_in_days | – | yes | Days from now, or null to keep the branch indefinitely |
| id | integer | yes | Instance id, as returned by list_instances |
No output schema declared.
No examples provided.
whoami Show the authenticated account ~39
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
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.
npm · zektor
claude mcp add m-akcan-zektor -- npx -y zektor
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.