Ask Your AI Agent About Your NGINX Servers: Amplify MCP

Your monitoring data knows a lot about your NGINX servers. Which hosts run a version with a known CVE. Which configs have a header-injection bug. Whether 5xx errors spiked last night, and on which box. The problem is that all of it lives behind a dashboard. When you are already working with an AI coding agent, you end up copying numbers out of a browser tab and pasting them into a chat.

GetPageSpeed Amplify now has a hosted NGINX MCP server, so your agent can ask Amplify directly.

What MCP is, in one paragraph

The Model Context Protocol is an open standard for connecting AI agents to tools and data. A client such as Claude Code, Cursor, VS Code or Codex connects to an MCP server, discovers the tools it offers, and calls them when a question needs live data. You do not write glue code or prompts that describe an API. The agent sees a list of well-described tools and decides which ones to call.

What the Amplify NGINX MCP server gives your agent

The server lives at https://amplify.getpagespeed.com/mcp. It is hosted, so there is nothing to install or keep running. It uses the stateless Streamable HTTP transport and authenticates with your account API key.

Every tool is read-only. Nothing in your account can be changed through MCP, which makes it safe to connect to production monitoring.

The 14 tools cover:

• Security: get_security_overview ranks every host by NGINX CVEs, gixy configuration findings and PHP CVE exposure in a single call. get_host_security returns one host’s full detail, including suggested config fixes and PHP upgrade commands.
• Inventory: hosts, agent versions, tags, and detected components (NGINX version and modules, PHP-FPM pools, MySQL, Varnish).
• Metrics: up to 10 metrics over a time window. By default you get a compact min/max/avg/last summary per metric, so your agent’s context is not flooded with thousands of data points. Raw points are available on request.
• Alerts and websites: what fired recently, uptime, response time, HTTP/3 and TLS certificate checks.

Every host argument accepts a hostname, so the agent can say web1.example.com instead of hunting for a UUID.

Setup

First, copy your API key from the API Keys settings page.

Claude Code

claude mcp add --transport http --scope user amplify \
    https://amplify.getpagespeed.com/mcp \
    --header "Authorization: Bearer YOUR_API_KEY"

Cursor

Add this to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "amplify": {
      "url": "https://amplify.getpagespeed.com/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

VS Code (GitHub Copilot)

Add this to .vscode/mcp.json or your user MCP configuration:

{
  "servers": {
    "amplify": {
      "type": "http",
      "url": "https://amplify.getpagespeed.com/mcp",
      "headers": { "Authorization": "Bearer YOUR_API_KEY" }
    }
  }
}

OpenAI Codex CLI

Add this to ~/.codex/config.toml, then export AMPLIFY_API_KEY in your shell:

[mcp_servers.amplify]
url = "https://amplify.getpagespeed.com/mcp"
bearer_token_env_var = "AMPLIFY_API_KEY"

Any other client that supports remote Streamable HTTP servers with a custom header works with the same URL and header. Full details are in the Amplify MCP documentation.

Real questions, real answers

We connected our own agents to the Amplify account that monitors the GetPageSpeed servers and asked plain questions. These are lightly trimmed answers from those sessions. Hostnames are replaced with web1, web2 and web3, and exact file names and line numbers are removed.

“Which of my servers need security attention, and what should I fix first?”

The agent made one get_security_overview call, then drilled into each host with get_host_security:

All three servers are flagged, and the findings are all NGINX config issues. None has an NGINX CVE, and PHP on web1 is patched (8.4.27 includes the fixes for the critical “PHP2Shell” RCEs).

Host	Gixy findings (high / medium / low)
web1	16 (7 / 4 / 5)
web2	14 (3 / 4 / 7)
web3	8 (3 / 3 / 2)

Fix first: web1. It has the most high-severity findings: HTTP response splitting through unvalidated variables in two add_header lines, a regex prone to catastrophic backtracking (ReDoS), TLS 1.1 and 3DES still enabled, public DNS resolvers, and quic_bpf combined with reuseport.

Then the same three config fixes on all three hosts, which one shared change covers: ssl_protocols TLSv1.2 TLSv1.3;, a modern cipher list, and a local resolver.

That is a real prioritized work list, with the “why” attached, in about 30 seconds. One of those findings, quic_bpf with reuseport, is the exact problem behind HTTP/3 silently dropping connections after a reload. The weak TLS findings map straight to our NGINX TLS vulnerability fixes guide.

“Show gixy findings on web1 and write the NGINX config fix”

The agent returned a severity-sorted table of all 16 findings, each with a one-line fix, and wrote a patch file. It also did something we liked: it separated the fixes that came straight from gixy’s suggestions from the ones it had to infer without seeing the config, and asked us to check those against the real lines before applying. Its closing advice was the right one: run nginx -t and re-run gixy after applying.

“Did any website go down this week?”

Nothing has gone down in the last few days. There was one outage on Saturday, 17 Oct, about 07:54 to 09:07 UTC. Both monitored sites failed their checks at the same time, with timeouts, a DNS lookup timeout and “network is unreachable”. The simultaneous failures point to a network problem, not an application crash. An “Agent Down” alert fired at 09:07 UTC, which fits.

The agent correlated website check failures with an agent alert on its own and labelled its conclusion as inference, not fact.

Works the same in Codex

We asked Codex: “Which of my hosts run an outdated Amplify agent or an end-of-life PHP version?” It fanned out over list_hosts, get_host and list_host_components, then answered in three lines: two hosts need an agent upgrade, and no end-of-life PHP was found.

Why the security angle matters

Generic monitoring MCP servers can tell your agent that CPU is high. Amplify can tell it why a server is exposed:

• NGINX CVEs matched against the exact version each host runs.
• gixy findings from automatic analysis of the live NGINX configuration: header injection, SSRF-prone proxy_pass, proxy_pass path pitfalls, weak TLS, missing HSTS and more, each with a suggested fix.
• PHP CVE status per host, including PHP2Shell exposure, with the upgrade command to run.

Combined with an agent that can write config, this closes the loop from “something is wrong” to a reviewed patch. You still review and apply every change yourself, because the server is read-only by design.

Limits and data handling

MCP tools are built on the Amplify REST API (/api/v2) and follow its rules:

• 120 calls per minute per API key, shared between REST and MCP.
• Time windows are clamped to your plan’s data retention.
• Your agent sees the same data your dashboard shows. Review your AI client’s data-handling terms before connecting a production account.

Web connectors that only support OAuth sign-in, such as claude.ai and ChatGPT, are not supported yet. That is next on the roadmap.

Get started

MCP access is part of API access on the Pro plan and higher. Free and Starter accounts can connect and see the tool list, and tool calls return an upgrade pointer.

See Amplify plans and pricing

Coming from F5’s discontinued service? Amplify is a drop-in NGINX Amplify alternative: the same agent, plus security analysis, and now an MCP server for your AI agents.