> ## 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

> The neetodesk CLI brings tickets, comments, customers, forms, reports and team members to your terminal.

`neetodesk` is the command-line interface for NeetoDesk. It talks to the same
[external v2 API](/getting-started/introduction) the docs on this site describe, so anything
you can do over HTTP you can do from a shell, without writing a request by hand.

<CardGroup cols={2}>
  <Card title="Work without leaving the terminal" icon="terminal">
    List and triage tickets, post replies, save drafts and pull reports from the same window
    you already have open.
  </Card>

  <Card title="Script your workflows" icon="code">
    Every command emits JSON, so results pipe straight into `jq`, a shell script or a CI job.
  </Card>

  <Card title="Sign in through the browser" icon="key">
    `neetodesk login` authenticates against your workspace in a browser. There is no API key
    to copy or rotate.
  </Card>

  <Card title="Hand it to an AI assistant" icon="robot">
    `neetodesk setup` installs a NeetoDesk skill into Claude, Cursor, Codex, Copilot, Gemini
    or Windsurf.
  </Card>
</CardGroup>

## CLI vs MCP: which should I use?

NeetoDesk's [MCP server](/mcp/introduction) reaches the same resources the CLI does - tickets,
comments and drafts, customers, forms, team members and reports. It adds one thing the CLI has
no equivalent for: searching tickets by subject and by the text of their comments. Past that,
neither can do more than the other, so choose on how the work reaches NeetoDesk.

### Reach for the CLI when

* **No AI assistant should be in the loop.** A nightly cron entry that sweeps the pending queue
  runs `neetodesk` with nothing but the binary and the session you already signed in with - no
  assistant open, no model account, no tokens spent per run. Over MCP, something with model
  access has to be running before any call happens at all.
* **The output feeds another program.** `--quiet` prints the bare ticket id, so
  `ticket_id=$(neetodesk tickets create ... --quiet)` hands it straight to the next command.
  `--json` returns a `data` envelope for `jq`, a spreadsheet or your own dashboard -
  `neetodesk reports agents --range-type last_30_days --json` is a month of response times you
  can chart rather than read. An assistant replies in prose you would have to copy out by hand.
* **You are working through thousands of tickets.** Over MCP every page is a separate tool call,
  and a queue that long crowds out the assistant's context. The CLI pages on your terms instead:
  `--page-size 100` is the maximum, and `--json` returns `current_page_number`, `total_pages`,
  `total_records` and `page_size` alongside the tickets, so a loop knows how many are left and
  walks the whole queue unattended. Each page lands in a file or goes straight into `jq`, so
  nothing has to be held in memory and the size of the queue stops mattering.
* **The run has to be repeatable and reviewable.** The command is the artifact.
  `neetodesk tickets update 1042 --status resolved` in a runbook, or
  `neetodesk team-members delete <id>` in an offboarding checklist, says exactly what it will do
  before anyone runs it and makes the identical call next time. Ask twice over MCP and the
  assistant may take a different route.

### Reach for MCP instead 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.

<Tip>
  You can have both. Run [`neetodesk setup claude`](/cli/ai-assistants) and your AI assistant
  drives the CLI itself, so a plain-language request still ends in an exact command you can
  read, repeat and paste into a script.
</Tip>

## Prerequisites

* A NeetoDesk workspace and your workspace subdomain. See
  [Workspace subdomain](/getting-started/workspace-subdomain) if you are not sure what yours is.
* An account on that workspace. The CLI acts as you, so it can reach exactly the tickets your
  role allows.

## Next steps

<CardGroup cols={2}>
  <Card title="Installation" icon="download" href="/cli/installation">
    Install the CLI on macOS, Linux or Windows.
  </Card>

  <Card title="Authentication" icon="lock" href="/cli/authentication">
    Sign in, switch between workspaces and sign out.
  </Card>

  <Card title="Commands overview" icon="list" href="/cli-reference/overview">
    Every command grouped by resource.
  </Card>

  <Card title="Output formats" icon="brackets-curly" href="/cli/output-formats">
    Tables, JSON, TOON and the quiet mode.
  </Card>
</CardGroup>