The Skill Dealer: Skills over MCP


![Three figures in a dark, Sandman-esque realm - The Skill Dealer, The Nuclear Football, and Codey C. Maude - standing before swirling constellations of MCP tool connections](/images/progressive-discovery/banner.webp)

Mario Zechner wrote a post last year called ["What if you don't need MCP?"](https://mariozechner.at/posts/2025-11-02-what-if-you-dont-need-mcp/). I like Mario. I watched him speak at AI Engineer Europe and was genuinely inspired by his approach to [Pi](https://pi.dev/) - the simplicity of it, the emphasis on doing your own context engineering, the "I was just crazy enough to build this" energy. He makes strong arguments about composability, bash fluency, and the tax that large MCP tool schemas impose on agents.

But I think he's wrong about the conclusion, and I think a lot of people are making the same mistake: conflating the laziest possible MCP implementation with the protocol itself.

Mario's critique boils down to: two MCP servers exposing 47 tools using \~32k tokens were just too many tools with too large a context footprint, they confuse the model, the results aren't composable, and you could replace it all with four bash scripts and a 225-token README. He's right about all of that, in that context.

But MCP doesn't tell you to dump every tool into the system prompt. MCP doesn't prevent you from composing results through pipes. MCP doesn't force you to roundtrip every intermediate result through the model. Those are implementation choices, and the entire industry of client builders made them by default because almost nobody applied serious context engineering to MCP.

I work on the [GitHub MCP Server](https://github.com/github/github-mcp-server). We have over 100 tools (just over 40 by default). We serve approaching 12 million tool calls a week. I've lived the tool bloat problem from the inside, and "having a CLI that models are well trained to use" at the same time - we watched agents get worse at using GitHub as we added more tools, while more and more people would ask "why not just use GitHub CLI?". Even myself, I have reasons to do both. I helped build `gh skills` too, adding ability to install agent skills directly from `gh cli`. Clearly, I see some value in CLIs, Skills and MCP all.

We tried toolsets (groups of related tools users could pick). We tried dynamic tool selection. I even prototyped a version with RAG-based semantic tool search back in April 2025. And what happened?

Everyone used the default settings. The dynamic tool selection actually worked well, but it busted the model cache on every tool set change, so we stopped innovating in that direction.

That was genuinely frustrating. We had elegant solutions, all they required was users to configure them. But most users don't configure things. So we took a different path: we optimised the out-of-the-box experience. We reduced the default tool count by 49%, consolidated CRUD tools, [cut output tokens by over 75%](https://github.blog/changelog/2025-10-29-github-mcp-server-now-comes-with-server-instructions-better-tools-and-more/) on tools like `list_pull_requests` without losing useful information.

But that was just trimming. Collectively what we have needed to build is progressive discovery - tools that appear in the model's working set only when they're relevant to the current task. The full catalog exists, but the model sees a curated surface. You pay context tokens only for what you actually use.

## The ideas aren't new. So where are the implementations?

Anthropic shipped [tool search with `defer_loading`](https://www.anthropic.com/engineering/advanced-tool-use) - server-side search that loads tools on demand, cutting context by up to 85%. Cloudflare shipped [Code Mode](https://blog.cloudflare.com/code-mode/) - the model writes code against a typed SDK, collapsing hundreds of endpoints into two tools. [Phil Schmid's mcp-cli](https://www.philschmid.de/mcp-cli) showed that progressive discovery via shell commands can reduce token usage by 85x. These are all real, working approaches. And none of them require giving up MCP.

In my [MCP Dev Summit talk](https://www.youtube.com/watch?v=ideYDMJKujE&list=PLjULwdJUtFdhIBhibLEogtK1XYCNaFyFl&index=10), I said "MCP vs CLI is the wrong question" - and I meant it. Both CLIs and MCP are in the mix. Every hot take that says one kills the other is really just saying "at this exact moment, this works well for me." Extrapolating that into the future is a mistake.

I got bored waiting for others, so I finally built the thing I kept talking about.

## Three tiers, three characters

[mcpi](https://github.com/SamMorrowDrums/mcpi) is an experimental fork of [pi](https://pi.dev/) + [extension](https://github.com/SamMorrowDrums/mcpi-ext) that implements three complementary strategies for progressive tool discovery. Each pays only the context tokens it needs. Each handles a different shape of work. And because the best ideas deserve characters, each has a name.

| Tier | Name | Mechanism | Best for |
| --- | --- | --- | --- |
| 1 - Skills | **The Skill Dealer** | `skill://` resources gate tools via `allowed-tools` | Curated workflows |
| 2 - tool-cli | **The Nuclear Football** | CLI progressive discovery via shell | One-shot exploration |
| 3 - Code Mode | **Codey C. Maude** | Sandboxed JS over read-only tools with `outputSchema` | Computation across many calls |

This series goes deep on each. But first, the property that ties them together:

**Every call flows through the harness.** Whether the model loads a skill, shells out to `tool-cli`, or writes sandboxed JavaScript, the actual MCP tool call happens in the extension process. One choke point for all three tiers. Every invocation logged, observable, gatable. That matters for security, auditability, and future human-in-the-loop gating - and it's a point I'll return to throughout the series.

## Additionally - large output offloading

Progressive discovery controls input tokens - what the model sees. But output tokens matter too. A single `list_issues` call can return 50KB of JSON that sits in the transcript forever. Copilot CLI already does this with MCP - large tool responses get written to disk so the agent can use local tools like grep over them instead of bloating context.

The extension does the same thing. It intercepts tool results. If output exceeds a threshold, it writes the full response to a temp file and returns a pointer to the model. The model can read the file if it needs the content, but the default path keeps context lean. This is the output-side equivalent of progressive discovery: don't pay for what you don't need.

## Try it yourself

This is a working system, not a thought experiment. Here's how to set it up:

### 1. Install

```sh
npm install -g @sammorrowdrums/mcpi@latest @sammorrowdrums/mcpi-ext@latest @sammorrowdrums/tool-cli@latest
```

### 2. Configure MCP servers

Create `~/.config/mcpi-ext/mcp.json`:

```json
{
  "mcpServers": {
    "github": {
      "type": "stdio",
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server:skill-discovery",
        "stdio"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "your-token-here"
      }
    }
  }
}
```

Replace `your-token-here` with your [GitHub personal access token](https://github.com/settings/tokens).

### 3. Run

```sh
mcpi --extension $(npm root -g)/@sammorrowdrums/mcpi-ext/dist/index.js \
  --mcp-config ~/.config/mcpi-ext/mcp.json
```

You'll see the extension discover servers, tools, and skills. From there, you have all three tiers available.

## The series

This is Part 1 of 5. The rest of the series covers each tier in depth:

- **Part 2: The Skill Dealer** - Deep dive into skills over MCP. How `skill://` resources **could** gate tools, preserve prompt cache, and why this emerging spec direction could change how MCP servers are designed.
- **Part 3: The Nuclear Football** - The MCP CLI. Progressive discovery through shell composability, and why routing every call through the harness changes the security story.
- **Part 4: Codey C. Maude** - Code Mode. Sandboxed JavaScript over read-only MCP tools with structured output. Why computation and accountability combine to create a very efficient and powerful harness.
- **Part 5: Three Is Not Redundancy** - How the three tiers compose, what's left to build, and a call to action.

**If you build MCP servers**, this series shows a new paradigm for how your tools get discovered and used. You can experiment with `skill://` resources on your own server today.

**If you build agent harnesses**, you'll find concrete patterns to implement - including the [`tool-cli`](https://github.com/SamMorrowDrums/tool-cli) binary, which is a standalone package you can integrate with your own harness as a progressive discovery layer over any MCP connection.

**If you use agents**, these experiments should help you save money on tokens and have smoother agent runs by keeping only relevant tools in context.

MCP doesn't have a context problem. It has a solution awareness problem. And the pieces of the puzzle required to solve it are mostly already in the protocol.

---

*Have thoughts on this article or progressive discovery in MCP in general? I opened a* [*discussion on GitHub*](https://github.com/SamMorrowDrums/cv/discussions/63) *for this series.*

MCP Doesn't Have a Context Problem


Your [MCP server](https://modelcontextprotocol.io/) has a public interface. Tools, prompts, resources, capabilities: everything an AI client sees when it connects. Together, these responses form a contract. Unlike a REST API with an OpenAPI spec or a library with type definitions, this contract is defined at runtime. You don't see it until something connects.

I built [mcp-server-diff](https://github.com/SamMorrowDrums/mcp-server-diff) to answer a simple question: what changed between two versions of my server? It's available as a [GitHub Action](https://github.com/marketplace/actions/mcp-server-diff) and a [CLI tool on npm](https://www.npmjs.com/package/mcp-server-diff). The tool probes both versions and compares their `initialize`, `tools/list`, `resources/list`, and `prompts/list` responses, producing a diff that shows exactly which tool, which property, which value changed.

Understanding how your server contract changes is incredibly useful, but it's one of those subtle things that doesn't make sense until you make a subtle mistake. Then suddenly it's invaluable.

## It keeps catching things

During a major refactor of the [GitHub MCP Server](https://github.com/github/github-mcp-server), a colleague at GitHub, Adam, sent me this after the diff workflow flagged something:

> kudos for the MCP diff workflow. Picked up that I missed a bit of toolset filtering

The code looked right. Tests passed. Code review didn't flag anything. But the runtime interface had shifted in a way nobody intended, and the diff caught it before it reached users. This wasn't a one-off. The diff has saved myself and other team members from shipping unintended changes numerous times now. SDK upgrades that silently changed tool schemas. Refactors that accidentally dropped capabilities. Toolset filtering that shifted in ways nobody noticed in code review. Each time, the code and tests looked correct, but the server was advertising something different to clients than we expected.

The pattern is always the same: the diff reveals what lives in the gap between what you think your code does and what your server actually advertises at runtime. Those are different things more often than you'd expect.

The [GitHub MCP Server workflow](https://github.com/github/github-mcp-server/actions/workflows/mcp-diff.yml) tests [eighteen separate configurations](https://github.com/github/github-mcp-server/blob/main/.github/workflows/mcp-diff.yml) on every PR: default mode, read-only mode, dynamic toolsets, individual and combined toolset flags, and custom tool call sequences that exercise dynamic toolset loading. The point is that any of these configuration variants could accidentally diverge from each other during a change, and the diff makes that visible. The Remote GitHub MCP Server uses it on our internal repo too.

## Seven languages, one interface

I maintain [MCP starter repos](https://github.com/SamMorrowDrums?tab=repositories&q=mcp-starter) in Python, TypeScript, Go, Rust, C#, Kotlin, and PHP. I use them for workshops to get people off to a warm start with MCP development in their preferred language, so keeping the interfaces consistent matters.

A [cross-repo workflow](https://github.com/SamMorrowDrums/mcp-starters/issues/26) compares all six non-Python implementations against the Python reference and opens a tracking issue whenever differences are detected. Most of the differences come from SDK behaviour or language conventions rather than mistakes in repo code (although at the start of using this workflow there were many in my code). That's exactly the point. Without the diff, you can't tell where the difference comes from.

When I was iterating on consistency for these repos, I used agent loops that compared each starter against the Python reference, had the agent fix what it could, and re-ran the comparison as validation. It's a good example of how a concrete, machine-readable diff gives agents something to iterate against rather than just hoping the output is right.

## People I didn't expect are using it

[Matthew Diakonov](https://github.com/m13v) from [mediar-ai](https://github.com/mediar-ai) reached out on the [starter repo tracking issue](https://github.com/SamMorrowDrums/mcp-starters/issues/26#issuecomment-4079388640) to share that they maintain MCP servers in both [Swift](https://github.com/mediar-ai/mcp-server-macos-use) and [Rust](https://github.com/mediar-ai/terminator) for their macOS computer use agent. Interface differences between the two had been a constant source of bugs until they added automated conformance tests. That's a use case I'd hoped for but hadn't seen confirmed in the wild yet, at least not beyond personal experimentation.

On the official MCP side, MCP Maintainer [Ola Hungerford](https://github.com/olaservo) created an [issue on the Inspector repo](https://github.com/modelcontextprotocol/inspector/issues/1034) exploring whether mcp-server-diff could become a plugin for the [Inspector CLI](https://github.com/modelcontextprotocol/inspector), tagged for v2. That could be an effective way of increasing awareness of the tool, and getting it into more hands.

I've also [proposed adding the workflow to the official Everything Server](https://github.com/modelcontextprotocol/servers/pull/3260), the protocol's reference implementation that exercises all MCP features. Tracking public interface changes there would help SDK developers validate compliance and catch unintended regressions when the reference server evolves.

## What I'm most excited about

The tool is still in its infancy, but the use cases that keep surfacing are:

- **PR validation**: compare your branch against main to check that interface changes are intentional, not accidental side effects of internal refactoring
- **Regression prevention**: avoid breaking changes during SDK upgrades, dependency updates, or major rewrites (this is where the team and I have got the most value, repeatedly)
- **Cross-language consistency**: maintain similar servers in different languages and always know the exact differences, whether from your code or SDK divergence
- **Release auditing**: compare a new semver tag against the previous one to see what changed in the public interface
- **Fork comparison**: see precisely what a fork changed in the server's public interface
- **SDK compliance testing**: verify reference implementations stay consistent as SDKs evolve

## Try it

The [GitHub Action](https://github.com/marketplace/actions/mcp-server-diff) is a few lines of YAML. The [CLI](https://www.npmjs.com/package/mcp-server-diff) works for ad-hoc comparisons:

```bash
npx mcp-server-diff -b "your-server-command" -t "other-server-command"
```

Full documentation and language-specific examples are in the [repository](https://github.com/SamMorrowDrums/mcp-server-diff).


Why Diffing Your MCP Server Matters


<p><iframe allow="monetization" class="embedly-embed" src="//cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FLwqUp4Dc1mQ%3Ffeature%3Doembed&amp;display_name=YouTube&amp;url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DLwqUp4Dc1mQ&amp;image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FLwqUp4Dc1mQ%2Fhqdefault.jpg&amp;key=d932fa08bf1f47efbbe54cb3d746839f&amp;type=text%2Fhtml&amp;schema=youtube" width="640" height="360" scrolling="no" title="GitHub Universe MCP Server Demo video" frameborder="0" allowfullscreen="true"></iframe></p>

I was honoured to be invited to demo the GitHub MCP Server at GitHub Universe with Toby Padilla. This was a chance to showcase the work my team has been doing on agent extensibility with a live demonstration of the server in action.

The demo covered setting up Copilot agent mode to interact with GitHub from VS Code, key MCP tools, prompt engineering, and agent-to-agent capabilities that unlock powerful multi-step workflows through natural language.

## The Week Around Universe

Universe was an epic and ridiculously well organised event. There was a huge buzz around MCP and I had a lot of great conversations with developers and builders exploring agent extensibility.

I also attended <a href="https://resources.github.com/mcp-universe-2025/">MCP Universe</a>, a micro summit for agentic builders hosted alongside GitHub Universe. The event brought together open source contributors, startup founders, and enterprise builders to explore MCP and the agentic web. I attended with Carlos Becker, maintainer of the awesome GoReleaser tool.

The event featured an impressive lineup of speakers including David Soria Parra (Anthropic), Den Delimarsky (Microsoft), and Nick Cooper (OpenAI) from the MCP Steering Committee. We also heard from Jeremiah Lowin (FastMCP, Prefect.io), Shannon Williams (Obot), Toby Padilla (GitHub), Vitaly Gordon (Faros AI), Angie Jones (Block), Matvei Popov (Roboflow), and Cathy Di (Dedalus). The event was moderated by Rob Ferguson (Microsoft for Startups), Kevin Crosby (GitHub), and Simina Pasat (GitHub).

Later in the week, I attended the Figma MCP Meetup at Figma HQ. It was another great night of MCP discussion featuring talks from Jake Albaugh and Aditya Muttur from Figma, Harald Kirschner from Microsoft, Tadas Antanavicius (PulseMCP), and Gagan Bhat from Anthropic. It was a chance to connect with VS Code team members and other MCP adopters in person.

## Other Highlights

I took my first Waymo rides around San Francisco, which was an experience in itself.

I also took home a hackable badge from the event after quickly hacking it to show the GitHub MCP Server star count (which has almost hit 25k stars!).


GitHub Universe: MCP Server Demo


I've been using [reMarkable](https://remarkable.com/) tablets since 2021. They're excellent for capturing notes, annotating PDFs, and generally keeping your focus where it should be. But getting content back out has always been a friction point, and I finally got annoyed enough to do something about it.

I built an [MCP](https://modelcontextprotocol.io/) server that lets AI assistants read your reMarkable documents directly. What started as a weekend project turned into something genuinely useful.

## Why I Built This

I've been gradually building up an [Obsidian](https://obsidian.md/)-based second brain for my MCP R&D work. It's where I index ideas, draft articles, prepare conference talks, and collect academic papers. The system works well for digital content, but my reMarkable had years of handwritten notes that weren't part of it. Conference notes, research annotations, talk outlines, margin notes on PDFs, ideas and TODO lists. All that knowledge was trapped on the device, invisible to my Obsidian vault and not accessible for AI agents either.

reMarkable does offer ways to export content and get OCR through their cloud service. But somehow I never actually did it. The friction of manual export, one document at a time, meant those notes just sat there accumulating.

Two things inspired me to finally solve this. First, my day job. I build the [GitHub MCP Server](https://github.com/github/github-mcp-server), so I spend a lot of time thinking about MCP tool design. Second, [Scrybble Sync](https://scrybble.ink/), which syncs reMarkable to Obsidian. Scrybble showed me what was possible, but I wanted something that worked directly with AI assistants rather than as a sync tool.

So I built remarkable-mcp. Within a day, I had completely indexed everything from my reMarkable. Hundreds of documents spanning years of notes. Ideas I'd forgotten about resurfaced. Connections I'd missed became obvious. My handwritten notes were no longer lost; they were searchable, queryable, and integrated into my knowledge system. Sometimes you need to build the tool that finally makes you do the thing you've been putting off.

## SSH Mode is the Way

My first version used the reMarkable Cloud API. It worked, but felt sluggish. Then I pivoted to using SSH to connect directly to the tablet over USB, and the difference is dramatic (the cloud APIs were just not built to support my use-cases although the MCP Server still supports it). Fortunately, I already had developer mode enabled on my tablet so it was very straightforward to get going.

Connecting via USB and SSH gives you direct filesystem access. No cloud roundtrip, no subscription gatekeeping for basic functionality. The tablet becomes a local device you can query instantly. The [reMarkable guide](https://remarkable.guide/guide/access/ssh.html) has excellent documentation on enabling developer mode.

I should note that I actually enjoy reMarkable Connect. I have both a Paper Pro Move for when I'm out of the house and a Paper Pro for reading academic papers, and cloud sync across devices is genuinely useful. I just think basic programmatic access to your own documents should be available to all owners, not just subscribers. SSH mode makes that possible.

## Five Tools, Not Fifty

The reMarkable API has dozens of endpoints. I could have exposed them all as tools. Instead, I shipped five [MCP tools](https://modelcontextprotocol.io/docs/concepts/tools):

| Tool | Purpose |
|------|---------|
| `remarkable_read` | Extract text from any document |
| `remarkable_browse` | Navigate folders or search by name |
| `remarkable_search` | Search content across multiple docs |
| `remarkable_recent` | See what you've worked on lately |
| `remarkable_status` | Check connection health |

That's it. These five cover maybe 95% of what you'd actually want to do. The constraint forced better design decisions. Each tool is deeply capable rather than superficially complete.

This approach comes from [our research on the GitHub MCP Server](https://github.blog/engineering/copilot/how-were-making-github-copilot-smarter-with-fewer-tools/). We found that having too many tools actually decreased resolution rates by 2-5%. Models get confused when they have dozens of similar-looking options. Fewer, more capable tools perform better.

## Native Text Extraction

Something most people don't know: reMarkable tablets running v3+ software store typed text in a structured format. If you use the Type Folio keyboard or the on-screen keyboard, that text is stored as data, not pixels.

The [`rmscene`](https://github.com/ricklupton/rmscene) library can parse it directly. This means instant text extraction for Type Folio documents, typed annotations on PDFs, quick notes, and any typed content in notebooks. No OCR needed, no delay, no cost.

For handwritten content, you'll need OCR.

## Handwriting OCR

I originally used Tesseract for OCR. It's free, offline, and works great for printed text. For handwriting? Pretty terrible unless you write like a font. My handwriting is atrocious, so bad my 10-month-old daughter probably writes better than I do, so Tesseract was essentially useless for my notes.

Google Cloud Vision is a different story. Their handwriting recognition is genuinely impressive. My scrawled meeting notes become readable text. The service offers 1,000 free requests per month, then costs about $1.50 per 1,000 images. That's reasonable for actual use.

The server supports both: Google Vision for quality, Tesseract as an offline fallback.

## Response Design

David Cramer's [work on MCP tool design](https://cra.mr/subagents-with-mcp) influenced how I think about responses. Every tool response includes a `_hint` field suggesting logical next steps:

```json
{
  "documents": [
    {"name": "Meeting Notes", "path": "/Work/Meeting Notes"}
  ],
  "_hint": "Found 1 document. To read: remarkable_read('Meeting Notes')."
}
```

This matters more than you'd think. AI models work better when responses guide them toward sensible follow-up actions. Errors don't just say "failed," they explain what went wrong and suggest fixes:

```json
{
  "_error": {
    "type": "document_not_found",
    "message": "Document 'Meting Notes' not found",
    "suggestion": "Did you mean: 'Meeting Notes'?",
    "did_you_mean": ["Meeting Notes", "Meeting Notes 2"]
  }
}
```

## Root Path Filtering

Sometimes you don't want an agent accessing all your documents, so I added: `REMARKABLE_ROOT_PATH`. Set it to a folder e.g. `/Work` and the AI only sees your work documents. Set it to `/Journals` and it only accesses your journals. Whatever you need.

```json
{
  "env": {
    "REMARKABLE_ROOT_PATH": "/Work"
  }
}
```

This is useful for privacy (limiting AI access to specific folders), for focus (pinning to a project folder during deep work), and for context (different configs for different AI workflows). When configured, all paths are relative to the root. Browsing `/` shows the contents of `/Work`. Documents outside the provided root simply don't exist to the AI.

## MCP Resources

Beyond tools, MCP supports [Resources](https://modelcontextprotocol.io/docs/concepts/resources), which are data the AI can access directly without tool calls. Every document registers as a resource:

```
remarkable:///Meeting%20Notes.txt
remarkable:///Work/Project/Report.txt
```

In SSH mode, you also get raw file access (which provides the full text of the PDF or EPUB):

```
remarkableraw:///Research%20Paper.pdf
remarkableraw:///Books/Deep%20Work.epub
```

These appear in VS Code's MCP resource panel, letting you attach documents directly to conversations.

## Technical Stack

- **[FastMCP](https://github.com/jlowin/fastmcp)** for the [MCP server](https://modelcontextprotocol.io/docs/concepts/servers) framework
- **rmscene** for native .rm file parsing (typed text, no OCR)
- **PyMuPDF** for PDF text extraction
- **[Google Cloud Vision](https://cloud.google.com/vision)** for handwriting OCR
- **Paramiko** for SSH transport

The codebase is modular: separate files for tools, resources, API interactions, and extraction logic. Makes testing easier and keeps the mental model clean.

## What I Learned

**Design for intent, not capability.** Users don't want to "call the document metadata endpoint." They want to "find my notes from last week."

**SSH beats cloud for local devices.** Direct access is faster, works offline, and doesn't require subscriptions for basic functionality.

**Guide the next action.** Response hints aren't hand-holding. They're context that helps AI models make better decisions.

**Good OCR is worth paying for.** Tesseract is fine for printed text. For handwriting, Google Vision is transformatively better.

**Constraints improve design.** Limiting to five tools forced me to make each one deeply capable.

## Try It

The package is available on [PyPI](https://pypi.org/project/remarkable-mcp/).

### SSH Mode (Recommended)

See the [SSH Setup Guide](https://github.com/SamMorrowDrums/remarkable-mcp/blob/main/docs/ssh-setup.md) for enabling developer mode on your tablet.

Add to your `.vscode/mcp.json` or similar:

```json
{
  "inputs": [
    {
      "type": "promptString",
      "id": "google-vision-key",
      "description": "Google Vision API Key",
      "password": true
    }
  ],
  "servers": {
    "remarkable": {
      "command": "uvx",
      "args": ["remarkable-mcp", "--ssh"],
      "env": {
        "GOOGLE_VISION_API_KEY": "${input:google-vision-key}"
      }
    }
  }
}
```

### Cloud Mode

1. Visit [my.remarkable.com/device/desktop/connect](https://my.remarkable.com/device/desktop/connect) to get a one-time code
2. Convert it to a token:

```bash
uvx remarkable-mcp --register YOUR_CODE
```

3. Add to your `.vscode/mcp.json`:

```json
{
  "inputs": [
    {
      "type": "promptString",
      "id": "remarkable-token",
      "description": "reMarkable API Token",
      "password": true
    },
    {
      "type": "promptString",
      "id": "google-vision-key",
      "description": "Google Vision API Key",
      "password": true
    }
  ],
  "servers": {
    "remarkable": {
      "command": "uvx",
      "args": ["remarkable-mcp"],
      "env": {
        "REMARKABLE_TOKEN": "${input:remarkable-token}",
        "GOOGLE_VISION_API_KEY": "${input:google-vision-key}"
      }
    }
  }
}
```

The [Quick Install badges](https://github.com/SamMorrowDrums/remarkable-mcp) in the README handle VS Code configuration automatically.

## What's Next

The [GitHub issues](https://github.com/SamMorrowDrums/remarkable-mcp/issues) track future plans: write support, more OCR providers, semantic search, and export features. But for now, the core experience is solid. Your reMarkable as a queryable second brain. If you encounter any problems, that's the best place to file them.


Building an MCP Server for reMarkable


<p><iframe allow="monetization" class="embedly-embed" src="//cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2F0d9TR91iLx0%3Ffeature%3Doembed&amp;display_name=YouTube&amp;url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D0d9TR91iLx0&amp;image=https%3A%2F%2Fi.ytimg.com%2Fvi%2F0d9TR91iLx0%2Fhqdefault.jpg&amp;key=d932fa08bf1f47efbbe54cb3d746839f&amp;type=text%2Fhtml&amp;schema=youtube" width="640" height="360" scrolling="no" title="LastMile AI Silsila Sessions: MCP at Hyperscale video" frameborder="0" allowfullscreen="true"></iframe></p>

I had the pleasure of joining the [LastMile AI](https://lastmileai.dev/) Silsila Sessions this week, where we went deep on what it really takes to make MCP agents production-ready. The session brought together some fantastic speakers to discuss the core challenges of building secure, scalable agent systems.

## The Panel

- **Sam Morrow (GitHub)** — I broke down what it really looks like to run an MCP server at scale, from tool bloat to evals to security surprises.
- **Tobin South (WorkOS)** — Unpacked the practical realities of OAuth, agent identity, and enterprise-grade authentication.
- **Sarmad Qadri (LastMile AI)** — Shared upcoming MCP spec updates and how they unlock more advanced agent behaviors.

## Key Takeaways

One of my main points during the session was around the tradeoffs between atomic tools and higher-level workflow tools:

> "Atomic tools give you flexibility, but too many create context bloat and tool confusion — workflow-style tools are where agents really shine."

This is something we've learned firsthand running MCP at hyperscale at GitHub. When you're operating at this level, the design decisions around tool granularity become critical. Too many fine-grained tools and you overwhelm the model with choices; too few and you lose the flexibility that makes agents powerful.

We also discussed:
- Running MCP at hyperscale and the unique challenges that come with it
- OAuth and agent identity in enterprise contexts
- Upcoming MCP spec changes that open the door to long-running workflows and smarter agents

Huge thanks to [LastMile AI](https://lastmileai.dev/) for hosting, and to everyone who joined live. These conversations are invaluable for pushing the MCP ecosystem forward.


LastMile AI Silsila Sessions: MCP at Hyperscale


Toby Padilla, Harald Kirschner and I will be live-streaming on The Context, on the MCP Developers Summit YouTube channel this coming Tuesday.

https://www.youtube.com/live/rtht8dbwe5U?feature=shared

The channel hosts the amazing content from their conference, as well as numerous videos and livestreams on all sorts of MCP and AI related topics.

I'm honoured to be invited to talk about my involvement in building the GitHub MCP Server, there have been so many legends in the field on their channel! I can't wait to share the ideas, problems and dreams we have.

The Context - Special Episode ft. GitHub & Microsoft



<p><iframe allow="monetization" class="embedly-embed" src="//cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FT44T55wvDD0%3Ffeature%3Doembed&amp;display_name=YouTube&amp;url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DT44T55wvDD0&amp;image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FT44T55wvDD0%2Fhqdefault.jpg&amp;key=d932fa08bf1f47efbbe54cb3d746839f&amp;type=text%2Fhtml&amp;schema=youtube" width="640" height="360" scrolling="no" title="YouTube embed" frameborder="0" allowfullscreen="true"></iframe></p>

> Join us for VS Code Live: Extending Agent Mode, a livestream showing how to unlock the full potential of agent mode using MCP servers and extension tools. We'll kick things off with a look at VS Code's vision in the MCP space, followed by demos from the VS Code team. Plus, we'll spotlight powerful MCP servers and extensions that you can start using in agent mode right away - featuring special guests you won't want to miss!

I had great fun chatting with Olivia Guzzardo McVicker (@OliviaGuzzardo) on the VS Code Livestream on YouTube about the [Remote GitHub MCP Server](https://github.blog/changelog/2025-06-12-remote-github-mcp-server-is-now-available-in-public-preview/) that launched during the episode! We chat about the server, I demo some functionality live and we also chat about using and extending agents in general.

I hope she'll have me back on again in future to see what we've achieved over the next few months.

VS Code Live: Extending Agent Mode


If you're like many people, the rapid rise of AI tools might bring a mix of excitement and, perhaps, some unease. It's natural to wonder what it all means for how we work. I've been thinking a lot about this, especially in my role with GitHub Copilot (although comments and opinions on this blog are my own), and I've noticed something that feels important to share.

Will AI make our existing tasks faster and easier, or will it replace our jobs entirely? I believe the answer is neither.

I've come to a different conclusion, which I think is more honest: AI probably won't make your job easier in the ways you expect, but it *can* help you do work that's genuinely better than what you might have produced before, and I do not believe we have arrived at an employment extinction event.

---

## The Quality Shift

When powerful AI tools become widely accessible, something interesting happens to the value of work.

Standard, good-enough output becomes abundant. Whether it's code, writing, or analysis, the baseline of acceptable is easier for everyone to reach. This also means that simply meeting that baseline is no longer a differentiator, worse than that it's almost indistinguishable from the noise floor of AI slop that people are already cursing the internet with. Tasks AI can do excellently autonomously, should be offloaded to AI, so what is left?

Truly excellent work—work that demonstrates deep understanding, thoughtful judgment, or unique insight—becomes necessary to stand out from the new noise floor.

This isn't just about working harder or faster. It's about the nature and quality of what we produce, and redefining what our best work is.

> Something I told 16 yo: In the near term, AI will increase variation in the returns for work. For example, mediocre programmers are now finding it hard even to get hired, but great programmers are making more than ever.

> Something else I told him: This is a trend that has been going since the stone age. Technology always increases variation in the returns for work. The bottom end is anchored at zero. Technology lets the top end move.

*Paul Graham*

---

## Moving Beyond "Write This For Me"

I've noticed a common pattern (and I've done this myself) when we first start using AI tools:

We provide minimal input, ask the AI to generate something complete, and then make a few tweaks.

It often works, to a degree. The output is usually... fine. But it rarely feels remarkable, and sometimes there's a subtle "off-ness" that's hard to pinpoint or fix with simple edits.

I've come to believe this isn't necessarily a limitation of the tools themselves, but more about how we're engaging with them.

---

## Finding A More Collaborative Approach

What's been working better for me is treating AI less like a vending machine and more like a thinking partner:

- Using it to explore various approaches to a problem, some of which I wouldn't have considered on my own.
- Asking it to critique my work (and then, importantly, critiquing its critique in return). With current models you have to push hard for critical feedback, they behave like sycophants by default, so ignore their flattery or at least remain suspicious of it.
- Using it to help articulate complex thoughts I'm struggling to put into clear words.
- Giving it rich context: not just *what* I'm trying to do, but *why* and what the broader goals are. This includes doing real research. Data, citations and subtle nuance are all things you should provide as context. 

It's important to note that these approaches often don't save time upfront. In fact, they can sometimes take longer than just diving into the work directly. The real difference I'm seeing is in the depth and quality of the final result.

---

## A Personal Example

Recently, I was wrestling with an annual performance self-reflection. My early drafts lacked a narrative that contextualised the relevance of my work to the company as a whole, undersold things and also lacked hard numbers, citations and other additions that would give clout to my words.

Instead of prompting AI to "write my self-reflection," I tried a more layered process:

I gathered all the relevant context—project outcomes, feedback from colleagues, company values, specific challenges I'd encountered—and then worked with an AI to help me structure and articulate this information coherently.

We went back and forth multiple times. I'd challenge its framing of a point; it would prompt me to consider an angle I'd missed. We explored different ways to structure the narrative.

The final document definitely took longer to create than if I'd just pushed through on my own. But it was clearer, more balanced, and, I think, more insightful than what I would have produced in isolation. I expect the next one will be much faster too.

---

## Some Things I've Learned About Working With AI

If you're looking to explore this kind of collaborative approach, here are a few things I've found helpful:

- **Be generous with context.** AI tools provide better assistance when they understand not just *what* you want, but *why* you want it and what success looks like.

- **Use it for thinking, not just producing.** Some of the most powerful uses involve exploration, brainstorming, critique, and refining ideas, rather than just generating finished products from scratch.

- **Expect to iterate.** As screenwriting guru Robert McKee wisely said: "Secure writers don't sell first drafts. They patiently rewrite until the script is as director-ready, as actor-ready as possible. Unfinished work invites tampering, while polished, mature work seals its integrity." This principle holds true for AI collaboration; the real value often emerges through a process of refinement.

- **Give yourself permission to experiment.** The most effective ways to use these tools are still being discovered. What works best for you might be different from what works for others, and new models are released almost daily.

---

## It's Not Just About Productivity

One of the most interesting realizations for me has been that the primary value here isn't solely about boosting productivity in the traditional sense.

A thoughtful VP at Cloudflare, William Allen, put it well: "The lesson isn't 'do more with less'—it's 'do more with more.'"

The opportunity isn't just to produce the same work faster. It's about raising the ceiling on the quality and impact of what we can achieve.

---

## A Suggestion

If you're navigating the world of AI tools, perhaps consider shifting your primary expectation from "this will make my current job easier" to "this might help me do work I'm even more proud of."

With that mindset, the learning curve can feel different. The occasional frustrations or clunky outputs become part of the investment in a new skill, rather than just failures of the tool.

And the collaboration—because that's what it truly is when it works best—can lead to outcomes that genuinely surprise you, in a good way.

Not necessarily faster, not always easier. But potentially, meaningfully better.

---

## A Note on How This Came Together

If you've made it this far, thanks for reading! I wanted to share a little about the process behind this piece, as it mirrors some of the iterative collaboration I've been discussing.

This article didn't spring out fully formed. It started as a stream-of-consciousness reflection on my experiences and observations. From there, it went through quite a journey:

*   I ran initial drafts and ideas through four different AI models, using them not just for generation, but for critical discussion, feedback on tone, and to explore different ways of articulating the core message.
*   There were many rounds of manual edits and rewrites based on my own reflections and the AI's input.
*   I consciously wove in quotes from people whose ideas resonated with the points I wanted to make.
*   Crucially, I also shared drafts with human friends and colleagues to get their invaluable perspectives and feedback.
* I consciously left in em dashes (I am not pretending I didn't get help from AI, why would I? This is exactly what I wanted to write and better use of punctuation is a gift)
*   Finally, I let it sit for a while, giving myself time to reflect and ensure it felt authentic to my voice and experience before feeling ready to share it.

It was a process of layering, refining, and sometimes stepping away. I genuinely hope you enjoyed reading it, and more importantly, that you found something to consider in your own interactions with AI.

For my part, I certainly enjoyed the process of producing it and learned a lot more about my own writing style and how to collaborate effectively with these new tools along the way.

Blog