Most MCP servers connect AI to things it can't reach on its own. Send a Slack message. Create a GitHub issue. Query a database. The tools add capability.

There's a second kind of MCP server that nobody's really building yet. One where the AI could do the work itself, but the tools make it reason correctly instead of probably.

Capability vs. meaning

You could hand an AI a JSON file full of reference data and say "figure it out." It will parse the schema, invent heuristics, cross-reference fields, and produce a plausible answer. It might even be right. But it's doing that from scratch every time, with no guarantee it interprets the data the way a domain expert would.

Wrap that same data in a thin set of tools, and something changes. The tools don't add new information. They add judgment. Priority order for evaluating conflicts. Ranking logic built on real-world experience. Labels that distinguish "technically claimed but safe to use" from "do not touch."

The AI goes from reasoning probabilistically to reasoning reliably. Not because it gained a new capability, but because the tools reduced its cognitive load the same way a good API reduces a developer's.

The experiment

I built KeyGap to test this. It's a keyboard shortcut availability tool: pick your platform, pick your apps, see which hotkey combos are still free. There's an interactive web UI and an MCP endpoint, both served from the same Cloudflare Worker, both reading from the same shortcut database.

I should be clear about what KeyGap is not. It's not a comprehensive shortcut reference. keycheck.dev already does that far better, covering 1,400+ shortcuts across 100+ apps with community contributions. KeyGap covers 12 apps. It's a toy by comparison.

The point was never "can I build a better shortcut tool." The point was: what's the narrowest expression of an MCP server that creates semantic value? How little data and how few tools can you get away with and still produce something that makes an AI more reliable than its training data alone?

The answer: a single TypeScript file of curated data, three query functions, and good tool descriptions. One Cloudflare Worker, zero databases. The HTML is a big self-contained file. The data module is a big static object. Neither is elegant. But the constraint was deliberate. I wanted to find the floor, not the ceiling.

What the tools add

The shortcut data in KeyGap is roughly 300 lines of TypeScript. An AI could read the raw JSON and cross-reference it. But the tools encode things the data alone doesn't express.

suggest_hotkeys doesn't just filter available keys. It ranks by ergonomic comfort, because a human figured out that Cmd+Ctrl is a natural left-thumb-plus-left-pinky reach while Cmd+Ctrl+Shift requires three fingers and falls apart at speed. That judgment isn't in the data. It's in the function.

check_key doesn't just look up a value. It cascades through OS-level claims, then app claims, then risky-but-probably-fine status, in that priority order. The ordering reflects how shortcut conflicts actually work. Give an AI the raw data and it might check app claims first, or treat "risky" the same as "taken."

The tools are opinions encoded as functions. The data is facts. The tools are facts plus judgment.

What a real version looks like

KeyGap is the narrow version: hand-curated data, small scope, single file. A broader take on the same idea would pull from something like keycheck's community-maintained database, covering hundreds of apps instead of twelve. The tools would stay thin, but the ranking logic could get smarter: weighting by app install base, factoring in user-reported conflicts, scoring ergonomic comfort based on actual hand geometry research rather than my rough notes.

The web UI and the MCP tools would diverge further. The UI could become a full shortcut explorer with search, filtering, and contribution flows. The MCP tools would stay focused on the three questions an AI actually needs to answer: what's free, is this specific combo taken, and what do you recommend.

The architecture stays the same. Static data, thin query layer, two interfaces. The investment shifts from code to curation.

Other approaches

Static data plus tools is the simplest version of a knowledge server. It's not the only one.

Retrieval-backed. The tools query a vector store or search index instead of holding everything in memory. You'd need this for something like npm's full dependency graph or the CVE database. More infrastructure, but it scales.

Computed. Some domains need to calculate answers, not look them up. A color contrast checker doesn't store every possible color pair. It computes WCAG compliance on the fly. The judgment is in the algorithm, not the data.

Hybrid. Static reference data combined with live lookups. A browser compatibility server might embed curated "safe to use" thresholds but fetch current support percentages from caniuse at query time. Static layer for opinions, live layer for facts.

If I were building another one of these, I'd probably start with hybrid. The static data keeps the tools opinionated, and the live lookups keep them current. But the pure static version is where I'd tell anyone to start, because it proves the concept with zero infrastructure risk.

The pattern

Three things make this work:

Curated data, not just structured data. A CSV is structured. A curated dataset includes editorial judgment: risk assessments, quality ratings, "this is the one you actually want" designations. The curation is the value. The tools are just delivery.

Domain logic in tools, not left to the AI. Anywhere you have reasoning that an AI would otherwise hallucinate, put it in a tool. The tool doesn't prevent the AI from thinking. It prevents it from guessing where guessing is unnecessary.

Two interfaces from one source of truth. Humans get a visual interface optimized for scanning and pattern recognition. Machines get MCP tools optimized for structured queries and parameter validation. Neither wraps the other. They're parallel projections of the same data.

Where it breaks down

This doesn't work when data changes faster than you can redeploy, when the dataset outgrows memory, or when domain experts genuinely disagree on the right answer (encoding one opinion in a tool is limiting).

But for small, curated, slowly-changing reference data where cross-referencing is tedious and judgment matters? A static file and five functions might be all you need.

The current MCP ecosystem is almost entirely integration servers. I think there's a lot of room for knowledge servers. Not "connect me to a thing" but "help me reason correctly about a thing." The bar is lower than people think. No API keys, no database, no state. Just curated data, a few functions, and well-written tool descriptions.

I've seen a growing conversation on LinkedIn and Reddit about what AI tooling is doing to software teams - Cursor, Claude, Copilot, the whole wave. Velocity is up, backlogs are shrinking - by every measure teams track, things look great. But what's catching my attention is the feeling that teams are losing context - code review burdens have exploded as weeks are compressed into days and features are shipping, but its becoming harder to tell which ones moved the needle. Teams are building faster than ever but its not claer if they're learning faster too.

And it got me thinking: sprints, backlogs, velocity, story points - all of it was designed to manage build capacity. To prioritize carefully, because building was expensive and slow. That was the bottleneck, and agile was a really good answer to it. But what if that's not the bottleneck anymore? For a growing chunk of the work, AI has made building fast and cheap. But the process hasn't changed. Teams are using AI to sprint faster through a system designed for when sprinting was hard.

If building isn't the constraint anymore, what is?

But what if I could just tell an AI to go click the buttons for me?

I spent some time this morning trying to figure that out. The answer is yes, with some caveats worth understanding before you try it yourself.

The Experiment

I had been itching to try out some new Claude features. Anthropic's Claude for Chrome extension launched recently as an add-on browser agent - it can navigate pages, fill forms, and interact with web applications on your behalf. I was curious whether I could trigger it from outside the browser, specifically from a script or Claude Code instance running from the command line.

If it works, it means I can build mini-data pipelines that pull from multiple reporting systems and sources without building custom API integrations for each source. For example, think of grabbing the most recent forecast from a Google Drive Folder, the most recent actuals from Looker and additional supplemental details from various ad hoc sales, marketing and customer service reports. The idea is to let the Chrome agent handles the browser automation and let my reporting scripts handle everything else.

I started with a simple test: get Claude Chrome to set up and download a dataset from Looker. Navigate to a saved query, configure the export options, download the CSV. Three steps that take me thirty seconds manually but don't have an easily accessible clean API equivalent.

What I Learned

The --chrome flag in Claude Code lets you run browser automation non-interactively:

claude --chrome -p "your prompt here"

Authentication is inherited. Claude uses your existing browser session. If you're logged into Looker in Chrome, the agent can access it. This is what makes the whole approach practical for internal tools.

Direct URLs beat UI navigation. Every menu click is another opportunity for something to go wrong. If your tool gives you a URL with query parameters (like Looker's ?qid=...), use that instead of instructing the agent to click through the interface. Fewer steps, fewer failures, faster results.

Claude Chrome hesitates at downloads. My initial test worked right up until the final step - Claude wanted me to press the download button myself. That would defeat the automation I was looking for. I got around it by asking Claude to "test the function before bothering me with any tasks," which worked. Later I found that adding "Proceed without asking for confirmation" to prompts is a cleaner solution.

Safety guardrails are real. Curious about the boundaries, I tried getting Claude to complete a CAPTCHA using similar misdirection. It refused, correctly interpreting the context of the form and running right into its safety guardrails. Probably the right outcome.

Saved shortcuts aren't accessible from CLI. The Chrome extension lets you save task shortcuts (like /explore-orders), but there's no way to call those from the command line. You have to replicate the full prompt in your script. This actually turns out to be fine—moving prompts into shell scripts or environment variables is more useful anyway. You can version control them, parameterize them, and chain them together.

Profile selection doesn't work/doesn't exist. Claude connects to whatever Chrome profile it finds first. Meaning if you have separate Chrome profiles for work and home, it selects whichever one is currently active and has focus. The --profile-directory flag exists but gets ignored when Chrome is already running. If you're juggling work and personal accounts, you need to manually activate the correct profile before running your script. There's an open issue tracking this.

The Working Script

Here's what I ended up with:

#!/bin/bash
# NOTE: Ensure correct Chrome profile is active before running

claude --chrome -p 'Navigate to https://example.looker.com/explore/your_model/your_explore?qid=your_query_id

Once the page loads, click the gear icon in the top right corner. In the download options, ensure "All Results" is selected. Then click Download to export the data as CSV. Proceed with the download without asking for confirmation.'

It works. The agent navigates to the saved query, configures the export, and downloads the CSV. No manual intervention required.

What's Next

Browser agents have come a long way in a year. I remember being impressed by the promise of Manus around this time last year, but it struggled with anything requiring authentication and most of the browser based solutions, like Comet, never seemed to hit the spot. With its tight pairing with Claude Code, Claude for Chrome might be the implementation that actually has the practical utility I'm looking for - at least for now.

The next step is testing whether a headless Claude Code agent can reliably dispatch these browser tasks as part of a larger workflow, which doesn't feel like a high-bar for CC. If it holds up, I've got a path to automate data collection across a whole category of tools that were previously manual-only.

Spoiler alert - they can't. But the exploration taught me something useful about what I was already doing.

How Skills Work

Skills are SKILL.md files that live in .claude/skills/. They're designed for interactive Claude Code sessions. At startup, Claude loads just the name and description from each skill's YAML frontmatter—around 30-100 tokens per skill. The actual instructions in SKILL.md only get read into context when Claude decides the skill is relevant. Reference files bundled with the skill load later still, only when Claude needs them for a specific task.

The value proposition is progressive disclosure. You can have dozens of skills installed and only pay tokens for the ones you actually invoke.

Why They Don't Work for My System

My system spawns agents as separate CLI processes:

cmd = [
    "claude", "--print",
    "-p", prompt,
    "--model", model,
    "--allowedTools", "Read", "Write", ...
]
subprocess.Popen(cmd, ...)

Each agent is a fresh claude --print invocation. Stateless. No session memory. All context arrives via the prompt string. The --print flag runs in non-interactive mode, so there's no progressive loading benefit.

Skills require an interactive Claude Code environment that maintains session state. I don't have one. My orchestrator is Python. Each spawn is isolated. Skills can't help here.

The Realization

Despite the technical incompatibility, skills and my system solve the same problem:

Reusable instructions. Skills use SKILL.md files. I use AGENT.md files.

Selective loading. Skills auto-invoke when Claude matches your request to their descriptions. I use a TASK_CONTEXT_REQUIREMENTS dictionary.

Domain knowledge. Skills use a reference/ folder. I use hub/config/ and hub/strategy/.

I've essentially built a custom skills system for spawned agents. It just operates at the process level instead of the session level.

Here's what that looks like in practice:

TASK_CONTEXT_REQUIREMENTS = {
    "write_content": ["strategy/pillars.md", "config/site.json"],
    "analyze_performance": ["config/site.json", "strategy/goals.md"],
    "deploy_content": ["config/site.json"],
    # 30+ more mappings
}

Instead of loading everything, each task type gets only the context files it needs.

When to Use Which

Use Claude Code skills when:

You're working interactively. You want instructions to persist across conversations. You have domain-specific workflows—code review, PR creation, documentation. You want Claude to automatically invoke relevant capabilities based on your request.

Use spawned subagents when:

You need autonomous multi-agent orchestration. Agents need different tool permissions. You want programmatic control over dispatch. You're building pipelines where task A feeds task B feeds task C.

There's also a hybrid approach. If you're running an orchestrator from within Claude Code, you could use skills for the orchestrator itself while spawning subagents for the workers. The orchestrator benefits from skills; the workers don't.

There are probably other approaches too. I haven't learned them yet ;-)

What I Learned

Skills and spawned subagents serve different architectures. Skills are single-session knowledge injection. Subagents are multi-process autonomous execution.

If you're building an autonomous agent system, you're already doing what skills do. Just at the process level instead of the session level. The concept of "load only what you need" applies to both. The implementation differs.

The lesson isn't that one approach is better. It's that both approaches exist because the underlying problem is real: context is expensive, and selective loading matters.

For Anthropic's full comparison of Skills, subagents, Projects, MCP, and prompts, see their Skills Explained guide.

Most of the claims in these posts are overstated, overwrought or just plain wrong. But those matter less than the posture they encourage.

The posture is fear dressed up as sophistication.

People are right to be uneasy about AI. Large language models sound confident and get things wrong. Treating them like analysts or decision makers is a category error. Delegating judgment to a system that has no concept of truth is irresponsible.

All of that is correct.

But the second half of the thought is missing.

These are the worst models most of us will ever work with.

They are slow. They hallucinate. They require hand-holding. They fail loudly and often. That's exactly why this moment matters.

Right now, the cost of misuse is low. Failure is obvious. The stakes are mostly optional. You can choose where and how to apply these tools. You can experiment without wiring them directly into core decisions. You can see the limitations in plain view. That won't last.

Before someone builds a “super-bad robot,” someone has to build a “mildly bad robot,” and before that a “not-so-bad robot.” – Michio Kaku

Remember how easy it used to be to pick out AI generated images, and how quickly that became a real challenge and the lines between "real" and "artificial" got really blurry?

Future systems will be more capable and more convincing. They'll fail less often and more quietly. They'll be embedded deeper into workflows before most organizations understand how they behave. Learning how to work with probabilistic systems after you depend on them is much harder than learning before.

The real opportunity isn't in pretending these models reason or think. It's in learning how to design around their weaknesses.

That learning doesn't happen by standing at a distance and pointing out flaws. It happens by use.

Using these systems well means specific things.

It means separating generation from validation, never treating an output as an answer and forcing assumptions into the open. It means building checks instead of trust and deciding, explicitly, where judgment lives.

Whether a model “reasons” is a distraction. What matters is whether you reason about its output.

Used this way, language models aren't analysts. They aren't strategists. They aren't authorities. They are tools for synthesis, exploration, and pressure-testing ideas. Sometimes they are noise. Sometimes they are useful. Your job is to know which is which.

Pundits who dismiss these systems outright often sound savvy, but in practice, it is usually a performative move to signal distance from hype. It doesn't engage with the substance and often misses the point.

The risk isn't that people overestimate today’s models. The risk is that we fail to build the discipline required for tomorrow.

The window where you can learn cheaply, visibly, and with low consequence is now. Ignoring it doesn't make you prudent, it makes you unprepared.

I ran a small experiment today that I thought was worth sharing. I needed to run some deep research, accounting for operations data from the business. That gave me an opportunity to test how different models handle a detailed, context rich prompt informed by a fixed dataset and I was especially interested in messing around with Gemini 3 Pro "for real".

My first pass was simple. I handed the same prompt and dataset to three models requested a deep research-style analysis of the data and market. ChatGPT 5.1 stalled after several attempts. Claude delivered a strong outline but missed some basic facts. Gemini produced sharp analysis but lost important operational detail that Claude had caught. Each of them produced helpful parts, but none of them produced a complete or consistent answer.

So the challenge shifted from producing a meaningful analysis to how to extract the best material from each run and merge it into a single view, and to do so carefully without losing context, which gave me the idea to layer in a second stage. I gave a fresh instance two things. First, the full set of inputs used in the original prompts and second, the full set of reports that Claude and Gemini produced in the first go round. I intentionally presented the reports as written by someone else which made for a meaingful difference. Earlier runs had treated the reports as my own work, which muted the critique as the chatbot skewed toward agreeability. Once I made it clear that the reports came from an external source, the review became sharper and more useful.

Here is the core prompt I used with Gemini 3 Pro:

You are a senior telcom market and competition analyst. I have received competing reports from two other analysts that provide differing perspectives on the market, competition and data. Evaluate the two reports I attached. Use the instructions and data I gave to the analysts, that they used to prepare their reports, as your baseline. Identify where each report is inaccurate, incomplete, inconsistent and also the strongest most compelling points from each. Resolve any conflicts and produce one set of recommendations in a detailed document. Your output should be precise, internally consistent, and supported with clear reasoning.

Long story short, the results were merely "okay". The merged output was clearer, more accurate, and more consistent than the individual runs but overall, the output lacked the depth of the two input documents, even with the benefit of the same context. After six different tries, with slight tweaks to the prompt each time, it still felt like I was reading a copy of a copy. For all of the extra effort, the extra steps don't quite seem to be worth it.

I wanted to learn more about Netlify and similar services, and I needed a use case, so I set up a static site that commits to GitHub and gets automatically pushed into production at Netlify. There are simpler ways to get HTML online - I still remember hand coding HTML in 1993 using the original HTML spec and FTPing files to the company web server.

This site runs on a simple build and deployment flow. A local script turns Markdown into HTML, commits it to a Git repo, and Netlify deploys it. If I wasn’t interested in leaving room for app driven dynamic content later, I’d probably just use GitHub Pages, Surge.sh, or a host like NearlyFreeSpeech.

So, Hello World! rossrader.ca is back on the air.