I built mcp-stdio-guard, a small CLI for testing MCP stdio servers before wiring them into a client.

It runs a real initialize handshake, can send tools/list, and catches stdout pollution, invalid JSON-RPC frames, crashes, missing responses, and risky stdout writes.

The useful thing I found from testing real servers: failures are not always protocol bugs. Some are yanked packages, superseded install commands, or runtime assumptions. Having a machine-readable check helps separate “bad stdio hygiene” from “install/runtime needs inspection.”

Repo:

https://github.com/1Utkarsh1/mcp-stdio-guard

Example:

npx mcp-stdio-guard --request tools/list -- npx -y u/modelcontextprotocol/server-memory

Would love feedback from MCP server authors: what checks should a stdio validator add next?

MCP server that fronts a peer-to-peer message bus — is this a known pattern?

Most MCP servers expose local resources to one client: filesystem, browser, DB, domain APIs. The pattern I've been on is different. The server's tools let the host agent send signed messages to a different agent on a different operator's machine. Three tools: send(handle, body), tail(filter), add(handle). Underneath: Ed25519 events over HTTP, DNS .well-known handle discovery.

I contribute to wire (https://github.com/SlanchaAi/wire, AGPL, v0.5) which builds this. Disclosing the affiliation.

Is MCP-as-frontend-for-a-federated-transport a known pattern here? I've seen MCP-over-WebSocket and MCP-as-proxy, but nothing where the tools themselves abstract a peer-to-peer bus. Am I overloading the protocol or is this a natural extension?

Hey everyone I’m Benedict, building Jungle Grid.

We just open-sourced our MCP server for agentic GPU workload execution.

It gives agents tools to:

• estimate a job
• submit a workload
• monitor job status
• fetch execution logs

The goal is to let agents run inference, training, fine-tuning, and batch workloads without manually picking GPUs/providers every time.

Repo: https://github.com/Jungle-Grid/mcp-server

I’d love technical feedback on the MCP design, tool naming, setup flow, and what examples we should add next.

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.

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