Agent Skills for Linear MCP: 62% → 90% Accuracy Benchmark

Here is a number that should not exist. We ran 342 Linear tasks through Claude with nothing but the MCP tool list. Then we ran the same 342 tasks again after handing the agent a 56-line markdown file to read first. Accuracy went from 62% to 90%. The bill went from $38.15 to $36.17.

More instructions, more context, more tokens on every task, and the run came out cheaper. Every intuition about prompt cost says that is backwards. It isn't, and the reason is the part worth reading.

The agent was never failing because a tool broke. It was failing because the wrong tool worked. Ask Linear for the current sprint and the cycle list comes back empty. That empty list is the correct answer. But the issue list is one call away, it returns real issues, and nothing in that result says “this is not the sprint.” So the agent reports the issues as the sprint, confidently, after paying for every call it took to get there. Each wrong call costs tokens on the way out and tokens for the result on the way back, and then the agent has to reason about a result it should never have seen.

The 56-line file did one thing. It told the agent which object the request was about, and that an empty answer is an answer. The accuracy came from the first part. The savings came from the second.

The fallacy: if the agent can call the tool, it knows when to stop

Most teams treat an MCP server like an API reference. Expose the tools, write decent descriptions, and the model will figure out the rest. When it doesn't, the fixes people reach for are the same three: add more tools, improve the descriptions, or turn up reasoning effort.

All three assume the problem is missing capability. On Linear it is the opposite. The agent has too many tools that succeed. Cycles, projects, milestones, and initiatives can all sound like “the plan.” Someone says “this sprint,” which Linear calls a cycle. Someone asks for a checkpoint inside a project, which Linear calls a milestone. Four tools can each return a list, and any of those lists can look like an answer.

An MCP server tells an agent what it can call. It never tells it which successful call is enough. That is the gap, and no amount of reasoning effort fills it. In this benchmark, raising effort from medium to high without a skill added at most 3.5 percentage points. The model can think harder about the wrong list all it likes. It cannot recover a distinction the tool roster never gave it.

The cost fallacy sits on top of that one. Every instruction you add is tokens on every task, so a skill should make the run more expensive. That holds only if the skill is read in full every time and changes nothing about what the agent does. A skill that prevents one wrong call saves the call, the result that came back with it, and the reasoning the agent spent on a result it should never have seen. On Linear that saving was bigger than the cost of reading the index.

TL;DR: the example and the learning

The example. “What is qa-release working on in the current sprint?” Sonnet 4.6 at medium effort, no skill: 15 tool calls. It listed teams, listed cycles twice, got an empty cycle list, then called the issue list over and over, then get_team, issue statuses, and projects. It answered with the team's issues. With the skill: 2 calls. It listed teams, listed cycles, saw the empty list, said no sprint was configured, and stopped. The empty list was the answer all along.

The numbers. 19 deliberately confusing Linear tasks, six Claude settings, three runs each. Accuracy 62.0% without the skill, 90.4% with it. Every model and effort setting improved, by 22.9 to 31.6 points. Tool calls per task fell from 2.41 to 1.39, a 42% drop, against a shortest correct path of 1.0. Input tokens per task fell from 42.0k to 39.7k. Benchmark cost fell from $38.15 to $36.17. The slowest 5% of tasks dropped from 80.5 seconds to 50.9.

The learning. When two tools can both return a plausible answer, the model needs three things the tool list does not give it: which object the request is about, what an empty result means, and what the server cannot do. A short index that names the object before the tool supplies all three. Keep it small enough to read every time, put argument details in reference files loaded on demand, and the skill pays for itself in calls it prevents.

How we benchmarked agent skills on Linear MCP

We changed one variable. Everything else was held constant.

The tasks. 19 Linear prompts written around the three things that confuse agents: lookalike tools (cycle versus project versus milestone versus initiative), missing capabilities (delete an issue, merge a PR), and writes that need a confirmation. We picked them because they are confusing, so they are harder than ordinary Linear traffic.

The data. Linear responses came from a frozen recording. Both arms saw identical data, and writes never reached a real workspace. That also removes real API latency from the timings.

The models. Sonnet 4.6, Opus 4.8, and Fable 5, each at medium and high effort. Six settings, three runs per task, in a fresh workspace each time. 342 runs with the skill and 342 without.

The two arms.

The skill. A 56-line SKILL.md index the agent always reads. It names Linear's objects, gives a short rule for choosing one, lists the lookalikes, says what an empty result means, and lists what the server cannot do. Four reference files hold argument details, such as which filters need an id and which accept a name. The agent opens one of those files or none. On a typical task it names one object, picks the tool from the index, opens that object's reference file if the call needs it, and makes one call, then stops.

The scoring. A task passed only if the agent chose the right tools in the right order, respected the confirm rules, and gave a correct final answer. A separate Opus 4.8 judge graded the answer without knowing whether a skill was present. Three runs per task is a small sample and two of the pass checks are model-judged, so read the exact percentages as directional.

The tasks, skills, scoring rules, and reproduction steps are in the public mcp-skillbench repository.

Results: Linear MCP accuracy with and without a skill

Accuracy rose from 62% to 90%, tool calls fell 42%, and the run cost 5% less.

Where the agent got lost. Without a skill, the agent was fine on single issues, comments, and help-center questions. It got lost on planning objects. Four tools can each return a list, so it checked more than one, and any of those lists looked like an answer.

The current sprint was the clearest case. The cycle list answers it on its own. Without a skill, the agent often looked the team name up as if it were a user first. When the cycle list came back empty, it went on to read issues anyway. That task never passed on any model. With the skill it read the cycle list, said no cycle was configured, and stopped. It passed almost every time.

Two runs, side by side. Same model, same prompt. The only change is the skill.

The half-fixed case. An org-wide initiative spanning several projects is the planning question the skill only partly solved. “Give me the status of the company-wide Pfizer Marketing Agents theme and its projects” never passed without the skill, because the agent found the initiative and then pulled each project with separate calls. With the skill it passed about half the time.

Invented tools. “Permanently delete QAR-113 from Linear.” Linear MCP cannot delete an issue. Without a skill, the agent often made no call and answered as if a delete tool existed and was only waiting on confirmation. “Merge pull request 758 using the repository default method” got the same treatment: the agent sometimes said Linear's merge tool would do it, without calling anything. A short “not available” section plus a list of writes that need a confirm fixed most of these.

Each of those failures is one row in the index:

Why effort didn't help. Turning effort from medium to high without a skill added 3.5 points for Sonnet and 1.8 points for both Opus and Fable. Adding the skill added 22.9 to 31.6 points depending on the model and setting. Opus 4.8 at high effort with the skill reached 96%. More effort helped a little on its own. It never closed the gap, because effort cannot recover a distinction the tool roster does not provide.

Why it cost less. The index is short enough to read every time. The reference files load only for the object in play, so most of the skill never enters the context. The skilled agent spent a little on the index and saved more by skipping the wrong call and the result that came back with it. The shortest correct path averages one call. Without the skill the agent averaged about two and a half. With it, under one and a half. The slowest 5% of tasks dropped from about 80 seconds to about 51. That tail is where the detours lived, so that is where a skill that says “stop” showed up.

Use a skill when successful tools are still ambiguous

Skip it when the tool list is small and the names do not overlap. If no two tools can plausibly answer the same question, the model does not need a tiebreaker.

Add one when two tools can both return something that looks like an answer. Linear's planning objects are the case we kept hitting: the neighboring tool succeeds too, so nothing in the result tells the model to stop.

Keep the always-read index to the choice itself. Objects, lookalikes, what an empty result means, and which writes need a confirm. Argument names and filter quirks go in reference files, opened after the choice is made. The index is what moved accuracy. The reference files are what kept the token count from rising.

Name the object before the tool. If your MCP server has objects that share names, the model will spend calls telling them apart, and some of those calls will produce plausible wrong answers. A short index that names the object first, says what an empty result means, and lists what is not available closes most of that gap. On Linear that took accuracy from 62% to 90% with fewer calls and a lower bill.

Governing Linear MCP tool calls with TrueFoundry

A skill changes which tool gets called. It does not decide who may call it, which credentials the call uses, or what gets logged. In production those are separate jobs, and you want both.

The TrueFoundry Skills Registry is where a skill like this lives once more than one team uses it. A skill sits in a repository alongside prompts and models. The repository decides who can discover it, edit it, and attach it, and keeps the version history and audit log. Each publish is a numbered version, so an agent can stay on the current one or pin an older one if a new publish misbehaves. The Linear index you tune is the one every agent loads, and the same version can be attached to a TrueFoundry agent or pulled into Claude Code and Cursor. This Linear skill is an index plus reference files, so it is published as a bundle through the CLI or through GitOps with tfy apply.

The TrueFoundry MCP Gateway sits in front of the Linear MCP server. It handles authentication, tool-level access control, and a trace of every call. Overhead is about 3 to 4 ms, and it handles 350+ requests per second on one vCPU. This benchmark used a local replay, so it says nothing about the gateway. The skill makes the call the right one. The gateway decides whether that call is allowed.