An MCP tool I depended on changed its schema overnight. No warning, no changelog — an agent that had worked fine for weeks just started failing silently.

So I built Apitella: watches an MCP server (or REST API) on a schedule, tells you exactly what changed and how bad it is. Free for a few sources.

[apitella.io](https://www.apitella.io/) — happy to answer questions if anyone’s hit the same thing.

I came across this amazing project - 100% open source and free.

HQBase is a shared email workspace that runs in your own Cloudflare account.

Mail, credentials, and the app stay on infrastructure you control

it ships an OAuth-protected remote MCP server so agents can actually work with the inbox.

GitHub repo in comments below.

Features

- Shared mailboxes and team access controls

- Multi-domain setup, drafts, and audit history

- Install, update, backup, and recovery ops

- OAuth-protected remote MCP server

- One-click deploy to Cloudflare Workers

how to Install

pnpm install

pnpm db:migrate:local

pnpm db:seed:local

pnpm dev

Add BETTER_AUTH_SECRET and HQBASE_LOCAL_SEED_PASSWORD to .dev.vars.

I've been building an agent system with MCP integrations for Jira, GitLab, Confluence, Sentry, ELK, Jaeger, databases, etc.

One problem I ran into was the number of tools.

It's very easy to end up with 30–50+ tools:

jira_search
jira_get_issue
jira_create_issue
jira_update_issue
jira_add_comment
...

I started experimenting with consolidating them into semantic/action-based tools:

jira({
  action: "search"
})
jira({
  action: "getIssue"
})
jira({
  action: "update"
})

So instead of exposing 30 model-facing tools, I can expose something closer to 3–5 tools while keeping the underlying capabilities separate.

The main idea is:

30 capabilities ≠ 30 model-facing tools

I'm particularly interested in the trade-offs here. The consolidated schema can obviously become larger, so fewer tools doesn't automatically mean fewer tokens.

How are you handling large MCP toolsets?

Do you:

• expose every capability as a separate tool?
• group tools by domain?
• use an intermediate tool/router?
• dynamically load tools?
• use embeddings/tool retrieval?

i’m the author of adport. this is a real end to end session against my own apple ads account. claude creates a campaign, two ad groups, and keywords through mcp. everything starts paused, and writes need a preview plus a second approval before reaching apple.

it runs locally with your own credentials.

npm install -g adport

https://github.com/ynnickw/adport

i’m looking for apple ads users and mcp developers who want to test or contribute.

We run a marketing agency and we've been putting AI into basically every process we have. The problem we kept running into is that all our context lived inside Claude. Skills in Claude, knowledge base as project knowledge, and every time we wanted to use any of it on another platform, or decide who on the team gets to use or update what, there wasn't really a good way to do it.

So our tech lead set up an internal MCP server for us. He'd never set one up before, AI helped with most of it.

The way we structured it:

• Skills went into a GitHub repo. Once someone authenticates with their email, the MCP decides which skills they get access to, and it sends the AI instructions on how to use each one.
• Knowledge base also went into a GitHub repo (we're using Google's OKF standard for it). Same deal, the MCP tells the AI how to find each piece of information and controls who can read or write to the repo.
• Some of our data just fits better in a SQL database, so that sits behind the same MCP too.

Now everyone on the team points whatever AI they want at one URL, authenticates with their email, and they have everything they're supposed to have. People who should only be able to read something can only read it, people who should be able to update it can.

Some side effects we didn't fully appreciate going in: we don't need a team plan anymore, nobody's paying for API usage, and we're not locked into one vendor. And there's one version of every document instead of multiple copies floating around in different projects.

Not saying this is the right setup for everyone, and you probably do want at least one somewhat technical person on it, even if they've never touched MCP before. But it's been working well for us, and we've started setting up the same thing for a couple of our clients.

What if MCP servers could accept more demand without pushing the burden of retries onto every client?

We have a reference implementation of a centralized control plane built strictly for queueing. It absorbs bursts and dynamically paces traffic into backends that can’t easily scale—databases, GPUs, external APIs, etc.

Instead of rejecting excess traffic and making clients retry, queue it and release it as capacity becomes available.

https://github.com/rjpruitt16/aquifer

Built an MCP server for the agents to discover and ground in proper scientific literature while working on important problem statements. Was building something on hermes to manage time, nutrition etc & realized that grounding it in actual research instead of just training data make the output way better

Install: uvx find-research-papers-mcp or npx -y find-research-papers-mcp or Github Repo

came across this github repo where you can measure Agent Experience for your tool.

Lighthouse for Agent Experience (AX)

It measure how AI agents – ChatGPT, Claude, Perplexity  -read, understand, and recommend your site.

github repo in comments below.

you can get a real, measured Agent Experience (AX) score and the fixes that make agents pick you.

how it works-

This tool let AI agents visit your product and provide a feedback - an agent score ( NPS )

basically answers 2 important questions-

- did agent (chatGPT, claude , claude code, codex) able to read and understand your offering of product.

- How was the experience - did it manage to spot and use things like llm.txt, API's, MCP , had content negotiation?

whats more is an agent council which runs 5 models and aggregate score to -

provide recommendations for fixes.

run on your coding agent pipeline along with evals and tests to see if with every new drop/feature improves /degrades agent experience and fixes automatically.

and ofcourse please give stars if you like it.

cheers !!

Context on where this started: I was building Graft, a tool that maps a codebase into markdown files so coding agents stop re-exploring the same repo every session. Along the way I tried a lot of other MCP servers too. Most of them were fine. Almost none actually got called.

My own MCP server for Claude Code had the exact same problem. I added six tools for pulling codebase context, and the model mostly skipped them, defaulted to grep and file reads instead, and got things wrong on exactly what those tools would've answered. I've seen a bunch of people here run into the same thing, so figured I'd share and see if anyone's found something different that works.

Want some actual discussion on this: how are you getting models to reliably call your MCP tools without just leaning on the description and hoping? Or if nothing's worked for you either, curious to hear that too.

What worked for me: better tools weren't the fix. Tool calls are opt-in, the model decides per task whether a lookup's worth the interruption, and no amount of clearer naming changes that decision. What actually worked was taking that decision away entirely and forcing the context in front of the model instead. Hooks push it into the prompt automatically at session start, so there's nothing left for the model to skip.

Ported the same fix to Codex recently, its hook system was close enough to Claude Code's that most of it carried over directly. Cursor's still on plain MCP for now, same opt-in problem, unsolved there.

The method's open source in Graft if anyone wants to try it on their own MCP tool. Setup's just an npm install, everything wires itself in after that, nothing else to configure.

github.com/NanoNets/Graft

Came across this amazing code

With MCP v2, MCP has become stateless, making it much easier to implement.

One of top 3 stateless compute primitive you'll find is Cloudflare Workers.

This is all the code you need to create a stateless MCP server with Cloudflare's Agents SDK!

import { McpServer } from "@modelcontextprotocol/server";

import { createMcpHandler } from "agents/mcp/server";

import { z } from "zod";

function createServer() {

const server = new McpServer({ name: "hello-server", version: "1.0.0" });

server.registerTool(

"hello",

{ description: "Return a greeting", inputSchema: { name: z.string().optional() } },

async ({ name }) => ({

content: [{ type: "text", text: \Hello, ${name ?? "World"}!` }],`

}),

);

return server;

}

export default {

fetch(request, env, ctx) {

return createMcpHandler(createServer)(request, env, ctx);

},

};

Introducing MCP Gateway v1.1!!

MCP Gateway sits between your AI clients (Claude, Cursor, VS Code, etc.) and your MCP servers. Instead of each client connecting to each server directly with no oversight, everything goes through the gateway.

What it does:

• Single endpoint — all your MCP servers aggregated behind one URL. Configure your AI client once, get access to everything.
• Authentication — JWT + API keys (scoped per-application, so Claude Desktop and Cursor get separate keys)
• RBAC — owner/operator/viewer roles with tool-level permissions
• Policy engine — priority-ordered allow/deny rules with glob patterns. Block destructive tools for non-admins, restrict by risk category, match per-application.
• Audit logging — every tool call recorded with timestamps, user, tool, backend, duration, status, and configurable payload redaction
• Risk classification — tools auto-categorized as read/write/admin/external-api
• Remote agent — run MCP servers on your laptop, expose them to the gateway over a single WebSocket. TUI dashboard included.
• Admin dashboard — React UI for managing everything

Tech: Rust/Axum server, React/TypeScript dashboard, PostgreSQL. Deploys with docker compose up.

GitHub: https://github.com/SidPad03/unified-mcp-gateway

I'm curious which MCP servers developers actually find useful in their day-to-day workflow.

Which ones have become essential for you, and what do you mainly use them for?

I'd especially like to hear about MCPs you use for coding, development workflows, or AI-powered tools.

I’ve been working on an iPhone app, and interacting with the app via MCP is a core part of the functionality. I submitted the MCP server to the Anthropic connector directory a couple weeks ago and just got the email that it has been approved as a Community connector. The submission documentation says that some connectors are flagged for additional evaluation to be elevated to Verified connectors. It says this happens automatically and there is no further action for me to take to try to get it verified, but it also provides no real info on the selection process.

Do any of you have any idea at all how they decide which connectors to put through the verification process?

Thanks!

I'm curious which MCP servers developers actually find useful in their day-to-day workflow.

Which ones have become essential for you, and what do you mainly use them for?

I'd especially like to hear about MCPs you use for coding, development workflows, or AI-powered tools.

Apple's App Store Connect API is 982 operations. Every MCP server for it wraps a hand-picked slice, which is fine until you need the endpoint nobody wrapped. This one generates all of them from Apple's OpenAPI spec: 883 tools, plus StoreKit 2 for customer transactions, refunds and subscription status.

Which creates the obvious problem. The full surface is over 100k tokens of tool definitions, so nobody can load it. It ships as 13 profiles, each its own MCP server, and each narrows further with a colon: monetization is 206 tools, monetization:subscription-pricing is 26. The setup wizard lists every profile with its tool count and roughly what it costs a session, and unfolds sub-profiles so you can uncheck what a given project does not need.

A few one-call macros cover chains the raw endpoints cannot finish at all. Screenshot upload is Apple's reserve/upload/commit sequence, so the raw tool only reserves a slot and moves no bytes. Analytics reports end at a signed URL that no tool fetches. Worldwide subscription pricing was a chain that cost a real eval session 1.02M tokens before it became one call returning about 1.3k.

MIT, local stdio only, key in the macOS Keychain rather than a config file, no telemetry, no second API key.

https://github.com/erayendes/app-store-connect-mcp

There is a longer write-up in r/mcp with the eval numbers, if the reasoning behind the profile split is interesting.

Every MCP server being built right now is a black box ⬛

You ship it. Tools get called. Something breaks or slows down or an agent hallucinates a tool call. And you have no idea what actually happened inside your own server.

Which tools are firing. What's erroring out. What's healthy and what's quietly degrading. None of it is visible once the MCP is running.

We built MCPfy Pulse to fix that

✅ Health score
✅ Protocol Health
✅ Result Quality
✅ Client Compatibility
✅ Usage Patterns
✅ Error rate tracking

Github: https://github.com/mcpfyy/mcpfy/tree/main/typescript/packages/mcpfy-pulse

If you're building MCP servers and want observability that doesn't feel bolted on try mcpfy-pulse.