home  /  projects  /  mcp trio for magicnote
live

MCP Trio for MagicNote

Three small MCP servers that give MagicNote's agent real situational awareness. Where I am (gpslog), what the weather is doing, what's happening on X right now via the Grok API. Each one is a couple hundred lines of Python. Each one is the reason the notebook feels smart.

why this matters

Three senses for the notebook.

A chatbot on its own is a friendly brain in a jar. Give it a way to know where you are, what the weather is, and what the world is talking about, and it starts feeling less like a chatbot and more like an assistant.

That's what these three small servers do. You ask the notebook "what's the weather?" and it knows to check where you are first, then look up the forecast for that spot. You ask "what are people saying about the market today?" and it has a live search tool to reach for. Below is how each one works — and why I kept them small and separate instead of building one big tool.

gpslog — location MCP

Two small programs plus one SQLite file:

Architecture diagram: BT GPS puck feeds rfcomm0 into gpsd, then the gpslog daemon writes to log.db; gpslog-mcp reads the same database and serves MCP clients alongside the Weather and Grok MCP servers.

The daemon subscribes to gpsd on loopback, parses TPV JSON, downsamples, and appends fixes. The MCP server opens the same file read-only (WAL mode so writer and reader share it without locks) and exposes five location.* tools over JSON-RPC newline-delimited stdio.

The five tools

  • location.currentmost recent fix within max_age_s (default 300)
  • location.atnearest fix to ts within max_age_s
  • location.nearbbox prefilter + Haversine refine, sorted by ts
  • location.visitscluster contiguous in-radius runs ≥ min_duration_s
  • location.timelineone fix per downsample_s bucket

Problems overcome

◆

Tool errors come back as readable results

Any tool exception is caught and converted to {isError: true, content: [{type:"text", text: …}]} so an LLM can recover instead of seeing a transport-level error. The run keeps going.

Weather forecast MCP

A tiny stdio MCP server that wraps Open-Meteo. Three tools: weather.current, weather.forecast, weather.hourly. Each one takes a latitude / longitude (or the string "here" which resolves via the gpslog MCP companion tool). Responses cache to disk for 15 minutes so a hot notebook doesn't hammer the API.

The notebook's notebook spell grants gpslog.location.current + weather.* in the same allowlist — ask "what's the weather?" and the model chains them without being told.

Notebook pane: user asks 'what's the weather?'; the model calls location.current, receives a lat/lon result, then calls weather.current with that coordinate, receives conditions, and writes a natural-language reply.

Grok X search MCP

A stdio MCP server that proxies the Grok API for live X searches. One tool — xsearch.query(query, limit?, since?) — returns a list of posts with author, timestamp, and body. Powers the notebook's "what are people saying right now about …" moments.

Rate-limit aware (429 → exponential backoff). API key loaded from an env var, never logged. Failure responses come back as structured tool errors so the notebook can fall back to a plain web search if the Grok API is down.

Notebook showing xsearch.query('NVDA earnings') expanded into a list of X post results with author handle, timestamp and body text.
◆

Three small tools > one big one

None of these servers is interesting on its own. What they enable — a notebook that knows where you are, what the weather's doing, and what's happening on X — is only interesting together. This is the shape of useful MCP work: small verbs that compose in the agent's head.