Skip to main content
The NeetoKB MCP server lets your AI assistant work with your knowledge base from plain-language requests. Ask it to find an article, draft a new one, publish a change, share an unlisted link, or invite a teammate, and it works with your NeetoKB workspace for you. MCP (Model Context Protocol) is an open standard that connects AI assistants to tools such as NeetoKB. You describe the task; the assistant uses the right tool.

​
What you can do

Find articles

Search and browse published articles and drafts, and read their full content.

Write and publish

Create articles in a category, revise them, and move them between draft and published.

Share and manage

Generate unlisted links, browse the category tree, and invite team members.

Hand off the busywork

Ask your assistant to find a stale article, rewrite it, and publish it for you.

​
MCP vs CLI: which should I use?

NeetoKB’s CLI reaches the same resources MCP does - articles, unlisted links, categories, authors, recommendations, team members, and workspace settings. The one exception is small: only MCP can 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 MCP 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. The CLI wants the finished HTML from you, and it 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.

​
Reach for the CLI instead when

  • No AI assistant should be in the loop. A cron entry or a docs pipeline runs the CLI against a workspace it is already signed in to - no assistant open, no model account, no tokens spent per run. Every MCP call needs something with model access running.
  • The output feeds another program. The CLI prints a bare article id, or raw JSON with a pagination block, straight into jq, a spreadsheet, or your own script. Here you get prose you would have to copy out by hand.
  • You are sweeping the whole knowledge base. Here 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 returns total_pages and total_records next to the records, so a shell loop walks every page unattended and writes each one to a file or into jq - the size of the knowledge base stops mattering.
  • The run has to be repeatable and reviewable. A command is the artifact: it records exactly what ran and repeats identically in a runbook or a pull request. Ask twice here and the assistant may take a different route.
You can have both. Run neetokb setup claude and the same assistant drives the CLI for you, so a plain-language request still ends in an exact command you can read, repeat, and paste into a script.
Ask your assistant to show you what it plans to do before it creates, publishes, or removes anything. These tools act on your live workspace.

​
What you need

  • An AI assistant that supports MCP. Setup steps for Claude, ChatGPT, Claude Code, Codex, Cursor, Gemini CLI, VS Code with GitHub Copilot, Windsurf, and Antigravity are on Connect.
  • A NeetoKB API key, but only for workspace scoped access, and for Antigravity, where it is the only documented route. Every other client can sign you in over OAuth instead, which needs nothing beyond the server URL. See Authentication.
The choice decides what the assistant can reach: an OAuth connection acts as you and sees what you see, while an API key acts as the workspace and sees everything in it.
An OAuth connection is approved in the browser, much as the CLI signs you in, and you decide there whether the assistant may create, update, or delete. An API key is the same one the REST API uses, passed as a bearer token from your assistant’s config, and it carries every permission for the whole workspace.
Connect your assistant to get started.