# Gitsu MCP: GitHub Projects reads in milliseconds

Author: Sahil Dave
Canonical: https://gitsu.app/features/mcp-local-reads
Published: 2026-10-07
Updated: 2026-10-08
Last checked: 2026-10-08

> **TL;DR** Gitsu MCP can answer GitHub Projects questions from the board already loaded on the laptop. Direct sidecar measurements recorded cached list_items at 4–7 ms. An in-process test with a fake app over a real socket recorded cached get_item at 4.5 ms on a 900-row board; the earlier GitHub-backed get_item read measured 877 ms on a test board. These are tool-call measurements with different test conditions, not whole-agent task times or a four-tool speed ranking. A separate task-level benchmark of nine agent tasks gave Gitsu MCP the lowest median, 10.5 s per task, with its list reads served from the app's local copy of the board. GitHub MCP, gh and gh-axi remain useful for their broader GitHub workflows.

Gitsu MCP is the GitHub Projects MCP server bundled with the Gitsu desktop app, and it can answer board questions from data already on the laptop. Direct sidecar measurements recorded cached board reads at **4–7 ms**.

That is the reason to consider Gitsu alongside GitHub's official MCP server, the GitHub CLI, and `gh-axi`. If Gitsu already holds the requested board data, the agent can read it locally rather than wait for another GitHub request.

## What is the fastest way to get GitHub issues into my agent?

For issues on a board already loaded in Gitsu, its MCP server can answer from local data, with recorded cached `list_items` calls at 4–7 ms. Per-call timings for the alternatives are unavailable, so this result does not establish a universal fastest tool. Task-level timings do exist: a benchmark ran the [same nine agent tasks through all four tools](#how-long-does-a-whole-agent-task-take-with-each-tool).

The scope matters. Gitsu reads GitHub Projects items; repository issues outside the board need a repository-wide interface such as `gh` or GitHub MCP. The [agent integration reference](/docs/github-issues-ai-agent) explains both paths and how to verify that the agent is reading the intended issue.

## How fast are Gitsu MCP reads from the cache?

The recorded measurements put cached board and item reads in single-digit milliseconds, with different conditions for each measurement.

| Read | Recorded time | Measurement conditions |
| --- | ---: | --- |
| `list_items` from Gitsu's cache | 4–7 ms | Direct sidecar calls on a test board, recorded on September 29, 2026 |
| `get_item` from Gitsu's cache | 4.5 ms per call | In-process test with a fake app over a real socket and a 900-row board |
| Earlier `get_item` through GitHub | 877 ms | Direct GitHub-backed read on that test board before the cached item-read change |

```chart
title: One get_item call, in milliseconds, lower is better
unit: ms
note: Gitsu only, not gh, gh-axi or GitHub MCP. The cached figure was measured in-process, a fake app over a real socket on a 900-row board, median of 5. The GitHub figure came from a separate test board. Different boards and setups, so the bars show scale, not a controlled ratio.
series:
  - label: Gitsu, from its cache
    value: 4.5
    highlight: true
  - label: Gitsu, read through GitHub
    value: 877
```

The cached item test measures repeated calls within an MCP session. It subtracts a one-call session from a 21-call session, divides the difference by 20, and takes the median across five repetitions. This isolates per-call work from session overhead. It also checks that no GitHub request was made.

The 877 ms measurement is the earlier network path that the cached item implementation replaced. It was measured on a different board from the 900-row test. These numbers explain the cache improvement; they are not a controlled speed ratio or a promise for every machine. A live before-and-after check was still pending when the cached item-read change shipped.

## How does Gitsu MCP compare with GitHub MCP, gh and gh-axi?

Gitsu's specific advantage is access to its existing local board data; the other tools offer different ways to work with GitHub.

| Tool | How the agent uses it | Relevant strength | Millisecond measurement on this page |
| --- | --- | --- | --- |
| Gitsu MCP | MCP tools that read the running app's cache, a supported snapshot, or GitHub | Reuse board data already loaded in Gitsu | Cached reads measured above |
| GitHub MCP | GitHub's official server, including its Projects tools | GitHub operations exposed directly as MCP tools | No equivalent tool-call measurement recorded here |
| GitHub CLI, `gh` | Shell commands, including `gh project item-list` | Project commands with JSON output, query options and shell processing | No equivalent tool-call measurement recorded here |
| `gh-axi` | A wrapper around the official `gh` CLI | Compact TOON output, next-step suggestions and structured errors for agents | No equivalent tool-call measurement recorded here |

[GitHub's MCP server](https://github.com/github/github-mcp-server) documents Projects tools as well as repositories, pull requests and other toolsets. The [GitHub CLI](https://cli.github.com/manual/gh_project_item-list) supports listing project items with output formatting and filtering options. [`gh-axi`](https://github.com/kunchenguid/gh-axi) wraps that CLI to make its replies easier for an agent to use.

Choosing between them depends on the work. A board question about data already loaded in Gitsu fits the local read path. A shell script may fit `gh`; an agent using shell tools may benefit from `gh-axi`'s output; an MCP client needing broader GitHub operations may fit GitHub's server.

## How long does a whole agent task take with each tool?

On September 29, 2026 we ran nine GitHub Projects tasks through each of the four tools and timed every agent run end to end, in seconds. Gitsu MCP had the lowest median, 10.5 seconds, and its list reads came from the board already loaded in the running app, a GitHub round trip the other three paid on every list.

These are task times, not tool-call times. Each one covers the agent's reasoning, every tool call it made and its final answer, so they do not compare with the milliseconds above. Six tasks were reads and three were writes.

| Tool | Median time per task | Tasks passed | Average cost per task |
| --- | ---: | ---: | ---: |
| Gitsu MCP | 10.5 s | 8 of 9 | $0.0415 |
| GitHub MCP, Projects toolset only | 15.8 s | 3 of 9 | $0.0598 |
| GitHub CLI, `gh` | 18.8 s | 5 of 9 | $0.0342 |
| `gh-axi` | 20.6 s | 6 of 9 | $0.0266 |

```chart
title: Median seconds per whole agent task, lower is better
unit: s
note: One run per task, nine tasks, Claude Haiku 4.5, September 29, 2026. Gitsu's list reads came from the running app's local copy of the board.
series:
  - label: Gitsu MCP
    value: 10.5
    highlight: true
  - label: GitHub MCP, Projects toolset only
    value: 15.8
  - label: GitHub CLI, gh
    value: 18.8
  - label: gh-axi
    value: 20.6
```

```chart
title: Tasks passed out of 9, higher is better
max: 9
note: One run per task, nine tasks, Claude Haiku 4.5, September 29, 2026. For Gitsu's 8 of 9 the 95% interval is 56% to 98%. We wrote the tasks, and we built Gitsu. GitHub MCP ran with only its Projects toolset.
series:
  - label: Gitsu MCP
    value: 8
    highlight: true
  - label: GitHub MCP, Projects toolset only
    value: 3
  - label: GitHub CLI, gh
    value: 5
  - label: gh-axi
    value: 6
```

Read the table with its limits:

- **One run per task per tool.** For Gitsu's 8 of 9 passes, the 95% interval runs from 56% to 98%. None of Gitsu's pass differences against the other three tools reaches p < 0.05.
- **One model.** Every agent was Claude Haiku 4.5 at low effort with thinking off. Stopping at the first page of a long list was the most common way the other tools failed, and a stronger model may page further.
- **Gitsu costs more per task than `gh-axi`.** Its average was $0.0415 against $0.0266, and per passing task $0.0467 against $0.0398. One Gitsu run, a current-cycle question, hit a filter bug in Gitsu and took 157 turns and $0.2203, 58.9% of Gitsu's total cost. It still passed.
- **Tool definitions add input.** Gitsu's 14 tools at the time took 11,431 bytes of definitions and GitHub MCP's three Projects tools took 14,877. Against `gh`, which carries the shell tool's definition, that added only about 317 and 746 tokens to the first turn, so definitions do not explain the cost gap.
- **We built Gitsu and wrote the tasks.** GitHub MCP ran with only its Projects toolset, and three of its failures came from that choice. Gitsu's one failure was listing open sub-issues, which live on the issue rather than the board; both CLIs passed it.

## Why does the local read path save time?

The local path saves a GitHub round trip when the requested data is already cached.

For `list_items` and `list_fields`, Gitsu tries the running app first, then its saved MCP snapshot, then GitHub. Each answer names its source and, for local data, its age. A snapshot can therefore answer a board read even when the desktop app is closed.

For `get_item`, the sidecar asks the running app for the cached board row and that item's detail. Item bodies stay out of the board snapshot, so reading the list does not repeatedly carry every issue's body. With the app closed, `get_item` reads GitHub.

The [MCP server reference](/features/mcp-server) describes the tools and board selection. [MCP views](/features/mcp-views) explains how compatible hosts render their answers as cards.

## When does Gitsu still need to read GitHub?

Gitsu reads GitHub when local data cannot answer the request or the caller asks `get_item` for `fresh: true`.

A cached answer is as recent as the data Gitsu holds. Its source line makes that visible, for example `from Gitsu · 2 min ago`. Comments and blocking details are included on request and can come from memory when the cache has the required complete data; otherwise they require a GitHub read. `list_projects` still reads GitHub.

Writes have a separate rule. They need the running desktop app and return a result after GitHub accepts or refuses the change. The single-digit read measurements do not describe write latency, model reasoning time, or a complete agent task.

## How do I use the cached read path?

Use Gitsu's desktop MCP server with the relevant board loaded, then let the tool answer from its available data.

1. Open Gitsu, sign in, and load the GitHub Projects board the agent will use. MCP access requires a paid Seat through Pro or Team; see [pricing](/pricing).
2. Connect the bundled server to the agent using the [MCP setup guide](/guides/connect-claude-code-to-github-projects-mcp).
3. Ask for matching board items or an item's details. Check the source and age in the reply.
4. Call `get_item` with `fresh: true` when the decision requires a fresh GitHub item read. The board-list and field-list tools do not expose this flag.

For repeated board reads, that makes the data Gitsu already loaded useful to the agent too. The measured benefit is the local read itself, with the answer's age visible alongside it.

## How we checked

Direct sidecar list_items measurements of 4–7 ms, the documented 4.5 ms cached get_item test on a 900-row board, and the earlier 877 ms GitHub-backed get_item read, with the socket-test method and cache boundaries traced to Gitsu's source and tests.

Public references:
- https://github.com/github/github-mcp-server
- https://cli.github.com/manual/gh_project_item-list
- https://github.com/kunchenguid/gh-axi

## Frequently asked questions

### How fast are Gitsu MCP cached reads?

Direct sidecar measurements recorded cached list_items at 4–7 ms. The documented in-process get_item test recorded 4.5 ms per call with a fake app over a real socket on a 900-row board. Actual latency depends on the read path and environment.

### Is Gitsu MCP faster than GitHub MCP, gh and gh-axi?

The recorded millisecond data shows Gitsu cached reads and its earlier GitHub-backed get_item read. It does not contain equivalent tool-call measurements for GitHub MCP, gh or gh-axi. A separate task-level benchmark on September 29, 2026 timed nine whole agent tasks with each tool: Gitsu MCP had the lowest median, 10.5 s, with its list reads served from the running app's local copy of the board, and it passed 8 of 9. That was one run per task with one model.

### Does a fast cached answer contain the latest GitHub data?

A cached answer contains the data Gitsu already holds and states its source and age. Use get_item with fresh: true for a fresh GitHub item read; list_items and list_fields do not expose that flag.

### Does Gitsu need to be open for cached MCP reads?

Cached get_item reads need the running app. list_items and list_fields can also read a saved board snapshot with Gitsu closed. If local data cannot answer a read, Gitsu uses GitHub. Writes need the app open.

## Related resources

- [Connect Claude Code to GitHub Projects with MCP](https://gitsu.app/guides/connect-claude-code-to-github-projects-mcp)
- [GitHub Projects MCP views: cards inside your AI chat](https://gitsu.app/features/mcp-views)
- [Let an AI agent update GitHub issues safely](https://gitsu.app/features/agent-safety)
- [The Gitsu MCP server for GitHub Projects v2](https://gitsu.app/features/mcp-server)
- [How fresh is Gitsu MCP data? Cached vs fresh reads](https://gitsu.app/docs/gitsu-mcp-cache-freshness)
- [How to integrate GitHub Issues with an AI agent](https://gitsu.app/docs/github-issues-ai-agent)
- [Gitsu pricing: free Web App, paid desktop app](https://gitsu.app/pricing)