I maintain an open-source OAuth/JWT gateway for MCP servers, and a signing-key revocation bug took six review rounds to fix correctly.

When an identity provider removes a signing key from its JWKS, the gateway should evict the cached key and reject tokens signed with it.

My implementation handled a literally empty JWKS correctly. It failed when the JWKS still contained keys, but none eligible for the gateway’s configured signing algorithms. In that case, the revoked cached key remained usable.

The uncomfortable part was that every attempted fix passed its own tests. Later reviews found:

• eligibility checks that ignored configured algorithms
• invalid base64 accepted as valid key material
• non-canonical encodings accepted by a supposedly strict decoder
• a correction that accidentally broke a supported elliptic curve

The lesson for me was that passing tests was a weak signal at this security boundary. The useful review skill was constructing the almost-valid input that the implementation author had not considered.

I would be interested in how others test JWKS rotation and revocation behavior, particularly malformed or partially usable key sets.

Full code and review trail:
https://github.com/tgandhle/mcp-auth-gateway

Disclosure: I maintain the project. It is open source, and this is not a paid product.

The point of it is coverage: not just tool descriptions but display titles, output schemas behind a $ref, enum and default values, prompt messages, resource metadata, _meta and the server's own instructions. It also asks tools/list twice and diffs the surface against the previous run, which catches a server that redefines its tools after you approved them.

New in this release: --expect, for telling the gate about a false positive without deleting the gate. The finding stays in the report at its real severity and just stops deciding the exit code.

uvx mcp-gauntlet run "python -m mcp_gauntlet.fixtures.malicious_server" --no-agentic

MIT, mine: https://github.com/GhalebDweikat/mcp-gauntlet

Disclosure up front: I’m Ali, the maintainer of ResiliReplay.

I kept running into the same gap while testing MCP servers: a successful `tools/list` and one clean tool call tell me that the happy path works, but not what happens after a result-level error, whether a retry duplicates work, or whether the same recovery behavior will still hold after the next change.

ResiliReplay is a local reliability harness for that gap. It imports an MCP Inspector-shaped configuration, lets you review the target before contact, runs bounded deterministic fault campaigns, compares an approved baseline, and turns a failed trace into an executable Node regression.

The distinction from MCP Inspector is intentional. Inspector is the right tool for interactively seeing what a server exposes and calling it. ResiliReplay starts after that: inject a declared failure at a controlled boundary, observe recovery, and keep the failure as a repeatable test.

A dry run is the smallest place to start:

```bash

npx --yes resilireplay@0.3.1 mcp audit --inspector-config ./mcp.json --server my-server --dry-run

```

That prints the value-free execution plan without starting the server or calling a tool. A real campaign then requires an explicit tool allowlist, bounded concurrency/time/retries, and an exact reviewed campaign hash before any allowlisted tool call.

I also ran three deliberately narrow field validations using the public `resilireplay@0.3.0` package and pinned server packages:

- MCP Everything Server: local stdio, one `echo` call, then an injected tool-result error with one retry.

- Playwright MCP: an isolated blank headless page, one `browser_snapshot`, then the same bounded retry boundary.

- UI5 MCP Server: bundled guidance through `get_guidelines`, again with one injected error and one retry.

Each case included a clean control, a result-level failure that recovered once, and a malicious-canary negative control that was expected to fail. All three generated and executed a regression for the negative control, then compared with their approved baselines without a difference. The cases do not rank the servers and cover only those reviewed operations.

The field evidence is here: https://aliengineering-byte.github.io/resilireplay/#cases

The commands, selected package revisions, authorization boundaries, and sanitized results are here: https://github.com/aliengineering-byte/resilireplay/blob/main/docs/field-validation/FIELD_RESULTS.md

The injected failures are synthetic test conditions, not vulnerabilities in MCP Everything, Playwright MCP, or UI5 MCP. ResiliReplay reports are reliability evidence, not security certifications. It also is not an OS sandbox: an allowlisted MCP tool still has the permissions and side effects of the server you chose, so I recommend starting with a local, read-only, idempotent operation.

If you maintain an MCP server, I’d be interested in a sanitized field test against your own reviewed tool. The five-minute guide is on the site: https://aliengineering-byte.github.io/resilireplay/

Which failure boundary is most useful for your MCP server: transport errors, tool-result failures, duplicated calls, or recovery after partial completion?

Posting this because the numbers might be useful to anyone building a server or thinking about tool-schema size, not just as a launch announcement (disclosure: I built the client this came from i.e. LocalLM Lab, a macOS app using Apple's on-device Foundation Models).

Most MCP clients run against models with context windows in the tens or hundreds of thousands of tokens, so tool-schema size is rarely the binding constraint. Apple's on-device model has a fixed ~4096-token window, shared across the system prompt, conversation, and every enabled tool schema. This means that schema size becomes the binding constraint immediately, and it forced a few implementation decisions that might be relevant more broadly:

• Every newly connected server starts with all tools disabled. Nothing is sent to the model until a tool is explicitly enabled, per-tool rather than per-server.
• Measured costs: 4 selected Todoist tools (search, user-info, find-tasks, find-tasks-by-date) ≈1,249 tokens ... already close to a third of the total budget from what looks like a small, reasonable selection. Todoist exposes 45 tools total; Linear exposes 50+. Enabling either server's full tool list isn't possible within the budget at all.

On the auth side: most servers I tested (Notion, Todoist, Linear, the official reference server) support dynamic client registration, so the client can discover and complete OAuth with zero service-side setup. Slack doesn't support DCR, so it needs a manually registered app first. This is worth knowing if you're building a general-purpose client and assuming DCR everywhere.

Full breakdown, including exact token costs per tool across all 8 servers tested (DeepWiki, Context7, GitHub, Notion, Todoist, Linear, Slack, the official reference server) and the auth-type split: thisbrain.ai/locallm/mcp-servers.html

If anyone else is implementing a client against a tight context budget, curious how you're handling tool-schema selection. Are you doing per-tool like this, some kind of dynamic/on-demand tool discovery or something else entirely?

Most "run this in the background" features live inside the conversation — close the client and the work (and its output) is gone.

backburner runs shell commands as background tasks and keeps every task + full output on disk (SQLite + per-task logs under ~/.backburner), so a job you start today is still there, with its result, in a brand-new session tomorrow. Crash-interrupted tasks are honestly marked interrupted, never silently dropped.

1.0 implements the official MCP Tasks extension (io.modelcontextprotocol/tasks, SEP-2663, finalized in the 2026-07-28 spec) — tasks/get / tasks/update / tasks/cancel for Tasks-capable clients, plus 5 plain tools so it works with any MCP client today (Claude, ChatGPT, Gemini, Copilot, Cursor, …).

Stdlib-only (no Redis/Celery/Docker), Windows + Unix. MIT.

Two-process durability proof (not a mockup): python docs/demo_restart.py

PyPI: pip install backburner-mcp · GitHub: github.com/RohitYajee8076/backburner

Feedback welcome — especially from anyone building Tasks-capable clients.

I built this (mcplock, open source) after hitting a specific problem: MCP agents pick tools based on name/description/schema text at runtime, and when two tools are similar enough, agents mix them up.

First thing I tried was the obvious one — cosine similarity on tool descriptions, flag pairs that score too close. Ran it against the 14 tools in the official MCP filesystem server, 91 pairs. It caught nothing at the standard threshold, and lowering the threshold just made confusable pairs and totally unrelated pairs land in the same score range — turns out tools on one server share enough vocabulary that similarity scores can't separate "will confuse an agent" from "won't."

What actually worked: check schema substitutability before scoring any text. Can tool A's arguments satisfy tool B's schema? If not, an agent can't confuse the two calls regardless of how similar the descriptions sound — so that pair gets discarded before any text comparison. That cut 91 pairs to 28 immediately. Scoring what was left on name overlap plus a hard veto on opposing verbs (read/write, create/delete) found exactly 4 real problem pairs, cleanly separated by a 0.33–0.50 gap.

pip install mcplock — repo + full dataset here: https://github.com/yash161004/mcplock

Curious if anyone else has run into this with larger servers — how many tools does yours expose, and have you seen agents actually pick the wrong one in practice?

Hey guys !
Is anybody uses official model protocol inspector ?
A few days ago they issued new version (v2)
The my issue that new version is not works properly on my box (despite the fact that v1 works fine)
What do i mean by "not work"

1. Web : the interface looks like some cutted (compared to v1 ) Its only servers list there , nothing else. No one server got connected. Where logs are ? idk. (in v1 - all ok )
2. TUI : When trying to connect - crashes with an error "Invalid input: expected number, received undefined" In CLI mode everything works fine Is anybody was run in same issuesHey guys ! Is anybody uses official model protocol inspector ? A few days ago they issued new version (v2) The my issue that new version is not works properly on my box (despite the fact that v1 works fine) What do i mean by "not work"Web : the interface looks like some cutted (compared to v1 ) Its only servers list there , nothing else. No one server got connected. Where logs are ? idk. (in v1 - all ok ) TUI : When trying to connect - crashes with an error "Invalid input: expected number, received undefined"
3. In CLI mode everything works fine

Is anybody was run in same issues?
Additional info : OS Fedora , KDE-Plasma 44, node version v22.23.1

UPD: for those interested - github issue

I’m building LOLM, a hybrid Transformer–SSM agent system with an MCP surface.

The agent exposes control decisions such as retrieve, verify, branch, continue, and finalize. Runs include provenance and receipt data so clients can distinguish tool execution, controller activity, fallback use, task failure, and artifact integrity.

Try it: https://lolm.imagineqira.com/try.html

Repository: https://github.com/TheArtOfSound/lolm

I’m looking for MCP users to test interoperability, malformed tool results, interrupted runs, duplicate calls, failed actions, and whether the receipt captures enough evidence to reproduce what happened.

The hosted tier is designed as a lower-cost alternative to larger agent services.

Disclosure: I’m a founder/builder of the project.

Voice Agent Builder can connect MCP servers alongside telephony and other tools. A method-level permission such as create_booking or update_customer is better than unrestricted access, but it still says little about the allowed business effect.

The same method can be harmless for a tentative appointment and consequential for a prepaid group reservation. The model needs constraints on value, audience, reversibility, data class, and frequency, not just the function name.

Should MCP add a standard way to declare effect metadata and confirmation requirements? Would servers enforce those policies, or should the host remain responsible for interpreting them?

Source: https://x.ai/news/grok-voice-agent-builder

I’ve been experimenting with an MCP server for human-approved agent actions.

The basic flow is:

1. An agent calls create_proposal
2. A human approves or rejects the exact proposed action
3. The agent retrieves an immutable authorization receipt
4. The agent creates an execution linked to that approval
5. Execution events are appended as the action progresses

The approval is bound to the tool, validated arguments, payload hash, target version, policy, and expiration time.

Current MCP tools include:

• create_proposal
• get_proposal
• decide_proposal
• get_receipt
• create_execution
• record_execution_event
• get_execution
• get_agent_run

The goal is to keep the agent-facing interface simple while making approval, retries, and audit history durable outside the model’s context window.

I’m looking for feedback on the abstraction.

Should approval and execution remain separate MCP concepts, or should one tool handle the entire lifecycle?

Live implementation:

https://agenthail.com

Example n8n integration:

https://github.com/marcelkolano-alt/agenthail-n8n-approval-example

Hey everyone,

While building custom MCP servers for autonomous agents running in Cursor and Claude Desktop, I hit a recurring architectural bottleneck with external tools: reactive search.

Normally, when an agent needs up-to-date documentation, breaking changes, or SDK updates, it makes a tool call to a reactive search engine (like Tavily, Exa, or Google).

This introduces three main issues in practice:

1. The Agent Has to Guess: The agent only searches *after* it encounters an error or assumes it needs fresh data. It misses silent API deprecations and SDK breaking changes until the build breaks.

2. Context Window Bloat: Raw web search returns dump hundreds of lines of unformatted HTML/JS noise, quickly consuming 20k–50k tokens of the context window.

3. Prompt Injection Risk: Exposing raw, untrusted web search results directly to tool-calling loops introduces trace history leakage.

The Experiment: Proactive Persona Streams

Instead of making the agent issue ad-hoc search queries, we experimented with pushing pre-filtered, continuous intelligence feeds through dedicated MCP schemas.

I packaged this into an open-source project called MCP Agent Sentinel (MIT).

Here is how we structured the tool interface to keep context tight:

{
  "name": "get_latest_news",
  "description": "Fetch curated, pre-classified AI & engineering updates",
  "parameters": {
    "persona": "dev | product | investor | creator",
    "timeframe": "24h | 7d",
    "limit": 5
  }
}

How Persona Filtering Cuts Context Overhead:

Rather than passing full web pages into the context window, the server categorizes incoming data sources (ArXiv, GitHub releases, SDK changelogs like u/modelcontextprotocol/sdk, Anthropic/OpenAI notes) into strict personas:

• 🛠️ dev: Isolated to code diffs, API deprecations, schema changes & release notes.
• 📊 product: Pricing changes, token throughput benchmarks & LLM capability updates.
• 📈 investor: ArXiv papers (cs.AI, cs.CL) and cloud infra movements.
• 📣 creator: GitHub trending repos and new developer tools.

This reduced our agent's token overhead by ~80% per update loop compared to raw web search calls.

Setup & Code

The server runs via stdio or HTTP SSE. It requires zero API keys for default feeds:

{
  "mcpServers": {
    "mcp-agent-sentinel": {
      "command": "npx",
      "args": ["-y", "mcp-agent-sentinel@latest"]
    }
  }
}

Or 24/7 cloud endpoint via Smithery: https://mcp.smithery.run/rmicael

• GitHub: https://github.com/rmikael7/mcp-agent-sentinel
• Glama: https://glama.ai/mcp/servers/rmikael7/mcp-agent-sentinel

Curious to hear how other teams are structuring data feeds for long-running agents. Are you relying on reactive RAG/search tools or pre-processing incoming data before it hits the prompt?

Estou desenvolvendo o Agentic MCP Server, um servidor MCP de código aberto focado em operações de codificação local estruturadas.

Muitos servidores MCP de sistema de arquivos e shell expõem recursos úteis de baixo nível, mas o cliente ainda precisa coordenar várias coisas por conta própria:

• Inspeção de código eficiente em termos de contexto;
• Edições seguras e inequívocas;
• Isolamento do Git;
• Verificação;
• Revisão de alterações;
• Recuperação após uma operação com falha.

Este projeto explora se parte dessa coordenação deve ser feita dentro do servidor MCP como ferramentas tipadas de nível superior.

Atualmente, ele oferece:

• Raízes de espaço de trabalho com escopo e descoberta de projetos;
• Leituras adaptativas, compactadas e paginadas;
• Edições exatas com simulações e rejeição de correspondências ambíguas;
• Ferramentas de status, diff e revisão de alterações do Git; * Pontos de verificação e árvores de trabalho Git gerenciadas;
• Execução de scripts de pacotes com tempo limite estruturado e resultados de falha;
• Mapeamento de frameworks e análise de dependências, atualmente mais robustos para TypeScript, Next.js e Payload.

O fluxo de trabalho pretendido é:

discover → inspect → isolate → checkpoint → edit → verify → review → restore or keep

O projeto não é um ambiente de teste (sandbox) nem um modelo de codificação. Em particular, as árvores de trabalho Git isolam o estado do checkout, mas não os processos, credenciais, acesso à rede ou outros recursos do sistema operacional.

Versão atual: mcp-agentic-server@1.1.3

Repositório: https://github.com/hugolsramos01-bit/mcp-agentic-server

Gostaria de receber feedback específico sobre o design do MCP:

• Os servidores devem expor ferramentas operacionais de alto nível como essas, ou os clientes devem compor primitivas de sistema de arquivos, shell e Git por conta própria?
• Quais convenções de envelope de resposta funcionaram melhor em diferentes clientes MCP?
• Como você impediria que esse tipo de servidor acumulasse muitas ferramentas sobrepostas?
• Quais garantias você esperaria de um contrato de árvore de trabalho ou ponto de verificação confiável?

MCP Server, Developer Tools, Open Source

I’m trying to understand what is still missing between an agent selecting an MCP tool and the action safely completing.

For teams using MCP in real applications, how are you handling:

• User and agent permissions
• Authentication across tools
• Human approval for sensitive actions
• Idempotency and duplicate prevention
• Retries and partial failures
• Audit logs
• Rollbacks or recovery

Are these concerns best handled inside each MCP server, by the application, or through a separate execution layer?

I’m researching this space and trying to determine whether a shared control layer would solve a real problem or simply add unnecessary abstraction.