> ## Documentation Index > Fetch the complete documentation index at: https://apidocs.neetoengage.com/llms.txt > Use this file to discover all available pages before exploring further. # NeetoEngage MCP > Manage your NeetoEngage feature requests and changelogs from an AI assistant in plain language. 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](https://modelcontextprotocol.io) (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 Search for a similar request first, then add a vote or create a new request with a private note. List the voters on a request, or every request a customer voted for. Move a request to another track, attach a changelog, and email every voter. 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](/cli/introduction) 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`](/cli/ai-assistants) 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](/mcp/authentication). [Connect your assistant](/mcp/connect) to get started. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.