neetokb) lets you manage NeetoKB from your terminal. It covers the v2 REST API: list and search articles, create and publish content, browse the category tree, share unlisted links, and manage team members.
It is designed for people comfortable with a terminal or HTTP. You do not need to be a developer: run neetokb setup to connect an AI assistant such as Claude or Cursor, then describe the task in plain language.
Why use the CLI?
Publish from scripts
Create and update articles from shell scripts, cron jobs, and content pipelines instead of the editor.
Audit your knowledge base
Search articles, list drafts, and pipe the results to
jq to build one-off content reports.Manage many workspaces
Sign in to multiple workspaces at once and target any of them with a single flag - no browser switching.
Built for AI agents
Use token-efficient
--toon output and one-command setup for Claude, Cursor, Copilot, and more.CLI vs MCP: which should I use?
NeetoKB’s MCP server reaches the same resources the CLI does - articles, unlisted links, categories, authors, recommendations, team members, and workspace settings. The one exception is small: MCP can also read a published article from a knowledge base you are not signed in to. Otherwise neither side can do more than the other, so choose on how the work reaches NeetoKB.Reach for the CLI when
- No AI assistant should be in the loop. A cron entry or a docs pipeline runs
neetokbagainst the workspace you already signed in to - no assistant open, no model account, no tokens spent per run. Over MCP, something with model access has to be running before any call happens at all. - The output feeds another program.
neetokb articles create ... --quietprints the bare article id for the next command;--jsonreturns the records plus apaginationblock forjq, a spreadsheet, or your own script. An assistant replies in prose you would have to copy out by hand. - You are sweeping the whole knowledge base. Over MCP every page is a separate tool call, and a thousand article titles crowd out the assistant’s context long before the audit is finished. The CLI pages on your terms instead:
neetokb articles list --page-size 100 --jsonreturnstotal_pagesandtotal_recordsalongside the records, so a loop knows how many pages are left and walks all of them unattended. Each page lands in a file or goes straight intojq, so nothing has to be held in memory and the size of the knowledge base stops mattering. - The run has to be repeatable and reviewable. The command is the artifact: put
neetokb articles update <id> --state publishedin a runbook or a pull request and it makes the identical call next time. Ask twice over MCP and the assistant may take a different route.
Reach for MCP instead when
- The words live in your chat, not in your head. A support thread, a customer email, or a pasted release note becomes the article body with no retyping and no hand-written markup.
neetokb articles create --html-contentwants the finished HTML from you, and the CLI cannot see the conversation it should come from. - You have not decided the steps yet. “Our refund window moved to 30 days - fix whatever still says 14” means searching, reading each hit, and judging which ones are genuinely wrong. A command can only carry out a decision you have already made.
- One request should cover several steps. Find the article, read what it says today, rewrite only the paragraph that is stale, publish it, and hand back an unlisted link for a colleague to check. A script can pass an article id from one command to the next, but it cannot read the body and work out what to change in it.
- The person doing it does not use a terminal. A support lead or a writer can keep the knowledge base current from a chat window. NeetoKB hosts the server, so there is nothing to install or keep updated.
What you need
- Access to one or more NeetoKB workspaces.
- Permission to manage the resources you want to work with (articles, categories, team members, and so on).
- The
neetokbbinary. See Installation.
Unlike the API, which authenticates with an
X-Api-Key header, the CLI signs
you in through your browser and stores credentials locally. See
Authentication.