Skip to main content
The NeetoEngage MCP server lets your AI assistant manage feedback from plain-language requests. Ask it to file a customer’s request, list who voted for a feature, or tell voters a feature has shipped, and it works with your NeetoEngage workspace for you. MCP (Model Context Protocol) is an open standard that connects AI assistants to tools such as NeetoEngage. You describe the task; the assistant uses the right tool.

​
What you can do

File feature requests

Search for a similar request first, then add a vote or create a new request with a private note.

See who voted

List the voters on a request, or every request a customer voted for.

Move requests and tell voters

Move a request to another track, attach a changelog, and email every voter.

Hand off the busywork

Ask your assistant to file the request from a support ticket and give you the link.

​
MCP vs CLI: which should I use?

NeetoEngage’s CLI reaches the same resources MCP does - feature requests, voters, tracks, changelogs, and settings. Neither one can do more than the other, so choose on how the work reaches NeetoEngage.

​
Reach for MCP when

  • The details live in your chat, not in your head. An email, a thread, or a pasted note turns into a feature request with no retyping. The CLI cannot see any of it.
  • You have not decided the steps yet. “A customer asked for something we may already track - check and sort it out” 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. Search for a similar request, add a vote or create a new one, and write the private note, with no glue between commands.
  • The person doing it does not use a terminal. NeetoEngage 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 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.
  • The output feeds another program. The CLI prints a bare identifier or raw JSON 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. Here every page is a separate tool call, and a list that long crowds out the assistant’s context. The CLI returns total_pages 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 list stops mattering.
  • The run has to be repeatable and reviewable. A command is the artifact: it records exactly what ran and repeats identically. Ask twice here and the assistant may take a different route.
You can have both. Run neetoengage 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 files, moves, or comments on anything. These tools act on your live workspace.

​
What you need

  • An AI assistant that supports MCP, such as Claude, ChatGPT, Claude Code, Codex, Cursor, Gemini CLI, VS Code with GitHub Copilot, Windsurf, or Antigravity.
  • A NeetoEngage account. You need an API key only if the assistant must reach the whole workspace, or if you use Antigravity. See Authentication.
Connect your assistant to get started.