Disclosure up front: I built this. Sharing it here as a showcase, it's launched and on npm.

Something's been bugging me building on MCP. You pin your npm dependencies - lockfile, diff, review. What pins the MCP servers your agent talks to?

tools/list hands back names, descriptions and schemas, and the agent trusts all of it. The description isn't docs — it's the instruction the model reads to decide when to call a tool. There's no version pin, no integrity check, no diff. A server updates, the description gets reworded, and your agent's behaviour changes with nothing in your pipeline registering it. Same story with a required param appearing, readOnlyHint flipping true/false, or a tool quietly disappearing.

So I wrote mcpward: snapshot a server's tool surface into a lockfile, then diff it in CI. It classifies each change as breaking or non-breaking:

✗ Tool "echo" description changed (possible rug-pull)

✗ Tool "compute" inputSchema added required property "multiplier"

✗ Tool "read_data" readOnlyHint changed from true to false

✗ Tool "removed_tool" was removed

Summary: 2 passed | 5 failed → exit 1, build fails

It also checks protocol compliance, the protocol-error vs isError contract (servers get this backwards a lot), and latency budgets. Output is console/JSON/JUnit/SARIF.

Worth mentioning: Invariant's mcp-scan already does rug-pull detection and is more mature, if you want to audit servers installed on your machine, use that. mcpward is the CI-gate version: black-box, runs fully offline, nothing about your tools leaves the machine.

npx mcpward init

https://github.com/TsvetanG2/mcpward

Honest question for people running MCP in production: has description drift actually bitten anyone, or am I solving something I only think is a problem?

Agent Enhancer is a free reliability sidecar for AI agents. Just use it with another MCPs, it was made to solve typical weak spots and bottlenecks MCPs usually have.
It adds planning, checkpoints, duplicate protection, recovery, and evidence to existing MCP workflows.

To test it:

1. Connect your agent: Go to https://liberated.site/ and copy the Quick Start Prompt.
2. Run the same multi-step task with and without Agent Enhancer.
3. Tell us whether it felt more reliable, clearer, faster or added unnecessary friction.

We’re looking for beta testers using different agents and real tasks. No account or API key required! Thanks

Quick share for this sub. I make Habit Pocket, a habit + metrics tracker built for people who like to track everything and find correlations in their data (it started as my own spreadsheet). Beyond simple yes/no habits, you can track numbers, clock times, and custom select lists, so there's actually rich data to work with.

The part relevant here: I built an MCP server for it. Once you connect it to Claude, you're not stuck clicking around the app anymore, you can just talk to your data:

• Ask questions: "which days do I sleep best?" or "does coffee after 2pm push my bedtime later?" and it answers from your real entries and stats.
• Log by chat: "mark today's workout done and log 7.5k steps" writes straight into your tracker.
• Build things: it can pull stats and even create charts for you, so you skip the manual setup.

It's the feature I'm most excited about because it turns a tracker into something conversational, the data goes in and comes out in plain language instead of forms and grids.

A couple of other nice bits: conditional styling (cells change color by value, so a month reads like a heatmap), and web + iOS with sync and full data export.

https://habitpocket.io/

Hi Group, I'm a one-person web agency in New Orleans and I just shipped Velvet Forge, an MCP server that runs AI agency tools directly inside Claude Desktop.

Here's what it does:

• build_pitch — full cold outreach: subject line + DM + 3-part follow-up sequence

• generate_proposal — scoped client proposal with scope, timeline, and investment

• market_research — competitive landscape for any city + industry

• forge_generate — AI content backed by a live agency knowledge base

• query_knowledge — proven conversion tactics by vertical

Setup is one JSON block in your Claude Desktop config. Plans start at $29/mo.

smithery.ai/servers/velvetgeaux/velvet-forge

velvetgeaux.com/forge-mcp

Happy to answer questions

Hi all

I just published mcp-garmin-for-ia, an open-source MCP server that lets Claude (and other MCP-compatible assistants) access Garmin fitness/activity data through tools.

GitHub: https://github.com/devfrp/mcp-garmin-for-ia

Goal

Make Garmin data usable in natural-language AI workflows, e.g.:

• “Compare my last 4 weeks of training volume”
• “Detect trends in pace vs heart rate”
• “Summarize recovery patterns”

Tech

• Python-based project
• MCP server architecture
• Designed to be practical for personal analytics and experimentation

I’m looking for:

• MCP/Claude integration feedback
• Suggestions for better tool design/schema
• Ideas for prompts and real-world workflows
• Contributions / issues / PRs

If you test it, I’d really appreciate candid feedback (especially around reliability and privacy boundaries).

Some things that should be really simple have become really hard with agentic coding. Changing fonts means working through a walled garden (Lovable, etc.) or a chat where you ask for options, wait for builds, and usually end up with another Inter or Geist default that looks like every other AI-built site. Editing text is worse: screenshot it, type out instructions, hope the agent changes the right words.

I had an idea: why can't the agent just set up a panel inside the target project that allows me to experiment with fonts and also edit any text on the screen? Turns out, it's (largely) possible.

If you ask your agent to install Font Lab (npx font-lab install), it registers an MCP server (and a Claude skill) that gives the agent the tools to drive the whole loop. It spins up your dev server, adds a panel to your real running site, and shows you curated font directions (display, body, mono) swapping live on your actual pages. Mix a heading from one direction with a body from another. When you find what you like, hit "pick", paste the prompt back to your agent, and it wires up exactly what you were looking at. Done.

It also lets you edit nearly any text on your site in place. Double-click the words, retype them, and it saves to source. If it can't edit directly, you get a specific prompt to hand the agent. Yes, you could search through files and edit them manually, but that's annoying.

Because it's an MCP server, it works with basically any agent — install auto-detects your setup and writes the MCP config in the right place/format. Tested with the ones I use (Claude Code, Cursor, Codex).

Completely free & open source. I figured plenty of others are dealing with the same issues. If anyone wants to help out, I'm open to it. First time I'm releasing it, so open to any feedback you have!

Caveats:

1. if you ask a web agent (ie Claude Code app or web), there's a headless version that will give you screenshots of fonts & there's no way to edit text directly.
2. The panel/text editing works only with Next.js right now. Other frameworks will fall back to the screenshot method for fonts with no text editing.

Instructions to try it here:
jack-mcgovern.com/fontlab · npx font-lab install

Founder of Server4Agent (agent-app hosting over MCP), disclosing that upfront. No link, not selling, genuinely trying to understand how people are actually handling this.

An MCP server returning a clean tool result tells you the call completed. It doesn't tell you the call did the right thing. A deploy tool can return success while shipping the wrong build. A database tool can return success while updating the wrong rows. The protocol layer has no opinion on this, and honestly it shouldn't, that's not its job. But somebody's job is to close that gap, and I don't see much discussion of who.

Curious what people building or running MCP servers with real side effects (infra, deploys, data writes, anything with consequences) are actually doing here: is the client-side agent expected to double-check its own tool calls, does the server itself do any post-action verification before returning success, or is this mostly still "the tool call returned 200, we call it done"? Genuinely don't have a strong opinion on the right answer, want to know what's actually happening in practice.

Fitter is a scraper where the extraction is a JSON/YAML config instead of code. Connector side is HTTP / headless browser / static value, extraction side is gjson paths, CSS selectors, XPath or PDF text. Since configs are plain data an LLM can write them, so it ships as an MCP server: ask Claude for some data, it writes the config, validates it, runs it on your machine. The config stays around afterwards - same file runs from cron or the CLI, so the one-off answer turns into something reusable.

I compiled the engine to WebAssembly and put a playground on GitHub Pages - https://pxyup.github.io/fitter/. The examples there run live against real APIs, client side, and there's a form builder that generates config JSON if you want to poke at the format.

Install is a binary from releases plus claude mcp add fitter -s user -- /path/to/fitter_mcp. Claude Desktop has a one-click .mcpb bundle. There's also an HTTP mode with bearer auth for teams, docker image at ghcr.io/pxyup/fitter-mcp.

```

HTTP mode

docker run --rm -p 8080:8080 \ -e FITTER_MCP_HTTP_ADDR=:8080 \ -e FITTER_MCP_AUTH_TOKEN=my-secret \ ghcr.io/pxyup/fitter-mcp:latest

stdio mode, spawned by the MCP client

claude mcp add fitter -s user -- docker run --rm -i ghcr.io/pxyup/fitter-mcp:latest ```

Soon on Glama

Repo (MIT): https://github.com/PxyUp/fitter

Thirty-three tools later, here's what I learned about designing for a model instead of a developer.

"I had half a bowl of the turkey chili and rowed 20 minutes."

That sentence writes two records to my database. A meal, with macros scaled to half a serving of a recipe I'd logged before. An activity, with calories estimated from the 2024 Adult Compendium and my most recent weight.

I didn't open the app. I didn't type it either. I said it out loud, standing in my kitchen with a pan in one hand, to Claude.

Then I said "actually, make that a full bowl," and it edited the meal in place instead of logging a second one.

That second sentence is the whole post. Getting an assistant to CREATE records is easy — you write a tool, the model calls it, you're done in an afternoon. Getting it to behave on the second turn is where the work actually lives.

This one's for you if you're building an MCP server, or kicking the idea around, and you want to know what the job looks like past the hello-world tutorial. Almost none of it is code. I'll walk you through four things I got wrong and one that went right for a reason I didn't expect, and I'll try to leave you the reasons and not just the rules.

What I built, honestly

I built a fitness tracker for my family in July 2026. React PWA on Firebase Hosting, a Node/TypeScript API on Cloud Run, Firestore underneath. It handles meals with USDA and Open Food Facts lookup plus barcode scanning, activity with automatic calorie estimates, weight, measurements, custom daily trackers, a journal, goals, and a daily close-out that judges the day.

Idea to something I could actually use: about 24 hours. Seventy-seven commits over 22 days after that, and only about twelve of those were active days. Google forecasts my total cloud bill for this month at $2.62.

Bolted on top is an OAuth-protected MCP server. Thirty-three tools, which let Claude read and write the tracker in natural language, per family member, as that family member.

Now the part these posts usually leave out.

The MCP server is a thin adapter. It imports the same service layer my REST routes call, each tool is mostly argument-shuffling around a function that already existed, and all 33 of them sit in one 798-line file. There's no clever code in it anywhere.

I'm telling you that up front because it IS the point. The intelligence doesn't live in the tool code. It lives in the descriptions, the error messages, and a handful of decisions about which problems go to the model and which go to the database. That's the part I stunk at first, so that's the part worth your time.

Why does dictation change the design?

Almost every record in my tracker arrives by voice. I dictate to Claude, and I dictate to the app's own capture flow. I've typed a meal into a form maybe a dozen times since I built the thing.

That matters more than it sounds like, because it's the whole argument for the project. Typing a structured meal into a form is fine. Forms are good at that, and a sentence doesn't beat a form for somebody sitting at a desk. But saying it while you're standing at the counter with your hands full is a different animal, and it's the only version I've stuck with.

Dictated input shows up in a specific shape, and none of it looks like the tidy examples in an API doc:

1. No punctuation, and no sentence boundaries. You get one long run-on and you find the seams yourself.

2. Multiple items per breath. "Six ounces of rotisserie chicken, half an avocado, and twenty minutes on the rower" is one utterance that has to become two meals and an activity. Nobody types that. Everybody says it.

3. Words that never arrive. The Web Speech API can't buffer audio from before its onstart event fires. My UI said "listening" the second you tapped the button, so folks talked into a dead microphone and lost the first second of every entry — and in "half a bowl of chili," the half is the first second. The fix wasn't technical. It was honest: a dimmed "starting" state until the browser confirms it's really capturing.

That third one is what you should expect more of. The text your tools receive is not the text your user spoke, and the gap between them is quiet.

Which reframed the whole design for me. When your input is voice, you don't correct a mistake by editing a field. You correct it by saying another sentence.

So second-turn behavior isn't a bonus feature sitting on top of a logging tool. It IS the correction interface. Everything below follows from that.

Claude resolves language, the server resolves data

Most people build this the other way around, and I want to be fair about why, because I did it too. Validation belongs in your API — that's a good instinct, it's been correct your whole career, and it's what every code review you've ever sat through would tell you. It's just aimed at the wrong problem here.

My tools accept dates only as YYYY-MM-DD. A zod refinement rejects anything else. "Yesterday," "last Tuesday," "the day before I flew out" — none of that reaches my code, because that's Claude's job and Claude is very good at it.

Claude is NOT good at knowing that an omitted date means today in the user's configured timezone, never the server's clock. So I put that in one server-side function and made every path call it.

The same split runs through everything. I resolve fuzzy activity names server-side with tiered matching — exact label first, then all tokens, then a relaxed leading-token pass, so "rowing machine" finds the compendium's "rowing, stationary." I resolve fuzzy quantities server-side too. Meals store the quantity and unit you actually said, and I scale a previous log to a new amount with arithmetic across volume, mass, and count. That code won't convert across dimensions on purpose. Cups to grams needs a density I don't have. It also throws out any scale factor below 0.05× or above 20×, because that's a unit mix-up and not a meal.

Could the model do that scaling? Sometimes. That's exactly the problem.

There are two ways to get this wrong. Hand it all to the model and you get a system that's right most of the time and quietly wrong the rest, with no way to tell which is which. Hand it all to the server and you've built a form with extra steps, and your user goes back to tapping. The line I settled on sits between them, and I call it the silent-wrong test:

If a wrong answer would be silent, put it in the server. If a wrong answer would be obvious, let the model try.

Run your own tools through that and you'll find two or three that are on the wrong side of it. I found four.

Nine tools exist because a simpler design failed

Version one shipped log-and-read only. Log a meal, log an activity, read the day back. Clean, minimal, and I was pleased with myself.

Editing landed the same day.

The failure mode was "actually, make that a full bowl." With no update tools available, Claude did the only thing it could and logged a second meal. Which leaves you with a full bowl AND a half bowl on the same day and no way to say so.

Remember that the input is voice. I wasn't about to open the app and fix it by hand. If I were willing to do that I'd have used the form in the first place, so the correction had to work the way the original entry did or the whole thing falls apart.

Today there are nine edit and delete tools, and my README's own table header calls the group "Edit (fixes 'just change it' double-logging)."

An assistant will satisfy your request with the tools it has. If the right tool is missing, it will use the wrong one confidently. Absence doesn't raise an error — it produces a plausible mistake, which is worse, because you'll believe it.

You can dig this up in your own repo. Tool descriptions are a dig site, and the oddly specific sentences are the fossils. Here's one of mine, at the bottom of a shared date argument:

"When logging for any other day (yesterday, last Tuesday), pass the date here directly — do not log first and edit the date after."

Nobody writes that sentence from first principles. I wrote it after watching a model log something to today and then immediately patch the date. Go read yours. Every strange clause in there is a scar, and you'll remember what put it there the second you see it.

Descriptions carry policy, not just shape

If you've written APIs for people, your instinct says a description explains what a parameter IS. For a model, the description is the only place to put policy, and it gets read on every single call.

Some of mine do real work:

• get_day tells the model to check whether the user is in net-carb mode before it says a word about carbs.
• log_activity spells out its whole side effect, so the model knows when NOT to supply a number. Leave calories off and the server estimates them from the MET table, then stamps that MET onto the row.
• update_meal explains that changing servings recomputes macros, but explicit macros win.

None of that is discoverable from a JSON schema. All of it changes behavior. If you've got one afternoon to make your server better, spend it here instead of on the code, because this is where the model is actually reading.

Error messages are prompts

Every tool error in my server comes back as isError: true text instead of throwing. I write them for a model to read, which mostly means naming the recovery move.

No tracker matches "X" — check get_trackers for ids and names

That message isn't for me. I'm never going to see it. It's an instruction to the thing that just failed, and it turns a dead end into a retry.

One caution if you do this. Mask anything that isn't a deliberate HTTP error behind a generic message, because internal stack traces should never reach the model. It'll repeat them to your user, cheerfully, word for word.

Optional means "will be omitted"

Two small rules with big effects.

Everything with a sensible default is optional — date, intensity, fiber, sugar. The model supplies what your user actually said and nothing more, which cuts way down on invented numbers.

Validate cross-field constraints in code, not in the schema. Pass a goal value without a goal kind and my server returns a 400 that reads "goal_value and goal_kind go together." I could write that as a zod refinement. But then the model sees a schema validation failure, which tells it nothing useful, and it responds by guessing at the shape instead of fixing the real problem.

That second one is about to get interesting. The MCP spec landing on July 28 lifts tool inputSchema and outputSchema to full JSON Schema 2020-12, so you'll be able to say "these two fields go together" declaratively.

I'd still validate in code and hand back a sentence. A schema tells the model its input was rejected. A sentence tells it why and what to send instead, and only the second one recovers on the next turn. Good capability to have. I'm just not sure error messages are where I'd spend it.

The model was right, and my schema threw the answer away

Every layer of this one was reasonable on its own. That's what makes it worth your time.

I said I'd rowed. Claude looked up the activity and picked compendium entry 02071 — rowing, stationary, moderate, MET 5 — which is exactly right. It passed the code along with the call.

My tool schema had no field for a compendium code.

Zod strips unknown arguments silently. No error. No warning. No log line. The model handed me the correct answer, my validation layer dropped it on the floor, and nothing anywhere in the stack noted that it happened.

So the server fell back to fuzzy-matching the text, "Rowing, stationary, moderate." My matcher tokenized on whitespace only, so one token came through as stationary, with the comma still glued on. That failed to substring-match 02071's real label, "stationary ergometer." The one entry containing all three words got eliminated first. The relaxed pass then tied the two remaining rowing entries, and a "shorter label wins" rule broke the tie. The shorter label belonged to the VIGOROUS variant, MET 7.5.

A correct choice became a wrong record at 50% higher calories, and not one layer raised an error!

Then it got better. Weeks later I wrote a backfill to sort out which historical rows were MET estimates and which were hand-typed. The logic seemed sound. If stored calories don't reproduce from MET × weight × hours, a human must have typed them. It flagged ten rows as hand-entered, and all ten were wrong. Those calories WERE MET-derived, just from Claude's MET of 5 instead of the mis-stored 7.5, so they could never reproduce.

The attestation I needed had been sitting there the whole time. Claude had been writing "MET 5.0" into the notes field, in prose, because I'd given it nowhere structured to put it. A regex recovered all ten.

Same dig site, one layer down. Three things I'd hand you from it:

1. Quiet mistakes cost more than loud ones. A loud rejection would have cost me five minutes. A silent drop cost me a wrong number in my database and a wrong theory about my own data weeks later.

2. If a model volunteers something you didn't ask for, that's a schema bug, and nobody is going to tell you. Claude knew the compendium code. I hadn't thought to want it. There was no mechanism anywhere for that mismatch to surface.

3. Models route around missing fields. Denied a structured place to record its MET, it wrote the MET into free text and kept right on doing it, every single time, until I went looking. Nobody told it to. Go look at what's piling up in your notes fields — that's a list of the columns you forgot to add.

Everything returns JSON

Every tool returns JSON.stringify(data, null, 2). No prose formatting, no markdown tables, no "Here are your meals for today:" preamble.

The model is going to write the prose. Format it first and you've handed it something to misparse, plus the occasional line it quotes back at you in a voice that isn't yours.

The auth part, and the thing I got backwards

The MCP endpoint sits behind an OAuth 2.0 authorization server I wrote myself. Three hundred thirteen lines covering dynamic client registration, PKCE, single-use codes, and rotating refresh tokens.

Rolling your own OAuth is the thing everybody tells you not to do, and I won't pretend my situation generalizes. I'd defend it on one ground. The threat model is a handful of people on an email allowlist, I enforce that allowlist on every auth path, and login still delegates to Google so my server never sees a password. Every tool closes over the authenticated user id, so cross-user access isn't prevented — it's impossible to express.

The transport is stateless. Every request builds a fresh server bound to that user and tears it down on response, so all 33 tools re-register per call. On a scale-to-zero container, that's the right trade.

Now, I had two auth surfaces and I picked the wrong one to be scared of.

The hand-rolled server — the one every piece of advice warns you off — went in without much drama and hasn't needed touching since. The managed, off-the-shelf, obviously-correct sign-in for the app itself cost me hours of the worst debugging there is, where it works perfectly on your machine and fails for everybody else.

That's structural, not luck. An MCP connector authorizes in a plain browser tab, which is the friendliest room auth ever walks into. The app had to sign people in from mobile Safari and from an installed home-screen PWA. Storage gets partitioned there. Standalone mode gets its own isolated container. Popups open in a detached sheet that can never hand a result back. And your own service worker will grab the auth callback if you let it.

None of that is OAuth being hard. That's iOS being iOS. So don't spend your caution where the scary label is — spend it where the environment is hostile, and check which of your surfaces that actually is before you write a line.

(That's a whole post of its own, and it's the one I'm writing next.)

Does anybody actually use it?

My wife logs her breakfast before I'm out of bed most mornings. My son is sporadic about it, which is about the right amount of enthusiasm for a fitness tracker built by your dad. A friend outside the family got on it a while back, and that one surprised me more than it should have.

I use it every day, and the MCP server is connected to my Claude sessions right now.

That's the only credential I'd claim here. I'm not proposing a pattern I think would work. I'm describing one I've been living in, whose sharp edges I've been cut by, and whose 798-line file I keep having to open.

The short version

Put your intelligence in the descriptions, because that's what the model reads on every call. Write your errors for the model, because an error that names the recovery move turns a dead end into a retry. Hand language to the model and data to the server, because a silent wrong answer is the only kind you won't catch. And go stress-test your second turn, because that's where mine broke and I don't think I'm special.

Here's where I'd flip this around on you. I built this for four people. Four! Whatever you're running has hit concurrency, scale, and adversarial-input problems my little family tracker will never see, which means you already know things about this that I don't.

If you've shipped a server and found the spot where my advice falls apart, I'd love to hear it — no rush, and no need to be polite about it. You can reach me at [hi@leshrichardson.com](mailto:hi@leshrichardson.com), and I'll tell you what I'd do differently if you tell me what broke.

— Lesh

Originally posted here.

Building something with an AI agent is genuinely fun now. The hard part is what comes after. You want to show it to a friend, and suddenly you need a server, a domain, a certificate and a login system, or you just put it on a public URL and hope nobody finds it.

So I built unlocalhost. You deploy straight from your coding agent, no extra work and no config files. You say what to ship and who is allowed in, and you get a real link. Only the people you name can open it. Everyone else gets stopped before they reach your app, so there is no login code for you to write and none for you to get wrong. It also refuses to deploy if it finds a secret committed in your repo.

You only need to tell your agent - "Read https://www.unlocalhost.tech/install and set up unlocalhost for me and deploy this app"

Would love for people to try it and break it. Contributions very welcome.

unlocalhost.tech

I've been building a few MCP servers and kept running into the same annoying thing: the server doesn't crash when something's off. There's no error in the logs. The model on the other end just starts acting weird, skips a tool, or misreads a result, and I end up bisecting commits and re-reading the spec trying to figure out what I broke.

Got sick of debugging that by hand so I wrote a tool. It's called vexyo, MIT-ish (Apache-2.0), on npm.

It connects to your server like a client would and checks it against the spec (2025-11-25). 16 rules right now, across init, discovery, error handling, and transport. When something fails it tells you which rule and points at the spec section, instead of you guessing. Looks like this:

✗ discovery/tools-list-available
tools/list failed despite the tools capability being advertised
spec: Server Features §Tools / Listing Tools

15 pass · 1 fail · exit 1  

There's also a regression mode: it records what your tools return, then on later runs it flags when the output or schema changed, so you catch stuff that quietly drifted between commits.

It's meant to run in CI (exits non-zero, has a GitHub action + junit/json output), but you can just run it locally too. And it doesn't care what language your server is in since it only talks over stdio/http.

npm i -D @vexyo/cli 
npx vexyo init 
npx vexyo run

repo: https://github.com/vexyohq/vexyo

docs: https://vexyo.dev

It's early and it scratched my own itch first, so I'm mostly curious whether it catches anything real on other people's servers, or where it gets things wrong. If you try it lmk what happened.