ClockNext MCP Server
OfficialClockNext MCP server lets AI agents configure, inspect, verify, and record usage-based billing for ClockNext workspaces.\n\n- Identify the organisation/workspace and whether it is sandbox or live.\n- List enabled models with USD prices per 1M tokens and enable catalog models with autopricing.\n- Dry-run and price a usage signal without billing (verify_signal), or record real usage with an optional idempotency key (record_usage).\n- Search and read official ClockNext documentation for concepts, REST API, and JS/TS SDK.\n- Create, read, update, and soft-archive billing plans with wallet/flat/credit/outcome/unit components.\n- Manage credits, outcomes, and units, including model-grounded pricing, token splits, multi-step outcomes, and flat/tiered unit pricing.\n- Create, fetch, list, search, and bulk-import customers (up to 200 per call).\n- Subscribe customers to plans and read their active plan, balances, and recent usage logs.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@ClockNext MCP Server verify usage signal for customer_abc with model gpt-4 and 500 tokens"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
@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-onboardingskill — 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 — | the guided onboarding flow | every agent (Claude Code, Cursor, Codex, Windsurf, Gemini, Antigravity, VS Code, …) |
MCP server — | the tools an agent calls | every MCP client |
Plugin — | 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-codeSwap 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 barenpx 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/mcpGemini 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 |
| yes | Your org's |
| no | Override the API origin (e.g. a staging URL). Defaults to production. |
| no | Override the docs origin for the |
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@clocknextClaude 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→ theclocknexttools 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 |
| Identify the org behind the key and whether it's sandbox or live. Call first. |
| List enabled models + USD prices per 1M tokens. Use a |
| Enable a catalog model (autopriced); warns if it has no catalog price. |
| A customer's current wallet / credit / outcome / unit balances. |
| 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 startBuilt 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 --tagsThe 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 toolsclocknext_add_modelClockNext: add (enable) a modelAIdempotent
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 creditADestructiveIdempotent
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 outcomeADestructiveIdempotent
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 planADestructiveIdempotent
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 unitADestructiveIdempotent
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 creditARead-only
Get one credit type in full by id — pricing, token mapping and active state.
Inputs: id (required).
clocknext_get_customerClockNext: get customerARead-only
Fetch one customer by ClockNext id.
Inputs: id (required).
clocknext_get_customer_balancesClockNext: get customer balancesARead-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 planARead-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 usageARead-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 outcomeARead-only
Get one outcome type in full by id — its steps plus in-flight/completed stats.
Inputs: id (required).
clocknext_get_planClockNext: get planARead-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 unitARead-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 creditsARead-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 customersARead-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 outcomesARead-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 plansARead-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 unitsARead-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:
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, searchconceptfirst before touching any reference.api— the language-agnostic REST API reference (endpoints, params, request/response shapes). Use this to actually implement or call ClockNext from ANY language.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 creditAIdempotent
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 outcomeAIdempotent
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 planAIdempotent
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 unitAIdempotent
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
Scored across 35 tools
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.
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.
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.
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
Related MCP Connectors
Log hours and invoice clients from your AI chat. Time tracking and invoicing for freelancers.
Time tracking and invoicing for AI agents and their humans: track, log and bill work by agent.
Free client billing for AI assistants: hours, expenses, timers, invoices and payments.
Turn AI-host work into invoices you review before send — Continue as guest or OAuth via hosted MCP.
Related MCP Servers
AlicenseCqualityBmaintenanceConnects AI agents to Revenium for cost tracking, alerting, and usage-based billing, enabling AI assistants to manage costs, set alerts, and handle billing operations.7500 PyPIMIT- AlicenseNot gradedqualityCmaintenanceEnables creating, sending, and tracking invoices from MCP clients like Claude, Cursor, or Windsurf, using a hosted endpoint with API token.MIT
- FlicenseNot gradedqualityAmaintenanceEnables AI coding agents to add stablecoin checkout, payment links, payment status checks, webhook verification, and webhook-based access logic to applications through crypto payment APIs.-
- FlicenseNot gradedqualityAmaintenanceLets AI coding agents integrate crypto checkout, payment links, payment status checks, and webhook-based entitlements into applications.-