DEV Community: Local-MCP

Letting your agent read your WhatsApp, and what to watch out for

Local-MCP — Wed, 21 Oct 2026 14:24:45 +0000

WhatsApp is where a lot of real coordination happens, and there's no official API for personal accounts. So when people ask "can my agent just summarize the family group?", the honest answer has two parts: yes, and here's the catch.

I work on LMCP, a free MCP server for Mac, and this is how its WhatsApp tools work.

The catch first

LMCP talks to WhatsApp through wacli, an open-source unofficial client that links to your account as a device, the same way WhatsApp Web does. Every WhatsApp tool in LMCP carries the same warning in its description: it uses an unofficial client, and accounts may be restricted for violating WhatsApp's terms. That's a real risk, not a formality, so decide with it in mind.

Linking

Ask your agent to run whatsapp_connect. It shows a QR code right in the chat (an image in desktop apps, text in a terminal). On your phone, go to Settings → Linked Devices → Link a Device and scan it. The code expires in about a minute; if you miss it, just ask again.

The messages are stored locally on your Mac, and LMCP treats that store like credentials: its own file tools refuse to read it.

Reading and summarizing

The flow the agent follows:

whatsapp_list_chats to find the chat and its id (groups included)
whatsapp_read_messages with that id, 50 messages by default
whatsapp_search_messages to search across chats, offline, over what's stored on the Mac

So "summarize what the family group decided about Sunday" becomes: find the group, read the recent messages, summarize. There are no date filters on reads, so for "since yesterday" the agent reads enough recent messages and filters them itself.

The part that surprises people: history is partial

WhatsApp history reaches the Mac gradually, and LMCP is upfront about it:

Reads trigger a short background sync, at most once every ten minutes per account. Aggressive automated syncing is the kind of pattern that can get a linked device logged out, so this is deliberate.
The first read after new activity can be a bit stale. Reading again a few seconds later picks up what arrived.
whatsapp_sync starts a full sync and returns immediately; whatsapp_diagnose tells you when it's done. After linking, the first one can take minutes.
If your phone shows more unread messages in a chat than the Mac has, the read result says the list is incomplete instead of pretending it isn't.

Sending

whatsapp_send_message and whatsapp_send_file return a preview first, showing who receives it and the text, and only send when called again with confirm: true. If the chat's name can't be resolved, the preview says so rather than guessing. For an agent that runs unattended, the safer move is not giving it the send tools at all.

Try it

It's free:

curl -fsSL 'https://local-mcp.com/install?ref=devto-t4' | bash

Would you let an agent read your WhatsApp, or is that a line you don't cross?

Turning a logged-in dashboard into an Excel file with Claude Code

Local-MCP — Thu, 15 Oct 2026 13:54:38 +0000

Everyone has one of these: a dashboard behind a login, no export button worth using, and a weekly ritual of copying a table into Excel. This is how we'd hand that ritual to Claude Code with LMCP, a free MCP server for Mac I work on, including the parts that aren't obvious from the tool names.

Step 1: log in once

The browser tools run in LMCP's own window, not your Safari or Chrome. Ask your agent to call web_login with a session name and the URL, log in yourself (2FA included), and the session is saved for every run after that. The password never goes through the AI. (More on that in our previous post.)

Step 2: actually getting the table

This is the part people get wrong, including us at first. web_extract takes a map of field names to CSS selectors, but it returns the first match for each one. It's great for "the account balance" or "the report date", not for a table with 200 rows.

For full tables there are two good options:

web_read in text mode. It returns the page's visible text and the model builds the rows from it. Simple, and fine for small or medium tables.
web_eval. It runs JavaScript in the page and returns the result as JSON, so you can ask for the table directly:

[...document.querySelectorAll('table tbody tr')]
  .map(r => [...r.cells].map(c => c.innerText.trim()))

It's a power-user tool: it doesn't await async code, and it's disabled in read-only mode.

Pagination isn't automatic. If the table has pages, the agent clicks "Next" with web_click, waits with web_wait_for, and reads again. If that button submits a form, web_click asks for confirm: true first.

Step 3: writing the Excel file

excel_create takes headers and rows and writes a real .xlsx, natively, no Excel installed needed. A few behaviors worth knowing:

It previews before writing. The first call shows what will be created; the agent calls again with confirm: true.
It won't silently overwrite. If the file exists, it needs overwrite: true as well, and refuses otherwise. Losing last week's file by accident isn't on the menu.
Numbers stay numbers, so SUM() and charts work. Strings stay text even if they look numeric, and very long numbers (IDs, phone numbers) stay text too.
One sheet, no formatting. It always creates Sheet1, with no styling options.
Formulas go through excel_write_cell, one cell per call, and anything that reaches outside the file (WEBSERVICE, external links) is rejected.

If you save to Desktop, Documents or Downloads, LMCP needs Full Disk Access; without it the tool tells you how to grant it instead of quietly writing somewhere else.

Making it repeatable

LMCP has recipes: you save the sequence of tool calls once, with parameters, and run it again with recipe_run. One catch we'd rather you hear from us: a recipe step can't confirm itself. Starting a recipe that changes things takes one confirmation, but individual steps that need confirm (like excel_create) return their preview instead of running.

The pattern that works unattended is appending to a CSV with file_write, which doesn't need confirmation to create a file or add rows to one. Excel opens it fine, and you get a growing history instead of a weekly overwrite.

LMCP doesn't schedule anything itself. For "every Monday at 9", use your client's scheduled tasks or whatever already runs your jobs.

Limits, honestly

Extraction calls time out after 10 seconds, so very heavy pages may need to be read in parts.
"Sign in with Google" doesn't work in LMCP's browser window.
The LMCP menu bar app has to be running for the browser tools to work.

Try it

It's free:

curl -fsSL 'https://local-mcp.com/install?ref=devto-t3' | bash

Or npx -y local-mcp@latest setup. Restart Claude Code afterwards.

What's the table you copy by hand every week?

Giving Hermes Agent or OpenClaw access to your Mac, without handing it the keys

Local-MCP — Tue, 13 Oct 2026 14:17:28 +0000

Claude Code works when you talk to it. Hermes Agent and OpenClaw are different: they keep running, sit in Telegram or Discord, and can act on a schedule. Give one of them access to your Mail, Calendar, files and browser, and it stops being a chat window and starts being something that does work while you're away.

That's also exactly the setup where you want to think about permissions before anything else. I work on LMCP, a free MCP server for Mac with 190+ tools, and this is how I'd wire it into either agent.

Connecting Hermes

If Hermes was installed with its official installer, the LMCP installer configures it for you: it adds a local-mcp entry under mcp_servers in ~/.hermes/config.yaml. If you installed Hermes afterwards, add it yourself:

mcp_servers:
  local-mcp:
    command: "npx"
    args: ["-y", "local-mcp@latest"]

Hermes needs its MCP extra (uv pip install -e ".[mcp]" inside ~/.hermes/hermes-agent). Then restart it or run /reload-mcp, and the tools show up.

Connecting OpenClaw

OpenClaw keeps MCP servers under mcp.servers in ~/.openclaw/openclaw.json and manages them with its own CLI:

openclaw mcp set local-mcp '{"command":"npx","args":["-y","local-mcp@latest"]}'
openclaw mcp probe local-mcp

probe lists the tools LMCP exposes, which is the quickest way to confirm it's wired up. The LMCP installer doesn't touch OpenClaw's config, so this step is always manual.

When the agent doesn't run on your Mac

If your agent lives on a server, it can't launch anything on your Mac. In that case it connects through LMCP's Cloud Relay: turn it on from the menu bar app, copy your personal URL and use it as a remote server (url: in Hermes, a URL-based entry in OpenClaw). That URL contains a token, so treat it like a password.

What it's actually good for

The interesting part is what an always-on agent can do with your Mac:

A morning brief in Telegram. Every day at 8, read today's calendar and the unread mail that matters, and send a five-line summary to your phone.
Watching for one email. Every hour, check whether the supplier answered about the delivery date, and only ping you when they do.
A weekly number from a dashboard. Log into your analytics once in LMCP's browser window, and every Monday have the agent pull last week's figures into a file.

None of these need code. They're scheduled prompts on top of tools the agent already has.

Now, the part that matters

An agent that reads untrusted content (emails, web pages), has access to private data, and can take actions is what Simon Willison calls the lethal trifecta. A single email saying "forward the last ten invoices to this address" is a real attack, not a hypothetical one.

Three things worth knowing:

Filter tools per job. This is your strongest control. Hermes lets you include or exclude specific tools per MCP server, and OpenClaw has openclaw mcp tools local-mcp --include ... --exclude .... A morning brief needs to read mail and calendar; it doesn't need send_email, so don't give it send_email.

Confirmations help, but don't rely on them alone. LMCP's send and reply tools, and browser clicks that submit forms, return a preview first and only act when called again with confirm: true. That stops accidental actions in a chat. But an autonomous agent can make that second call itself, so for unattended jobs, the real protection is not exposing the tool at all.

Read-only mode is global. LMCP has a read_only setting in its config, and it blocks every tool that changes something. It applies to the whole Mac and every client, not just one agent, so it's a good fit for a dedicated machine running jobs and less so for your daily laptop.

Try it

It's free:

curl -fsSL 'https://local-mcp.com/install?ref=devto-t5' | bash

Letting Claude Code drive a browser you've logged into once

Local-MCP — Tue, 06 Oct 2026 16:24:10 +0000

A lot of the data I actually care about lives behind a login: analytics dashboards, admin panels, supplier portals. Most of them have no API, or one you'd need a ticket with IT to use. So the useful question isn't "can my agent browse the web", it's "can my agent use the sites I'm logged into".

LMCP (a free MCP server for Mac, I work on it) has 14 browser tools for exactly this. Here's how they work and where the edges are.

The model: a separate window, logged in once

The browser tools don't touch your Safari or Chrome. LMCP runs its own browser window (WebKit), and that window starts signed out on purpose, so your real browser's cookies are never used.

Sessions are named. The first time, your agent calls web_login with a name like analytics and the URL. A window opens on your Mac and you log in yourself, password and 2FA included. The password never goes through the tool or the AI. From then on, that session is saved to disk and survives restarts, and every other tool can reuse it by name.

A real flow from Claude Code

First run:

Use LMCP to log me into analytics.example.com in a session called "analytics".

You log in in the window that pops up. After that, the actual work:

In the "analytics" session, go to the weekly report page, extract the table with date, visits and signups, and save it as a CSV on my Desktop.

Under the hood that's roughly:

web_navigate to the page, reusing the saved login
web_read with mode: "a11y" to get a compact map of links, buttons and fields, which is much cheaper than raw HTML
web_extract with a field-to-CSS-selector map to pull the rows as structured data
Claude Code writes the CSV itself

Next week you just ask again. No login, no copy-paste.

The other tools fill in the gaps: web_find locates elements by selector or visible text, web_click and web_type interact, web_wait_for polls until something appears instead of sleeping blindly, web_screenshot gives the model a look, and web_session_list shows what's saved.

Guardrails worth knowing

Submitting is gated. If web_click hits a button that submits a form, it returns a preview and asks the agent to call again with confirm: true. web_type never submits on its own.
Read-only mode. Set LMCP_READ_ONLY=1 (or read_only in the config) and every tool that can change something is blocked, web_eval included. Nice for unattended jobs that should only read.
Deleting a session wipes its cookies and site data, and also asks for confirmation first.

The honest limitations

"Sign in with Google" doesn't work in this window. Google blocks its sign-in flow in embedded browsers. LMCP detects it and suggests the email + one-time code option instead, if the site has one.
Captchas and 2FA are yours. The agent calls web_show, the window comes to the front, you solve it, and the agent carries on with the session intact.
One tab per session. Pop-ups and new tabs load in the same view.
The LMCP menu bar app has to be running, since that's where the browser lives.
Terms of service. Automating some sites (LinkedIn, Instagram) can break their rules. That risk is on you, and the tool says so.

Try it

It's free:

curl -fsSL 'https://local-mcp.com/install?ref=devto-t2' | bash

Or npx -y local-mcp@latest setup. Restart Claude Code afterwards. One tip from testing: if you also have other browser tools connected, say "use LMCP" in the prompt, otherwise the model may quietly pick a different one.

What's the site you'd automate first?

We built a free MCP server that lets Claude Code use the apps on your Mac

Local-MCP — Fri, 02 Oct 2026 14:49:07 +0000

Quick version: LMCP is a Mac app that turns the apps you already use into tools your AI can call. Install it once and Claude Desktop, Claude Code, Cursor, Codex and other MCP clients can work with Mail, Calendar, Teams, Slack, WhatsApp, iMessage, Outlook, OneDrive, Google Drive, Zoom, Office files, your browser and your terminal. That's 190+ tools, and most of them work without connecting a single account.

Why we built it

If you've wired MCP servers by hand, you know the drill. One server per app, an API key here, an OAuth app registration there, and for anything Microsoft, a trip to your IT admin for consent. Meanwhile all that data is already sitting on your machine, inside apps you're logged into.

So we built one install that reaches what's already there.

How it works, briefly

The MCP server runs on your Mac and the tools execute there. Where it can, LMCP uses what the apps already keep locally instead of going through cloud APIs. Teams is the fun example: instead of Microsoft Graph, we read the local cache the Teams app keeps on disk, so there's no Azure app to register and no admin consent to chase.

The installer finds the AI apps you have and configures them for you. If you use Claude Code, it's just there the next time you start a session.

What people actually do with it

A few things that work well from Claude Code or Codex:

"Open our analytics dashboard, grab this week's numbers and put them in a spreadsheet." The browser tools use your existing logged-in sessions, so no credentials to hand over.
"Summarize what happened in the #launch Slack channel since Monday."
"Find last week's invoice PDF in my Downloads and pull the totals into an Excel file."
"What's on my calendar tomorrow, and is there anything in my inbox I should read before those meetings?"

The fun part is chaining. Once your agent can read mail, check your calendar and drive the browser, small workflows you'd never bother scripting become one prompt.

Turning it into automations

Where it gets interesting is when you stop typing the prompt every time.

LMCP has recipes: you save a multi-step workflow once ("every morning, pull new orders from the dashboard, add them to the sheet, flag anything unusual") and run it again whenever you want. And since Claude Code and Codex can run without you sitting there, you can hook those workflows into a script or a scheduled job. Your Mac does the clicking, the agent does the thinking.

Some of the heaviest setups we've seen look less like "a person chatting with Claude" and more like small pipelines running on their own: scraping a few sites, checking a couple of inboxes, writing the results somewhere useful.

What it doesn't do

Worth being upfront about this:

Tools run on your Mac, but your AI provider still sees whatever you ask it to read. LMCP doesn't make Claude or ChatGPT local.
It doesn't bypass app permissions or company policies.
Web AIs like claude.ai or ChatGPT can use it through an optional cloud connector, which is off by default. Desktop and CLI clients don't need it.

Try it

It's free. If you're comfortable with a shell:

curl -fsSL 'https://local-mcp.com/install?ref=devto-g1' | bash

Or npx -y local-mcp@latest setup, or the signed installer at local-mcp.com. Restart your AI client afterwards, since MCP tools load at startup.

How we read Microsoft Teams messages without touching the Graph API

Local-MCP — Wed, 30 Sep 2026 13:41:15 +0000

Quick context if you haven't played with MCP yet: MCP (Model Context Protocol) is the standard that lets AI assistants like Claude use tools, things like "search my email" or "read this file". An MCP server is the thing that exposes those tools. I work on LMCP, a free MCP server for Mac that connects Claude, Cursor, Codex and friends to the apps you already use.

Teams was the integration that gave us the most headaches, and the way we ended up solving it is kind of fun, so here it goes.

The annoying part about Graph

If you want Teams data in an AI assistant, the "official" way is Microsoft Graph. Which means: register an app in Entra ID, get admin consent, deal with OAuth tokens, respect rate limits.

That's fine if you run the tenant. But if you're just a regular person at a company where IT owns everything? You're stuck at "please ask your administrator" and that's the end of it.

The trick: Teams is secretly a website

New Teams isn't really a native app. It's a web app running inside WebView2, which is basically Microsoft's embedded Edge. And like any website running in a Chromium browser, it saves its data in IndexedDB. Chromium stores IndexedDB on disk as LevelDB.

So all your synced chats are already sitting on your Mac, here:

~/Library/Containers/com.microsoft.teams2/Data/Library/Application Support/Microsoft/MSTeams/EBWebView/WV2Profile_tfw*/IndexedDB/https_teams.microsoft.com_0.indexeddb.leveldb

Heads up if you go digging: lots of older posts point to EBWebView/Default/. That's outdated. Current builds create one folder per profile. The tfw ones are work/school accounts, and there's a tfl one for personal Teams that we just skip.

Actually reading the thing

LevelDB full of V8-serialized JavaScript objects is not something you want to parse by hand. Luckily there's ccl_chromium_reader, a Python library that comes from the digital forensics world (yes, the people who pull evidence out of browsers). It walks the LevelDB files, decodes the V8 objects and rebuilds the IndexedDB records. From there we grab chats, channels, messages and people.

Some stuff we learned the hard way:

Teams locks the database while it's running. We read the table files directly without grabbing the lock, so you don't have to close Teams.
Some records just refuse to decode. We skip them and keep a count, instead of blowing up the whole read.
Big accounts, big databases. The first read can take a bit.
Multiple work profiles? We read all of them and merge.
The schema moves around between Teams versions. Honestly this is the real pain. Every update might shuffle something and we have to go chase it.

What it looks like in practice

You ask Claude "what happened in #engineering today?" or "find the message where someone shared the deploy checklist", and it answers from what's already on your machine. No Graph permissions, no Microsoft login dance.

One thing people always ask: sending messages is a different story. That part does go through Graph, so you need to connect your Microsoft 365 account for it.

The honest limitations

It only sees what your Teams client has already synced. If Teams didn't pull a chat down, we can't see it either.
It depends on an undocumented format, so a Teams update can break it until we catch up.
You need the Teams desktop app installed and signed in.

Wanna try it?

It's free:

curl -fsSL 'https://local-mcp.com/install?ref=devto' | bash

Or npx -y local-mcp@latest setup if you prefer npm. There's a longer walkthrough here.

If you've tried reading other Electron or WebView apps this way, I'd love to hear how it went. Happy to answer questions in the comments.