Skip to main content
Glama
ClockNext MCP Server

ClockNext MCP Server

Official

@clocknext/mcp

The Clocknext MCP server — meter usage, verify signals, and manage usage‑based billing directly from AI coding tools (Claude Code, Cursor, Codex, Antigravity, …) and any other Model Context Protocol client.

It runs locally over stdio: your AI tool spawns it as a subprocess, and your organisation's cnk_… API key stays in the server's environment — never in the model's context.

This repo ships two things:

  • the MCP server (@clocknext/mcp) — the tools an agent calls.

  • the clocknext-onboarding skill — the step‑by‑step playbook that drives a full setup using those tools (human‑in‑the‑loop, sandbox‑first).

Install them together (the Claude Code plugin) or separately. Pick by what you want and which agent you're on:

Install

What you get

Works in

Skill — npx skills add Clocknext-Inc/clocknext-mcp

the guided onboarding flow

every agent (Claude Code, Cursor, Codex, Windsurf, Gemini, Antigravity, VS Code, …)

MCP server — npx -y @clocknext/mcp

the tools an agent calls

every MCP client

Plugin — /plugin install clocknext@clocknext

MCP tools + skill, one step

Claude Code only

The skill and the MCP server work together — the skill drives the tools — so for the full guided experience install both (or just use the plugin, which bundles them). The plugin is the one‑command option, but Claude Code only.

A Clocknext API key is required for the tools: Settings → API Keys → cnk_…. It is a server‑side secret — keep it in env/secret config, never in client code or a repo.


1 — The skill (every AI coding agent)

The clocknext-onboarding skill is the guided playbook (detect models → entitlements → plan → meter the codebase → test with a dummy customer). It drives the MCP tools, so install the MCP server too (§2 below) — the skill on its own has nothing to call.

Install it with npx skills — one command, works across Claude Code, Cursor, Codex, Windsurf, Gemini, Antigravity, VS Code, and ~20 other agents. Target your agent with --agent so it lands where that agent actually looks:

# user-wide (all projects), for a specific agent:
npx skills add Clocknext-Inc/clocknext-mcp --global --agent claude-code
# …or this project only:
npx skills add Clocknext-Inc/clocknext-mcp --agent claude-code

Swap claude-code for cursor, codex, windsurf, … (or * for every detected agent). npx skills list shows what's installed; npx skills remove clocknext-onboarding removes it. After installing, restart the agent — most load skills at startup.

Claude Code, read this. Claude Code only loads skills from ~/.claude/skills/, .claude/skills/, or a plugin — not the CLI's default universal .agents/skills/ folder. So you must pass --agent claude-code (as above), which installs to ~/.claude/skills/ (with --global) or .claude/skills/. A bare npx skills add … puts it in .agents/skills/, where Claude Code will never see it. Simplest of all for Claude Code: use the plugin — it registers the skill natively and wires the MCP in one step.

Copy the folder from the repo into your agent's skills directory:

git clone https://github.com/Clocknext-Inc/clocknext-mcp
# Claude Code — all projects:
mkdir -p ~/.claude/skills && cp -r clocknext-mcp/skills/clocknext-onboarding ~/.claude/skills/
# …or this project only: .claude/skills/

For tools without a native skills folder (Cursor / Windsurf / Codex / Antigravity), point their rules file at skills/clocknext-onboarding/SKILL.md — e.g. .cursor/rules/clocknext-onboarding.md, Windsurf Rules, or AGENTS.md. Keep the references/*.md files alongside SKILL.md.


Related MCP server: InvoiceBloom MCP server

2 — The MCP server (every AI coding agent)

Gives you the tools the skill (and you) call — one stdio server, npx -y @clocknext/mcp, with your CLOCKNEXT_API_KEY in its env.

Most clients take the standard block below — same JSON, they just differ on the file it goes in:

{
  "mcpServers": {
    "clocknext": {
      "command": "npx",
      "args": ["-y", "@clocknext/mcp"],
      "env": { "CLOCKNEXT_API_KEY": "cnk_your_key" }
    }
  }
}

CLI agents

Claude Code — one command:

claude mcp add clocknext --env CLOCKNEXT_API_KEY=cnk_your_key -- npx -y @clocknext/mcp

Gemini CLI — ~/.gemini/settings.json → the standard block.

Codex — ~/.codex/config.toml:

[mcp_servers.clocknext]
command = "npx"
args = ["-y", "@clocknext/mcp"]
env = { CLOCKNEXT_API_KEY = "cnk_your_key" }

GitHub Copilot CLI — copilot mcp add, or ~/.copilot/mcp-config.json:

{
  "mcpServers": {
    "clocknext": {
      "type": "local",
      "command": "npx",
      "args": ["-y", "@clocknext/mcp"],
      "env": { "CLOCKNEXT_API_KEY": "cnk_your_key" },
      "tools": ["*"]
    }
  }
}

OpenCode — ~/.config/opencode/opencode.json (note: mcp root, command is an array, env is environment):

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "clocknext": {
      "type": "local",
      "command": ["npx", "-y", "@clocknext/mcp"],
      "environment": { "CLOCKNEXT_API_KEY": "cnk_your_key" },
      "enabled": true
    }
  }
}

Factory (Droid) — droid mcp add, or the standard block in its config with "type": "stdio" added to the server:

droid mcp add --type stdio clocknext "npx -y @clocknext/mcp"

Kimi Code — kimi mcp add clocknext -- npx -y @clocknext/mcp (set CLOCKNEXT_API_KEY in the environment; config lives in ~/.kimi/config.toml).

IDEs

Cursor — .cursor/mcp.json (project) or ~/.cursor/mcp.json (global) → the standard block.

Windsurf — ~/.codeium/windsurf/mcp_config.json → the standard block.

Antigravity — its MCP settings JSON → the standard block.

Kiro — .kiro/settings/mcp.json (project) or ~/.kiro/settings/mcp.json (user) → the standard block. Kiro doesn't inherit your shell PATH, so if npx isn't found, use its full path (which npx).

VS Code (native MCP / Copilot) — .vscode/mcp.json (uses servers, not mcpServers):

{
  "servers": {
    "clocknext": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@clocknext/mcp"],
      "env": { "CLOCKNEXT_API_KEY": "cnk_your_key" }
    }
  }
}

Any other MCP client — point it at the stdio command npx -y @clocknext/mcp with CLOCKNEXT_API_KEY in env. @clocknext/mcp is also in the official MCP Registry as io.github.Clocknext-Inc/mcp, so registry‑aware clients can discover it directly. (The older entry io.github.Clocknext/mcp stops at 0.13.0: the GitHub organisation was renamed to Clocknext-Inc, and the registry only lets it publish under its own name.)

Environment

Variable

Required

Description

CLOCKNEXT_API_KEY

yes

Your org's cnk_… key (Settings → API Keys).

CLOCKNEXT_BASE_URL

no

Override the API origin (e.g. a staging URL). Defaults to production.

CLOCKNEXT_DOCS_URL

no

Override the docs origin for the search_docs/get_doc tools. Defaults to https://help.clocknext.com.


3 — The Claude Code plugin (Claude Code only)

The one‑command option — installs the MCP server and the clocknext-onboarding skill together, and wires the API key for you. Claude Code only (the plugin format is Claude Code's; other agents use §1 + §2 above).

/plugin marketplace add Clocknext-Inc/clocknext-mcp
/plugin install clocknext@clocknext

Claude Code prompts for your Clocknext API key at install (stored securely), runs the bundled server, and auto‑discovers the skill from the plugin's skills/ folder. Verify:

  • /mcp → the clocknext tools are listed.

  • The skill triggers automatically when you start any Clocknext work (or check your installed skills).

No manual config, no env vars, nothing to build.


Tools

Tool

What it does

clocknext_whoami

Identify the org behind the key and whether it's sandbox or live. Call first.

clocknext_list_models

List enabled models + USD prices per 1M tokens. Use a modelId in signals.

clocknext_add_model

Enable a catalog model (autopriced); warns if it has no catalog price.

clocknext_get_customer_balances

A customer's current wallet / credit / outcome / unit balances.

clocknext_get_customer_plan

A customer's current active plan (from their purchase).

Plus catalogue CRUD (create_plan / create_credit / create_outcome / create_unit …), customer tools (create_customer, create_purchase, bulk_import_customers), and the docs tools (search_docs, get_doc). Run /mcp to see the full list.

A typical agent flow: whoami → list_models → get_customer_plan (confirm the plan, and that every model and agent key the code will send resolves) → run the product's own code so it fires a real signal through @clocknext/sdk → the SDK's signals.usageLog({ customerId }) (confirm it landed). The clocknext-onboarding skill orchestrates all of this.

The MCP configures billing but never meters it. There is no record/track tool by design, and no preview either: real signals come from your product's code via the SDK (signals.credit / .wallet / .outcome), which is also the only thing that proves the integration end-to-end. The SDK's signals.usageLog() is the proof one landed; the MCP has no usage-read tool.

Development

npm install
npm run build        # tsup → dist/index.js (executable bin)
npm run dev          # run from source via tsx
CLOCKNEXT_API_KEY=cnk_... npm start

Built on the official @modelcontextprotocol/sdk, with its own small fetch client for the Clocknext API (src/api.ts), all bundled into dist/ by tsup. stdio today; a hosted Streamable‑HTTP variant is planned. Logs go to stderr (stdout is the protocol channel). The committed dist/ is what the plugin runs — rebuild and commit it on any code change.

Releasing (maintainers) — automated

A tag push publishes both the npm package and the official MCP Registry entry, via .github/workflows/publish-mcp.yml:

# 1. bump the version in package.json, server.json (both "version" fields),
#    src/index.ts and .claude-plugin/plugin.json; rebuild + commit:
npm run build && git commit -am "release: vX.Y.Z"

# 2. tag and push — CI does the rest:
git tag vX.Y.Z && git push origin main --tags

The workflow checks the tag matches package.json, builds, npm publishes (with provenance), then authenticates to the registry with GitHub OIDC (no secret) and publishes server.json. It hosts only metadata pointing at the npm package, so the npm publish runs first.

One‑time setup: add an NPM_TOKEN secret (repo → Settings → Secrets → Actions). To drop the token entirely, configure npm trusted publishing (OIDC) for @clocknext/mcp on npmjs.com and delete the NODE_AUTH_TOKEN line.

npm publish --access public                 # npm first — the registry validates against it
# get the publisher CLI (Linux/macOS, no brew needed):
curl -L "https://github.com/modelcontextprotocol/registry/releases/latest/download/mcp-publisher_$(uname -s | tr '[:upper:]' '[:lower:]')_$(uname -m | sed 's/x86_64/amd64/;s/aarch64/arm64/').tar.gz" | tar xz mcp-publisher
./mcp-publisher login github                # device flow — must be a Clocknext org member
./mcp-publisher publish                     # reads server.json (name io.github.Clocknext-Inc/mcp)

See the MCP Registry docs.

Available Tools

35 tools
clocknext_add_modelClockNext: add (enable) a modelA
Idempotent

Enable a model for the organisation so usage can be metered against it — afterwards its modelId is valid in clocknext_record_usage / clocknext_verify_signal and appears in clocknext_list_models. Only models in ClockNext's pricing catalog can be added, AUTOPRICED: give the provider and model (its catalog id) and ClockNext copies that model's input/output/cache prices from the catalog — you never set prices here. If the catalog has no price for it, the model is still enabled but meters at $0, and you must set its price manually on the Models page (the tool returns that link and a warning). A model or provider that isn't in the catalog can't be added — check clocknext_list_models first.

Inputs: model (required), provider (required).

clocknext_archive_creditClockNext: archive creditA
DestructiveIdempotent

Deactivate a credit TYPE in your catalogue (sets isActive→false) — ClockNext's soft archive, NOT a delete. The credit and its history are kept; recorded usage and any plan already granting it keep working (update those plans with clocknext_update_plan to stop offering it). It simply can't be added to new plans and drops out of active lists. Reversible: reactivate via clocknext_update_credit with isActive:true (a full rewrite) — there is no separate un-archive tool. Use ONLY to retire a credit you no longer sell. This does NOT delete anything and is unrelated to archiving a customer, ending a purchase, or clearing a balance.

Inputs: id (required).

clocknext_archive_outcomeClockNext: archive outcomeA
DestructiveIdempotent

Deactivate an outcome TYPE in your catalogue (sets isActive→false) — ClockNext's soft archive, NOT a delete. The outcome, its steps, and any in-flight or completed history are kept; existing plans and outcomes already in progress are unaffected. It simply can't be added to new plans and drops out of active lists. Reversible: reactivate via clocknext_update_outcome with isActive:true (a full rewrite) — there is no separate un-archive tool. Use ONLY to retire an outcome you no longer sell. This does NOT delete anything and is unrelated to archiving a customer or ending a purchase.

Inputs: id (required).

clocknext_archive_planClockNext: archive planA
DestructiveIdempotent

Deactivate a plan in your catalogue (sets isActive→false) — ClockNext's soft archive, NOT a delete. The plan and its history are kept and customers already on it are unaffected; it simply becomes unsellable and drops out of active lists. Reversible: reactivate via clocknext_update_plan with isActive:true (a full rewrite) — there is no separate un-archive tool. Use ONLY to retire a plan you no longer sell. This does NOT delete anything and is unrelated to cancelling a customer's purchase or ending a subscription.

Inputs: id (required).

clocknext_archive_unitClockNext: archive unitA
DestructiveIdempotent

Deactivate a unit TYPE in your catalogue (sets isActive→false) — ClockNext's soft archive, NOT a delete. The unit and its recorded usage are kept; existing plans metering it keep working. It simply can't be added to new plans and drops out of active lists. Reversible: reactivate via clocknext_update_unit with isActive:true (a full rewrite) — there is no separate un-archive tool. Use ONLY to retire a unit you no longer sell. This does NOT delete anything and is unrelated to archiving a customer or ending a purchase.

Inputs: id (required).

clocknext_bulk_import_customersClockNext: bulk import customersA

Bulk-create ClockNext customers in ONE request — for backfilling an existing user base. Pass an array of customers (each needs name + email; up to 200 per call). The whole batch goes to the server in a single call and comes back with a PER-ROW result — created id, or an error — so one duplicate/bad row never aborts the batch. Match results back to your users by email. Runs against a private, MCP-only bulk endpoint (no SDK / public API); for a larger base, call it again in ≤200-row chunks.

Inputs: customers (required).

clocknext_create_creditClockNext: create creditA

Create a credit type — a token-metered entitlement your product draws down against its agentKey. Pricing is MODEL-GROUNDED: give models (a mixer of enabled catalog model(s) + avg tokens + input/output/cache split) and a marginPercent; the tool reads live model prices and COMPUTES the base price + price-per-credit — you never hand-type a price, so a credit can't be mispriced or grounded in a disabled model. First-class alternative: create/price it in the dashboard (https://payments.clocknext.com/credits) — its live mixer preview is clearer and records the full per-model bundle; use this tool as the fallback (it stores the computed price only). A plan grants the credit via a CREDIT component referencing its id.

Inputs: name (required), models (required), agentKey (required), marginPercent (required), +2 more.

clocknext_create_customerClockNext: create customerA

Create a ClockNext customer — the entity you bill (maps to one of your end-users / tenants / organisations). name and email are required; everything else is optional profile. Returns the customer with its ClockNext id, which you pass as customerId when subscribing to a plan (clocknext_create_purchase) and when recording usage (clocknext_record_usage).

Inputs: name (required), email (required), city, notes, +12 more.

clocknext_create_outcomeClockNext: create outcomeA

Create an outcome type — a multi-step LLM deliverable billed per COMPLETED outcome. Each of the 1–50 steps has its own agentKey and its own model mixer (models): the tool computes each step's base cost from live model prices, sums them, and applies marginPercent. Outcomes are for token-priced, multi-LLM-step deliverables; a fixed-cost / non-LLM event (e.g. an upload or export) belongs in a UNIT, not an outcome step. First-class alternative: build it in the dashboard (https://payments.clocknext.com/outcomes) — clearer per-step pricing preview; use this tool as the fallback. A plan grants it via an OUTCOME component referencing its id.

Inputs: name (required), steps (required), marginPercent (required), isActive, +1 more.

clocknext_create_planClockNext: create planA

Create a billing plan. A plan bundles one or more entitlement components: WALLET (prepaid USD balance, debited at raw model cost — NO margin), FLAT (one-off fee), or CREDIT/OUTCOME/UNIT entitlements that reference an existing credit/outcome/unit BY ID — so create those first (clocknext_create_credit / _outcome / _unit) and list them to get ids. Each component has a billingMode: ADVANCE (up-front, needs amount/quantity) or ARREAR (metered). FREE plans must be ADVANCE-only with no FLAT component. PREFER the dashboard plan builder (https://payments.clocknext.com/plans) — it previews what a customer pays; use this tool as the fallback. This creates a real, sellable plan — get the pricing right before you create it.

Inputs: name (required), components (required), billingCycle (required), isActive, +3 more.

clocknext_create_purchaseClockNext: subscribe customer to a planA

Subscribe a customer to a plan (a 'purchase') — this is what activates the plan for that customer. A usage signal only prices if the customer has an active plan whose components match the meter (credit / outcome / unit), so do this after clocknext_create_customer + clocknext_create_plan. Used to wire up a dummy customer before firing test signals.

Inputs: planId (required), customerId (required), notes, autoPayment, +2 more.

clocknext_create_unitClockNext: create unitA

Create a unit type: a metered usage unit reported against a lowercased stable agentKey (the key you send when recording unit usage) — its durable identity, unique org-wide. Units are for FIXED-COST / non-LLM events (an upload, an export, a seat) — one event = one unit, no tokens. Price it FLAT (a single flatPrice per event, default 0) or tiered — pricingType SLAB or VOLUME with tiers (1–50, ordered; only the last tier may have upTo:null). PREFER the dashboard (https://payments.clocknext.com/units) for the live price preview; use this tool as the fallback. A plan meters it via a UNIT component referencing this unit's id.

Inputs: name (required), agentKey (required), pricingType (required), tiers, +3 more.

clocknext_get_creditClockNext: get creditA
Read-only

Get one credit type in full by id — pricing, token mapping and active state.

Inputs: id (required).

clocknext_get_customerClockNext: get customerA
Read-only

Fetch one customer by ClockNext id.

Inputs: id (required).

clocknext_get_customer_balancesClockNext: get customer balancesA
Read-only

Fetch a customer's current wallet / credit / outcome / unit balances. Use it to confirm a purchase granted the expected entitlements, or that a test signal drew the balance down as expected.

Inputs: id (required).

clocknext_get_customer_planClockNext: get customer planA
Read-only

Fetch a customer's current active plan (from their purchase). Use it to confirm a customer is subscribed to the plan you expect before firing a test signal.

Inputs: id (required).

clocknext_get_customer_usageClockNext: get customer usageA
Read-only

Read back a customer's recent usage logs (most recent first). Use it to CONFIRM a signal landed — e.g. after running the product's code so it fires a real signal, check the event shows up here with the expected model, tokens, and cost. For a signal you fire directly, clocknext_record_usage already returns the priced log inline, so this is mainly for signals sent by the running codebase.

Inputs: id (required), limit.

clocknext_get_docClockNext: read a docs pageA

Read the FULL contents of a single ClockNext docs page as Markdown. Use this right after clocknext_search_docs: pass the url of a promising search result to read the whole page — endpoints, parameters, request/response fields, and code samples that the search snippet leaves out.

clocknext_search_docs finds WHICH page you need (title + url + a short snippet); this tool reads THAT page in full. A snippet is enough to choose a page, never enough to implement against — when you need exact field names, types, or the request body, call this.

ALWAYS use this for ClockNext docs instead of any external web-fetch/browser tool: it returns the authoritative page verbatim, whereas an external fetch routes the page through a summariser that can silently drop details (e.g. required fields like agentKey/idempotencyKey).

Inputs: path (required).

clocknext_get_outcomeClockNext: get outcomeA
Read-only

Get one outcome type in full by id — its steps plus in-flight/completed stats.

Inputs: id (required).

clocknext_get_planClockNext: get planA
Read-only

Get one plan in full by id — its entitlement components (wallet/credit/outcome/unit/flat), billing cycle, currency and active state.

Inputs: id (required).

clocknext_get_unitClockNext: get unitA
Read-only

Get one unit type in full by id — pricing type, flat price or tiers, plus usage stats.

Inputs: id (required).

clocknext_list_creditsClockNext: list creditsA
Read-only

List the organisation's credit types (id, name, agentKey, price, active). Use it to find a credit id to reference from a plan's CREDIT component.

Inputs: active.

clocknext_list_customersClockNext: list customersA
Read-only

List / search the org's customers, most-recent first (cursor-paginated). Use it to find a customer id or check whether one already exists before creating.

Inputs: q, limit, cursor.

clocknext_list_modelsClockNext: list modelsA

List the models the organisation has enabled, with their USD prices per 1,000,000 tokens. Use a returned modelId as the model when verifying or recording usage. Pass active=true to see only models that can be metered right now.

Inputs: active.

clocknext_list_outcomesClockNext: list outcomesA
Read-only

List the organisation's outcome types (id, name, price, active). Use it to find an outcome id to reference from a plan's OUTCOME component.

Inputs: active.

clocknext_list_plansClockNext: list plansA
Read-only

List the organisation's billing plans (id, name, billing cycle, price, active). Use it to find a plan id or to see what's on offer. Pass active=true for only sellable plans.

Inputs: active.

clocknext_list_unitsClockNext: list unitsA
Read-only

List the organisation's unit types (id, name, pricing type, active). Use it to find a unit id to reference from a plan's UNIT component.

Inputs: active.

clocknext_record_usageClockNext: record usageA

Record ONE real usage signal — it is metered and billed. Prices the tokens against the model and the customer's plan and returns the resulting usage log. Pass an idempotencyKey to make retries safe (a repeat with the same key returns the original result instead of double-recording). For a no-op preflight, use clocknext_verify_signal instead.

Inputs: type (required), model (required), customerId (required), inputTokens (required), +5 more.

clocknext_search_docsClockNext: search docsA

Search ClockNext's official documentation and get back the most relevant pages (title, URL, and a snippet). ClockNext is a usage-based billing platform: you meter product/AI usage, price it against plans and units, and bill customers for it.

ALWAYS prefer this over answering from memory — the docs are the source of truth and are more current than your training data. Call it before you explain a ClockNext concept, design an integration, or reach for any other ClockNext tool.

Docs come in three kinds. Work through them in order:

  1. concept — WHAT things are and HOW ClockNext works: the domain model (plans, units, outcomes, credits, customers, invoices, wallet/balances) and billing behaviour. START HERE to get context. If a term is unfamiliar, search concept first before touching any reference.

  2. api — the language-agnostic REST API reference (endpoints, params, request/response shapes). Use this to actually implement or call ClockNext from ANY language.

  3. javascript — reference for the official JavaScript/TypeScript SDK (@clocknext/sdk), a typed convenience wrapper over the same REST API.

IMPORTANT — the SDK is JavaScript/TypeScript ONLY, and the docs will NOT tell you this. If the customer's codebase is not JS/TS (e.g. Python, Go, Ruby, PHP, Rust, Java, C#), do NOT use the javascript kind — use api and integrate against the REST API directly. Only choose javascript once you have confirmed the target codebase is JS/TS.

Omit kind to search everything. Typical flow: search concept to understand the task, then search api (or javascript for a JS/TS codebase) for the exact reference you need to write code.

Inputs: query (required), kind, limit.

clocknext_update_creditClockNext: update creditA
Idempotent

Replace a credit by id with its COMPLETE new definition — a full rewrite, NOT a partial patch (omitted fields are cleared). Pricing is re-grounded from the models mixer you pass (same as create). To only flip active state, pass the current values plus isActive. Read the current credit with clocknext_get_credit first. Changing agentKey re-points which runtime signals map here — do it deliberately.

Inputs: id (required), name (required), models (required), agentKey (required), +3 more.

clocknext_update_outcomeClockNext: update outcomeA
Idempotent

Replace an outcome by id with its COMPLETE new definition — a full rewrite, NOT a partial patch (omitted steps/fields are dropped). Each step's price is re-grounded from its models mixer (same as create). Read the current outcome with clocknext_get_outcome first. Step agent keys are the runtime binding — change them deliberately.

Inputs: id (required), name (required), steps (required), marginPercent (required), +2 more.

clocknext_update_planClockNext: update planA
Idempotent

Replace a plan by id with a COMPLETE new definition (same shape as create — a full rewrite, not a patch; omitted fields are dropped). Changes the plan going forward; customers already on it keep their terms. Read it first with clocknext_get_plan, edit, then send the whole thing back.

Inputs: id (required), name (required), components (required), billingCycle (required), +4 more.

clocknext_update_unitClockNext: update unitA
Idempotent

Replace a unit by id with its COMPLETE new definition — a full rewrite, NOT a partial patch: any optional field you omit (description, tiers, flatPrice) is CLEARED, not left as-is. Read the current unit with clocknext_get_unit first, edit, then send the whole object back. Changing agentKey re-points which runtime signals map here — do it deliberately.

Inputs: id (required), name (required), agentKey (required), pricingType (required), +4 more.

clocknext_verify_signalClockNext: verify signal (dry run)A

Validate and PRICE a usage signal WITHOUT recording it — a dry run. Returns the projected usage log (cost, credits drawn, applied rules) so you can confirm the customer, model, and plan are wired up correctly before sending real traffic. Records nothing and never bills.

Inputs: type (required), model (required), customerId (required), inputTokens (required), +4 more.

clocknext_whoamiClockNext: identify workspaceA

Identify the ClockNext organisation behind the configured API key, and — crucially — whether it is a 'sandbox' (a disposable staging twin) or the 'live' organisation. Call this FIRST to confirm you are pointed at the intended workspace before recording any real usage.

Inputs: no named parameters.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4/5.0

    Scored across 35 tools

    Disambiguation5/5

    Every tool targets a distinct resource and action: CRUD per entity plus usage verification/recording and docs helpers. The verify vs record usage pair is clearly separated as dry-run vs billed, and all list/get/create/update/archive tools are unambiguous for their entity.

    Naming Consistency5/5

    All tools follow a consistent clocknext_verb_noun pattern in snake_case (list_models, create_credit, archive_unit, etc.). Even compound names like bulk_import_customers and whoami fit the general style without mixing conventions.

    Tool Count2/5

    35 tools is well above the 25+ threshold for 'too many', even though the billing domain has many entity types. The number feels heavy and could be trimmed or split into focused sub-servers, especially given several entities have near-identical CRUD patterns.

    Completeness2/5

    Significant lifecycle gaps exist: customers have no update/archive/delete, purchases have only create (no list/get/update/cancel), and there are no tools for invoices or wallet transactions. The core setup and usage recording flows work, but managing subscriptions and customers over time is incomplete.

    Maintenance

    ActivityMaintained
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers