> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trycaesar.com/llms.txt
> Use this file to discover all available pages before exploring further.
# CLI vs MCP for agents
> Choose Caesar's CLI, remote MCP server, or both for an agent workflow.
Agents can use Caesar through the [CLI](/clients/cli/install), the [remote MCP server](/clients/mcp/remote), or both. If the agent has shell access, start with the CLI. Use MCP when the client is built around remote tools or cannot run local commands.
Caesar's MCP server is intentionally small: two tools, `web_search` and `web_fetch`. That keeps its schema cost bounded. The broader MCP vs CLI tradeoff still matters when an agent session loads many MCP servers: tool schemas compete with task context, while CLI access is more progressive — the agent sees a short instruction, runs a command, and only then receives output.
## Quick answer
| Choose | When | Why |
| ------ | --------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| CLI | The agent has shell access, can write files, or runs in CI | Lowest context overhead, explicit exit codes, `--json`, and `-o` file capture for large outputs |
| MCP | The agent runs in a chat or IDE client with remote tool support | No local binary, discoverable tools, structured calls, and centralized auth |
| Both | The agent can use tools and shell commands | MCP gives easy interactive access; CLI handles scripts, artifacts, and repeatable automation |
For Claude Code and other coding agents with a shell, start with the CLI or the Caesar skill. For Cursor, Windsurf, and chat clients that already manage MCP servers, start with MCP.
## What changes for the agent
The agent runs `caesar-search`, reads stdout/stderr, checks exit codes, and can save JSON to files with `-o`.
The client connects to Caesar's remote server and exposes `web_search` and `web_fetch` as structured tools.
## Use the CLI when
* The agent can run shell commands.
* You want a lean prompt: a short skill or instruction can teach the command without loading tool schemas into every turn.
* You want deterministic scripting behavior: exit codes, stderr error envelopes, and `--json` output.
* Large search results should be written to a file instead of pasted into the chat context.
* The workflow is part of CI, a local script, or a repeatable terminal task.
* You want the same commands a human can run and debug.
* You want to restrict the agent's tool surface by documenting only the commands it should use.
Start here:
Install `caesar-search` with Homebrew, npm, or the standalone installer.
Search, read, feedback, JSON output, and exit codes.
Use `caesar-search` in scripts, schedulers, and CI pipelines.
## Use MCP when
* The agent client already supports remote MCP tools.
* You want a no-binary setup for a chat or IDE assistant.
* The client should discover the available Caesar tools instead of being prompted with shell commands.
* Auth should live in the MCP client configuration.
* The workflow is interactive and only needs search and read.
* The agent does not have a shell, or shell access is intentionally disabled.
MCP exposes exactly two tools: `web_search` and `web_fetch`. Feedback is REST, CLI, and SDK only.
Connect any MCP client to Caesar's hosted streamable-HTTP server.
## Use both when
Many agent setups benefit from both surfaces:
* MCP for quick interactive search and read inside the client.
* CLI for scripted runs, saved JSON artifacts, and commands the agent can replay outside the chat.
* Skills for coding agents that need durable instructions about when to choose each path.
The Caesar skill uses the CLI when available because shell agents handle command output and files well. MCP remains the better first choice for clients whose native integration model is remote tools.
## Keep the tool surface lean
For shell-capable agents, a small instruction file plus the CLI is often enough:
```text theme={"system"}
Use caesar-search for web search and document reads.
Prefer --json for machine output.
Use -o for large responses.
Never pass literal API keys; use CAESAR_API_KEY.
```
That is the Caesar version of progressive disclosure: document the command and constraints, then let the agent call the tool when the task needs it. Avoid giving an agent every possible surface at once. If the agent only needs search and read, install the Caesar skill or CLI; add MCP only when the client benefits from remote tool discovery.
## Decision checklist
| Question | Lean CLI | Lean MCP |
| ------------------------------------------------------------------------- | -------- | -------- |
| Does the agent have shell access? | yes | no |
| Does the workflow need `-o` files or CI artifacts? | yes | no |
| Does the client already manage MCP servers? | optional | yes |
| Does the workflow need only search and read? | either | yes |
| Does it need CLI-style automation, exit codes, or raw API escape hatches? | yes | no |
| Is the session already loaded with many MCP servers? | yes | no |
| Do you need dynamic tool discovery? | no | yes |
## External context
The broader MCP vs CLI discussion usually lands on a practical split: CLI is strongest for lean local or scripted work, MCP is strongest for structured remote tool access in clients that support it, and mature agent setups often use both. Recent critiques of MCP make the context-cost point more forcefully; for Caesar, that means defaulting shell agents to the CLI while keeping the small remote MCP server available for MCP-native clients.
* [CircleCI: MCP vs. CLI for AI-native development](https://circleci.com/blog/mcp-vs-cli/)
* [IBM Community: MCP vs CLI](https://community.ibm.com/community/user/blogs/jia-qi/2026/04/08/mcp-vs-cli)