What can you do with this server?

This server is designed for auditing and cleanup of an Amazon Alexa account, with read-only operations enabled by default. Read-only tools (default): * List all Alexa devices: Retrieve all registered Echos, apps, and Fire TVs with their name, type, and serial number. * List all routines: Get all routines with their automation ID, name, status, and trigger types. Supports an optional limit parameter (up to 5000). * Inspect a specific routine: Fetch the full raw JSON of a single routine by its automationId, including its complete action sequence. * List scenes and smart-home entities: View smart-home entities and scenes usable as routine actions. * View activity history: Access customer activity records to see what fired and when, with filtering by start/end time and record type. * List smart-home devices: Get all smart-home devices with source info (skill, Matter, etc.) — useful for identifying orphaned devices no longer exposed by their source. * Audit broken references: Identify routines targeting non-existent devices, scenes, or groups. Destructive tools (require ALEXA_MCP_ALLOW_WRITE=1 and confirm: true on each call): * Delete an Alexa routine. * Delete a smart-home device (with safeguards against deleting referenced devices). * Trigger an Alexa routine. Note: This server uses undocumented, reverse-engineered Amazon APIs and may break at any time. Login uses Amazon's real sign-in page; the server only captures the resulting session token.

Which integrations are available for this server?

Provides tools to audit and clean up Amazon Alexa account: list routines, smart-home devices, scenes, activity history, and optionally delete routines and orphaned devices.

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 list all my smart home devices" 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 snordquist

Overview Schema Related Servers Score Discussions

JavaScript

Remote

alexa-mcp

The cleanup-focused Alexa MCP server. An MCP server that lets an AI assistant (Claude Code, Claude Desktop, …) audit and clean up your Amazon Alexa account: list and inspect routines, list smart-home devices and delete the orphans that pile up over time, plus read scenes and activity history.

It talks to Amazon's internal Alexa cloud API via alexa-remote2.

⚠️ Disclaimer
This project is not affiliated with, endorsed by, or supported by Amazon. There is no official public API for managing Alexa routines or smart-home devices — this tool uses the same undocumented, reverse-engineered endpoints the Alexa app uses, and may break at any time when Amazon changes them. Using it may violate Amazon's Terms of Service. Use at your own risk, against your own account only. The login happens on Amazon's real sign-in page (including 2FA); your credentials go only to Amazon — the local proxy only captures the resulting session token afterwards.

Why this exists (vs. other Alexa MCP servers)

Other Alexa MCP servers focus on control (announcements/TTS, volume, lists). This one does that and the things nothing else does — full routine CRUD (create/update/enable-disable/ delete) and audit & cleanup that Amazon's own app can no longer do (bulk-deleting smart-home devices was removed from the Alexa web app). All reverse-engineered from the Alexa app and verified end-to-end.

Capability	This server
List / inspect routines (triggers + action sequence)	✅
Create / update / enable-disable / delete routines	✅ (write-gated; verified)
Find routines with broken references (dangling targets)	✅
List smart-home devices (with source + reachability)	✅
Delete a smart-home device (orphan cleanup, reference-safe)	✅ (write-gated)
Scenes, groups (list/create/delete), activity history	✅
Announcements / TTS / SSML, media transport, volume, DND	✅ (write-gated)
Shopping / to-do lists (read + add)	✅

It is read-only by default. Destructive tools are only registered when you explicitly opt in.

Related MCP server: Enhanced Home Assistant MCP

Requirements

Node ≥ 20 (compiles with tsc to dist/, then runs on plain Node — no bundler).
An Amazon account with app-based 2FA (SMS/email OTP no longer works with Amazon's login).
Log in from a device/browser without the Alexa app installed (otherwise Amazon deep-links into the app instead of finishing the web login).

Quick start

git clone https://github.com/snordquist/alexa-mcp.git
cd alexa-mcp
npm install
npm run doctor      # shows config + the login URL (no network)
npm run auth        # ONE-TIME: starts a local proxy, browser login incl. 2FA
npm run smoke       # lists devices, routines, scenes (read-only)

`npm run auth` in detail

It starts a local proxy and prints a URL (default http://127.0.0.1:3456/).
Open that URL in a browser on the same machine and log in to your Amazon account (2FA).
On success the token (cookie + refreshToken) is written to ./.auth/alexa.json (git-ignored) and refreshed automatically afterwards (every 4 days).
A smoke test (device list) runs. Done.

Logging in from another device? proxyOwnIp must match the URL in your browser exactly:

ALEXA_MCP_PROXY_IP=192.168.x.x npm run auth   # then open http://192.168.x.x:3456/

Use as an MCP server

Read-only (recommended for auditing):

claude mcp add alexa -- node /ABSOLUTE/PATH/alexa-mcp/dist/index.js

With destructive tools enabled (delete routines / devices):

claude mcp add alexa --env ALEXA_MCP_ALLOW_WRITE=1 -- node /ABSOLUTE/PATH/alexa-mcp/dist/index.js

(Run npm run build first.)

Tools

Tool	Purpose	Writes
`alexa_list_devices`	Registered Echos / apps / Fire TVs	no
`alexa_list_routines`	All routines: id, name, status, triggers	no
`alexa_get_routine`	One routine as raw JSON (incl. action sequence)	no
`alexa_list_scenes`	Smart-home entities incl. scenes	no
`alexa_get_activity`	Activity history (customer-history-records)	no
`alexa_list_smarthome_devices`	Smart-home devices with source (skill/Matter) + entity id — find orphans	no
`alexa_audit_broken_references`	Find routines whose action targets a device/scene/group that no longer exists	no
`alexa_get_volumes`	Current speaker volume of every device	no
`alexa_get_do_not_disturb`	Do-Not-Disturb status per device	no
`alexa_query_device`	Live state of smart-home devices/groups by applianceId	no
`alexa_list_groups`	Smart-home groups (rooms/spaces) with members	no
`alexa_list_lists`	Shopping / to-do / custom lists	no
`alexa_get_list_items`	Items of a list by id	no
`alexa_get_player_info`	Now-playing / media player state of a device	no
`alexa_list_notifications`	Reminders / alarms / timers (id, time, label, status)	no
`alexa_create_routine`	Create a routine (voice- or time-triggered) with one or more actions	yes
`alexa_update_routine`	Update a routine in place (full re-spec)	yes
`alexa_set_routine_enabled`	Enable/disable a routine by id (rebuilds + PUTs with flipped status)	yes
`alexa_trigger_routine`	Execute a routine now	yes
`alexa_delete_routine`	Delete a routine + verify	yes
`alexa_delete_smarthome_device`	Delete a smart-home device (orphan cleanup) — refuses if referenced by a routine/group unless `force`, and verifies removal	yes
`alexa_speak`	Make a device speak / announce (`speak` \| `announcement` \| `ssml`)	yes
`alexa_text_command`	Run a typed command as if spoken to a device	yes
`alexa_set_volume`	Set an Echo's speaker volume (0–100)	yes
`alexa_set_do_not_disturb`	Enable/disable Do-Not-Disturb on a device	yes
`alexa_media_control`	Media transport: play/pause/next/previous/forward/rewind/shuffle/repeat	yes
`alexa_add_list_item`	Add an item to a list	yes
`alexa_update_list_item`	Edit a list item's text / mark complete	yes
`alexa_delete_list_item`	Remove a list item	yes
`alexa_create_group`	Create a smart-home group (room/space)	yes
`alexa_update_group`	Rename a group / set members (read-modify-write)	yes
`alexa_delete_group`	Delete a smart-home group (members untouched)	yes
`alexa_set_smarthome_enablement`	Enable/disable a smart-home device	yes
`alexa_create_reminder`	Create a reminder on a device	yes
`alexa_create_alarm`	Create an alarm (< 1 year out; it rings)	yes
`alexa_delete_notification`	Delete a reminder / alarm / timer by id	yes

Most write tools also accept dryRun: true to preview the request/plan without executing.

Routine create/update were reverse-engineered from the Alexa app and verified end-to-end; see ARCHITECTURE.md for the exact write-API (the trigger payload is double-encoded and the action operationPayload must be /operation/validate-normalized — the tools handle both). Example create:

{ "name": "Gute Nacht Ansage", "triggerUtterance": "gute nacht",
  "actions": [ { "type": "Alexa.TextCommand", "operationPayload": { "text": "schlaf gut" } } ],
  "confirm": true }

Write tools are only registered when ALEXA_MCP_ALLOW_WRITE=1, and each destructive call also requires an explicit confirm: true argument.

Configuration (environment variables)

Variable	Default	Purpose
`ALEXA_MCP_AMAZON_PAGE`	`amazon.de`	Login region (e.g. `amazon.com`, `amazon.co.uk`)
`ALEXA_MCP_ACCEPT_LANGUAGE`	`de-DE`	Accept-Language header
`ALEXA_MCP_PROXY_IP`	`127.0.0.1`	Must match the URL you open during login
`ALEXA_MCP_PROXY_PORT`	`3456`	Proxy port for the login
`ALEXA_MCP_PROXY_BIND`	`0.0.0.0`	Proxy bind address
`ALEXA_MCP_REFRESH_MS`	`345600000` (4 d)	Token refresh interval
`ALEXA_MCP_ALLOW_WRITE`	–	`1` enables the destructive tools
`ALEXA_MCP_AUTH_PATH`	`.auth/alexa.json`	Token file location

Security & privacy

The session token is stored only in ./.auth/alexa.json (mode 0600, git-ignored). It is never logged or committed. Treat that file like a password.
The login proxy binds to 0.0.0.0 by default so you can log in from another device; set ALEXA_MCP_PROXY_BIND=127.0.0.1 to keep it local-only.
To fully sign out, delete ./.auth/alexa.json (and remove the registered "device" from Amazon → Manage Your Content and Devices).

Known limitations

Unofficial API — can break whenever Amazon changes it.
Routine deletion endpoint is unverified. alexa_delete_routine attempts DELETE /api/behaviors/v2/automations/{id}, which is not documented or confirmed. Verify the real request via browser DevTools before relying on it.
Device deletion may not be permanent if the underlying source still advertises the device: a skill that is still linked (and whose backend responds) or a Matter bridge will re-add it on the next discovery. Orphans whose backend is gone (unlinked skill, removed integration) stay deleted.
Matter duplicate devices (the same device appearing once per Alexa Echo/hub that acts as a Matter controller) are an Alexa-side artifact, not a bridge misconfiguration. Deleting the redundant copies works, but new ones can reappear if the Matter bridge is re-commissioned.

See ARCHITECTURE.md for the auth flow, endpoint reference, and implementation notes.

License

MIT © Sascha Nordquist

Available Tools

6 tools

alexa_get_activityActivity historyB

Activity history (customer-history-records-v2). Shows what fired when — useful to confirm when a routine or command was triggered.

ParametersJSON Schema

Name	Required	Description	Default
`endTimeMs`	No
`recordType`	No
`startTimeMs`	No

TDQS

B3/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only says 'Shows what fired when' without detailing read-only nature, rate limits, pagination, or authentication needs.

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?

Single concise sentence with additional parenthetical identifier. Front-loaded with purpose, but very brief. Could add more value without losing conciseness.

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?

No output schema, no annotations, and 3 undocumented parameters. Description is too minimal to fully equip an AI agent for correct invocation. Missing details on response format, filtering, and constraints.

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

Parameters1/5

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

Schema has 3 parameters with 0% description coverage. Description does not explain any parameter meaning, format, or usage beyond field names (endTimeMs, recordType, startTimeMs).

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 the tool retrieves activity history to confirm when routines or commands were triggered. Distinguishes from siblings (routines, devices, scenes) by focusing on activity log.

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

Usage Guidelines3/5

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

Implies use for verifying triggers, but no explicit when-to-use or when-not-to-use. Sibling tools are listed but no guidance on choosing between them.

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

alexa_get_routineInspect an Alexa routineA

Raw JSON of one routine (incl. action sequence) by automationId.

ParametersJSON Schema

Name	Required	Description	Default
`automationId`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

The description notes it returns 'Raw JSON' including action sequence, which gives some behavioral insight. However, no annotations are provided, and the description does not disclose any other traits (e.g., read-only nature, permission requirements).

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, concise sentence that conveys the essential information without unnecessary words.

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 the tool's low complexity (1 parameter, no output schema), the description is roughly adequate but could be improved by mentioning error conditions or the exact return structure beyond 'raw JSON'.

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

Parameters2/5

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

The only parameter 'automationId' is not explained beyond its name. The schema has 0% description coverage, and the description adds no semantic context about where to find the ID or its format.

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 states 'Raw JSON of one routine (incl. action sequence) by automationId.' It clearly specifies the resource (routine), the action (get), and is distinct from siblings like alexa_list_routines which lists multiple routines.

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

Usage Guidelines3/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 versus alternatives. It implies usage when a specific automationId is known, but does not mention when not to use it or point to siblings like alexa_list_routines for listing.

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

alexa_list_devicesList Alexa devicesA

All registered Echos / apps / Fire TVs (name, type, serial number).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states the tool lists devices and returns fields, but it does not disclose any behavioral traits such as read-only nature, required permissions, or possible limitations. For a list operation, the behavioral transparency is minimal.

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 that efficiently conveys the purpose and output fields. No unnecessary words. Front-loaded and 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?

Given the tool has no parameters and no output schema, the description is fairly complete. It tells what it lists and what fields are returned. However, it could benefit from clarifying 'apps' or noting that it returns all registered devices. Still, adequate for its simplicity.

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?

There are zero parameters, and schema coverage is 100%. According to calibration guidelines, zero parameters baseline is 4. The description adds no parameter info, but none is needed.

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 'list' and the resource 'registered Echos / apps / Fire TVs' along with the returned fields (name, type, serial number). It distinguishes itself from sibling tools like alexa_list_smarthome_devices by focusing on Alexa devices specifically.

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

Usage Guidelines3/5

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

The description does not provide explicit when-to-use or when-not-to-use instructions. The scope is implied by naming and description, but no alternatives or prerequisites are mentioned. The tool is simple enough that usage is intuitive, but lack of explicit guidance prevents a higher score.

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

alexa_list_routinesList Alexa routinesB

All routines: automationId, name, status, trigger types. Use this to identify a routine (e.g. a scheduled one that fires an unexpected scene).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It states that the tool lists routines with certain fields, but it does not disclose any behavioral traits such as read-only nature, rate limits, ordering, pagination, or error conditions. The description is insufficient for an agent to understand all implications of calling this tool.

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 extremely concise—two sentences that front-load the key information (fields returned) and then provide a usage example. Every sentence is valuable and there is no redundancy.

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 the tool's simplicity (1 optional parameter, no output schema, no annotations), the description is adequate for basic understanding but has clear gaps. It lacks parameter semantics and behavioral details, which are needed for complete guidance.

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

Parameters1/5

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

Schema description coverage is 0% for the single parameter 'limit'. The description does not mention the parameter at all, failing to add any meaning beyond the schema's type constraints. The agent has no guidance on how to use the limit parameter or its effect.

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 it lists all routines and specifies the returned fields (automationId, name, status, trigger types). It also provides a concrete use case (identifying a routine), and the tool is distinct from sibling tools like alexa_get_routine which retrieves a single routine.

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 includes a usage guideline: 'Use this to identify a routine (e.g. a scheduled one that fires an unexpected scene)'. This provides clear context for when to use the tool, but it does not explicitly mention when not to use it or name alternative tools.

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

alexa_list_scenesList scenes / smart-home entitiesD

Smart-home entities including scenes usable as routine actions.

ParametersJSON Schema

Name	Required	Description	Default
`filter`	No

TDQS

D1.3/5.0

Behavior1/5

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

No annotations present. Description does not disclose any behavioral traits (e.g., read-only, permissions, side effects). All burden on description, which provides nothing.

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

Conciseness2/5

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

Description is only a short phrase, lacking structure. While concise, it is under-specified and does not front-load the tool's action.

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

Completeness1/5

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

Given no output schema, no annotations, and minimal description, the tool's full functionality is unclear. No information on output format, filtering behavior, or how it differs from sibling tools.

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

Parameters1/5

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

Schema has 0% coverage for parameter 'filter'. Description does not mention or explain the filter parameter at all, leaving the agent without guidance on how to use it.

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

Purpose2/5

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

Description is vague: 'Smart-home entities including scenes usable as routine actions' does not clearly state that the tool lists scenes. It relies on the title for context, which is insufficient for standalone clarity.

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

Usage Guidelines1/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 over siblings like alexa_list_routines or alexa_list_smarthome_devices. Missing context for selection.

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

alexa_list_smarthome_devicesList smart-home devices (with source)A

All smart-home devices with applianceId, source (manufacturerName + applianceId prefix: SKILL = a smart-home skill, AAA = Matter/Matter bridge) and — for skill devices — the backing entity id. Use this to find orphaned devices (still in Alexa but no longer exposed by their source).

ParametersJSON Schema

Name	Required	Description	Default
`manufacturer`	No
`onlyManufacturer`	No

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the burden. It details the output fields and their interpretation (prefix meanings), which is helpful. However, it does not mention that the tool is read-only, whether authentication is needed, or any constraints like pagination. Safety information is missing.

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 consists of two sentences, with the first sentence immediately stating what the tool returns. Every word adds value, and the structure is efficient. No redundancy or unnecessary details.

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?

While the output fields are well described, the parameters are completely ignored, making the tool definition incomplete. Given no output schema, the description compensates partially but fails to address the input schema gap. The use case is clear, but parameter semantics are missing.

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

Parameters1/5

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

The schema has 2 parameters (manufacturer, onlyManufacturer) with 0% description coverage. The tool description does not explain their purpose or how they affect results. For a tool with parameters, the description should clarify their semantics, but it remains silent.

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 it returns all smart-home devices with specific fields (applianceId, source, backing entity id). It distinguishes from siblings like 'alexa_list_devices' by focusing on smart-home devices and mentioning a specific use case (finding orphaned devices). The verb 'list' is implied, and the title reinforces the purpose.

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 explicitly says to use this for finding orphaned devices, providing a clear context. However, it does not explicitly contrast with alternatives or mention when not to use it. The sibling tools are not referenced, so guidance is somewhat implicit.

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.

6 tool updatesv0.1.0Jul 12, 2026
- First observedalexa_get_activity
- First observedalexa_get_routine
- First observedalexa_list_devices
- First observedalexa_list_routines
- First observedalexa_list_scenes
- First observedalexa_list_smarthome_devices

Install Server

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

TDQS

B3/5.0

Disambiguation5/5

Each tool targets a distinct Alexa entity: activity history, routine details, device list, routine list, scenes, and smart-home devices. Descriptions clearly differentiate between Alexa devices and smart-home devices, preventing confusion.

Naming Consistency5/5

All tools follow the consistent pattern 'alexa_verb_noun' (e.g., alexa_get_activity, alexa_list_devices). Perfect snake_case uniformity makes the set predictable and easy to navigate.

Tool Count5/5

With 6 tools covering core Alexa entities (activity, routines, devices, scenes, smart-home devices), the count is well-scoped for a diagnostic/inventory assistant. Neither too few nor too many.

Completeness3/5

The tools provide comprehensive read access to Alexa objects but lack any write or control capabilities (e.g., no create/update routine, no device control). This limits the surface for active management, though it may be intentional for a diagnostic-focused server.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

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

mytesla.io
io.mytesla
Control your Tesla from your AI assistant - climate, charging, access, and security.
Home Automation & IoT Travel & Transportation
2
echo-ai
so.echoai
List, configure, chat with, analyse and embed your Echo AI assistants.
AI & Machine Learning Agent Orchestration
2
mcpOAuth
com.vibgrate
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
Security Monitoring
2
Jungle Cleaner AOAuth
com.junglecleaner
Lowers your AWS bill by helping you clean up and optimize your setup
Cloud Platforms Monitoring
2

Related MCP Servers

SwitchBot MCP Server
Home Automation & IoT App Automation OS Automation
genm
A
license
C
quality
B
maintenance
Enables AI assistants to control SwitchBot devices, providing functionalities like device management, scene execution, and sensor information monitoring through the SwitchBot API.
Updated 13 days ago (2026-08-23 19:38 UTC)
3
7
ISC
Enhanced Home Assistant MCP
Home Automation & IoT App Automation Autonomous Agents
gilberth
A
license
Not graded
quality
D
maintenance
Enables comprehensive control and monitoring of Home Assistant smart home devices, automations, scenes, and system management through AI assistants. Supports lights, climate, media players, notifications, history tracking, and advanced automation workflows.
Updated a year ago (2025-06-20 04:16 UTC)
21
2
MIT
Alexa Home Automation MCP
Home Automation & IoT App Automation Autonomous Agents
guitarbeat
F
license
Not graded
quality
B
maintenance
Enables AI agents to control Alexa-connected smart home devices, including voice announcements, music control, smart lighting, sensor monitoring, and volume management through the Alexa API.
Updated 11 days ago (2026-08-26 03:18 UTC)
-
Amazon MCP Server
E-commerce & Retail App Automation
drahmad89
A
license
Not graded
quality
D
maintenance
Enables interaction with Amazon services through AI assistants, allowing users to search products, manage their cart, view order history, and place orders using natural language.
Updated 9 months ago (2025-12-17 12:11 UTC)
11
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/snordquist/alexa-mcp'

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

alexa-mcp

⚠️ Disclaimer

Why this exists (vs. other Alexa MCP servers)

Requirements

Quick start

npm run auth in detail

Use as an MCP server

Tools

Configuration (environment variables)

Security & privacy

Known limitations

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`npm run auth` in detail