DEV Community: Sergey Byvshev

MCP servers for the entire team: from local launch to centralized access

Sergey Byvshev — Wed, 15 Apr 2026 06:50:14 +0000

When you have six MCP servers and ten colleagues, "just run npx locally" stops working. Not everyone wants to install Node.js, managers don't have Docker, and your local claude_desktop_config.json starts looking like a secrets vault for every production system.

I went from remote MCP → local setup → Docker → Kubernetes with a universal Helm chart and JWT auth via Envoy. Here's what I hit along the way, what worked, and what's still unsolved.

Level 1: Remote MCP — When the Vendor Did the Work

My first MCP experience was dead simple. I added the Atlassian MCP server to Claude as a remote MCP, authenticated, and it just worked:

{
  "mcpServers": {
    "atlassian": {
      "type": "http",
      "url": "https://mcp.atlassian.com/v1/sse"
    }
  }
}

The problem? Very few SaaS products offer this. Everything self-hosted or without native MCP support is a different story.

Level 2: Local Setup — The Dependency Zoo

Next, I wanted to connect my IDE to Kubernetes. No built-in MCP support here, so dependencies it is:

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

It worked, but one server needs Node.js, another needs Python and uvx, a third needs a Go binary. The runtime zoo on your machine grows with every new MCP server. Not great when you're not even a developer.

Level 3: Docker — Isolation Without the Mess

The logical next step — containers. Each MCP server with its own runtime, no host pollution:

{
  "mcpServers": {
    "grafana": {
      "command": "docker",
      "args": [
        "run", "--rm", "-i",
        "-e", "GRAFANA_URL",
        "-e", "GRAFANA_SERVICE_ACCOUNT_TOKEN",
        "grafana/mcp-grafana",
        "-t", "stdio"
      ],
      "env": {
        "GRAFANA_URL": "https://grafana.example.com",
        "GRAFANA_SERVICE_ACCOUNT_TOKEN": "<token>"
      }
    }
  }
}

For one engineer on one machine — enough. But when ten people need access, questions pile up:

Production tokens are scattered across laptops.
Automated workflows (n8n, CI/CD) need MCP access too — and they run remotely.
Managers and analysts want AI tools but aren't ready to deal with docker run.

One conclusion: MCP servers need to move into shared infrastructure.

Level 4: Kubernetes — Centralized Deployment

The initial idea was straightforward: deploy remote MCP servers inside your infrastructure perimeter. At minimum, you can restrict access via corporate VPN.

Anyone who's tackled this has hit the same wall: most MCP servers communicate via stdio (stdin/stdout). You can't reach them over HTTP directly.

This is where MCP Gateway comes in — a proxy that translates Streamable HTTP to stdio and back.

The flow: client (Claude Desktop, IDE, n8n) → HTTPS → Ingress → Kubernetes Service → Pod with MCP Gateway sidecar (HTTP → stdin) → MCP server process.

Universal Helm Chart

To avoid writing manifests for every MCP server, I built a universal Helm chart: mcp-helm-chart on ArtifactHub.

What it supports:

mode: proxy — runs MCP Gateway as a sidecar, translating HTTP ↔ stdio
mode: native — for servers that already support HTTP (no sidecar needed)
Vault and ExternalSecrets integration for secrets management
Gateway API and classic Ingress support
HPA for horizontal scaling

Installation with Ingress-nginx (no auth):

helm repo add mcp https://javdet.github.io/mcp-helm-chart
helm install my-mcp mcp/mcp -f values.yaml

Key sections of values.yaml for deploying DigitalOcean MCP:

mode: proxy

proxy:
  image:
    repository: node
    tag: "20-bookworm"
    pullPolicy: IfNotPresent
  gateway:
    package: "@michlyn/mcpgateway"
    stdioCommand: "npx -y @digitalocean/mcp --services apps,droplets,doks,networking"
    outputTransport: streamable-http
    port: 8080
    httpPath: /mcp

# Token stored in HashiCorp Vault, injected via Vault Webhook
vault:
  enabled: true
  role: "mcp"
  path: "kubernetes_dev-fra1-01"

env:
  - name: DIGITALOCEAN_API_TOKEN
    value: vault:devops/data/ai/mcp/digitalocean#token

ingress:
  enabled: true
  className: "internal"
  annotations:
    nginx.ingress.kubernetes.io/proxy-buffering: "off"
    nginx.ingress.kubernetes.io/proxy-http-version: "1.1"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
    nginx.ingress.kubernetes.io/use-regex: "true"
    nginx.ingress.kubernetes.io/rewrite-target: /$2
  hosts:
    - host: aitool.example.com
      paths:
        - path: /digitalocean(/|$)(.*)
          pathType: ImplementationSpecific
  tls:
    - secretName: ssl-certificate
      hosts:
        - aitool.example.com

MCP servers in Streamable HTTP mode are stateless. They scale horizontally with a standard HPA without any issues.

The most pressing question here is authentication — or better yet, authorization. Most MCP servers don't support incoming authentication, so you have to handle it yourself.

Authentication: JWT via Envoy

Basic auth is barely better than nothing, so — straight to JWT. I used Envoy API Gateway since it natively supports JWT validation and was already in our stack.

Key and Token Generation

# 1. Generate RSA keys
openssl genrsa -out mcp-jwt-private.pem 4096
openssl rsa -in mcp-jwt-private.pem -pubout -out mcp-jwt-public.pem

# 2. Generate Key ID
KID=$(openssl rand -hex 16)

# 3. Build JWT header (base64url)
HEADER=$(echo -n "{\"alg\":\"RS256\",\"typ\":\"JWT\",\"kid\":\"${KID}\"}" \
  | base64 -w0 | tr '+/' '-_' | tr -d '=')

# 4. Build JWT payload (1 year expiry)
PAYLOAD=$(echo -n "{\"sub\":\"claude-desktop\",\"aud\":\"mcp-servers\",\"iss\":\"https://your-domain.com\",\"iat\":$(date +%s),\"exp\":$(( $(date +%s) + 31536000 ))}" \
  | base64 -w0 | tr '+/' '-_' | tr -d '=')

# 5. Sign
SIGNATURE=$(echo -n "${HEADER}.${PAYLOAD}" \
  | openssl dgst -sha256 -sign mcp-jwt-private.pem \
  | base64 -w0 | tr '+/' '-_' | tr -d '=')

# 6. Final token
echo "${HEADER}.${PAYLOAD}.${SIGNATURE}"

The public key is packaged into JWKS and stored in a ConfigMap. Envoy validates every incoming request by checking issuer, audience, and signature.

Auth configuration in the chart values (Gateway API variant):

gatewayApi:
  enabled: true
  parentRefs:
    - name: internal
      namespace: ai-infra
      sectionName: https
  hostnames:
    - mcptools.example.com
  timeouts:
    request: "3600s"
    backendRequest: "3600s"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /digitalocean
      filters:
        - type: URLRewrite
          urlRewrite:
            path:
              type: ReplacePrefixMatch
              replacePrefixMatch: /
  auth:
    type: jwt
    jwt:
      providers:
        - name: mcp-jwt-auth
          issuer: mcp-issuer
          audiences:
            - mcptools.example.com
          localJWKS:
            type: ValueRef
            valueRef:
              group: ""
              kind: ConfigMap
              name: jwks-config

# If you use External Secrets Operator, secrets can be fetched through it
externalSecrets:
  enabled: true
  refreshInterval: 1h
  secretStoreRef:
    name: aws
    kind: ClusterSecretStore
  target:
    creationPolicy: Owner
  dataFrom:
    - extract:
        key: infra/mcp/digitalocean

Currently, access to target systems (DigitalOcean, Grafana, Kubernetes) goes through a single service account. For read-only tasks — monitoring, diagnostics, fetching info — this is enough. For write operations, the question remains open..

Automated Access

Periodic tasks (n8n workflows, CI/CD pipelines) connect to the same MCP servers over Streamable HTTP with separate service JWT tokens. The setup is identical — only the subject in the token payload differs, and optionally the access scope at the Gateway level.

What's Working, What's Not

MCP tooling and infrastructure still have a few steps to take toward each other before usage becomes truly simple, reliable, and secure.

The current setup works: six MCP servers in Kubernetes, one Helm chart, JWT auth via Envoy, secrets in Vault. Colleagues connect to remote MCP servers with zero local dependencies, automation uses the same endpoints.

What's still missing:

Per-user authorization. The MCP protocol doesn't support passing user context. We're living with service accounts for now.
Audit logging. Who called which tool with what parameters — not logged at the MCP level. You can collect this at the Envoy layer, but without call context.
Auth standard. Every vendor does it differently. OAuth, API Key, Bearer — no unified approach.

The Helm chart is open source: ArtifactHub.

How do you handle per-user authorization for MCP? We're still on a single service account — would love to hear from anyone who's moved past that.

AI Is for DevOps: How a Neural Network Debugs Failed Pipelines

Sergey Byvshev — Wed, 01 Apr 2026 14:38:51 +0000

How often does someone rush to you wide-eyed, begging for help with a broken pipeline? Or you find yourself staring at a red status in Slack on a Friday evening, knowing the next 15–20 minutes will be spent on routine work: open the log, find the error line, compare with the last commit, check dependencies…

The work is straightforward. And that's exactly why it's boring — a perfect candidate for automation.

Fortunately, neural networks can now handle this for us and provide solid advice (not all of them, but some definitely can).

What to Think Through Beforehand

Before writing any code, it's worth answering four questions. They'll define the architecture of the entire solution.

What events trigger the analysis? In our case — a job that finished unsuccessfully in CI/CD. To start diagnostics, it's enough to pass the agent the last 50 lines of the build log and the pipeline file contents.

What data sources will be needed? The main ones are the version control system (repository access), CI/CD (full log, related jobs), an endpoint availability checker, and CI agent resource consumption metrics.

To build such an engineer, you first need to determine:

What events and in what format to provide to the engineer?
What sources and data might be needed?
How to manipulate this data to identify the root cause?
What should the diagnostic output look like in form and content?

How to analyze the data? This is the most interesting part, because there are many scenarios depending on the job type:

Build jobs — dependency issues (missing, incorrectly specified, unavailable), code errors, insufficient build resources.
Test jobs — code errors, incorrectly written tests.
Deploy jobs — manifest errors, issues on the target platform side.
Common problems — errors in the pipeline/workflow itself, missing utilities on the agent, agent initialization issues.

What should the report format be? Most often, such a report is read by human eyes in a chat, so it should be written in plain language. Concise, facts only: what was found, most probable causes, specific steps to fix. A convenient place for such a report is a thread under the corresponding error message or a dedicated channel.

Solution Architecture

At a high level, the flow works like this: an event arrives about a job completing unsuccessfully. Then we request data for analysis: build logs, pipeline description. Based on this data and its system prompt, the AI agent performs the failure analysis. During the process, the assistant can independently check the repository, see what changed, and so on. In case of external endpoint unavailability errors, it can verify this. On a failed deploy, it can check application logs and metrics. As a result, several most probable failure causes and remediation steps are generated. This data is then sent to the team chat.

Time to Implement

Some implementation aspects are covered in more detail in a the article.

n8n — You can quickly launch n8n with the MCP update using docker-compose (see below)
Gitlab
Grafana
Loki
Prometheus
Slack

Setting Up Incoming Events

The first step is to create a webhook in n8n. Gitlab uses the X-Gitlab-Token header for authentication, so in n8n we select Header Auth and specify the corresponding credential.

In Gitlab, we configure webhook delivery. This can be done for an individual repository or for an entire group. We specify the webhook address and the secret token, and from the event types we select Pipeline events.

Then, using the If node, we filter out all non-failed events — we don't need them.

Data Collection

As soon as we receive a job failure event, we request details from Gitlab. For this, you'll need to create a gitlab access token (I recommend read-only) and the corresponding credential in n8n.

As soon as we receive a job failure event, we request details from Gitlab. For this, you'll need to create a gitlab access token (I recommend read-only) and the corresponding credential in n8n.
Then we merge all the collected data using the Merge node.

Error Analysis

Data arrives to the agent in the following format:

{ "job_log": "Last 50 lines of failed job" },

{ "data": "Content .gitlab-ci.yml" },

{ "pipeline": {} },

{ "failed_job": {} }

This format should be communicated to the agent in advance via the system prompt. There we also describe the available tools, the investigation strategy (based on the considerations outlined above), and the desired output report format.

It's best to use the latest model versions, as they handle MCP tool use significantly better. We don't connect memory here, since each build failure is an independent event for the agent.

MCP Tools

The agent has access to three tools:

Gitlab MCP — for retrieving additional information about the failed job, code changes, etc.
Grafana MCP — for retrieving CI agent metrics, as well as failed deploy logs.
HTTP Request — n8n's built-in tool for checking endpoint availability.

Important note: make sure your MCP servers are running in remote mode. If an MCP server doesn't support remote out of the box, you can solve this with mcpgateway — it proxies HTTP to stdin. For the transport method, streaming HTTP is the best choice.

Posting to Chat

The final step is sending the generated report to Slack. The report goes to the selected channel or thread.

Testing and Real-World Examples

The final workflow looks like this.

Example 1: Failed Build

Gradle can't resolve a dependency. The agent determines that this is a dependency resolution issue, not a compilation error. It provides specific causes: the artifact isn't published in the repository, or credentials are unavailable inside the Docker build context. For each cause — concrete steps to fix.

Example 2: Infrastructure Change Errors

Terraform plan fails with Unsupported argument errors. The agent recognizes that the HCL configuration contains attributes not supported by the current DigitalOcean provider schema. It provides three probable causes — from the wrong resource type to provider version mismatch — with specific remediation steps for each.

Conclusion

We've built an assistant that performs full error analysis in approximately 30 seconds. This allows the team to respond to failed jobs significantly faster and spend their time on real engineering tasks rather than routine log analysis.

Token consumption stays at the level of a few thousand per analysis.

Base workflow version is here.
Full tutorial with all scripts can be seen here

AI Alert Assistant: How n8n + LLM Replace Routine Diagnostics

Sergey Byvshev — Tue, 24 Mar 2026 06:35:05 +0000

Anyone who has dealt with keeping services running knows how exhausting and unpredictably time-consuming incident diagnostics and resolution can be.

Over the years, I've watched the evolution of incident response processes — from "whoever spots the problem first owns it" to strictly defined 24/7 on-call rotations, SLA-driven response times, runbook adherence, and separation of responsibility across platforms.

One thing has remained constant:

Gathering data from multiple sources 1.1. Metrics 1.2. Logs 1.3. Traces 1.4. Release and maintenance timelines
Analysis based on personal knowledge and experience
Formulating possible solutions

If you have a documented procedure for every situation, that simplifies things somewhat — but it doesn't teach the investigative mindset needed for real troubleshooting.

Writing and maintaining a runbook for every alert is tedious work, which is exactly why an experienced engineer will always outperform a library of hundreds of runbooks.

But what if an engineer's function could be performed even when no engineer is physically present?

Designing the Assistant: What to Define Upfront

Before writing any code, four questions need to be answered:

What events, and in what format, should be provided to the agent?
What data sources might it need?
How should it manipulate that data to identify the root cause?
What should the diagnostic report look like in terms of form and content?

Let's break down each one. A link to the workflow itself can be found below.

Events and Format

Typically, what's sufficient to kick off diagnostics is an event containing:

Alertname
Description
Labels
job_name
namespac
pod
env
region
Grafana Dashboard
Runbook Url

Data Sources

Most frequently, we turn to:

Metrics that have breached acceptable thresholds
Resource consumption and load metrics
Error logs
The platform — Kubernetes or a standalone server
Related CI/CD releases
Alert definitions and firing conditions

Data Analysis

There is arguably no canonical sequence of steps for analysis. The diagnostic process is inherently variable — which is why no one has yet managed to write a single script that covers every possible scenario. But we'll give it a shot.

First, let's consider how we ourselves approach incident diagnosis:

Examine what's happening with the metric that triggered the alert: determine the nature of the anomaly — a spike, monotonic growth, or a persistently critical value
Determine whether this is a software-level failure or caused by issues at a lower layer
Check infrastructure metrics: resources, networking, system limits
Inspect logs at the point where the problem is occurring
Determine how recently the affected components were updated and what changed
Attempt to interact with the components directly — through the orchestrator or a Linux shell

Report Format

In most cases, this kind of report is meant to be read by humans, so it should be written in plain, natural language. Concise — just the discovered facts, a list of hypotheses, and possible remediation steps. The most convenient place for such a report is a thread under the corresponding alert in the team chat.

Solution Architecture
Here's the desired flow: when an alert fires, the event is sent to a webhook that extracts the relevant data and assembles a clear, well-structured prompt for the AI agent.

The AI agent, guided by its system prompt and the available MCP tools, performs diagnostics and generates a report in a predefined format.

The report is then posted to the team chat.

Implementation

If you're in a hurry, you can view the finished workflow below.

As the execution environment for workflows like this, I chose n8n because it:

Lets you build easily readable automations fairly quickly
Makes it simple to share your work
Separates logic from secrets and other hardcoded values
Has a free self-hosted version
Has an enormous community

Personally, it reminds me of Jenkins about ten years ago — and Jenkins was great.
You can install n8n using any of the methods described in the documentation, for example using docker-compose

From here, the implementation will depend on the systems you use. In my case:

Preprocessing Incoming Events

Alertmanager can send alerts to a custom webhook. In n8n, all you need to do is create a Webhook trigger node and and you can also specify authentication parameters.

Add data about the created webhook to the new receiver n8n in alertmanager.
After this, we'll be able to send alerts from Alertmanager to our workflow. However, the received messages contain unnecessary data, and the format is not entirely appropriate. This will make it difficult for LLM to understand what's being asked of it, leading to increased token consumption. Therefore, we'll make a small modification using Code node.

You'll likely want to store certain values as variables — for instance, the UID of your Prometheus datasource in Grafana.

AI Agent

A prerequisite for the AI Agent node to operate is a connected LLM. Almost any neural network can be connected, but in my experience, Codex and Opus perform best.

We don't use Memory here, since each alert is an independent event unrelated to others.
One of the key aspects is writing the system prompt. What should it include?

Agent purpose — what it's supposed to do
Brief description of your infrastructure and the type of service you provide
Description of each MCP tool — e.g., use the Kubernetes MCP to get pod status, related events, etc.
Important rules to follow and pitfalls to avoid — e.g., never ask questions, write the response in a specific language, never make any changes to the infrastructure
Diagnostic guidelines — essentially what we discussed in the Data Analysis section above

MCP — The Agent's Eyes and Ears

MCP tools serve as the agent's eyes and ears, giving it the ability to interact with the subject of diagnosis. The specific list may vary depending on your infrastructure, but the core categories of data sources (which we outlined earlier) remain the same. In my case, the list looks like this:

Metrics — mcp-grafana
Logs — mcp-grafana
Platform — kubernetes-mcp, digitalocean-mcp
CI/CD releases — gitlab-mcp
Alert descriptions — vector store

When running your mcp's, make sure they are running in remote http streaming mode.

Vector Store

The knowledge base deserves separate attention. It allows you to store large volumes of information and perform fast lookups. This saves tokens and reduces the time spent on external system queries. I use Qdrant as this knowledge base. I strongly recommend setting a service API token for authentication.

Next, you need to create a collection where your knowledge will be stored. You can do this through the web interface at http://:6333/dashboard.

Create a QdrantApi account and use it to connect.

Once the database is connected to the agent as a tool, it's time to load it with knowledge. I use a separate workflow for this.

Simply run this workflow and upload your knowledge file(s) through the form that appears — they'll be saved to the database.

Posting to Chat

After the AI agent completes its work, we need to send the results to the chat where engineers will see them. The delivery chain consists of three nodes:

Search for recent messages in the alerts channel. Unfortunately, not all group chats support keyword search via API, so the last 10 messages are retrieved instead.
Find the message that corresponds to our alert.
Post the diagnostic results as a thread reply to that message.

For Slack integration, you'll need to set up authentication following the official Slack API documentation.

Testing and Examples

Here's what the final workflow looks like.

I've tested minor variations of this workflow across several projects, and here are the results.

On average, analyzing an alert takes 30 seconds. In that time, the agent manages to inspect metrics, review logs, assess the state of the K8s cluster, and deliver a verdict.

Conclusion

What we end up with is an assistant that gets to work the instant an alert fires. The analysis time is minimal, which guarantees that by the time an engineer sees the alert, the initial diagnostics will have already been completed.

This is just one of the directions where AI can meaningfully simplify life for infrastructure teams — and for development teams who are forced to handle their own support. The agent doesn't replace the engineer, but it takes on the first-response diagnostics and shortens the gap between "alert fired" and "we understand what's going on." And at night — when the on-call engineer is asleep — that can be invaluable.

There is base version of workflow: https://github.com/javdet/automagicops-workflows/tree/main/workflows/AlertAssistant
Want to quickly implement a similar flow for yourself? Read the full Patreon guide with detailed examples and practical tips.
Author of the article: https://linkedin.com/in/sergeybyvshev