NeetoRecord MCP

The NeetoRecord MCP server lets your AI assistant work with your recordings from plain-language requests. Ask it to search recordings by what was said in them, read a transcript, pull a screenshot, or create a share link, and it works with your NeetoRecord workspace for you. MCP (Model Context Protocol) is an open standard that connects AI assistants to tools such as NeetoRecord. You describe the task; the assistant uses the right tool.

​

What you can do

​

MCP vs CLI: which should I use?

NeetoRecord’s CLI reaches nearly everything this server reaches - recordings, transcripts, chapters, folders, tags, CTAs, analytics, and recording requests. Two gaps are real: only this server reads a publicly shared recording that lives in someone else’s workspace, and only the CLI manages team members. Everywhere else the two overlap, so choose on how the work reaches NeetoRecord.

​

Reach for MCP when

• The details live in your chat, not in your head. A pasted support thread becomes the recording’s summary, its tags, or the label and link on a CTA, with no retyping. The CLI cannot see any of it.
• You have not decided the steps yet. “Something in last week’s demos worries me - find out what” means listening to what is there and judging what matters. A command can only carry out a decision you have already made.
• One request should cover several steps. Start the transcript, wait for it to finish, generate chapters from it, then write the summary onto the recording. Here that is a single ask; with the CLI you write the polling loop that sits between trigger-transcript and transcript-status.
• The person doing it does not use a terminal. NeetoRecord hosts this 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 CI step runs the CLI with nothing but the binary and 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 first.
• The output feeds another program. The CLI prints a bare identifier after a create, and raw JSON with a pagination block for jq, a spreadsheet, or your own script. Here you get prose you would have to copy out by hand.
• You are working through thousands of records. Re-tagging or re-foldering hundreds of recordings is one call per recording either way, but here each of those is a separate tool call, and every page of results crowds out the assistant’s context. The CLI reports total_pages and total_records beside the records, so a shell loop walks all of them unattended and writes each page to a file or into jq. The size of the library 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.

​

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 NeetoRecord 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. Connect your assistant to get started.