Using the AWS MCP Server from Agent Toolkit for AWS with GitHub Copilot

Learn how to manually connect GitHub Copilot in Visual Studio Code to the managed AWS MCP Server and use current AWS documentation to troubleshoot a real AWS DMS deployment error.

Harsha Mathan

Published Aug 4, 2026

Last modified Aug 4, 2026

AI coding assistants have become an important part of modern software development. They can explain errors, generate infrastructure code, review configurations, and suggest potential fixes.

However, cloud platforms such as AWS evolve rapidly. Service features, supported engine versions, instance classes, APIs, and regional capabilities can change over time. An AI assistant may therefore provide a reasonable answer based on its existing knowledge, but that answer may not always reflect the most current AWS documentation.

The AWS MCP Server, available through the Agent Toolkit for AWS, helps address this challenge by allowing compatible AI agents to search official AWS documentation and retrieve AWS service information at runtime.

In this article, I will explain how I connected GitHub Copilot in Visual Studio Code to the AWS MCP Server and used it to troubleshoot a real AWS Database Migration Service deployment error.

What is MCP?

The Model Context Protocol, commonly known as MCP, is an open standard that allows AI applications and coding agents to connect to external tools and information sources.

An MCP server can provide an AI agent with capabilities such as:

Searching documentation
Querying APIs
Retrieving service information
Interacting with databases
Running approved operations
Accessing external tools and workflows

In Visual Studio Code, GitHub Copilot Agent can use tools exposed by configured MCP servers while answering questions or completing development tasks.

What is the AWS MCP Server?

The AWS MCP Server is a managed remote MCP server provided as part of the Agent Toolkit for AWS.

It allows compatible AI agents to access AWS knowledge and service capabilities through MCP.

Some of the AWS knowledge tools exposed by the server include:

aws___search_documentation
aws___read_documentation
aws___list_regions
aws___get_regional_availability
aws___retrieve_skill

The server also provides capabilities for authenticated AWS API calls and script execution when appropriate credentials and IAM permissions are configured.

For documentation searches and general AWS service information, authentication may not be required. Accessing resources inside an AWS account, however, requires appropriate authentication and permissions.

An important distinction is that we are not creating a new MCP server in this setup. AWS already hosts and manages the AWS MCP Server. We are simply configuring GitHub Copilot in VS Code to connect to the existing server.

Why did the AWS MCP Server not appear in the VS Code gallery?

I initially opened the Agent Customizations section in Visual Studio Code and searched for an AWS MCP server.

However, the official AWS MCP Server did not appear in the search results.

The MCP server gallery in VS Code uses configured MCP registries, including the GitHub MCP Registry. Only servers available through the registry appear in that search experience.

This does not mean that GitHub Copilot cannot use another MCP server.

MCP servers that are not displayed in the registry can still be configured manually through the VS Code mcp.json file.

Prerequisites

Before beginning, ensure that you have:

Visual Studio Code
GitHub Copilot access
GitHub Copilot Agent mode
MCP support enabled in VS Code
Permission from your organization to connect to external MCP servers

Organizations using GitHub Copilot Business or Enterprise may apply policies controlling which MCP servers employees can discover or use.

Step 1: Open the MCP configuration

In Visual Studio Code:

Press Ctrl + Shift + P.
Search for:

1
MCP: Open User Configuration

Open the generated mcp.json file.

VS Code supports MCP configuration at two levels:

User configuration: available across multiple VS Code workspaces
Workspace configuration: stored in .vscode/mcp.json and applicable only to that project

For this experiment, I used the user-level configuration.

Step 2: Add the AWS MCP Server

Add the following entry inside the servers section of mcp.json:

1
2
3
4
5
6
7
8
{

    "servers": {

        "aws-mcp": {

            "type": "http",

            "url": "https://aws-mcp.us-east-1.api.aws/mcp"

        }

    }

}

AWS currently documents managed AWS MCP Server endpoints in the following Regions:

US East (N. Virginia)

1
https://aws-mcp.us-east-1.api.aws/mcp

Europe (Frankfurt)

1
https://aws-mcp.eu-central-1.api.aws/mcp

I already had Azure DevOps and Atlassian MCP servers configured, so my complete mcp.json looked similar to the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
{

    "servers": {

        "microsoft/azure-devops-mcp": {

            "type": "stdio",

            "command": "npx",

            "args": [

                "-y",

                "@azure-devops/mcp@latest",

                "${input:ado_org}",

                "-d",

                "${input:ado_domain}"

            ],

            "gallery": "https://api.mcp.github.com",

            "version": "1.0.0"

        },

        "com.atlassian/atlassian-mcp-server": {

            "type": "http",

            "url": "https://mcp.atlassian.com/v1/mcp",

            "gallery": "https://api.mcp.github.com",

            "version": "1.1.1"

        },

        "aws-mcp": {

            "type": "http",

            "url": "https://aws-mcp.us-east-1.api.aws/mcp"

        }

    },

    "inputs": [

        {

            "id": "ado_org",

            "type": "promptString",

            "description": "Azure DevOps organization name.",

            "password": false

        },

        {

            "id": "ado_domain",

            "type": "promptString",

            "description": "Azure DevOps domains to enable.",

            "password": false

        }

    ]

}

The gallery and version properties are not required for the manually configured AWS MCP Server endpoint.

Step 3: Start and verify the server

After saving the configuration, VS Code displays actions such as:

1
Start | Stop | Restart | Tools

Start the aws-mcp server.

You can also open the Command Palette and run:

1
MCP: List Servers

Select aws-mcp and review its status or output.

A successful connection should produce output similar to:

1
2
3
Starting server aws-mcp

Connection state: Running

Discovered 9 tools

The number of available tools may change as AWS updates the service.

At this stage, GitHub Copilot can use the tools exposed by the AWS MCP Server.

Step 4: Ask questions in GitHub Copilot Chat

Open GitHub Copilot Chat and select Agent mode.

You can explicitly ask Copilot to use the AWS MCP documentation tools:

1
2
3
4
Use the AWS MCP Server to search the current official AWS documentation.



Which AWS DMS replication instance classes are currently supported?

Include the AWS documentation sources used.

You can use the Configure Tools option in Copilot Chat to verify that the AWS MCP tools are enabled.

However, explicitly mentioning MCP is not always necessary.

When Copilot is operating in Agent mode and the AWS MCP tools are enabled, it can automatically decide that an AWS tool is relevant based on the question or error message.

That is exactly what happened during my test.

A real-world AWS DMS troubleshooting example

I encountered the following error while creating an AWS DMS replication instance:

1
2
3
4
5
6
7
8
9
10
Error: creating DMS Replication Instance

(<replication-instance-name>):



operation error Database Migration Service:

CreateReplicationInstance,



https response error StatusCode: 400,



api error InvalidParameterValueException:

No replication engine found with version: 3.5.3

For security and privacy, resource names, account information, and request identifiers have been removed from this example.

Instead of writing a detailed prompt, I pasted the error directly into GitHub Copilot Chat.

Copilot recognized that the message was related to AWS DMS and automatically invoked the AWS MCP documentation search tool.

The tool trace showed:

1
Ran aws___search_documentation — aws-mcp (MCP Server)

This confirmed that the integration was working.

I did not explicitly tell Copilot to invoke a particular MCP tool. Copilot identified the AWS context and selected the appropriate documentation search capability automatically.

Understanding the AWS DMS error

The important part of the error was:

1
No replication engine found with version: 3.5.3

The infrastructure configuration explicitly requested AWS DMS replication engine version 3.5.3.

However, AWS DMS rejected that value for the replication instance being created. This indicates that the specified engine version was not orderable for the selected Region and replication-instance configuration at that time.

AWS DMS provides a CLI operation that returns the replication instance types and engine versions that can currently be created in a specified Region.

The following command can be used to verify the supported combinations:

1
2
3
4
aws dms describe-orderable-replication-instances \

  --region <aws-region> \

  --query "OrderableReplicationInstances[*].[ReplicationInstanceClass,EngineVersion]" \

  --output table

For example:

1
2
3
4
aws dms describe-orderable-replication-instances \

  --region ap-south-1 \

  --query "OrderableReplicationInstances[*].[ReplicationInstanceClass,EngineVersion]" \

  --output table

This is preferable to assuming that a particular version is available in every Region.

Possible fixes

After checking the orderable engine versions for the target Region, there are two common approaches.

Option 1: Remove the explicitly pinned engine version

When no engine version is specified during replication-instance creation, AWS DMS selects its default available engine version.

For example, review an infrastructure configuration containing:

1
2
3
4
5
6
resource "aws_dms_replication_instance" "example" {

  replication_instance_id    = "example-dms-instance"

  replication_instance_class = "dms.t3.large"



  engine_version = "3.5.3"

}

The pinned value can be removed:

1
2
3
4
resource "aws_dms_replication_instance" "example" {

  replication_instance_id    = "example-dms-instance"

  replication_instance_class = "dms.t3.large"

}

This reduces the risk of future deployments failing because an older pinned version is no longer orderable.

However, teams should review compatibility and testing requirements before allowing automatic selection of a newer engine version.

Option 2: Select an orderable engine version

If the application requires the engine version to be explicitly controlled, replace the unsupported value with a version confirmed by:

1
aws dms describe-orderable-replication-instances

The replacement version should be validated in the exact AWS Region and with the intended replication-instance class.

Production infrastructure should not use an engine version suggested by an AI assistant without verifying it against AWS documentation or AWS API output.

How to confirm that MCP was actually used

When GitHub Copilot invokes an MCP tool, the chat response displays a tool-call section.

Look for a line similar to:

1
Ran aws___search_documentation — aws-mcp

Expanding the tool-call section allows you to review:

Which MCP tool was selected
The search query sent by Copilot
The tool input
Whether the request succeeded
The information returned to the agent

This makes it possible to distinguish between:

An answer based only on the model's existing knowledge
An answer produced after searching AWS documentation
An attempted MCP request that failed

Troubleshooting an `ECONNRESET` error

During my first test, the AWS MCP Server started successfully and discovered its tools. However, the first documentation request failed with an error similar to:

1
2
3
4
Error sending message to:

https://aws-mcp.us-east-1.api.aws/mcp



TypeError: terminated: read ECONNRESET

The initial MCP connection had succeeded, but the network connection was reset while the request was being processed.

I restarted the server and tried again. The next request completed successfully, suggesting that the original error was temporary.

If you encounter the same issue, try the following steps.

Restart the MCP server

Open:

1
MCP: List Servers

Select aws-mcp, and choose Restart.

Review the MCP output

Use the Show Output option to inspect the connection logs.

Check whether the server reaches:

1
Connection state: Running

and whether its tools are discovered.

Try the Frankfurt endpoint

Replace:

1
"url": "https://aws-mcp.us-east-1.api.aws/mcp"

with:

1
"url": "https://aws-mcp.eu-central-1.api.aws/mcp"

Save the configuration and restart the server.

Check enterprise network restrictions

On a corporate device, the connection may be affected by:

VPN configuration
Proxy settings
Firewall rules
SSL inspection
Organizational Copilot policies
MCP server allowlists

If the connection repeatedly fails, consult the team responsible for network security or GitHub Copilot administration.

Does MCP guarantee a correct answer?

No.

The AWS MCP Server gives Copilot access to current official AWS documentation and service information. However, Copilot still needs to:

Interpret the question
Select an appropriate tool
Construct a search query
Read the results
Generate the final response

The model can still misunderstand the question, search for a related topic, or summarize the documentation incorrectly.

For example, when asking about AWS DMS replication instance classes, a response might accidentally focus on replication engine versions because the topics are closely related.

A more precise troubleshooting prompt would be:

1
2
3
4
5
6
7
8
9
10
11
Analyze the following error using current official AWS documentation.



Explain:



1. The exact cause

2. Whether the issue may be Region-specific

3. How to verify the supported values

4. The safest configuration change



Do not modify any files until I approve.

Cite the AWS documentation used.

MCP improves grounding, but human review remains essential—particularly before changing production infrastructure.

Documentation access versus AWS account access

There is an important security difference between searching AWS documentation and accessing an AWS account.

Documentation search

The agent can search AWS documentation and retrieve general AWS service information without requiring access to your AWS account.

AWS account operations

Tasks such as the following require authentication and suitable IAM permissions:

Listing account resources
Inspecting deployed infrastructure
Calling AWS APIs
Running scripts against an AWS account
Creating or modifying AWS resources

In enterprise environments, organizations should review governance and security requirements before enabling account-level capabilities.

For my initial use case, I only needed access to AWS documentation. No AWS resource modification was required.

Key lessons from this experiment

We are connecting to an existing server, not creating one

AWS already provides and manages the AWS MCP Server. The VS Code configuration simply connects GitHub Copilot to the managed endpoint.

A server does not need to appear in the registry

If an MCP server is not visible in the GitHub MCP Registry search, it may still be added manually through mcp.json.

Copilot can invoke MCP tools automatically

When the AWS MCP tools are enabled, GitHub Copilot Agent can recognize an AWS-related error and invoke the relevant documentation tool without being explicitly instructed.

MCP helps ground responses in current documentation

The integration reduces dependence on only the model's pre-existing knowledge by allowing it to retrieve relevant AWS information when the question is asked.

Human validation is still necessary

MCP improves the quality and freshness of available context, but it does not guarantee that the final AI-generated interpretation will always be correct.

Conclusion

GitHub Copilot is already useful for generating code, explaining errors, and reviewing infrastructure configurations.

Connecting it to the AWS MCP Server makes it more effective for AWS development by allowing it to search current official AWS documentation while working inside Visual Studio Code.

The required configuration is small:

1
2
3
4
"aws-mcp": {

    "type": "http",

    "url": "https://aws-mcp.us-east-1.api.aws/mcp"

}

Once the server is running and its tools are enabled, Copilot Agent can automatically use AWS documentation tools when it encounters a relevant AWS question or error.

In my case, I simply pasted an AWS DMS deployment error. Copilot identified the AWS context, invoked the AWS documentation search tool, and helped identify that the explicitly configured DMS engine version was not available for the requested deployment configuration.

This is the practical value of MCP: it allows an AI coding assistant to retrieve authoritative external context at the moment it is needed, while keeping the developer inside the existing development workflow.

References

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

Using the AWS MCP Server from Agent Toolkit for AWS with GitHub Copilot

Harsha Mathan

What is MCP?

What is the AWS MCP Server?

Why did the AWS MCP Server not appear in the VS Code gallery?

Prerequisites

Step 1: Open the MCP configuration

Step 2: Add the AWS MCP Server

US East (N. Virginia)

Europe (Frankfurt)

Step 3: Start and verify the server

Step 4: Ask questions in GitHub Copilot Chat

A real-world AWS DMS troubleshooting example

Understanding the AWS DMS error

Possible fixes

Option 1: Remove the explicitly pinned engine version

Option 2: Select an orderable engine version

How to confirm that MCP was actually used

Troubleshooting an ECONNRESET error

Restart the MCP server

Review the MCP output

Try the Frankfurt endpoint

Check enterprise network restrictions

Does MCP guarantee a correct answer?

Documentation access versus AWS account access

Documentation search

AWS account operations

Key lessons from this experiment

We are connecting to an existing server, not creating one

A server does not need to appear in the registry

Copilot can invoke MCP tools automatically

MCP helps ground responses in current documentation

Human validation is still necessary

Conclusion

References

Troubleshooting an `ECONNRESET` error