Skip to main content
Glama

alexa_finish_login

Destructive

Complete an Alexa sign-in by submitting the login ID and Amazon redirect URL or authorization code, then register this server on the account and save the session.

Instructions

Finish an Alexa sign-in started by alexa_begin_login. Pass the loginId and the full address of the www.amazon.com/ap/maplanding page the user landed on (or just its authorization code). Registers this server as an "alexa-mcp" device on the Amazon account, saves the session, and checks it by reading the device list. Each sign-in link can be finished once; if it fails, start again with alexa_begin_login.

Input Schema

NameRequiredDescriptionDefault
loginIdYesThe loginId alexa_begin_login returned.
redirectUrlYesThe full address of the www.amazon.com/ap/maplanding page after signing in (or its authorization code).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.3

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare the write/destructive/openWorld profile, and the description adds substantial context beyond that: it registers the server as an 'alexa-mcp' device on the Amazon account, saves the session, and verifies by reading the device list. It also discloses the single-use nature of the sign-in link, which the annotations do not convey.

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?

Front-loads the purpose, then parameters, then side effects, then failure handling. Four tight sentences with no filler; every clause earns its place.

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

Completeness5/5

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

For a 2-param write tool with no output schema, the description covers the trigger, inputs, side effects, and failure recovery. An agent has everything needed to invoke it correctly and understands the resulting state change.

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 description coverage is 100%, so the schema already documents both required parameters including the 'or its authorization code' alternative. The description restates the same information without adding format or syntax beyond the schema, warranting the baseline 3.

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?

States a specific verb+resource ('Finish an Alexa sign-in') and explicitly ties it to its counterpart alexa_begin_login, so an agent can distinguish this from the ~35 other alexa_* siblings. The scope (completing a login flow) is unambiguous.

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

Usage Guidelines5/5

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

Explicitly states the prerequisite ('started by alexa_begin_login'), what must be passed, the one-time-use constraint ('Each sign-in link can be finished once'), and the recovery path ('if it fails, start again with alexa_begin_login'). This covers when-to-use and the fallback alternative.

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