Skip to main content
The NeetoCal CLI (neetocal) lets you manage NeetoCal from your terminal. It covers the v2 REST API: list and create bookings, manage meetings and availability, run reports, and automate bulk changes. It is designed for people comfortable with a terminal or HTTP. You do not need to be a developer: run neetocal setup to connect an AI assistant such as Claude or Cursor, then describe the task in plain language.

​
Why use the CLI?

Script your scheduling

Create bookings, provision availabilities, and update meetings from shell scripts and cron jobs.

Audit from the terminal

Pull upcoming or past bookings, pipe them to jq, and create one-off reports without leaving your shell.

Change things in bulk

Page through thousands of bookings in one loop, update them unattended, and switch workspaces with a single flag.

Built for AI agents

Use token-efficient --toon output and one-command setup for Claude, Cursor, Copilot, and more.

​
CLI vs MCP: which should I use?

NeetoCal’s MCP server reaches the same resources the CLI does - meetings, bookings, availabilities, team members, and the rest. Neither one can do more than the other, so choose on how the work reaches NeetoCal.

​
Reach for the CLI when

  • No AI assistant should be in the loop. A cron entry or a CI step runs neetocal with nothing but the binary and the workspace you already signed in to - 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 booking id for the next command; --json returns records plus pagination for jq, a spreadsheet, or your own script. An assistant replies in prose you would have to copy out by hand.
  • You are working through thousands of records. Over MCP every page is a separate tool call, and a list that long crowds out the assistant’s context. The CLI pages on your terms instead: --page-size 100 with --json returns total_pages and total_records alongside the records, so a loop knows how many pages are left and walks all of them 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 list stops mattering.
  • The run has to be repeatable and reviewable. The command is the artifact: put it in a runbook or a pull request and it 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. An email, a thread, or a pasted note turns into the booking with no retyping. The CLI cannot see any of it.
  • You have not decided the steps yet. “Someone double-booked me on Thursday - 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. Check availability, pick a slot, book it, and record the reason, with no glue between commands.
  • The person doing it does not use a terminal. NeetoCal hosts the server, so there is nothing to install or keep updated.
You can have both. Run neetocal setup claude 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.

​
What you need

  1. Access to one or more NeetoCal workspaces.
  2. Permission to manage the resources you want to work with (meetings, bookings, team members, and so on).
  3. The neetocal binary. See Installation.
Unlike the API, which authenticates with an X-Api-Key header, the CLI signs you in through your browser and stores credentials locally. See Authentication.