> ## Documentation Index
> Fetch the complete documentation index at: https://apidocs.neetodesk.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Introduction
> Connect an AI assistant to your NeetoDesk workspace over the Model Context Protocol.
NeetoDesk runs a hosted MCP server. Connecting an assistant to it lets you work on tickets by
asking in plain language, rather than switching to the web app or writing API calls.
Model Context Protocol is an open standard for exposing an application's data and actions to an
AI assistant. You do not need to know how it works to use it, and there is nothing to run or
host yourself.
## What an assistant can do
| Resource | Abilities |
| ------------------- | ----------------------------------------------------------------------------------- |
| Tickets | List, search, read, create and update tickets |
| Comments and drafts | List and read comments, post a reply or internal note, save a draft |
| Customers | Create a customer |
| Team members | List, read, invite, update and deactivate members |
| Forms | List the workspace's enabled web forms |
| Reports | Ticket volume, daily time series, agent and group performance, satisfaction surveys |
The full list, with what each tool does, is on the [Tools](/mcp/tools) page.
## MCP vs CLI: which should I use?
NeetoDesk's [CLI](/cli/introduction) reaches the same resources this server 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 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. `neetodesk tickets create` needs you to type `--email`, `--subject` and
`--description` yourself, because 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.** A support lead who works in the web app all
day can connect their assistant and start asking. 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 call made here needs something with model access
running first.
* **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 tickets.** 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 says exactly
what it will do before anyone runs it, and repeats identically. Ask twice here and the
assistant may take a different route.
You can have both. Run [`neetodesk 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.
These tools act on your live workspace. Ask your assistant to show you what it plans to do
before it posts a reply the customer will read, changes a ticket's status or deactivates a
team member.
## Prerequisites
* A NeetoDesk workspace and an account on it.
* An AI assistant that supports remote MCP servers. See [Connect](/mcp/connect) for the ones
covered here.
* Optionally, a NeetoDesk API key. A key is needed only for workspace-scoped access. Every
client listed on the Connect page can sign in with OAuth instead, so most people need no key
at all.
## Which credential to use
This is a permissions boundary, not a setup preference, so it is worth deciding up front:
| | OAuth | API key |
| --------- | -------------------------- | -------------------------------- |
| Scope | The person who approved it | The whole workspace |
| Identity | A NeetoDesk user | None |
| Set up by | Pasting the server URL | Pasting a key into a config file |
[Authentication](/mcp/authentication) explains what each one can reach and why.
## Next steps
OAuth, API keys and what each can see.
Per-client setup for Claude, ChatGPT, Cursor and the rest.
Prompts to try once you are connected.
Every tool the server exposes.