API vs MCP: when to use which

Jasning exposes two ways to drive the dispatch board from outside the web UI: the REST API and the MCP server. They serve different jobs.

This page is for when you're picking between them.

TL;DR

• MCP is for AI assistants. You connect once, your assistant decides which tools to call, and you talk to it in English.
• REST API is for code you write. You authenticate with a token, call endpoints yourself, parse the JSON.

If you're an end user dispatching by chat, you want MCP. If you're a developer building automation, you might want the API. Many setups use both.

When to use MCP

• You want to plan by chatting with Claude, ChatGPT, Cursor, or any MCP client.
• You want the assistant to decide which tool to call. It will pick appointments-list vs availability-suggest based on what you asked.
• You're building agent workflows that combine Jasning with other MCP servers (calendars, email, knowledge bases). MCP composes; REST doesn't.
• You want auth handled by OAuth, no token management in your code.

When to use the REST API

• You're writing a script or background job. Deterministic input, deterministic output.
• You need to do something with a result that the assistant can't help with (compute a precise checksum, write to a database, post to Slack with custom formatting).
• You need predictable latency. The REST API is one HTTP call. MCP wraps tool calls in an assistant's reasoning loop. That adds tokens, time, and the occasional surprise.
• You don't want a model in the loop at all.

What overlaps

The two interfaces sit on top of the same underlying logic. An appointment created via MCP looks identical to one created via REST. Same model, same constraints, same audit trail.

So you can mix freely: a cron job that imports appointments via REST, plus a dispatcher who chats with Claude over MCP, plus the dispatcher's colleague who drags cards on the board. All three see the same data, instantly.

Authentication

• MCP: OAuth 2.1 + PKCE. The assistant initiates the flow; the user grants access in a browser. Token is scoped to the account; no further key management.
• REST API: Personal access token, generated in Settings → Tokens. Long-lived, revocable, scoped to the account that minted it.

Both auth methods grant the same level of access (everything you can do in the UI). The audit trail records which method touched each record.

Shape

• MCP offers tools by name with structured arguments. Tool names are stable: appointments-list, appointments-create, etc. See the MCP tool reference.
• REST API offers endpoints by URL. GET /api/v1/appointments, POST /api/v1/customers, etc. Documented separately.

The shape of the data is the same. An MCP appointments-list response and a REST GET /appointments response carry the same fields.

Latency and rate limits

• MCP rate limit is generous for interactive use, tight for bulk. A few calls per second per token.
• REST API rate limit is higher for bulk work. Documented in the API reference.

If you find yourself wanting bulk loads through MCP, switch to REST for that workflow.

A worked example

You run a 5-person cleaning crew. You import next month's recurring rounds from an old Excel file:

• REST API is right for this. Loop through the spreadsheet, POST each appointment. Deterministic, fast, no model in the loop.

You take a phone call mid-day from a customer asking to reschedule:

• MCP is right for this. Open Claude, "move the De Vos appointment from Thursday to next Monday at the same time". One sentence, board updates.

You set up a Friday-afternoon report:

• Either works. REST is more efficient. MCP is more flexible if you want the AI to write the report prose for you, not just pull the data.

Both at once

Nothing stops you. We see setups where:

• A nightly REST job loads recurring jobs from a payroll system
• Claude over MCP handles all day-to-day adjustments
• A dashboard polls REST endpoints for occupancy stats

Same account, three interfaces, one source of truth.