Replacing Linear MCP with linear-CLI

A developer switched from Linear's official MCP server to the unofficial linear-cli tool and estimates the change saves between 5k and 25k tokens per session, according to a comparison run by Claude across 71 tickets. The median update-issue operation consumed 3,061 characters through MCP versus 211 through the CLI (14.5×), while reading an issue without comments took 3,721 characters via MCP versus 2,311 via CLI (1.6×) and reading with comments took 4,531 versus 2,615 (1.7×). The author attributes the gap to MCP's get_issue returning 31 fields, including always-null SLA timestamps such as slaStartedAt and slaHighRiskAt, and to MCP's update_issue response being nearly as large as its read payload, with neither MCP tool accepting a parameter to shrink the response.

Replacing Linear MCP with linear-cli https://github.com/schpet/linear-cli https://thebiglog.com/links/linear-cli-instead-of-linear-mcp /github.com Linear https://linear.app is one of my favorite software finds of the last few years. I’m not as big of a fan when it comes to their token-hungry MCP server though. I recently switched to this unofficial CLI https://github.com/schpet/linear-cli and my rough estimate is that it saves me between 5k to 25k tokens a session. I asked Claude to sample the differences and it came back with medians based on 71 tickets. Note the unit here is characters: | Operation | MCP | CLI | MCP ÷ CLI | |---|---|---|---| | Update issue | 3,061 | 211 | 14.5× | | Read no comments | 3,721 | 2,311 | 1.6× | | Read with comments | 4,531 | 2,615 | 1.7× | The explanation for both differences is simple and comes down to sane defaults and flexibility, both of which the MCP lacks: get issue returns thirty-one fields. Those include the issue’s body and status, but also fields like slaStartedAt , slaMediumRiskAt , slaHighRiskAt , slaBreachesAt . The last few are always null in my workspace. The CLI doesn’t return them by default. For updates, the CLI returns a simple success message while the MCP’s update issue response is almost as big as the read payload. Neither MCP tools accepts a parameter that makes its response smaller.