Which integrations are available for this server?

Supports authentication with Amazon accounts to enable secure access and interaction with Alexa-based services. Provides tools for managing Alexa shopping lists, allowing users to list, add, delete, update, and mark items as completed.

How do I use alexa-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@alexa-mcp add milk, eggs, and bread to my shopping list" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

alexa-mcp

by GraysonCAdams

Overview Schema Related Servers Score Discussions

Local

alexa-mcp

MCP server for Amazon Alexa -- manage your Alexa shopping list from any MCP client (Claude, etc.).

Built on the Model Context Protocol and the alexa-remote2 library.

Tools

Tool	Description
`authenticate`	Authenticate with your Amazon account. Uses a saved cookie if available, otherwise starts a browser login proxy and returns a URL to open.
`list_items`	Get items from your Alexa shopping list. Optionally include completed items.
`add_items`	Add one or more items to your Alexa shopping list.
`delete_items`	Delete items from your Alexa shopping list by name (case-insensitive match).
`update_item`	Update an item on your shopping list -- rename it and/or change its completion status.
`complete_items`	Mark items as completed on your Alexa shopping list by name (case-insensitive match).
`check_status`	Check whether the server is authenticated and show current configuration.

Related MCP server: alexa-mcp

Environment Variables

Variable	Default	Description
`COOKIE_PATH`	`~/.alexa-mcp/cookie.json`	Path to the persisted Alexa authentication cookie
`AMAZON_PAGE`	`amazon.com`	Amazon domain to authenticate against
`PROXY_PORT`	`3001`	Port for the browser login proxy (used during initial authentication)
`ALEXA_COOKIE`	--	Pre-seeded cookie JSON (alternative to `COOKIE_PATH` file)

Setup

npm ci

Usage

Stdio mode (direct)

node dist/index.js

HTTP mode (via mcp-proxy)

mcp-proxy --port 8005 -- node dist/index.js

Claude Desktop configuration

Add this to your Claude Desktop MCP config:

{
  "mcpServers": {
    "alexa": {
      "command": "node",
      "args": ["/path/to/alexa-mcp/dist/index.js"],
      "env": {
        "COOKIE_PATH": "/path/to/cookie.json"
      }
    }
  }
}

Authentication

On first run, the authenticate tool starts a local proxy server. Open the returned URL in your browser and log in to your Amazon account. The cookie is saved to COOKIE_PATH and reused for subsequent sessions.

If you already have a cookie (e.g., from a previous session or another machine), you can either:

Place the JSON file at COOKIE_PATH
Set the ALEXA_COOKIE environment variable with the JSON content

Patches

This project includes a patch for alexa-cookie2 (applied automatically via patch-package on npm ci) that improves resilience when the Amazon user-data endpoint returns unexpected responses.

License

MIT -- see LICENSE.

Available Tools

7 tools

add_itemsAdd Shopping ItemsB

Add one or more items to your Alexa shopping list.

ParametersJSON Schema

Name	Required	Description	Default
`items`	Yes	Items to add (e.g. ["milk", "eggs", "bread"])

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare openWorldHint=true and destructiveHint=false, covering basic safety. The description adds no extra behavioral context (e.g., idempotency, limits) beyond this.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no redundancy. It is front-loaded and efficient, though could be slightly more detailed without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and annotations, the description is adequate but lacks contextual completeness (e.g., no mention of use cases or limitations).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with required 'items' array fully described. The description adds minimal value beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'add' and clearly identifies the resource 'items to your Alexa shopping list'. It effectively distinguishes from sibling tools like 'delete_items' and 'list_items'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like 'update_item' or 'complete_items'. The description only states what it does without context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

authenticateAuthenticate with Amazon AlexaA

Authenticate with your Amazon account. If a saved cookie exists, uses it automatically. Otherwise starts a browser login proxy and returns a URL to open.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint=false, openWorldHint=true), the description reveals two distinct behaviors: automatic cookie use or browser login proxy with URL return, giving full transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no wasted words. Very concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Completeness is high given no output schema; it explains the two possible flows. Could mention that authentication is needed for other tools, but not required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. Baseline 4 is appropriate as description adds no parameter info beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: authenticate with an Amazon account. It distinguishes from sibling tools which are item operations, making it clear this is for authentication.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the behavior (uses saved cookie or returns URL) but does not explicitly state when to use vs alternatives. However, siblings are all item-related, so context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_statusCheck Alexa Connection StatusB

Read-only

Check whether the server is authenticated and show configuration.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true. The description adds that it checks authentication and shows configuration, providing some behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Exceptionally concise single sentence that conveys the tool's function without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequate for a simple read-only tool with no parameters, but could elaborate on what 'configuration' includes or how authentication is checked.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in schema, so description adds value by explaining the tool's purpose (checking auth and configuration). Baseline is high due to complete schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks authentication and shows configuration, which distinguishes it from sibling tools that manage items. However, it does not explicitly differentiate from similar status tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. It simply states what it does without context for appropriate invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

complete_itemsComplete Shopping ItemsA

Mark items as completed on your Alexa shopping list by name (case-insensitive match).

ParametersJSON Schema

Name	Required	Description	Default
`names`	Yes	Item names to mark as completed

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It reveals the case-insensitive matching behavior but omits details about side effects, authorization needs, or what happens if an item is not found. Adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no fluff. Every word adds value. Appropriate for a simple tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description covers the core action but lacks usage guidelines, error handling details, and return value explanation. Adequate for a straightforward tool but missing context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (parameter 'names' has a description). The description adds valuable context beyond the schema by specifying 'case-insensitive match' and 'by name', which is not in the input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Mark items as completed'), the resource ('on your Alexa shopping list'), and a key behavior ('by name (case-insensitive match)'). It effectively differentiates from sibling tools like delete_items or add_items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives like delete_items or update_item. The description does not mention prerequisites, error conditions, or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_itemsDelete Shopping ItemsA

Destructive

Delete items from your Alexa shopping list by name (case-insensitive match).

ParametersJSON Schema

Name	Required	Description	Default
`names`	Yes	Item names to delete

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true, and the description adds valuable context about case-insensitive matching. However, it does not disclose other behavioral details such as whether the deletion is permanent or requires authentication.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no filler, efficiently conveying the tool's purpose and key detail (case-insensitivity) in a front-loaded manner.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the description covers the core functionality and input details. However, it lacks guidance on edge cases like item not found or empty name array, which could affect completeness for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a description for the 'names' parameter. The description adds meaning by specifying 'case-insensitive match', which is not in the schema, thereby enhancing parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Delete', the resource 'items from your Alexa shopping list', and the matching method 'by name (case-insensitive match)'. It distinguishes itself from sibling tools like list_items and add_items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for deleting items but provides no explicit guidance on when to use this tool versus alternatives like update_item or complete_items. No exclusions or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_itemsList Shopping ItemsB

Read-only

Get items from your Alexa shopping list.

ParametersJSON Schema

Name	Required	Description	Default
`include_completed`	No	Include completed items (default: false)

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, but description adds no behavioral details like return format, ordering, or pagination; overly minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is concise but too sparse; lacks detail beyond the tool's basic function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and simple parameters, description fails to explain return values or any additional context needed for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so description adds no extra meaning for the include_completed parameter; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it retrieves items from an Alexa shopping list, specific verb+resource, and distinguishes from sibling tools like add_items or delete_items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this vs alternatives like add_items or complete_items; no context about exclusion or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_itemUpdate Shopping ItemA

Update an item on your Alexa shopping list by name (case-insensitive). Can rename and/or change completion status.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Current item name (case-insensitive)
`new_name`	No	New name for the item
`completed`	No	Set completion status

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description adds value beyond annotations by clarifying case-insensitive name matching and the ability to rename and change status. However, it does not disclose side effects, authorization requirements, or rate limits. Annotations only provide destructiveHint=false, so description carries moderate burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and key details. Every sentence adds value without redundancy. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool and full schema coverage, the description is fairly complete. It lacks information about return values (e.g., confirmation or updated item details) but covers core functionality. Sibling list provides external context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions, so baseline is 3. Description adds context by explaining how the 'name' parameter is used for lookup (case-insensitive) and that 'new_name' and 'completed' relate to rename and completion status, respectively.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action ('Update an item on your Alexa shopping list by name') and provides specifics (case-insensitive, can rename and/or change completion status). It distinguishes from siblings like add_items and delete_items by focusing on modifying existing items.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives (e.g., add_items for new items, complete_items for completion only). The description implies use for updating by name but does not exclude cases or provide context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv1.0.0Jun 26, 2026
- First observedadd_items
- First observedauthenticate
- First observedcheck_status
- First observedcomplete_items
- First observeddelete_items
- First observedlist_items
- First observedupdate_item

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool targets a distinct action on the shopping list (add, complete, delete, list, update) or authentication/status. No overlap; even complete_items and update_item have clear different purposes (batch complete vs. individual update).

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with underscores (e.g., add_items, check_status). The style is uniform across all 7 tools, making them predictable for an agent.

Tool Count5/5

With 7 tools, the server covers essential shopping list operations and authentication without being too sparse or bloated. The count is well-scoped for the domain.

Completeness4/5

The set covers all basic CRUD actions for shopping list items (create via add_items, read via list_items, update via update_item/complete_items, delete via delete_items) plus authentication. The only minor gap is the lack of a dedicated 'get single item' tool, but listing and name-based operations suffice.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

DataDoe MCPOAuth
com.datadoe
Hosted Amazon Seller and Vendor MCP server for Claude, ChatGPT, Cursor, Codex, Gemini, Copilot.
E-commerce & Retail CRM
212
agentcentral AOAuth
to.agentcentral
Hosted Amazon Seller Central and Amazon Ads MCP server for Claude, ChatGPT, Cursor, and agents.
E-commerce & Retail Customer Support
26
Agent Rails A
io.github.federicocelico
Shopping MCP for AI agents: search, compare, Amazon buy links. Auto-register.
E-commerce & Retail Search
51
thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2

Related MCP Servers

LystBot
App Automation Workplace & Productivity
TourAround
A
license
Not graded
quality
B
maintenance
MCP server that gives AI agents full control over grocery lists, todos, and packing lists. Your AI creates lists, adds items, checks them off, and shares with family/friends.
Updated 9 days ago (2026-08-28 11:35 UTC)
3
MIT
alexa-mcp
Home Automation & IoT App Automation
serversmx
A
license
A
quality
C
maintenance
An MCP server that lets LLMs control Amazon Alexa devices, including announcements, text commands, smart-home group management, routines, and list operations.
Updated 4 months ago (2026-05-15 20:12 UTC)
18
1
MIT
Unofficial AnyList MCP Server
E-commerce & Retail Note Taking
bobby060
F
license
Not graded
quality
A
maintenance
MCP server that integrates with AnyList for managing shopping lists, recipes, and meal planning via natural language.
Updated 2 months ago (2026-06-28 19:08 UTC)
29
-
mcp-amazon
E-commerce & Retail Web Scraping
kogecoo
A
license
Not graded
quality
C
maintenance
A read-only MCP server for accessing Amazon wishlist data via HTML snapshot parsing or optional live browser-backed reads.
Updated 3 months ago (2026-06-11 03:25 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/GraysonCAdams/alexa-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server