Introducing the Amazon Nova Act MCP Server for AI Agents

A practical guide to running Amazon Nova Act through MCP, from quick API key setup to advanced AWS-native browser automation.

Baizel, Emile

Published Apr 23, 2026

Last modified Apr 23, 2026

AI agents get much more useful when they can work with the web the way people do: open pages, click through flows, search, extract information, and continue across multiple steps without losing context. That is exactly the kind of workflow Amazon Nova Act is built for.

The Amazon Nova Act MCP server brings those capabilities into the Model Context Protocol (MCP) ecosystem. With it, MCP-compatible agents can use Nova Act through a consistent set of tools for browsing, interaction, extraction, and session management.

In this post, I'll walk through two ways to get started:

a quick setup using a Nova Act API key
a more advanced AWS-authenticated setup that can use AgentCore browser

The goal is simple: get a browser-capable agent working quickly, then show how to grow into a more AWS-native setup when you need it.

What you'll build

By the end of this walkthrough, you'll have:

an AI agent connected to a Amazon Nova Act MCP server
a working browser automation flow using Amazon Nova Act
a quick-start path using API key authentication
an AWS-native setup using IAM authentication and AgentCore browser

You'll also learn about the MCP server's core tools:

start_browse to access a URL and decide whether a browser session is needed
act to interact with a site using natural language
act_get to verify page state or extract data
session_close to explicitly end a session when you're done

That combination gives agents a practical browser workflow without requiring every MCP client to build its own Nova Act integration.

Two ways to run it

The Amazon Nova Act MCP server supports two main authentication paths.

API key authentication

If you want to get up and running quickly, start with a Nova Act API key (you can get one at https://nova.amazon.com/act). This is a great way to start experimenting.

AWS authentication with AgentCore browser

If you want a more AWS-native setup, the server also supports IAM-based authentication. This path is useful when you want tighter AWS integration and access to AgentCore browser, especially for sites that need bot detection handling.

What you need

To follow along, you'll need:

Python 3.10 or later
uv for the quickest install-and-run experience
an MCP-compatible client. Kiro works great!

For the AWS path later in this post, you'll need:

AWS credentials configured locally
access to Amazon Nova Act in your AWS environment
permissions needed to configure and use AgentCore browser

We'll start with the smallest possible setup and build from there, so you do not need the AWS path configured before getting started.

How the server works

At a high level, the server sits between your MCP-compatible agent and Amazon Nova Act:

Your agent calls an MCP tool exposed by the server.
The MCP server decides how to fulfill that request.
Amazon Nova Act either fetches content quickly or opens a browser session when the site requires richer interaction.
If a browser session is created, the server keeps it alive so the agent can continue across multiple tool calls.

The most important tool to understand is start_browse. It is the entry point for URL access and decides whether the task can be handled with a fast fetch or needs a full browser session.

Once a session exists, the typical pattern is:

act for interaction
act_get for verification or extraction
session_close when the task is complete

This session-oriented model is a big part of the server's value. Many useful browser tasks are not single-step operations. An agent might need to open a page, search, inspect results, take another action, and then extract structured output. Reusing the same session across those steps makes that workflow much more natural.

Quick start with API key authentication

The fastest way to get started is with a Nova Act API key.

Step 1: Run the configure flow

Use uvx to run the server directly:

1
uvx amazon-nova-act-mcp --configure

The configuration flow will prompt you for:

your Nova Act API key
which MCP client you want to configure
any local setup preferences needed for your environment

If you prefer a virtual environment-based install, you can also do:

1
2
pip install amazon-nova-act-mcp
amazon-nova-act-mcp --configure

Step 2: (Optional) Connect the server to your MCP client

The --configure flow can write configuration for supported clients automatically. For example, if you want to add the server manually in Claude Code, you can do:

1
claude mcp add nova-act-mcp --scope user -- amazon-nova-act-mcp

Once connected, your MCP client should expose tools such as:

start_browse
act
act_get
go_to_url
get_page_content
screenshot
session_close

Step 3: Try a simple task

Let's ask the agent to summarize an inter-planet travel reservation website.

1
Open https://nova.amazon.com/act/gym/next-dot/search and summarize the page in 3 bullet points.

Under the hood, your agent will call thestart_browse(url, intent) tool. To extract data, it may then call theact_get(session_id, prompt, format="text")tool. And then it may call session_close(session_id)when it is done to cleanup the session. All of this is abstracted to you as a user.

That is the fast path: no browser session needed.

Step 4: Move to a richer task

Now that we have a basic flow working, let's give a prompt that requires Nova Act to take actions on the page. Swap your favorite retailer's url for the placeholder <url> below, and then run the prompt:

1
On the site <url> search for wireless headphones, and return the first 3 visible results as JSON with title and price.

Your agent should now use other tools like:

act for site navigation and interaction
act_get for data verification and getting structured output

Again, this is all abstracted from you, but the agent knows which tools to call to achieve its objective.

Understanding the browsing flow

The most important design choice in this server is that start_browse is the entry point.

Instead of forcing the agent to decide up front whether it needs a simple fetch or a full browser session, the server handles that decision for it.

In practice, start_browse can do one of two things.

Fast path: return content directly

If the target page can be accessed without opening a browser session, start_browse returns content directly. This is useful for simpler pages where a full browser would be unnecessary overhead.

Browser path: open a session

If the site needs JavaScript, dynamic interaction, a logged-in browser profile, or a more capable browser environment, start_browse opens a browser session instead.

A browser-backed response typically looks like this:

1
2
3
4
5
6
7
{
  "status": "ok",
  "method": "browser",
  "session_id": "1234-...",
  "browser_backend": "local",
  "note": "Session created. Use act()/act_get() for interactions, then session_close() when done."
}

That gives agents a simple mental model:

start with start_browse
continue with act and act_get if a session is created
close the session when done

It also improves efficiency. Not every task needs a full browser, and not every browser workflow needs to start from scratch.

AWS setup with IAM and AgentCore browser

Once you have the API key flow working, the next step is to configure the server for a more AWS-native setup.

Use:

1
uvx amazon-nova-act-mcp --configure-aws

This setup flow is intended for builders who want to use AWS credentials and, optionally, AgentCore browser.

At a high level, the AWS configuration path can help set up:

IAM-based authentication for Amazon Nova Act
the workflow definition used by Nova Act when running in IAM mode
an S3 export bucket for workflow artifacts
optional AgentCore browser configuration
MCP client configuration updates

You are still using the same MCP server and the same MCP tools. The difference is the execution path behind them.

Running with AgentCore browser

Some sites are straightforward to automate in a local browser. Others are not.

In practice, you may encounter sites that:

require a stronger browser environment
make heavier use of anti-bot protections
are more reliable when run through AgentCore browser

That is where AgentCore becomes useful.

With the current MCP server design, you still begin with start_browse, but you can choose a browser mode that tells the server what kind of browser environment to use. The recommendation is to let the agent figure out the best option, including falling back to AgentCore browser if it is getting bot-detected on the local browser.

If you do want to force the AgentCore path, you can use an instruction like:

1
Use start_browse on this URL with browser_mode set to AGENTCORE, then continue the task in that session.

From the agent's perspective, the flow stays consistent:

start_browse(...) opens the target site using AgentCore browser
the response includes a session_id
the agent continues with:
- act(session_id, prompt)
- act_get(session_id, prompt, format=...)
when the task is complete:
- session_close(session_id)

That continuity is one of the strengths of the MCP server. The browsing backend can change, but the agent's workflow stays stable.

(Advanced) Choosing the right browser mode

The server supports multiple browser modes so the same tools can adapt to different situations.

`ANY`

Use ANY when you want the server to choose the best path. It can try a fast access method first and escalate only when needed. For many tasks, this is the right default.

`LOCAL`

Use LOCAL when you know the task needs a normal local browser session and you want a direct local-browser path.

`LOCAL_HEADED`

Use LOCAL_HEADED when you want the local browser window to be visible. This is especially useful for debugging and for watching the automation as it runs.

`LOCAL_SYSTEM_DEFAULT`

Use LOCAL_SYSTEM_DEFAULT when the task depends on your local browser profile, such as an existing login session or cookies already present in Chrome.

`AGENTCORE`

Use AGENTCORE when you know you want the AgentCore browser path. This is a good choice for more challenging sites or cases where you want a cloud-backed browser environment from the start.

A practical progression is:

start with ANY
move to LOCAL or LOCAL_HEADED when you want more control
use LOCAL_SYSTEM_DEFAULT when local authenticated state matters
use AGENTCORE when you need a stronger browser environment

Troubleshooting and practical tips

A few patterns come up repeatedly when people first start using the server.

If the MCP server is not showing up in your client

Verify that the client configuration was written correctly and that the client can see the server command. If you used the setup wizard, rerunning --configure or --configure-aws is often the quickest fix.

If authentication is not behaving the way you expect

The server supports both API key and IAM-based authentication. If an API key is present, it takes priority for Nova Act calls. AWS credentials remain relevant for AWS-backed features such as AgentCore browser.

If a site is interactive but the result is incomplete

This usually means the task needs a browser session rather than a fast fetch path. Let start_browse return a session_id, then continue with act and act_get.

If the site requires login or existing browser state

Use LOCAL_SYSTEM_DEFAULT. That mode is designed for cases where your local Chrome profile matters.

If a site is difficult to automate locally

That is a strong signal to try the AgentCore path instead of continuing to push the local browser further than it wants to go.

If the agent is doing too much in one step

Keep each act call focused:

use act for one clear interaction goal
use act_get in a separate call to verify or extract results

Conclusion

The Amazon Nova Act MCP server gives MCP-compatible agents a practical, session-aware way to work with the web through a consistent set of browser automation tools.

The quickest way to get started is to use an API key and run through the simple configuration flow. That path is a great way to learn the tool model and get your first browsing workflow running quickly.

When you are ready for a more AWS-native setup, you can move to IAM authentication and AgentCore browser without changing how your agent thinks about the workflow. The same core tools still apply:

start with start_browse
use act for interaction
use act_get for verification or extraction
close the session when you are done

That makes the server approachable for quick local experimentation while still giving you a stronger path for more advanced browsing scenarios when you need it.

Appendix: Sample MCP server JSON configuration

Use the following as a starting point for MCP client configuration:

1
2
3
4
5
6
7
8
9
10
11
{
  "mcpServers": {
    "nova-act-mcp": {
      "command": "uvx",
      "args": ["amazon-nova-act-mcp"],
      "env": {
        "NOVA_ACT_API_KEY": "your-api-key-here"
      }
    }
  }
}

For AWS-based setups, you would typically replace or extend the env block with the relevant AWS settings.

Appendix: Environment variables reference

The MCP server is highly configurable through environment variables, including model version selection, browser behavior, timeouts, logging, recording, S3 export settings, and AgentCore configuration.

You can find the full list of configurable parameters here:

https://github.com/amazon-agi-labs/amazon-nova-act-mcp/blob/main/src/amazon_nova_act_mcp/modules/settings.py#L26

# agentic-ai # ai # mcp # ai-agents # agents

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Introducing the Amazon Nova Act MCP Server for AI Agents

Baizel, Emile

What you'll build

Two ways to run it

API key authentication

AWS authentication with AgentCore browser

What you need

How the server works

Quick start with API key authentication

Step 1: Run the configure flow

Step 2: (Optional) Connect the server to your MCP client

Step 3: Try a simple task

Step 4: Move to a richer task

Understanding the browsing flow

Fast path: return content directly

Browser path: open a session

AWS setup with IAM and AgentCore browser

Running with AgentCore browser

(Advanced) Choosing the right browser mode

ANY

LOCAL

LOCAL_HEADED

LOCAL_SYSTEM_DEFAULT

AGENTCORE

Troubleshooting and practical tips

If the MCP server is not showing up in your client

If authentication is not behaving the way you expect

If a site is interactive but the result is incomplete

If the site requires login or existing browser state

If a site is difficult to automate locally

If the agent is doing too much in one step

Conclusion

Appendix: Sample MCP server JSON configuration

Appendix: Environment variables reference

`ANY`

`LOCAL`

`LOCAL_HEADED`

`LOCAL_SYSTEM_DEFAULT`

`AGENTCORE`