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 issearch, 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 adataenvelope with--jsonthat goes straight intojq, 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 100and returnscurrent_page_number,total_pages,total_records, andpage_sizealongside the tickets, so a shell loop walks the whole queue unattended and writes each page to a file or intojq- 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.
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.
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.