Deploy a static site with the MCP server

Open the agent in your project folder and describe the site and the goal. For example:

A client that supports MCP resources reads the four resources. A client without resource support calls the deploy_azion_static_site tool with action set to deploy, which returns all four steps. With action set to help, the tool lists the resource URIs.

In deploy/step-0-preparation, the agent reads the project and writes a deployment readiness report. The report names the framework, the package manager, the entry point, the preset, and whether the project is new or already linked to Azion. It also states whether the site is static or needs adjustment, and whether the Azion CLI is installed and authenticated.

The agent detects the framework from its configuration files and the package manager from the lock file. It looks for an existing azion/azion.json or azion.config.* file, and for server-side code. It checks the CLI with azion --version and the authentication with azion whoami. This step installs nothing and changes no file.

In deploy/step-1-configuration, the agent sets up the CLI and links the project. When the CLI is missing, the step installs it. When the CLI is not authenticated, it runs azion -t with a personal token, or azion login.

A new project is linked with azion link --name <project-name> --preset <your-preset> --auto --package-manager <your-package-manager>. An existing project is updated with azion sync, after you confirm the update. The agent then tests the build with azion build --preset <your-preset> --entry <your-entry-file>. When the build fails with a module error, the step adds "type": "module" to package.json and retries. When it fails with an entry point error, the step checks that the entry file exists and tries other paths.

The step ends with a linked project, a successful build, and an azion.config.js file.

In deploy/step-2-execute, the agent deploys the project with azion deploy --no-prompt --auto --local --debug. For more control over each phase, the step runs azion build --preset <your-preset> --entry <your-entry-file>, then azion deploy --auto --debug --local --skip-build. The step checks that the .edge/storage folder holds the static files before it continues.

From the deployment output, the agent takes the application name, the application ID, and the production URL, in the format xxxxxxxxx.map.azionedge.net. The name and the ID are also in azion/azion.json, and in the output of azion list application. The step says the first production deployment can take up to 10 minutes to propagate, and it tests the URL every 2 minutes until it answers.

To test, the agent resolves the production URL with nslookup, host, or dig. It then sends curl -H "Host: <production-url>" -I http://<ip>/ to that IP address, and repeats the request with -H "Pragma: azion-debug-cache" to read the cache headers. When a test fails, the step checks the logs with azion logs http.

In deploy/step-3-basic-test, the agent requests the home page and the main assets, such as CSS, JavaScript, and images, through the same IP address and Host header. It runs the cache check two or three times, because the first request can be a miss. The report marks site access, asset loading, and cache headers as OK or NOT OK.

When a test is NOT OK, the step checks the logs with azion logs http --tail. It also checks the build output directory in azion.config.js, and confirms that every static asset was part of the deployment.