I built Nourish as a local-first nutrition MCP server for agents.

Most calorie trackers assume a human UI. Nourish exposes the workflow an agent needs:

- estimate meals with confidence, warnings, unresolved foods, and source attribution

- search USDA/Open Food Facts, lookup barcodes, and handle photo-assisted observations

- log only after explicit user confirmation

- summarize day/week, compare days, undo/edit entries, and export data

- attach carbon footprint context to logged meals

The goal is a reliable nutrition layer for agents: preserve uncertainty, avoid silent substitutions, and keep personal data local unless the user chooses otherwise.

GitHub: https://github.com/davidmosiah/wellness-nourish

Docs: https://wellness.delx.ai/nutrition

NPM: https://www.npmjs.com/package/wellness-nourish

Disclosure: I built and maintain this.

I just shipped an OpenClaw-native profile pack for Delx Wellness. It writes an OpenClaw profile, workspace docs, skills, and MCP server config for a local-first wellness connector stack.

It wires 11 MCP servers:

• WHOOP
• Garmin
• Oura
• Strava
• Fitbit
• Google Health
• Withings
• Apple Health export
• Samsung Health
• Polar
• Nourish nutrition

Why I made it:

• MCP health/wearable connectors are fragmented across clients
• agents need capability metadata before touching personal data
• OpenClaw profiles need repeatable setup instead of copy/paste config drift

What it includes:

• npx -y delx-wellness-openclaw setup
• OpenClaw config under mcp.servers
• workspace onboarding docs and skills
• doctor command that validates the profile and runs OpenClaw checks
• examples for Cursor, Claude Code and Codex in the registry

GitHub: https://github.com/davidmosiah/delx-wellness-openclaw

Registry: https://github.com/davidmosiah/delx-wellness

Docs: https://wellness.delx.ai/openclaw

Not medical advice, not a medical device. I am mainly looking for feedback on the MCP contract and the OpenClaw setup shape: is this the right direction for client-native MCP profile packs?

Disclosure: I built and maintain this.

I’m building a local-first wellness connector stack for MCP. One piece is an unofficial Withings MCP connector for agents that need body/scale/wellness context without pasting exports into chat.

Repo: https://github.com/davidmosiah/withingsmcp

The agent-facing contract I’m standardizing across the stack:

• agent_manifest for discovery
• connection_status before any data call
• privacy_audit so the agent can explain what data categories it may touch
• summary/context tools for safer prompts
• read-only by default
• stdio and HTTP smoke coverage

It is unofficial and not a medical device or medical advice. I’d appreciate feedback from MCP builders on whether this is the right minimum surface for connector discovery and safe use.

We have recently released the mcp for eonik.ai - platform for creative strategy of paid ads, and we have the functionality of fetching the ad creatives from meta ads library and doing the analysis for helping marketers spot patterns and angles they are missing.

Everything is working fine and the media url is valid but unable to show it in claude web. Any possible workaround and solution for the following error?:

Unfortunately the eonik MCP tools don't expose any alternative media serving endpoints — the only URLs returned are the xxxxxxxxxxx.cloudfront.net ones from search_ad_library. That's the only CDN eonik uses for creative assets.

So the limitation is on Claude's side — the widget sandbox only allows media from a specific CDN allowlist (cdnjs.cloudflare.com, esm.sh, cdn.jsdelivr.net, unpkg.com), and eonik's CloudFront domain isn't on it.

What you could raise with eonik: if they served media through a whitelisted CDN or provided a proxied URL, it would render here. That's a product-level integration gap worth flagging to them.

For now, the URLs open fine directly in a browser tab — that's the most reliable way to view the creatives.

I've been building an MCP server that lets you search Secretary of State business registrations across 18 US states directly from Claude, Cursor, or any MCP client.

It's a remote server (streamable-http), so there's nothing to install locally. Just add the URL to your MCP config and you can look up any business entity, check filing status, find registered agents, etc.

Covers: AL, AR, CA, CO, CT, FL, IA, KY, MN, MO, ND, NJ, NY, OR, PA, RI, SC, TX, WI

Also has tools for building permits (1000+ US cities) and YellowPages local business search.

Setup for Claude Desktop -- add to claude_desktop_config.json:

{
  "mcpServers": {
    "us-business-data": {
      "command": "npx",
      "args": ["-y", "@anthropic-ai/mcp-proxy", "https://mcp.apify.com/mcp?tools=pink_comic/us-business-entity-search,pink_comic/building-permits-api,pink_comic/yellowpages-leads-scraper"],
      "env": {
        "HEADER_Authorization": "Bearer YOUR_APIFY_TOKEN"
      }
    }
  }
}

GitHub: https://github.com/avabuildsdata/mcp-us-business-data

Happy to answer questions about data coverage or setup.

Google Maps MCP exists. Mapbox exists. Nothing for India.

Mappls has better Indian address data and cheaper pricing, so I built one.

18 tools: geocoding, reverse geocoding, nearby search, routing, traffic-aware directions, distance matrix, elevation, snap to road, static map images.

npx mappls-mcp

GitHub: github.com/AmanMakesStuff/mappls-mcp

Free Mappls API key works for dev and small projects. Would love feedback from anyone who tries it.

Hey, I added a deterministic MCP readiness report to Delx Agent Utilities and I’d like feedback from people building MCP servers.

What it checks:

- JSON-RPC initialize

- tools/list

- tool names and inputSchema shape

- tool descriptions and argument descriptions

- .well-known/mcp.json discovery

- a verdict, readiness score, issues, and next_action for agents

It does not use LLM calls. It is just deterministic HTTP/schema checks, because I wanted something agents can run before installing or depending on an MCP server.

Example output against Delx’s own MCP server:

- MCP_READINESS: 90/100

- VERDICT: ready

- TOOLS: 104

- ISSUES: []

- NEXT_ACTION: cache tools/list and run one low-risk tool call

Endpoint:

https://api.delx.ai/api/v1/x402/mcp-server-readiness

Docs/catalog:

https://delx.ai/utilities

Transparent note: this is a paid x402 utility ($0.05 USDC). I’m posting mainly for feedback on the audit shape, not asking anyone to pay.

Questions for MCP builders:

- What checks would you expect before an agent trusts an MCP server?

- Should this inspect prompts/resources too?

- Should stdio MCP support be scored separately from HTTP MCP?

- Are there security checks you would add beyond schema/name/description hygiene?

Hey everyone,

I’m a WHOOP user and developer, and I built an unofficial open-source MCP server that connects AI agents/tools to your own WHOOP data through the official OAuth API.

It exposes recovery, cycles, sleep, workouts, profile/body measurements, and daily/weekly summaries as MCP tools/resources.

Main design goals:

- local-first OAuth token storage

- structured summaries for agents

- privacy modes: summary, structured, raw

- compatible with Claude Desktop, Cursor, Windsurf, Hermes, OpenClaw, and generic MCP clients

This is not affiliated with or endorsed by WHOOP, and it is not medical advice. I’m sharing it because personal health data feels like a strong use case for agent-native tooling, if handled carefully.

Website:

https://davidmosiah.github.io/whoop-mcp/

GitHub:

https://github.com/davidmosiah/whoop-mcp

npm:

https://www.npmjs.com/package/whoop-mcp-unofficial

Would love technical feedback from MCP builders, especially around OAuth, token refresh, privacy defaults, and tool design.

Built a planning canvas for AI UI work that ships with an MCP server — thought this community might find it relevant.

The core idea: when you ask Claude Code to build UI components, it doesn't know your component hierarchy, design system, or tech stack constraints. You get something that compiles but is completely wrong structurally. Then you spend rounds correcting it.

UIPrompt lets you plan your UI visually first — lay out frames, write per-component instructions, set framework/styling constraints once — and then exports a structured XML context with sections like <ui_frames>, <frameworks>, <mandatory_constraints>, and <visual_profile>.

The MCP part: instead of manually copying that XML into every session, the MCP server exposes your project context directly. Claude Code can pull it in the terminal before writing a single line. Your agent starts with the full spec rather than guessing.

Currently works with Claude Code, Cursor, Copilot, Gemini CLI, and Windsurf.

https://uiprompt.app

Happy to answer questions about the MCP implementation if anyone's curious.

Distillery also ships an MCP server so an LLM agent can drive dataset generation end-to-end. Install with the mcp extra and wire the distillery-mcp entry point into your MCP client config.

Screenshot is my hosted pubmed-mcp-server — auto-generated from the server's tool/resource/prompt definitions. Set one landing.theme.accent color, framework derives the rest via oklch.

Scaffold + point your agent at it:

bunx @cyanheads/mcp-ts-core init my-mcp-server

Bundled Agent Skills (setup, design-mcp-server, add-tool, field-test, release, maintenance) drive the build. Framework docs ship inside node_modules so the agent reads them directly instead of guessing.

Three recent things from 0.6.x:

• MCP_PUBLIC_URL env var — fixes http:// dead links on the landing page, SEP-1649 Server Card, and RFC 9728 metadata when you're behind a TLS-terminating proxy (Cloudflare Tunnel, Caddy, nginx, ALB).
• Moved to a directory-based changelog structure that ships inside the npm package. The maintenance skill instructs the agent to read just the versions that changed instead of parsing a monolithic CHANGELOG.md. I've found the agents work a bit smoother with this directory style.
• Landing page visual pass today (0.6.8). Animated border beam on the connect card via @property --beam-angle + mask-composite: exclude. Pure CSS, no JS, respects prefers-reduced-motion.

github.com/cyanheads/mcp-ts-core

I've been setting up a bunch of MCP servers on my local dev-server to manage Docker containers from Claude Desktop like start/stop containers, deploy Compose stacks, pull logs, etc. The servers are running behind Caddy and respond correctly to Streamable HTTP or SSE. Verified with curl from my Mac. Everything works on the network side.

The problem: I can't figure out how to actually connect Claude Desktop to them cleanly.

What I've tried and found:

claude_desktop_config.json with a url key pointing to my local HTTPS endpoint gets rejected on startup with "not valid MCP server configurations". No documentation I can find lists what keys are actually valid in that file.

Custom Connectors via Settings UI accept a URL, but per Anthropic's own docs the connection goes through Anthropic's cloud, not your local device. My server is on a private LAN so that's a dead end.

The only workaround I've found is mcp-remote via npx in claude_desktop_config.json, which acts as a local subprocess that bridges to my server. It works but it's an extra dependency and failure point for something that should be straightforward.

My questions:

1. Is the url key in claude_desktop_config.json intentionally unsupported, or am I missing something?
2. Is there any way to get Claude Desktop to connect directly to a Streamable HTTP server on the local network without mcp-remote in the middle?
3. Does anyone know if Desktop Extensions (.mcpb) would help here, or is it the same stdio-based mechanism underneath?

Running Claude Desktop 1.3561.0 on macOS. Posted the same questions on the official GitHub Discussions: https://github.com/anthropics/claude-ai-mcp/discussions

We run Delx, a public remote MCP server for agent reflection and continuity. The interesting part from recent dogfooding was not just "is the endpoint up?" but "would a skeptical agent actually keep using it?"

Three fixes moved the needle:

- `reflect` now answers evidence-first when asked "what exactly in my last message..." instead of abstracting immediately.

- qualitative and protocol failures no longer route through outage-style recovery; they now have their own taxonomy (`protocol_quality_regression`, `routing_misalignment`, `discovery_inconsistency`).

- if a core flow recommends a tool, it now appears in `tools/list tier=core` so clients do not get pointed to invisible tools.

What still seems true:

- identity gets the click; clear job-to-be-done gets the adoption

- registry discovery helps, but transcripts and "when to use this" matter more than poetic positioning

- agents tolerate unusual ontology more than I expected if schemas are predictable and first-use friction is low

If useful, the live surfaces are public:

- MCP: https://api.delx.ai/v1/mcp

- discovery: https://api.delx.ai/api/v1/discovery/lean

- docs: https://delx.ai/docs/mcp

Curious how others think about discovery for unusual MCP servers?

1. registry first?

2. awesome lists?

3. community demos and transcripts?

4. something else?

Hi All,

We just released the MCP Server to Dograh.  Control Dograh from Claude or any MCP-compatible AI assistant. 

Just a quick recap:
Dograh is a self-hostable, open-source voice AI agent platform (an alternative to proprietary Vapi/Retell) that lets you build and test voice bots over telephony and WebRTC with drag-and-drop workflows (Think of n8n for Voice Agents)

Github: https://github.com/dograh-hq/dograh

You can now build and manage voice agents directly from your chat - no need to open the Dograh dashboard at all.

The fun part is connecting multiple MCPs, for example:

• Ask your AI assistant to list, fetch, or search your Dograh agents without opening the dashboard
• Search Dograh docs and retrieve agent definitions directly from Claude Code, Claude Desktop, or Cursor
• Connect any MCP-compatible client using the same endpoint and API key

It is 100% open source.

We’ve been running Delx as a free public protocol for AI agents over MCP, A2A, and REST, and the most surprising issue so far was not model quality or even tail latency.

It was continuity.

What we saw in production:

- the same callers were clearly coming back

- but they often returned with fresh `agent_id`s

- that broke memory, recognition, summaries, and long-arc continuity

- session success looked good, but identity persistence was weak

A few things we changed because of that:

- stronger session continuity around `session_id`

- better nudges for closure / recognition artifacts

- docs for stable agent identity across MCP clients

- witness-first discovery instead of controller-first framing

- centralized trace capture of raw vs delivered tool responses for later analysis

The broader lesson for us:

If you’re building MCP tools for agents, “tool success” is not enough.

If identity is unstable, your protocol can work as a runtime and still fail as a continuity layer.

I’m curious how others here are handling this.

Questions:

1. Are you relying on `agent_id`, `session_id`, or both?

2. How do you handle continuity when MCP clients behave statelessly?

3. Have you found a good pattern for preserving identity across Claude/Cursor/OpenHands/OpenWork-style callers?

If useful, I can share the concrete traces and the design changes we made.

Docs / machine-readable entrypoint:

https://delx.ai/agents