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?
Script your publishing
Create articles, update their state, and share unlisted links from shell scripts and cron jobs.
Audit from the terminal
Search articles or list drafts, pipe them to
jq, and create one-off reports without leaving your shell.Change things in bulk
Page through thousands of articles in one loop, update them unattended, and switch workspaces with a single flag.
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: MCP can also read a published article from a knowledge base you are not signed in to. Otherwise neither one 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 CI step runs
neetokbwith nothing but the binary and 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.
--quietprints the bare article id for the next command;--jsonreturns records plus pagination forjq, a spreadsheet, or your own script. An assistant replies in prose you would have to copy out by hand. - You are working through thousands of records. Over MCP every page is a separate tool call, and a list that long crowds out the assistant’s context. The CLI pages on your terms instead:
--page-size 100with--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 list stops mattering. - You need the same run every time. A
neetokbcommand is plain text you can save. Drop it into a runbook or a pull request and anyone can read exactly what it will do before it runs, then run it later and get the identical call. An assistant works from a prompt rather than a fixed command, so the same request can come out as a different set of calls on a different day.
Reach for MCP instead when
- The details live in your chat, not in your head. A support thread, a customer email, or a pasted release note turns into the article body with no retyping. The CLI cannot see any of it.
- You have not decided the steps yet. “Our refund window moved to 30 days - fix whatever still says 14” means looking at what is there and choosing. A command can only carry out a decision you have already made.
- One request should cover several steps. Find the article, rewrite the stale paragraph, publish it, and share an unlisted link, with no glue between commands.
- The person doing it does not use a terminal. 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, unlisted links, 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.