docs: reconcile AGENTS.md, config.example.toml, and CONTRIBUTING.md with implementation

[Copilot]

Nightly reconciliation found 8 discrepancies between documentation and actual implementation. All are documentation-only fixes — no code changes.

AGENTS.md

• Guard types: internal/guard/ description listed AllowOnly (a policy key) instead of the actual exported types — corrected to NoopGuard, WasmGuard, WriteSinkGuard
• Missing packages: Added internal/httputil/, internal/oidc/, internal/proxy/, internal/syncutil/, internal/tracing/ to Project Structure
• DOCKER_API_VERSION: Removed — not referenced anywhere in internal/**/*.go
• Missing env vars: Added MCP_GATEWAY_PORT, MCP_GATEWAY_DOMAIN, MCP_GATEWAY_API_KEY (read by config_env.go / validation_env.go) and ACTIONS_ID_TOKEN_REQUEST_URL / ACTIONS_ID_TOKEN_REQUEST_TOKEN (used in oidc/provider.go)
• make test-integration: Changed "requires build" → "auto-builds binary if not present" (Makefile lines 68–71 auto-build)

config.example.toml

Overstated caveat said ${VAR} expansion is unsupported everywhere in TOML. Corrected to clarify it is unsupported in server args/env fields only — [gateway.opentelemetry] and [gateway.tracing] sections do expand ${VAR} via expandTracingVariables().

CONTRIBUTING.md

Changed --payload-dir /tmp/payloads example to --payload-dir ./payloads.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• example.com
  • Triggering command: /tmp/go-build1388902967/b513/launcher.test /tmp/go-build1388902967/b513/launcher.test -test.testlogfile=/tmp/go-build1388902967/b513/testlog.txt -test.paniconexit0 -test.timeout=10m0s -goversion go1.25.9 -c=4 -nolocalimports -importcfg /tmp/go-build1388902967/b495/importcfg -pack /tmp/go-build1388902967/b495/_testmain.go -W .cfg 649178/b314/ x_amd64/vet . --gdwarf2 --64 x_amd64/vet (dns block)
• invalid-host-that-does-not-exist-12345.com
  • Triggering command: /tmp/go-build1388902967/b495/config.test /tmp/go-build1388902967/b495/config.test -test.testlogfile=/tmp/go-build1388902967/b495/testlog.txt -test.paniconexit0 -test.timeout=10m0s /tmp/go-build1388902967/b398/vet.cfg 1.80.0/encoding/-errorsas 64/src/debug/dwa-ifaceassert x_amd64/vet /tmp/go-build477/opt/hostedtoolcache/go/1.25.9/x64/pkg/tool/linux_amd64/vet -imultiarch x86_64-linux-gnu-bool x_amd64/vet --de�� _.a --debug-prefix-m-ifaceassert x_amd64/vet -I race/v1 -I x_amd64/vet (dns block)
• nonexistent.local
  • Triggering command: /tmp/go-build1388902967/b513/launcher.test /tmp/go-build1388902967/b513/launcher.test -test.testlogfile=/tmp/go-build1388902967/b513/testlog.txt -test.paniconexit0 -test.timeout=10m0s -goversion go1.25.9 -c=4 -nolocalimports -importcfg /tmp/go-build1388902967/b495/importcfg -pack /tmp/go-build1388902967/b495/_testmain.go -W .cfg 649178/b314/ x_amd64/vet . --gdwarf2 --64 x_amd64/vet (dns block)
• slow.example.com
  • Triggering command: /tmp/go-build1388902967/b513/launcher.test /tmp/go-build1388902967/b513/launcher.test -test.testlogfile=/tmp/go-build1388902967/b513/testlog.txt -test.paniconexit0 -test.timeout=10m0s -goversion go1.25.9 -c=4 -nolocalimports -importcfg /tmp/go-build1388902967/b495/importcfg -pack /tmp/go-build1388902967/b495/_testmain.go -W .cfg 649178/b314/ x_amd64/vet . --gdwarf2 --64 x_amd64/vet (dns block)
• this-host-does-not-exist-12345.com
  • Triggering command: /tmp/go-build1388902967/b522/mcp.test /tmp/go-build1388902967/b522/mcp.test -test.testlogfile=/tmp/go-build1388902967/b522/testlog.txt -test.paniconexit0 -test.timeout=10m0s ut-1�� .cfg /tmp/go-build477-ifaceassert x_amd64/vet ctor --gdwarf2 E=3 x_amd64/vet .cfg�� 649178/b405/_pkg_.a otection x_amd64/vet --gdwarf-5 g/grpc/internal/-atomic -o x_amd64/vet (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

[Copilot]

Pull request overview

Documentation reconciliation to align agent docs, example configuration, and contributing instructions with the current MCP Gateway implementation.

Changes:

• Update AGENTS.md project structure and environment variable references.
• Clarify ${VAR} expansion support notes in config.example.toml.
• Adjust a --payload-dir example in CONTRIBUTING.md.

Show a summary per file

File	Description
AGENTS.md	Updates quick reference text, project structure listing, and environment variable documentation.
config.example.toml	Refines notes about where ${VAR} expansion is supported/unsupported in TOML config.
CONTRIBUTING.md	Updates an example CLI invocation for payload directory usage.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comments suppressed due to low confidence (1)

config.example.toml:193

• Same issue as above: the note states [gateway.opentelemetry] and [gateway.tracing] support ${VAR_NAME} expansion, but only the gateway.opentelemetry TOML key triggers expandTracingVariables(...) during LoadFromFile. Consider rewording to mention only [gateway.opentelemetry] (or clarify that legacy [gateway.tracing] does not get expanded).

# - Use ${VAR_NAME} syntax to reference environment variables in JSON stdin format only
# - TOML does not support ${VAR_NAME} expansion in server args/env fields; use absolute paths instead
# - The [gateway.opentelemetry] and [gateway.tracing] sections do support ${VAR_NAME} expansion

• Files reviewed: 3/3 changed files
• Comments generated: 3

[Copilot]

The comment says both [gateway.opentelemetry] and [gateway.tracing] support ${VAR} expansion, but in TOML load path variable expansion is only applied when the gateway.opentelemetry key is used (it’s merged into Gateway.Tracing and then expandTracingVariables is called). If users configure the legacy gateway.tracing key directly, ${VAR} placeholders won’t be expanded. Please adjust this note to avoid implying ${VAR} works in [gateway.tracing] TOML configs (or clarify the limitation explicitly).

This issue also appears on line 191 of the same file.

Suggested change

	# (The [gateway.opentelemetry] and [gateway.tracing] sections DO support ${VAR} expansion.)
	# (${VAR} expansion is supported in [gateway.opentelemetry]; the legacy [gateway.tracing]
	# TOML section does not expand ${VAR} placeholders.)

[Copilot]

The new descriptions imply MCP_GATEWAY_PORT/DOMAIN/API_KEY override the config’s port/domain/api_key fields and that the port is validated 1–65535. In the current implementation these env vars are only checked by environment validation / helper functions and used by run_containerized.sh to build the --listen flag; the awmg binary itself doesn’t apply these env vars as config overrides (and doesn’t currently range-validate the port unless callers invoke GetGatewayPortFromEnv, which is unused). Please reword these entries to reflect actual behavior (e.g., “required by run_containerized.sh / referenced via ${MCP_GATEWAY_*} in stdin JSON config”).

Suggested change

	- `MCP_GATEWAY_PORT` - Gateway listen port (overrides config `port` field; validated 1-65535)
	- `MCP_GATEWAY_DOMAIN` - Gateway domain name (overrides config `domain` field)
	- `MCP_GATEWAY_API_KEY` - Gateway API key (overrides config `api_key` field)
	- `MCP_GATEWAY_PORT` - Gateway listen port; used by `run_containerized.sh` when building the `--listen` flag and may be referenced via `${MCP_GATEWAY_PORT}` in stdin JSON config
	- `MCP_GATEWAY_DOMAIN` - Gateway domain name; may be referenced via `${MCP_GATEWAY_DOMAIN}` in stdin JSON config
	- `MCP_GATEWAY_API_KEY` - Gateway API key; may be referenced via `${MCP_GATEWAY_API_KEY}` in stdin JSON config

[Copilot]

DOCKER_API_VERSION was removed from the env var list, but it’s still set/used by the repository’s startup scripts (run.sh / run_containerized.sh) to pin the Docker client API version. If this section is meant to cover operationally relevant env vars (not only those read by Go code), consider keeping DOCKER_API_VERSION here (or add a short note that it’s script-managed so agents don’t try to set it manually).