So instead of just pressing the key like a normal person, i spent an evening building a thing that watches my face and does it for me.

Eye tracking (no)

My first idea was gaze tracking. Look at the right side of the screen, page turns. Look at the left, goes back. Sounds cool.

It doesn't work. Figuring out where your pupils are actually pointing needs way better hardware than the little camera above your screen. And even if it kinda worked, you'd be turning pages every time you looked at the clock or someone walked into the room.

So gaze is out. What works instead is a gesture, something you clearly did on purpose. Not "where is he looking" but "did he just do a thing with his face".

A wink is perfect for this. You never accidentally wink.

wink right eye → next page wink left eye → previous page

Blendshapes

Now the question is how does a computer know i winked.

Google has a model called MediaPipe Face Landmarker. You give it one frame from your webcam and it gives you back a bunch of information about the face it found in it.

The part i needed is called blendshapes. These are around 52 numbers, and each number tells you how much one specific facial thing is happening right now, from 0 to 1. There's one for smiling, one for each eyebrow going up, one for puffing your cheeks.

And there are two called eyeBlinkLeft and eyeBlinkRight.

eyes wide open   →  0.02
normal           →  0.15
eye fully shut   →  0.95

That's basically the whole thing. Someone already did the hard part of looking at a face and turning it into numbers, i just have to read two of those numbers 30 times a second and decide if it counts as a wink.

The naive approach

So the first version was pretty much this:

if right eye is shut and left eye is open:
    press page down

Ship it, what could go wrong.

Well first it crashed. Not a normal error, an actual C++ stack trace:

Check failed: service_ Service is unavailable.

mediapipe 1.0.1 on an M4 goes looking for a Metal (gpu) thing that isn't there, and instead of falling back to the cpu it just dies. Forcing cpu didn't help either. Pinning mediapipe<1.0 fixed it, 0.10.35 works fine. ok, moving on.

It worked, then it stopped

Second run it was actually seeing my face. I winked, page turned. Winked again, page turned. Third time, page turned.

Then nothing. Completely dead. I could wink all i wanted and nothing happened.

The reason was something i added on purpose. After turning a page i didn't want one long wink to keep firing again and again, so i added a rule: after firing, don't fire again until both eyes are open.

Sounds reasonable. The problem is how i decided what "open" means. I just picked a number, below 0.3 is open.

But when you're reading, you're looking down, and your eyelids come down a bit with your eyes. So my fully open eyes were sitting at around 0.28 while reading, which is just under my line. One tiny movement and my eye was no longer officially open, so the script sat there waiting forever for me to open my eyes, which were already open.

    shut  1.0 ┤
              │
  my line     ┤ 0.30   ← "below this = open"
  me reading  ┤ 0.28   ← eyes fully open btw
              │
    open  0.0 ┤

Great margin lmao.

Print the numbers

At this point i stopped guessing and made it print what it was actually seeing, which honestly i should do earlier every single time.

R 0.05  L 0.15   ← both eyes open, just sitting there
R 0.22  L 0.64   ← left wink   → worked
R 0.57  L 0.34   ← right wink  → nothing happened??

Two things came out of this.

First, my eyes are not the same. At rest my left eye reads 0.15 and my right reads 0.05. That's just my face. Nobody is perfectly symmetric.

Second, because of that, every wink was being counted as a left wink. My left eye starts 0.10 higher than my right, so it wins the "which eye is more shut" question before i've even done anything.

So when i winked with my right eye the difference between the two eyes came out to 0.23, and when i winked with my left it came out to 0.42. Same gesture, but one of them was above my threshold and one was below it, so right winks just got thrown away.

Comparing each eye to itself

The fix is to stop comparing my eyes to some number i made up, and compare each eye to its own normal instead.

So the script watches your face and learns what each of your eyes reads when you're just sitting there doing nothing. Then it only looks at how far each eye moved from its own baseline.

                   raw    baseline    moved
right eye     →   0.57  −   0.05   =   0.52
left eye      →   0.34  −   0.15   =   0.19
                                 difference = 0.33  ✅

left eye      →   0.64  −   0.15   =   0.49
right eye     →   0.22  −   0.05   =   0.17
                                 difference = 0.32  ✅

Now both winks come out around 0.32. Same gesture gives the same number no matter which eye you use.

And it accidentally fixed the reading problem too. When you look down, both eyes go up together, so the difference between them barely changes. A wink is one eye moving alone, looking down is both eyes moving together. So the difference between the two eyes tells them apart, and it doesn't need to know anything about where you're looking.

                  left   right   difference
just reading  →   0.16   0.22      0.06     → nothing
normal blink  →   0.34   0.32      0.02     → nothing
actual wink   →   0.49   0.17      0.32     → page turn

One small thing, the baseline follows your face down quickly but up very slowly. Otherwise if you hold a wink for a while, the script would slowly decide that "shut" is your new normal and the wink would disappear on its own.

Stuff i'd tell myself

• print the actual numbers first. every real fix here came from looking at real values, and every wrong turn came from me imagining what the values probably were.
• don't pick fixed thresholds when the thing you're measuring is a person. faces are different, and the same face is different depending on whether its looking at you or at a book. learn the normal instead of guessing it.

Two annoying things

If you try it, macos needs Accessibility permission to let any program send fake key presses, and it doesn't ask you for it. Camera it asks for, accessibility you have to go add by hand. And until you do, everything looks like its working while nothing happens. Took me a while to figure out.

Also winking is more tiring than you'd expect. Most people can't wink one eye without slightly squinting the other one, and that's exactly the confusing case i throw away on purpose. Ten minutes in you'll feel it.

In a nutshell

Its a menu bar app now, so its a toggle instead of a terminal window sitting open. 👁 means its watching and 😴 means its off, and the camera light actually goes off too.

Takes around 150ms from wink to page turn, which is fast enough that you don't feel like you're waiting for it.

Would pressing page down have been easier? yes. obviously. next question.

Code's here if you want to try it → winkscroll

I got to know oracle has an always free tier which has two types of compute instances

> In AMD you can get 2 micro VMs (1/8 OCPU, 1 GB RAM each)
> In ARM you can get 2 OCPUs and 12 GB of RAM (still pretty good)

I was able to get these two AMD instances and one of them i am using to hunt for the ARM one which is pretty hard to get, at least in my region on a free account.

Btw, worth checking your account limits before you enter the never-ending begging loop!!

  oci limits resource-availability get --compartment-id <tenancy> \
    --service-name compute --limit-name standard-a1-core-count \
    --availability-domain "<your AD>"

The Problem

ARM shape is mostly always out of stock in popular / busiest regions and obviously there's no waiting list or free-up notification saying "here you go with an always free instance" so the best we can do is keep hitting (begging) their servers for a VM instance.

The naive approach

If you understood the problem, we can solve it by writing a simple POST request inside a loop which'll hit the oracle till eternity or until we get a VM. It might look something like this

while (true) {
  const res = await fetch(ORACLE_API, { method: "POST", body: serverConfig });
  
  if (res.ok) break;  // got a server, done
  
  await sleep(500); // nope, try again lmao
}

Looks fine, right? It isn't. There are two major issues you can get into with this:

• Rate limit: considering this above script, let's say your one round-trip of request-response took 500ms to complete so in 1 sec 1 api call, in 1 min 60 api calls and in an hour 3600 api calls, you're ngmi.

• Error handling: It can get you into two kinds of error scenarios, retriable and non-retriable.

  • Retriable: error could be like no compute available, their server is down, some network issue.
  • Non-retriable: error could be like requested more compute than your account is allowed to (eg. their policy changed) or a malformed request. waiting won't fix these, this is how you end up with a script that looks busy for two days and was never going to work.

And here's the annoying part. You'd assume you can just check the status code, 4xx means i broke something, 5xx means they broke something.

but oracle sends "out of host capacity" as a 500 🙃

{
  "status": 500,
  "code": "InternalError",
  "message": "Out of host capacity."
}

Nothing is actually broken, there just aren't any servers. But it shows up dressed as a server error, so you can't go by the status code, you have to read the message.

there's one more risk, make sure the serverConfig you've passed to the request body has valid metadata for the vm you want. because once it initializes the instance, if you didn't add your public access key to it, you'll never be able to ssh into the vm hence you'll have to delete it and beg oracle again for an instance.

your payload should look something like this

  {
    shape: "VM.Standard.A1.Flex", // ARM machine
    shapeConfig: { ocpus: 1, memoryInGBs: 6 },
    imageId: "...", // Ubuntu 24.04 ARM
    subnetId: "...",  // which network to attach to
    assignPublicIp: true,
    metadata: {
      ssh_authorized_keys: "ssh-ed12345 ABCDE3Nz... MrBean" // ← this one ;)
    }
  }

Why a 429 is worse than it looks

This one took me a while to get. Your request doesn't go straight to the thing that knows about servers, there's a rate limiter sitting in front of it.

your request
     │
     ▼
┌──────────────────┐
│ rate limiter     │  "asking too often?"
└────────┬─────────┘
    yes ─┴─ no
     │       │
     ▼       ▼
   429    ┌──────────────────┐
          │ capacity check   │  "any servers free?"
          └────────┬─────────┘
              ┌────┴────┐
              ▼         ▼
        out of      here you
        capacity      go

"Out of host capacity" and "429" feel like the same thing. both are failures, both mean no server for you. But they're not the same at all.

"Out of capacity" means somebody actually checked, and there was nothing.

429 means nobody checked. you got stopped at the door.

So a rate limited request isn't a failed attempt, it's not an attempt at all. My script was running full speed, logs scrolling, and it wasn't even asking.

Oracle's Retry Mechanism

Which brings me to how i was hitting that limit without even realising.

So you send a POST, it fails, and you send another one. two requests, right?

Not really. Oracle's sdk/cli wrapper has its own retry mechanism baked in. When a request fails with something it thinks is temporary (their server choked, a network error, a 429) it quietly retries the same request in background until it's made 7 attempts, and you won't even know about it.

You see one failure in your logs. Oracle saw seven requests.

your script                 what Oracle receives
───────────                 ────────────────────
attempt #1  ─────────────►  request 1
                            request 2  ┐
                            request 3  │ SDK retrying,
                            ...        │ invisible to you
                            request 7  ┘
            ◄─────────────  one error

sleep 11s

attempt #2  ─────────────►  request 8

And remember the 500 thing? Their sdk retries any 5xx by default (except 501), because normally a 5xx is a blip, try again in a second and it'll probably work.

But "out of host capacity" is not a blip. there were no free servers a second ago and there are none now. might change in an hour, might change next week. So the sdk sees a 500, assumes it's temporary, and fires 7 more requests that ofcourse will fail.

It gets funnier. 429 is also on their retry list. Oracle tells you you're sending too many requests, and the sdk's answer is to send more requests. Idk what they're smoking lmao.

My log said attempt #47. Oracle's log said request #329.

So you make sure to pass the --no-retry flag, which simply means don't handle retry for me, I am already doing the error handling so i'll retry myself. Which i think probably is the safer approach here, because my loop knows things the sdk doesn't. it knows out-of-capacity won't fix itself in one second, and that the right answer to a 429 is to back off, not to try harder.

How I did it

┌────────────────────────────────────────────────┐
│ 1. SETUP — runs once                           │
└────────────────────────────────────────────────┘
   read public key  (~/.ssh/id_ed25519.pub)
   → build metadata  { ssh_authorized_keys: "..." }
   → do I already have an A1?
         yes → exit, nothing to do
         no  ↓

┌────────────────────────────────────────────────┐
│ 2. LOOP — until it lands                       │
└────────────────────────────────────────────────┘
   POST  /instances     (timeout 150s, --no-retry)
   ↓
   what came back?

   ├─ an instance id ─────────────────► SUCCESS
   │
   ├─ nothing / timed out ────────────► go and look:
   │                                      exists? → SUCCESS
   │                                      no?     → wait 165s
   │
   ├─ LimitExceeded, NotAuthorized ───► STOP. (un-retriable error).
   │  InvalidParameter                   
   │
   ├─ 429 Too Many Requests ──────────► wait 120s (retriable error)
   │
   ├─ 500 "Out of host capacity" ─────► wait 165s (retriable error)
   │
   └─ anything else ──────────────────► log it, wait 165s
                                          ↓
                                       loop again

┌────────────────────────────────────────────────┐
│ 3. SUCCESS                                     │
└────────────────────────────────────────────────┘
   poll for public IP   (up to 30 × 10s)
   → ping Discord
   → exit

In a nutshell, I tried to deep dive into why i am not getting VMs with my request loop and tried to make my approach optimal.

Its been running for 15 days now. 7,600 attempts. still nothing 🙂

But at least now its actually asking.

Code's here if you want to try it out → oci-a1-hunter

But it isn't.

I remember the first mcp I used was the Figma MCP to replicate the design my fellow designer had created. And after using it, I realized that mcp is not really so complex.

btw one of my friend is really obsessed with concept of mcp, he wants mcp for almost everything i wonder when he's going to build an mcp server to connect claude with his gf lmao :)

But jokes apart, let's break it down into small pieces.

Protocol

As developers, we've already been working with protocols like HTTP/HTTPS while building APIs all day.

A protocol is simply a shared set of rules that different systems follow when communicating with each other.

For example, with HTTP, we have methods like:

GET
POST
PATCH
DELETE

These are rules both the client and server understand. The client knows how to make a request, and the server knows how to respond to it.

MCP is also a protocol, but instead of defining how a browser talks to a web server, it defines how an AI application can communicate with external capabilities such as tools and data sources.

Context

Suppose you tell your LLM (ChatGPT, Claude, etc.) "I am XYZ and I'm from San Francisco." Then, after a few back-to-back messages, you ask the AI something about yourself.

It can still tell you that you're xyz and from sf, its because the conversation history is provided to the AI while generating its response as context.

context helps the model understand what you're talking about and generate a more relevant response. You can think of context as the AI's working memory for the conversation.

Now imagine that instead of just having your conversation, we could also provide the AI with information from the outside world like files, GitHub repositories, databases, APIs, Figma files, and so on.

That's where things start getting interesting...

Model

The model is the actual AI doing the reasoning like your Claude, ChatGPT, or whatever model you're using.

When you ask:

What's the weather in Moscow?

The ai models doesn't magically know the current weather they're just a dumb algorithm which predicts the next word. It needs some external capability that can fetch that information.

For example, imagine we have a tool called:

fetchWeatherOfCity(city)

The model can look at the tools available to it and decide that fetchWeatherOfCity is relevant to the question.

It can then request fetchWeatherOfCity("Moscow")

The tool goes and gets the actual information, returns the result, and the model uses that result to generate the final answer.

This is the basic idea behind tool calling.

But where do these tools actually live? Obviously in an MCP Server.

An MCP server is a program that exposes capabilities to an AI application through the MCP protocol. For example, imagine we create an mcp server for a city information service.

It could expose tools like:

fetchWeatherOfCity(city)
fetchPopulationOfCity(city)
fetchAreaOfCity(city)

Now your AI can connect to this MCP server and discover these tools.

The important part is that the AI doesn't need to know how the tool is implemented internally.

It only needs to know what the tool does and what input it expects:

Tool:
fetchWeatherOfCity

Input:
city: string

Description:
Fetches the current weather for a city.

So you can think of an MCP server as a bridge between an AI application and some external capability.

Host, Client and Server

There is one more piece we need to understand.

When you use something like Claude Desktop or Cursor, the application you're interacting with is the host.

Inside that host is an MCP client, which is responsible for communicating with mcp servers.

The basic architecture looks like this:

You → AI Host → MCP Client → MCP Server → External System
       Claude / Cursor                 Figma / DB / API

The important distinction is:

• Model → decides what it needs
• MCP Client → communicates with the MCP server
• MCP Server → exposes the tools
• External system → provides the data or performs the action

The model doesn't directly communicate with the MCP server. The model just decides which capability it needs, while the mcp client handles the communication.

Putting It Together

Let's go back to our weather example.

You ask:

What's the weather in Moscow?

The model realizes it needs current weather information and chooses the fetchWeatherOfCity tool.

The rough flow looks like this:

┌──────┐ → ┌────────┐ → ┌───────┐ → ┌──────────┐ → ┌──────────┐
│ User │   │  Host  │   │ Model │   │  Client  │   │  Server  │
└──────┘   └────────┘   └───────┘   └──────────┘   └────┬─────┘
                                                        │
                                                        ↓
                                                   ┌─────────┐
                                                   │ Weather │
                                                   │   API   │
                                                   └────┬────┘
                                                        │
                                                        ↓
┌────────┐ ← ┌───────┐ ← ┌────────┐ ← ┌──────────┐ ← ┌───────┐
│ Answer │   │ Model │   │ Client │   │  Server  │   │ Result│
└────────┘   └───────┘   └────────┘   └──────────┘   └───────┘

How Does the MCP Client Communicate with the Server?

Your mcp server defines how this communication happens. The two main transport mechanisms are stdio and Streamable HTTP.

Local MCP Server

A local mcp server can run as a process on your machine. The AI host communicates with it through standard input and output (stdin / stdout).

AI Host ── stdin / stdout ──> MCP Server

The messages use JSON-RPC.

This is useful for MCP servers that need access to things on your local machine, such as your filesystem.

Remote MCP Server

An mcp server can also run on another machine and communicate over HTTP / HTTPS network calls.

AI Host ── HTTP ──> MCP Server ──> External Service

This is useful when the server needs to be hosted remotely and accessed by multiple clients.

Instead of every AI application inventing its own way to talk to every service, an mcp server can expose those capabilities through a standardized interface.

Enough Theory, Let's Build One

So I wrote the smallest mcp server to learn about it. Only one tool, about 35 lines, no build step. It's literally the weather example we've been using.

server.registerTool(
  "getCityWeather",
  {
    description: "Fetch the current weather for a city",
    inputSchema: {
      name: z.string().describe("City name, e.g. Delhi"),
    },
  },
  async ({ name }) => {
    const city = name.toLowerCase();
    return {
      content: [
        { type: "text", text: weather[city] ?? "Unknown city" },
      ],
    };
  },
);

That's the whole tool. The weather itself is a hardcoded map of three cities, and that's on purpose, swap it for a real API call and nothing else about the server changes. The protocol doesn't care where your data comes from.

Two things here matter way more than they look: the description and the inputSchema. That's the only thing the model reads when it's deciding whether your tool is relevant to the question. Write a vague description and your tool just never gets called. it sits there. nobody calls it. kinda sad tbh.

The rest is three lines to connect it over stdio, then you point your claude_desktop_config.json at the file, restart, and ask it about the weather in Delhi.

Code's here if you want to run it → first-mcp-server

In nutshell it's simply a protocol for connecting AI applications to external capabilities.

Binary

Computers can understand only two things either something is done or its not done, like i said they're just bunch of switches, a switch has only two states On or Off nothing in between. So computers only understand 0 (off) and 1 (on) which is called binary

Bits and bytes

To represent a piece of information we use the word bit (a binary digit)

0 or 1 would be considered a bit

bit can only represent very small amount of information for example if a bulb is on or off, a single state. but if you want to represent big chunk of information like writing your pet's name, now you would need multiple bits to represent here comes bytes in the picture.

01001011 -> K

as you can see grouping these 8 bits makes a byte which can represent numbers, letters, colors, even pictures which can be understood by humans.

Example: the letter "A" is agreed (by a standard called ASCII) to be represented as the byte 01000001.

The cpu

Storing these bits / bytes in the computer won't help us in any way so there has to be something which can do things like adding, comparing and moving the numbers somehow, that doer is cpu.

cpu has a single job, to follow the instruction and execute a given task. It could be multiplying or adding two numbers. cpu follows a three step loop always to do something

Fetch -> Decode -> Execute

• Fetch the next instruction to be executed.
• Decode the instruction to understand what exactly needs to be done.
• Execute the instruction, actually do it.

Then it moves to the next instruction and repeats . Forever. Billions of times per second.

Memory

for our computer to store the bits and bytes and make some operation on them it needs a place to sit somewhere, we call it memory.

a memory is of two types RAM and ROM

RAM (Random Access Memory)

• short term
• fast
• wipes everything out when power is off.

ROM (Read Only Memory)

• long term
• slower
• keeps things even when power is off.

But why two types, not one?

• Computers need constant power to hold data and do any operation — which is expensive
• RAM is fast but short-lived → good for active work
• ROM is slower but long-lived → good for storage
• You rarely need all your data at once — just the chunk you're working with right now
• So keep the unused stuff in ROM, and load only what's needed into RAM

eg. chatGPT keeps all your chat histories ("memory") but you only use one conversation at a time. Loading everything into RAM at once would be wasteful, better to keep unused history in ROM and pull in only what's needed right now.

Stack vs Heap

computers can't just store anything anywhere, there has to be a structured way and different use cases right? So the RAM is organized in two structures with a different use cases:

Stack

• small data
• short lived operation
• ordered data

let age = 49; // small, static → STACK

Heap

• huge data
• long lived operation
• flexible data

let user = { name: "James" }; // bigger, flexible → HEAP

Processes vs Threads

Your computer's CPU has cores the parts that actually do the work.

Open Chrome, and the computer starts a process for it. Think of it as a separate box just for Chrome. Open Spotify, and it gets its own separate box too. One box can't see inside the other.

Inside each box, the work gets split into smaller pieces called threads

Process

one app running, in its own isolated box / environment.

Threads

a smaller task inside that box, like 1 tab playing a video and 1 rendering a webpage in chrome

Just fyi: one core can do one task at a time and when you try to open multiple processes (programs) it tries to switch between the processes to handle them parallely (fake parallelism)