PDF didn't stop evolving because it was perfect, it stopped because Adobe won

Alexandros Gounis — Tue, 30 Jun 2026 15:38:02 +0000

My bank requested 17 PDF documents for my mortgage application.

I was drowning in files and spent most of my time opening and closing tabs rather than actually reading them. That's when I came across Adobe's PDF Portfolio, which allows groupping multiple PDF files into a single bundle.

However, Adobe's portfolio implementation modifies the page tree. Standard viewers (Chrome or Preview) only see a generic cover page, forcing you to use Acrobat to actually access the rest of the pages. On top of that, modifying or creating these bundles requires a paid Acrobat subscription or a lot of manual work.

So I asked myself: what if I could scroll horizontally to see the pages of a file, and vertically to see more files, without touching the page tree?

I achieved this by embedding a small JSON manifest and bundling all documents sequentially into the main page tree. This produces a backwards-compatible PDF file.

In standard viewers (Chrome, Acrobat, Preview): It reads smoothly as a single, continuous document.
In the desktop app: (I called it PDFx) It parses the JSON metadata and renders the files onto a free-floating 2D canvas for batch processing.

The embedded JSON manifest maps where individual documents start and end and it’s a tiny metadata structure that scales well and adds negligible bytes to the bundle. To demonstrate the UX improvements, I coupled the spec extension with an open-source, cross-platform desktop client built with Electron and React (utilizing native Objective-C++ overrides to keep the window properties feeling premium and performant).

The project is open-source with an MIT license:
https://github.com/AlexandrosGounis/pdfx

I would highly appreciate your architectural feedback on the spec extension. My frustration with Adobe is the lack of evolution and the locked specs that require Acrobat Pro to take full advantage of.

MCP Is Costing You 37% More Tokens Than Necessary

Alexandros Gounis — Thu, 19 Mar 2026 13:50:44 +0000

The Problem

MCP is powerful, but there's a cost issue that is often neglected.

MCP servers contain tools, and each tool comes with a JSON schema. As more tools are added, input token usage increases significantly.

Every MCP request sends the full JSON schema for every registered tool, including the ones the model won't actaully use. There has to be a more efficient way to do this.

I built a tool called clifast that converts functions into CLI commands and I benchmarked exactly how much MCP costs vs. a CLI approach. Here's the repository, so you can test it yourself.

With just 5 tools:

37% more input tokens
74% larger tool definitions
it scales linearly

The Analysis

MCP tool discovery works like this:

your client calls listTools()
gets back full JSON schemas for every tool
converts them to the Anthropic format
sends all of them on every API call. No caching, no partial loading.

The CLI alternative: one generic run_command tool with a text description of available commands. Fixed size regardless of how many commands you have.

Two approaches, same result

Both approaches use the same weather API, same model, same prompt. The only difference is how tools are presented to Claude.

MCP — 5 individual tools, each with a full Zod schema:

server.registerTool("get_forecast", {
  description: "Get daily weather forecast for a location for 1 to 3 days ahead",
  inputSchema: {
    location: z.string().describe("City name or location"),
    days: z.number().min(1).max(3).default(3).describe("Number of days to forecast (1-3)"),
  },
}, async ({ location, days }) => {
  const data = await fetchWeatherData(location);
  if (!data) return errorResponse("Weather API error");
  return successResponse({ /* ... */ });
});

// ... repeat for all 5 tools

CLI — one tool, plain text description:

const weatherCliToolDefinition: Anthropic.Messages.Tool = {
  name: "run_command",
  description: `Run a weather CLI command. Available commands:
  getCurrentWeather <location>
  getForecast <location> [days]
  getHourlyForecast <location> [day]
  getAstronomy <location>
  getWindAndPressure <location>`,
  input_schema: {
    type: "object",
    properties: {
      command: { type: "string", description: "Command name" },
      arguments: { type: "array", items: { type: "string" }, description: "Command arguments" },
    },
    required: ["command", "arguments"],
  },
};

The CLI tools are generated from plain TypeScript exports using clifast:

export async function getCurrentWeather(location: string) { /* ... */ }
export async function getForecast(location: string, days: string = "3") { /* ... */ }
export async function getHourlyForecast(location: string, day: string = "0") { /* ... */ }
export async function getAstronomy(location: string) { /* ... */ }
export async function getWindAndPressure(location: string) { /* ... */ }

One command generates the CLI:

npx clifast generate cli/get-weather.ts -y

Results

Metric	CLI	MCP	Difference
Input tokens	1,498	2,368	CLI uses 37% fewer
Output tokens	228	230	Roughly equal
Total tokens	1,726	2,598	CLI uses 34% fewer
Latency	7.3s	7.1s	Comparable
Tool definition size	479 B	1,851 B	CLI is 74% smaller

Benchmarked on claude-sonnet-4-6. Both produced equivalent, correct answers. The token gap comes entirely from tool definitions sent on each request.

The scaling math:

MCP grows linearly: each new tool adds its full schema to every request.
CLI stays constant: adding a command is one more line of text.
At 20 tools, you're looking at ~4x the schema overhead on every single API call, across every turn of the conversation.

The hallucination risk (and how to mitigate it)

Let's be honest, the CLI approach trades schema precision for token efficiency. With MCP, Claude gets structured type information for every parameter. With CLI, it reads a text description and could hallucinate a command that doesn't exist or pass wrong argument types.

In practice, models like Claude are really good at understanding prompt intent. But if you need stronger guarantees:

Group by domain: instead of one mega-tool with 50 commands, create a few CLI tools per domain (run_weather_command, run_billing_command). You still get massive token savings over MCP while reducing the hallucination surface.
Validate before execution: check the command name against a known list before running it. Return a clear error if it doesn't match.
Be specific in descriptions: include argument types and constraints in the text (Claude respects these).

The sweet spot is usually 5-15 commands per CLI tool. Enough to save tokens, few enough that the model doesn't get confused.

When to use which

Use MCP when interoperability matters: shared tool servers consumed by multiple clients, strict parameter validation, or when you need the ecosystem.

Use CLI when cost and speed matter: high-volume production, many tools per agent, token-constrained budgets, or when you control the full stack.

They're not mutually exclusive. You can use MCP for discovery and path execution through CLI tools (mix and match).

Try it yourself

Benchmark repository: https://github.com/AlexandrosGounis/mcp-vs-cli.git

The benchmark outputs a timestamped JSON report and prints the full comparison to stdout. MCP is a great protocol. But abstractions have costs, and in AI tooling, those costs show up on every request. Measure yours.

DEV Community: Alexandros Gounis