We shipped a command-line tool for Tallyfy this week, and the quickest way to explain why is a confession: our own MCP surface refuses to do bulk work. On purpose.

Four doors into the same engine

The API vs MCP vs CLI question comes up in most technical evaluations we join now, and it’s usually asked as if the three were competing products. They aren’t. At Tallyfy they’re doors into the same engine: templates that define your processes, running instances launched from those templates, tasks with owners and deadlines, and the audit trail underneath it all. Every door reads and writes the same objects. What changes is who’s operating, how much judgment the work needs, and how many times it will repeat.

The web UI is the first door, and for most people the only one. A person completing today’s tasks, deciding an exception, approving a purchase: that’s UI work, and no automation surface should take it away from them.

The other three doors exist for machines. That’s where teams pick wrong, and a wrong pick gets expensive in ways that surface months later: a half-built integration nobody maintains, an AI agent assigned a job one cron line could do, a script scraping a UI that was never meant to be scraped.

One vocabulary note before the tour, because it trips people up. Tallyfy’s UI says “blueprint” and “process” while the raw API says “checklist” and “run” for the same two objects. The CLI leads with the UI words and treats the API words as aliases, so tallyfy blueprint list and tallyfy checklist list land on the same command. Small choice, saves real confusion.

So here’s each machine door, plainly, including the part where our own product tells you no.

When does the REST API earn its keep?

Pick the REST API when Tallyfy should disappear inside something you’re building. Your customer portal launches an onboarding process the moment a deal closes. Your internal admin panel shows open tasks next to data from your own systems. Or you’re a software company that wants workflow state in your product while your users never see our logo at all. That’s API territory: you write the code, you own the screens, and webhooks push events back into your stack as tasks complete and processes move.

The API is also where you pay for that control. Authentication, pagination, retries, rate limits: yours to handle, in code you maintain. For a developer building a durable integration that trade is fine, sort of the whole point. For a one-off job it’s overhead you don’t need, and for an AI assistant it’s a bad fit for a different reason, which is that models burn reasoning tokens juggling URL structures and auth headers instead of thinking about the task.

We compared the protocol layers in depth in MCP, AI agents, and REST APIs compared, so the short version will do here: MCP wraps APIs so models can discover them, and the API underneath still does the lifting. Nothing in this post changes that. This post answers the question that comes after it: which surface do you script against on Tuesday?

MCP is for conversations, not conveyor belts

Pick MCP when a person is mid-conversation with an AI assistant and Tallyfy should sit within reach of that conversation. Model Context Protocol is an open standard for exactly that: servers describe their tools, models discover and call them, and every message rides JSON-RPC 2.0, a stateless remote-procedure format that refuses to die. The protocol now runs under a formal open-governance model as a Series of LF Projects, LLC, with named lead maintainers and Apache 2.0 licensing rather than one vendor’s roadmap. And the MCP specification is blunt about the trust model: hosts must get explicit user consent before invoking any tool. Which, given what tools can do, is the bare minimum.

Connect ChatGPT, Claude, Gemini, or Copilot Studio to Tallyfy’s MCP server and the assistant gets more than 100 tools: search tasks, launch a process, tidy a template, check what’s overdue for whom. We wrote a full walkthrough in how AI agents manage workflows through Tallyfy MCP, so there’s no need to repeat the tour.

What we want to do instead is tell you what that surface won’t do, because nobody advertises this part.

Our hosted agent lane runs a hard budget of 15 tool calls per query. Its standing orders also carry a rule we’ll quote almost verbatim: for any operation affecting more than 5 items, refuse to proceed in bulk. Ask the user to name a subset of up to 5, or break the work into batches and approve each one. A single yes or no confirmation doesn’t clear a bulk destructive change. Archive 200 stale processes? The agent stops at five and asks you to name names.

The early build didn’t have this guard. An agent would cheerfully attempt whatever batch size a conversation implied. An OWASP-driven security review changed our minds: the tool-call budget went in as code, and the bulk refusal went into the agent’s standing instructions, alongside the rule that confirmation theater doesn’t count as consent.

The strictness has a reason, and it’s statistical rather than paranoid. A language model is a probabilistic actor. Ninety-nine clean runs tell you little about the hundredth, and the hundredth might land at 2am inside a compliance workflow. When a person fat-fingers a bulk action in the UI they usually notice mid-click. When an agent misreads “archive the stale ones,” the damage scales with whatever it’s allowed to touch. Keeping every batch small keeps every mistake small, and it keeps a person in the loop precisely where consent matters most, on destructive writes. That tracks with how the spec itself thinks about tool safety, and it’s the design stance we’d pick again.

Could we raise the caps? Sure, it’s an environment variable. We won’t.

So the confession pays off in a practical way: the AI door refuses bulk on purpose, which means bulk work needs somewhere else to live. For a while our answer was “use the API, write a script.” True, and a little clunky as answers go. Now there’s a proper door.

Use the CLI when the work must be boring

Pick the CLI for work that repeats, runs unattended, or has to be provable afterwards. The tallyfy CLI shipped yesterday: v0.1.0, tagged July 16, 2026. One static Go binary per platform across macOS, Windows, and Linux. Install it with brew install tallyfy/tap/tallyfy or grab a checksum-verified download from GitHub Releases. It exposes 23 top-level commands, and because it’s this new we can’t hand you adoption numbers or teams-saved-X-hours stories. Nobody has had it long enough. What we can tell you is the design brief, because it’s the one thing the other doors can’t satisfy: determinism.

A script calling the CLI produces the same API calls in the same order on every run. There’s no model in the loop and no interpretation step between your script and the engine. Output arrives as a table for humans or as json, csv, or ndjson for pipes, so tallyfy process list -o json drops straight into jq. A --dry-run flag prints the API calls a command would make without executing anything. A --no-input flag makes the CLI fail rather than prompt, which is what you want in CI, and it flips on automatically when no terminal is attached. Exit codes are specific, 5 for not-found and 7 for a validation failure, so a pipeline can branch on what went wrong instead of parsing error text. Aanand Prasad, Ben Firshman, Carl Tashian, and Eva Parish wrote up these expectations in the Command Line Interface Guidelines: small composable programs, plain-text pipes, exit codes a script can branch on. We tried to build a well-behaved citizen of that world.

Boring is a feature.

And bulk is the point. tallyfy process launch starts one process or many from a CSV file. tallyfy blueprint export writes a template to git-committable JSON, and blueprint import promotes it into another organization, which turns workflow definitions into reviewable pull requests instead of clicks nobody can replay. The counterintuitive part is that this door carries almost none of the guardrails the MCP door has, and that’s correct. A script gets written once, reviewed by a person, and versioned. When it launches 300 processes, those are 300 intended launches with a git blame attached. Intent lives in the diff. The agent lane can’t offer that kind of paper trail for its own reasoning, so it gets caps instead.

There’s a small poetry in how the two doors meet: the CLI ships a tallyfy mcp command that manages MCP server entries for a project and prints ready-made config blocks for AI clients. The deterministic door configures the conversational one.

The command we’d point CI teams at first is tallyfy task wait, which blocks until a named task completes. Put a human approval step in a Tallyfy process, call task wait from your deployment pipeline, and the pipeline holds until someone with authority clicks approve, with the sign-off recorded in the process’s audit trail rather than buried in a chat scroll. Deploy gates, invoice releases, access grants: any pipeline step that needs a person now has a wire to wait on.

For what it’s worth, the CLI also carries an api subcommand, tallyfy api GET me and friends, which sends raw authenticated requests with the standard headers and retry policy applied. Even after you outgrow the packaged commands, you keep the credential handling, which stores tokens in the OS keychain with an AES-256-GCM encrypted file as fallback. Its configuration system, six settings scopes with a deny-wins permission engine, got a separate write-up in how Claude Code’s configuration architecture shaped our CLI.

Pick your door in 30 seconds

One correction before the table. Earlier we said the MCP lane refuses bulk. Sharper: it refuses bulk changes. It will happily read a hundred tasks and summarize them inside its call budget; the refusal triggers when an operation would modify more than 5 records, with deletions, archivals, and role changes called out by name. Reads are budgeted. Writes are guarded.

With that distinction in hand:

Two patterns mix doors well. First: agent proposes, script executes. An assistant reads a messy request over MCP, works out which blueprint applies, and suggests the exact CLI line; a person reviews it and runs it, so the probabilistic step and the bulk step never share a door. Second: API feeds, CLI acts. Webhooks stream events into your systems all day, and a scheduled CLI job does the heavy maintenance at night when nobody’s watching.

Do you need all four? No. Most teams live in the UI plus one machine door, and that’s healthy. The guide exists to stop the two failure patterns we keep meeting: engineers hand-building API integrations for jobs one CLI line covers, and AI enthusiasts pushing a conversation surface toward batch work it’s built to refuse.

Same engine, whichever door you choose

After kicking this around with the team, the pattern that stuck with us has nothing to do with surfaces. The doors are worthless without the building behind them. A process that lives in someone’s head can’t be launched from a CSV, embedded in your product, gated in a pipeline, or handed to an agent. Write it down as a template and every door opens onto it at once: same steps, same owners, same audit trail, whether the caller was a browser click, a POST request, a model mid-conversation, or a cron job at 3am.

That’s the real answer to the API vs MCP vs CLI question. It’s a routing decision, and routing decisions get cheap once the thing being routed to exists. Define the workflow first. Then pick a door per job, and switch doors freely whenever the job changes shape.