Skip to main content
The NeetoDesk MCP server lets your AI assistant manage your helpdesk from plain-language requests. Ask it to list tickets, reply to a customer, save a draft, or pull a performance report, and it works with your NeetoDesk workspace for you. MCP (Model Context Protocol) is an open standard that connects AI assistants to tools such as NeetoDesk. You describe the task; the assistant uses the right tool.

What you can do

Manage tickets

List, search, read, create, and update tickets.

Reply to customers

Post a reply or internal note, and save a draft on a ticket.

Run reports

Ticket volume, agent and group performance, and satisfaction surveys.

Hand off the busywork

Ask your assistant to triage a queue, draft a reply, or pull a performance report for you.

MCP vs CLI: which should I use?

NeetoDesk’s CLI reaches the same resources MCP does - tickets, comments and drafts, customers, forms, team members, and reports. The one thing it has no equivalent for is search, which looks through ticket subjects and the text of their comments. Past that, neither one can do more than the other, so choose on how the work reaches NeetoDesk.

Reach for MCP when

  • The details live in your chat, not in your head. A forwarded email thread, or a complaint pasted out of Slack, turns into a ticket with the customer, subject, and description already filled in. The CLI cannot see any of it.
  • You have not decided the steps yet. “The refund queue is a mess - sort it out” means reading a thirty-comment thread, judging whether the customer is still waiting, and only then picking a status. A command can only carry out a decision you have already made.
  • One request should cover several steps. Find the open tickets about failed card payments, summarize what each customer is asking for, and draft a holding reply on the oldest one, with no glue between commands.
  • The person doing it does not use a terminal. NeetoDesk 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 nightly cron entry that sweeps the pending queue runs the CLI with nothing but the binary and a saved session - 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 the bare ticket id with --quiet, or a data envelope with --json that goes straight into jq, a spreadsheet, or your own dashboard. 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 queue that long crowds out the assistant’s context. The CLI takes --page-size 100 and returns current_page_number, total_pages, total_records, and page_size alongside the tickets, so a shell loop walks the whole queue unattended and writes each page to a file or into jq - the size of the queue 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 neetodesk 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 posts a reply, changes a ticket’s status, or deactivates a team member. 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 NeetoDesk 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.