n8n 2.28 Turns MCP and Instance AI Into an Operations Surface, Not a Demo Panel

n8n 2.28 Turns MCP and Instance AI Into an Operations Surface, Not a Demo Panel

n8n 2.28.0 is the kind of release that looks impossible to cover if you read it as a changelog. The compare from [email protected] to [email protected] spans hundreds of commits and hundreds of changed files. But the useful AI story is much narrower: n8n’s Instance AI and MCP surfaces are being treated like production middleware, not a demo panel bolted onto a workflow tool.

That is the right cut. Workflow automation platforms already sit near credentials, customer data, SaaS APIs, databases, approvals, and scheduled jobs. Add AI agents and MCP endpoints, and the blast radius changes. Now the system can interpret natural-language requests, call tools, edit workflows, retrieve knowledge, stream intermediate state, and execute across private credentials. At that point, the interesting engineering work is not the model dropdown. It is observability, permission gates, rate limits, OAuth negotiation, secret redaction, recoverable tool errors, and memory that does not vanish mid-thread.

n8n 2.28.0 was published on June 23, 2026. During the research run, the repository had roughly 193,808 stars, 58,788 forks, and 1,475 open issues. The release is broad, but the AI-relevant cluster is clear: Instance AI gets better metrics and error correlation; MCP gets real tool filtering, credential checks, configurable rate limits, and OAuth repair; the agent runtime gets decomposed; and several model-facing edge cases are fixed before they turn into support tickets.

Instance AI gets the observability operators actually need

PR #32400 adds structured error correlation for Instance AI. It changed 45 files with 745 additions and 321 deletions, creating a canonical context that includes threadId, runId, agentId, traceId, langsmithTraceId, and messageGroupId. It stamps traceId onto run-start SSE events and reports stream-loop, resumed-run, and background-task failures to Sentry with the same correlation metadata.

That is how agent support becomes possible. “The assistant did something weird” is not an incident report. “This run in this thread produced this trace, these logs, this LangSmith span, and this Sentry event” is. Agent systems are probabilistic at the model layer, but the runtime around them has no excuse to be foggy. Correlation IDs are not decoration; they are the rope operators use to pull a failure out of the swamp.

PR #32489 adds Prometheus metrics for Instance AI runs. It changed 16 files with 589 additions and two deletions, adding metrics such as instance_ai_runs_total{status, model} and instance_ai_run_duration_seconds{status}, plus cost, concurrency, and tool-failure visibility driven from terminal instance-ai-run-finished events. That is the difference between a feature and an operated service. If teams cannot alert on run failures, duration, cost shape, concurrency, and tool errors, they do not have an AI platform. They have a chat UI with hope-based monitoring.

MCP is useful only after the negative controls exist

The MCP work in this release is more important than another “connect tools to agents” announcement because it adds negative controls. PR #31836 makes MCP tool filtering real for Instance AI registry connections. The toolFilter column already existed; now n8n reads it, forwards it to @n8n/agents, and implements filtering in the MCP connection class. The PR changed eight files with 265 additions and 24 deletions.

Tool filtering is where MCP becomes enterprise-shaped. The question is not whether an agent can see tools. The question is which tools it should see in this context, for this user, with this registry connection, under this policy. If every available MCP tool is visible by default, the integration is convenient right up until a model picks the wrong affordance or a user discovers a tool they should never have been offered.

PR #32446 adds another necessary gate: MCP tool calls are blocked when the triggering user’s private credentials are not connected for n8nOAuth2 triggers. Instead of executing the workflow, the tool response returns connection URLs. The check happens on the request-handling main before enqueue. That placement matters. Credential availability is not a worker-side afterthought; it is part of authorization for the tool call itself.

Rate limits and OAuth negotiation also get less hand-wavy. PR #32203 makes MCP and OAuth server IP rate limits configurable through environment variables such as N8N_MCP_SERVER_RATE_LIMIT and OAuth-specific register, authorize, token, and revoke limits. PR #32289 fixes OAuth2 Dynamic Client Registration negotiation so n8n does not register token_endpoint_auth_method: "none" merely because S256 is advertised when the server actually supports confidential-client methods like client_secret_post.

Those details sound bureaucratic until you deploy behind a shared NAT, integrate with a stricter OAuth server, or watch an AI assistant trigger a tool path with the wrong credential state. Enterprise agent systems do not fail because the protocol name is wrong. They fail because the deployment assumptions are.

The runtime refactor is not glamour work. Good.

PR #32293 refactors agent-runtime.ts, which had grown into a roughly 2,700-line god class mixing telemetry, memory, tool execution, model/context assembly, and two near-duplicate agentic loops. The PR changed 89 files with 3,711 additions and 3,440 deletions, moving toward a facade plus shared runAgentLoop, RuntimeContextBuilder, MemoryOrchestrator, RuntimeTelemetry, ToolCallExecutor, and run-output sinks.

Refactors do not deserve applause by default. But this one is directionally important because agent runtimes collect invisible coupling fast. Streaming, resume, background observation, memory retrieval, tool execution, knowledge files, workflow edits, and telemetry all want to touch the same state. A giant class makes every safety check depend on every other concern behaving politely. Smaller runtime seams do not guarantee correctness, but they create places where correctness can be enforced and tested.

That matters because n8n is not building a toy agent loop. It is integrating AI into a workflow engine where tools can mutate real systems. The runtime needs explicit boundaries for context construction, memory orchestration, telemetry, tool execution, and output handling. Otherwise every new capability becomes another branch in the same maze.

The edge-case fixes are production tells

The release also fixes several agent-specific bugs that deserve more attention than they will get. PR #32276 handles malformed agent tool-call inputs without crashing the next model request. Valid stringified JSON object inputs are parsed; malformed JSON and non-object strings become model-visible tool errors; rejected calls are replayed with empty-object input instead of malformed assistant tool-use content. That is exactly the right instinct. Models will emit bad tool payloads. The runtime should convert that into a recoverable interaction, not poison the next request.

PR #32773 fixes mid-thread context loss where an observation cursor advanced even when the background observer produced zero observations, causing the next turn to load almost no prior conversation and behave as if the chat had just started. That bug class is deadly for user trust because it looks like the assistant forgot everything for no reason. In reality, memory bookkeeping lied. Agent memory failures rarely announce themselves as memory failures; they show up as inexplicable behavior.

PR #31681 preserves $fromAI() placeholders on fields with expressions disabled, fixing SQL nodes used as AI tools where expression stripping turned the placeholder into an inert string before the tool path resolved it. That is a good reminder that AI workflow builders are not just prompt routers. They sit inside existing expression systems, node schemas, UI affordances, and execution semantics. A small loader decision can break an AI tool in a way the model cannot reason about.

Secret redaction also expands. PR #32440 extends shared patterns used by Instance AI output and telemetry redaction to cover PEM private keys, JWTs, Stripe keys, Google API keys, GitHub fine-grained PATs, and credentials embedded in URLs. No redaction list is complete, but expanding the obvious categories is table stakes when model-visible output, traces, logs, and support tooling can carry sensitive workflow data.

What teams should test after upgrading

If you run n8n’s AI stack, the upgrade checklist should be operational, not aesthetic. Enable the metrics and confirm Instance AI counters and histograms appear with your expected labels. Trigger failed runs and verify you can pivot from the client-visible trace ID to LangSmith, Sentry, and logs. Check that cost, concurrency, and tool-failure metrics land where your alerts can see them.

Then test MCP like an authorization surface. Configure tool filters and confirm hidden tools are genuinely unavailable. Trigger MCP calls with missing private credentials and verify the response returns connection guidance instead of executing. Exercise OAuth Dynamic Client Registration against servers that require client_secret_post or client_secret_basic. Tune MCP/OAuth rate limits for your network topology instead of accepting defaults that may fit neither a shared office NAT nor a high-volume internal integration.

Finally, abuse the agent loop. Send malformed tool-call inputs. Run long threads with observation memory enabled and confirm history does not disappear after empty observation passes. Use SQL tools with $fromAI() placeholders and verify the resolver still sees them. Inspect logs and traces for leaked secrets. If those checks sound tedious, that is the point. Production AI systems are mostly tedious checks around a model that is very good at making the failure look novel.

The bigger take: n8n 2.28.0 shows what happens when AI workflow tooling becomes infrastructure. The maturity signal is not another template or provider. It is metrics, correlation IDs, credential gates, tool filters, OAuth negotiation, rate limits, redaction, runtime decomposition, and recoverable failure semantics. That is how an AI workflow builder earns the right to run near production systems.

Sources: n8n 2.28.0 release, Instance AI error correlation PR, Instance AI Prometheus metrics PR, MCP tool filtering PR, n8n Advanced AI docs