Skip to main content
Glama

Zenkit MCP Server (Raw API)

Direct Zenkit API access for Claude Desktop. Full control via single universal tool.

Installation

Using Node.js:

curl -O https://raw.githubusercontent.com/wbgrds/mcp-zenkit/main/install.js
node install.js

Using Bash:

bash <(curl -s https://raw.githubusercontent.com/wbgrds/mcp-zenkit/main/install.sh)

In Claude Code:

  1. Open this repo in Claude Code

  2. Say: "Run install.js"

  3. Provide your Zenkit API key

  4. Done!

The installer will:

  • Clone the repository

  • Install Node dependencies

  • Create .env with your API key

  • Build TypeScript → JavaScript

  • Test the MCP server

  • Output Claude Desktop configuration

Option 2: Manual Installation

# 1. Clone repo
git clone https://github.com/wbgrds/mcp-zenkit.git
cd mcp-zenkit

# 2. Install dependencies
npm install

# 3. Build TypeScript
npm run build

# 4. Create .env with your API key
echo "ZENKIT_API_KEY=your-api-key" > .env

Configure Claude Desktop

Find your configuration file:

macOS/Linux:

~/.config/Claude/claude_desktop_config.json

Windows:

%APPDATA%\Claude\claude_desktop_config.json

Edit or create it with:

{
  "mcpServers": {
    "zenkit": {
      "command": "node",
      "args": ["/path/to/mcp-zenkit/dist/index.js"],
      "env": {
        "ZENKIT_API_KEY": "your-zenkit-api-key"
      }
    }
  }
}

Replace /path/to/mcp-zenkit with your actual installation path.

Get your API key: https://zenkit.com/en/user/profile/developer/

Restart Claude Desktop after configuration.


Related MCP server: Vikunja MCP Server

Usage

Single tool: zenkit(method, path, body)

Get Workspaces

zenkit('GET', '/workspaces')

Response: All workspaces + lists

Get Lists in Workspace

zenkit('GET', '/workspaces/123')

Get List Fields (Elements)

zenkit('GET', '/lists/123/elements')

Returns: Field names, UUIDs, types, predefined values (for categories)

List Entries

zenkit('POST', '/lists/123/entries', {
  limit: 100,
  skip: 0
})

Create Entry

zenkit('POST', '/lists/123/entries', {
  title: "My Task",
  description: "Optional description",
  properties: {
    "field-uuid-1": "value",
    "field-uuid-2": 123,
    "field-uuid-3": ["array", "of", "values"]
  }
})

To find field UUIDs: zenkit('GET', '/lists/123/elements')

Update Entry

zenkit('PATCH', '/lists/123/entries/entry-uuid', {
  title: "Updated Title",
  properties: {
    "field-uuid": "new-value"
  }
})

Delete Entry

zenkit('DELETE', '/lists/123/entries/entry-uuid')

Architecture

Version 2.0 (Approach B: Raw API)

  • One universal tool zenkit(method, path, body)

  • Direct pass-through to Zenkit API

  • No abstraction layer, no hidden logic

  • Token-based auth = full account control

What changed from v1:

  • Removed: zenkit_create_entry, zenkit_update_entry, zenkit_get_entries, etc.

  • Added: Single zenkit tool for all operations

  • Benefit: Works for any Zenkit API endpoint (present + future)


API Reference

Full Zenkit API docs: https://zenkit.com/api/

Common Endpoints

Operation

Method

Path

Body

List workspaces

GET

/workspaces

Get workspace

GET

/workspaces/{id}

List entries

POST

/lists/{id}/entries

{limit, skip}

Get fields

GET

/lists/{id}/elements

Create entry

POST

/lists/{id}/entries

{title, properties}

Update entry

PATCH

/lists/{id}/entries/{uuid}

{title, properties}

Delete entry

DELETE

/lists/{id}/entries/{uuid}


Examples

Workflow: Create and Update

1. zenkit('GET', '/workspaces')
   → Find workspace ID

2. zenkit('GET', '/lists/123/elements')
   → Find field UUIDs you need

3. zenkit('POST', '/lists/123/entries', {
     title: 'New Task',
     properties: { 'field-uuid': 'value' }
   })
   → Create entry, get entry UUID back

4. zenkit('PATCH', '/lists/123/entries/entry-uuid', {
     title: 'Updated Task'
   })
   → Update the entry

Working with Categories (Dropdowns)

When predefinedValues are present in get_list_fields response, they are category options:

{
  "name": "Status",
  "uuid": "a1b2c3d4-...",
  "predefinedValues": [
    { "id": 1, "name": "Draft" },
    { "id": 2, "name": "In Progress" },
    { "id": 3, "name": "Done" }
  ]
}

Use the id value when setting properties:

zenkit('POST', '/lists/123/entries', {
  title: 'Task',
  properties: {
    'a1b2c3d4-...': 2  // ← Category ID for "In Progress"
  }
})

Troubleshooting

Problem

Cause

Solution

"ZENKIT_API_KEY is required"

Environment variable missing

Check claude_desktop_config.json, restart Claude

"npm: command not found"

Node.js not installed

Install Node.js >= 18 from nodejs.org

"Git clone fails"

Git not installed

Install Git

"Claude doesn't see tool"

Config not reloaded

Restart Claude Desktop completely

"Zenkit API error 404"

Wrong path or resource doesn't exist

Use zenkit('GET', '/workspaces') to discover IDs

"Field UUID not found"

UUID is incorrect

Get correct UUIDs via zenkit('GET', '/lists/123/elements')


Environment Variables

  • ZENKIT_API_KEY (required): Zenkit API token

  • ZENKIT_API_BASE (optional): Override API base URL (default: https://base.zenkit.com/api/v1)


Development

# Install dependencies
npm install

# Build TypeScript
npm run build

# Run locally (requires ZENKIT_API_KEY env var)
ZENKIT_API_KEY=xxx npm run start

License

MIT

Support


Complete Documentation

Available Tools

1 tool
zenkitB

Raw Zenkit API access. Complete control over any Zenkit operation via direct API calls. Pass method, path, and optional body.

ParametersJSON Schema
NameRequiredDescriptionDefault
bodyNoRequest body for POST/PATCH/PUT operations (optional for GET/DELETE)
pathYesZenkit API path (e.g., /workspaces, /lists/123/entries, /lists/123/elements). Full path without base URL.
methodYesHTTP method

TDQS

B3.4/5.0
Behavior2/5

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

The description does not disclose any behavioral traits such as destructiveness, idempotency, or error handling. Without annotations, this is a significant gap for a raw API tool that can perform arbitrary 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?

Three concise sentences with no wasted words. The purpose is front-loaded effectively.

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?

Missing key information: no mention of return value format, error handling, authentication, or preconditions. For a raw API tool with no output schema, more context is needed.

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?

Schema coverage is 100%, so baseline is 3. The description merely repeats parameter names without adding meaningful context beyond the schema descriptions. No additional format or constraint details.

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 provides raw access to the Zenkit API with complete control over any operation. This is a specific and unambiguous purpose, distinguishing it as a low-level gateway.

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

Usage Guidelines3/5

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

No explicit when-to-use or when-not-to-use guidance is given. It implies advanced usage via 'Complete control' but lacks alternatives or context for choosing this tool over higher-level abstractions.

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.

  1. 1 tool updatev1.0.0
    • First observedzenkit

TDQS

A3.7/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of confusion between tools. The tool's purpose is clearly defined as raw API access.

Naming Consistency5/5

With only one tool named 'zenkit', there is no inconsistency. The name matches the server's domain and is clear.

Tool Count3/5

A single tool for a server providing Zenkit access feels thin. While the tool is powerful, it lacks specialization, making the set minimal.

Completeness5/5

The tool provides raw API access to all Zenkit operations, offering complete coverage of the domain. No obvious gaps exist.

Maintenance

ActivityStale
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers