r/MCPservers

The default MCP pattern has a quiet cost: the model reads the full schema of every tool on every connected server, every turn, before it even knows which tool it needs.

We stress-tested it with a deliberately oversized tool: 217,316 bytes of schema, roughly 54k tokens at four characters per token, sitting in context just to make one tool callable.

You pay for that three times. It's input tokens on every call (caching softens the bill, not the rest). It's latency, more context to process before the first useful token. And it's context pressure, schema you never use crowding out the task.

The fix was to stop showing the model the catalog at all. It gets exactly two operations: search and execute. It searches with plain-language intent ("create a support ticket"), gets back a few compact cards capped at 1,800 bytes each, and executes one by its action ID. The full schema never enters context. The bridge rebinds it after selection and validates the call server-side against the real thing.

Result on the stress fixture: 217,316 bytes became a 5,062 byte card. 97.7% less, ~54k tokens down to ~1.3k, and execution stayed exact. The model still called the right tool with the right arguments. It just stopped reading the encyclopedia first.

What this does not solve, honestly:

- Discovery adds a step. The model searches before it executes.

- Large tool results still cost context. This compresses schemas, not outputs.

- It's one oversized fixture, not a promise that every catalog saves the same. What it demonstrates is the shape: two fixed operations and a few small cards, no matter how many servers you connect.

You can check your own overhead in two API calls: send the same one-line prompt with your MCP servers connected and with none, and diff the input tokens in the usage fields. That difference is your schema tax.

*We build Orca, an agent runtime, and this bridge is part of it. Happy to go deeper on any of this in the comments, including the tradeoffs.*

I've been experimenting with an MCP auth proxy that sits between the MCP client and server and handles the OAuth/token lifecycle on behalf of the client.

The basic idea:

MCP Client → Auth Proxy → MCP Server

The proxy would handle things like:

• OAuth authentication
• Access-token expiration
• Automatic/silent token refresh
• Refresh-token storage
• Multiple OAuth providers
• Client-specific OAuth quirks
• Self-hosting via Docker

The goal is that an MCP client shouldn't need to repeatedly deal with expired credentials or implement provider-specific refresh logic.

I'm considering making it open-source and self-hostable, rather than another hosted auth service.

I'm asking before building too much:

Is this actually a problem you're experiencing with MCP?

Particularly interested in people using Cursor, Claude, VS Code/Copilot, or custom MCP clients.

How are you currently handling token expiration and refresh? And what would make a proxy like this useful enough for you to actually deploy?

I'm more interested in hearing about existing pain/workarounds than getting "yes, I'd use it" answers.

Create a free MCP server for your website or organization. It allows direct integration with any other LLM or agent.

https://robauto.ai/create-mcp

I like Playwright MCP inside Cursor.

For unknown bugs it is genuinely useful.

Open the page, inspect the DOM, click around, read the console, figure out why the modal is stuck. That interactive loop is exactly what MCP is good at.

But I realised I was using the same setup for this:

Log in → open settings → change timezone → save → refresh → confirm timezone stayed changed.

The flow was already known.

Cursor still spent half the conversation opening the page, reading snapshots, deciding what to click, re-reading the page and then explaining what it saw.

It worked, but it felt like keeping an entire browser conversation alive for a 90-second smoke check.

So I split the workflow:

Unknown problem: Cursor + browser MCP

Known repeatable check: external CLI

Permanent critical flow: Playwright test in the repo

For the middle layer I’ve been trying Kane CLI from TestMu.

Cursor can read the Kane instructions through the same AGENTS.md-style path and call it after making a change.

Kane runs the objective and gives Cursor structured pass/fail output plus the browser evidence.

So instead of the coding conversation containing every click and page snapshot, Cursor basically gets:

• flow completed or failed

• assertion that failed

• final page state

• evidence from the run

That separation feels cleaner.

I’m not saying MCP always burns too much context. If the agent is debugging something unknown, that context is the whole point.

And I’m not replacing Playwright with Kane. Auth, billing, permissions and stable regression flows still belong in proper tests.

This is specifically for the awkward middle ground where the flow is too repeatable for exploration but not important enough to immediately build and maintain as a permanent test.

Do you keep browser control inside Cursor’s context, or move known checks out into CLI/CI?

Hello i've used for a lot mcp-reddit-server, but now it doesnt work anymore, are there any good mcps for reddit?

Spent the last few months actually building with AI agents instead of just reading about them. MCP servers, tool calling, the whole workflow of getting an assistant to do something useful instead of just answering questions in a chat window.

I keep running into the same problem though. Every time I search for a subreddit on this it's either dead, or it's just people posting screenshots of ChatGPT saying something mildly interesting with zero technical discussion underneath. Not what I'm looking for.

Are there actual communities where people are sharing real implementation details, debugging weird agent behavior, comparing frameworks, stuff like that? Or is this still too early and the real conversation is happening somewhere else entirely, Discord, GitHub issues, wherever. Genuinely asking because I haven't found it yet.

I like Playwright MCP inside Cursor.

For unknown bugs it is genuinely useful.

Open the page, inspect the DOM, click around, read the console, figure out why the modal is stuck. That interactive loop is exactly what MCP is good at.

But I realised I was using the same setup for this:

Log in → open settings → change timezone → save → refresh → confirm timezone stayed changed.

The flow was already known.

Cursor still spent half the conversation opening the page, reading snapshots, deciding what to click, re-reading the page and then explaining what it saw.

It worked, but it felt like keeping an entire browser conversation alive for a 90-second smoke check.

So I split the workflow:

Unknown problem: Cursor + browser MCP
Known repeatable check: external CLI
Permanent critical flow: Playwright test in the repo

For the middle layer I’ve been trying Kane CLI from TestMu.

Cursor can read the Kane instructions through the same AGENTS.md-style path and call it after making a change.

Kane runs the objective and gives Cursor structured pass/fail output plus the browser evidence.

So instead of the coding conversation containing every click and page snapshot, Cursor basically gets:

• flow completed or failed

• assertion that failed

• final page state

• evidence from the run

That separation feels cleaner.

I’m not saying MCP always burns too much context. If the agent is debugging something unknown, that context is the whole point.

And I’m not replacing Playwright with Kane. Auth, billing, permissions and stable regression flows still belong in proper tests.

This is specifically for the awkward middle ground where the flow is too repeatable for exploration but not important enough to immediately build and maintain as a permanent test.

Do you keep browser control inside Cursor’s context, or move known checks out into CLI/CI?

We do have many MCPs available and also looking for other MCPs that are not yet available to use.. what are they ? Let see how we can achieve them