This year I did couple of "LLM harness" corporate trainings. My unique twist on LLM training is trying to explain how LLM harnesses work. By harness I mean claude code, opencode and codex - not LLM itself. One thing made explicitly clear in those trainings is that MCP usage is highly discouraged. 

MCP protocol creators, Anthropic, lay out issues with MCP in their [Code execution with MCP: building more efficient AI agents](https://www.anthropic.com/engineering/code-execution-with-mcp) very clearly. In short I can describe those as:

1. Massive Token Bloat
2. Context Window Overload
3. Error-Prone Data Handling
4. Inefficient Architecture

Some of these issues have been mitigated by now. But shity protocol is a shitty protocol - no amount of patching will suddenly turn it into a fantastic one. 

I use [OpenCode](https://opencode.ai) as my primary harness and had two MCP services left configured ([githits](https://githits.com/) and [chrome_devtools](https://github.com/mcp/chromedevtools/chrome-devtools-mcp)) mostly due to time constraints. Since there was some free time on my hands, I took a closer look. For chrome devtools it was as easy as switching over to [Chrome Devtools CLI](https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/cli.md). But githits was a completely different issue... Do I even need it? 

As one of their active users, I had no clue how it contributes to my workflow. I begged the team to provide more visibility to iterations between their back-end and my harness. This was acknowledged and nothing was offered as a solution. So for some sensitive codebases GitHits MCP was already disabled (they are US-based LLC and I'm a European contractor).

There is a lot to like about Githits (mostly) Finnish team. They are really interesting people, approachable and their startup is somehow related to [Posh TUI](https://poshtui.com) project. So decision to pry open their MCP to see what exactly they are doing was made. 

As a small experiment, I decided to ask about changes in the [rdoc-markdown gem](https://github.com/skatkov/rdoc-markdown) in the last two releases. CHANGELOG.md file is usually stripped away during gem packaging, so this is not something the LLM can just read from disk. There could be 4 ways to go about this:

  1. OpenCode's WebFetch
  2. GitHits MCP
  3. GitHits CLI
  4. Lightpanda browser

Which one is better? Let's fire up opencode and see. GPT-5.6 Sol was used in all these examples.

## With OpenCode's WebFetch
[WebFetch](https://opencode.ai/docs/tools/#webfetch) is a default tool that comes with OpenCode and this would be a baseline.

Prompt:
```
Can you tell me out what kind of changes rdoc-markdown gem had last two releases?
```


Final response:
```
The latest two stable releases both shipped on July 8, 2026:
- 0.12.0: Added smarter index.csv classification. Root README/Guide pages become Readme; CHANGELOG/History become Changelog; other documents remain Page. It also automatically added these root pages when explicit input files were supplied.
- 0.12.1: Removed that automatic inclusion because it changed RDoc’s explicit-file behavior. Pages must now be explicitly supplied or discovered by RDoc normally, but the improved classification remains.
Overall, this was a search-indexing feature followed immediately by a behavioral correction, with no dependency, security, or Markdown-rendering changes.
Sources: RubyGems versions (https://rubygems.org/gems/rdoc-markdown/versions), 0.12.0 changes (https://github.com/skatkov/rdoc-markdown/compare/v0.11.1...v0.12.0), 0.12.1 changes (https://github.com/skatkov/rdoc-markdown/compare/v0.12.0...v0.12.1), feature PR #86 (https://github.com/skatkov/rdoc-markdown/pull/86).
```

This took **1m 2s** and **87.7K tokens** to complete according to OpenCode's TUI interface. Not a very precise stats, but I'll dig more deeply into numbers later.

### With Githits MCP
Part of my motivation was to better understand what GitHits is doing. So I hooked up [mcpsnoop](https://github.com/kerlenton/mcpsnoop) to intercept all MCP calls to back-end. I achieved that with a following change in `~/.config/opencode/opencode.json`.

```json
"mcp": {
  "GitHits": {
    "type": "local",
    "command": [
      "mcpsnoop",
      "--label",
      "GitHits",
      "--",
     	"npx",
     	"-y",
     	"githits@latest",
      "mcp",
      "start"
    ],
    "enabled": true
  }
}
```

Prompt:
```
Can you use githits to check out what kind of changes rdoc-markdown gem had last two releases?
```

Response:
```
The latest two releases were both published July 8, 2026:
- 0.12.0: Added classification of root documentation as Readme, Changelog, or Page. It also automatically added eligible root Markdown/RDoc files to explicit file lists.
- 0.12.1: Corrective rollback removing that automatic inclusion. Explicit file lists now remain explicit, while normal RDoc scanning still works for empty lists.
The page-classification behavior remains in 0.12.1. No dependency or gemspec changes occurred. GitHits found no 0.12.x release notes, so this is based on comparing tags v0.11.1, v0.12.0, and v0.12.1, primarily lib/rdoc/generator/markdown.rb and its tests.
```

And here is what our snooping returned: 

[https://gist.github.com/skatkov/6430deb29aa17c068e15f72a12d6c25d](https://gist.github.com/skatkov/6430deb29aa17c068e15f72a12d6c25d)

It took **9m 27s** and **26K tokens** to complete. At first this seems better than WebFetch result, but TUI interface is being misleading. After looking into mcpsnoop logs, I've seen more concerning numbers:

- 91 actual GitHits calls: 4 from the visible parent session, 87 from the hidden subagent.
- 279 wire records: requests, responses, startup messages, and post-call cancellation cleanup.

It felt more exhaustive than necessary and OpenCode obscured that cost. I'll dive deeper into numbers later.

## With Githits CLI

In this session we turned off Githits MCP and used CLI directly. I didn't had any custom skills, everything was vanilla the way it was installed by Githits installer.

Prompt:
```
Can you use githits skill (CLI) to check out what kind of changes rdoc-markdown gem had last two releases?
```

Response:
```
GitHits reports the latest releases as 0.12.1 and 0.12.0, both published July 8, 2026.
- 0.12.0: Added smarter page classification in index.csv. Root README/Guide pages become Readme; CHANGELOG/History become Changelog. It also auto-included eligible root Markdown/RDoc pages.
- 0.12.1: Corrective rollback of that auto-inclusion. Explicit RDoc file lists remain explicit, while the improved page classification remains.
The changelog has no entries for either release, so this comes from GitHits source comparisons across 0.11.1 → 0.12.0 → 0.12.1, primarily lib/rdoc/generator/markdown.rb and its tests. Repository: https://github.com/skatkov/rdoc-markdown
```

This took **2m 43s** and **40.2K tokens** to complete.

It may seem surprising, that this took less time than MCP, but their servers have been warmed up recently by previous similar request. But why does opencode report shows higher token usage?

CLI requests same data, from same back-end. It seems that CLI interface was an after-thought for Githits team:
- MCP defaults to compact text-v1, CLI returns richer JSON format. 
- MCP code_read enforces a 150-line cap. CLI reads are uncapped. 
- LLM requested multiple `--help` outputs, this is just bad design of CLI interface.
- CLI doesn't offer `--fields` flag to filter JSON data. This can also be solved by a skill, that will suggest use of `jq` utility.

Not a great first impression. What really matters is _actual_ token usage, interface can always be tweaked. 

## With Lightpanda Browser

[Lightpanda browser](https://lightpanda.io/) is a like WebFetch-tool on steroids. This is not a playwright-mcp or cdp protocol bolted on to a broken browser. This project is focused on a monumental challenge - rewrite a browser for particular use. And this already worked fantastically in a lot of cases for me. Let's see how it fares with Githits.

Prompt:
```
Can you tell me out what kind of changes rdoc-markdown gem had last two releases? Please use libpanda browser for this task, don't rely on WebFetch.
```

Response:
```
The latest two rdoc-markdown releases are 0.12.1 and 0.12.0, both published July 8, 2026.
0.12.0
Primarily a search-indexing enhancement:
- Classifies root-level README and GUIDE pages as Readme.
- Classifies root-level CHANGELOG and HISTORY pages as Changelog.
- Recognizes .rdoc, .md, and .markdown, case-insensitively by basename.
- Treats the configured RDoc main page as Readme, including nested or unusually named pages.
- Initially added automatic inclusion of recognized root pages when an explicit input-file list was supplied.
- Included path-normalization improvements and extensive tests.
0.12.1
A corrective simplification immediately following 0.12.0:
- Removed the automatic root-page inclusion hook.
- Explicit RDoc file lists are authoritative again; unlisted README, CHANGELOG, and similar files are not silently added.
- Retained the new Readme/Changelog search-index classification for pages RDoc actually processes.
- Mostly deleted implementation and test complexity: the source comparison shows 37 additions and 167 deletions.
In short, 0.12.0 introduced smarter page classification plus automatic discovery; 0.12.1 kept classification but backed out automatic discovery.
Sources browsed with Lightpanda:
- RubyGems version history (https://rubygems.org/gems/rdoc-markdown)
- 0.11.1...0.12.0 comparison (https://github.com/skatkov/rdoc-markdown/compare/v0.11.1...v0.12.0)
- Classification PR #86 (https://github.com/skatkov/rdoc-markdown/pull/86)
- 0.12.0...0.12.1 comparison (https://github.com/skatkov/rdoc-markdown/compare/v0.12.0...v0.12.1)
The repository has no formal GitHub release notes, so this summary comes from the published gem and tag diffs.
```

Completed in **1m 4s** and took **93.4K tokens** to complete as reported by TUI. 

Did you notice? This gave most complete answer, deletion count and exact sources.

## Comparison

Let's pry open opencode sqlite database to get overall statistics for each session. And here is what I found:

| Method | Time | Model turns | Retrieval activity | Input | Cache read | Output + reasoning | Recorded total |
|--------|------|-------------|-------------------|-------|------------|-------------------|----------------|
| GitHits MCP | 9:27 | 22 | 91 GitHits calls | 164.6K | 1,164.3K | 16.3K | 1,345.2K |
| GitHits CLI | 2:35 | 12 | 24 shell calls, ~32 CLI executions | 38.7K | 219.1K | 5.1K | 262.9K |
| WebFetch | 1:03 | 5 | 16 fetches | 88.8K | 156.7K | 2.1K | 247.6K |
| Lightpanda | 1:05 | 5 | 10 fetches | 88.2K | 112.1K | 2.4K | 202.7K |


As expected, Githits CLI interface was more efficient and faster than Githits MCP, even with interface being poorly designed for LLM use. But lightpanda blew everything else out of the water.

All four correctly identified changes introduces in last two releases of gem. But: 

- **Lightpanda**: Most complete answer, deletion count, and exact sources.
- **WebFetch**: Concise and well sourced with direct RubyGems, comparison, and PR links.
- **GitHits MCP**: Correct, but the exhaustive child investigation added little value to the final answer and provided no clickable citations. And was so wasteful in terms off token usage.
- **GitHits CLI**: Correct, but less detailed and required many help/discovery commands. I'd say interface requires more work.

## Conclusion
I'll be integrating Lightpanda more deeply into workflow. 

But for Githits MCP? That was removed completely, without replacing it with CLI interface. My original concern was that some personal information or code was leaking to their servers - that was absolutely not the case as proved by mcpsnoop. But after this experiment - Lightpanda seems better suited and wastes less tokens and time.

They are a fresh startup, so I will still keep my eye on them. They will certainly do something great, I believe in that.