Setting Up OAuth with Agent Central for Amazon MCP Clients

An Amazon seller has connected Claude or ChatGPT to an MCP client, asked for TACOS, Buy Box status, FBA inventory, or Sponsored Products performance, and then discovered that the difficult part isn't the first successful request. The difficult part is deciding which Amazon permissions the agent should retain, where refresh credentials live, how a revoked grant is detected, and whether an agency can remove one client's access without disrupting every other account.

That makes setting up OAuth an operational control, not a login checkbox. OAuth 2.0 became the formal foundation for delegated authorization when RFC 6749 was published by the IETF in October 2012, and the same authorization-code mechanics now sit behind Amazon seller workflows, hosted MCP servers, and agent-facing data access.

Table of Contents

• What Setting Up OAuth Actually Gets You with agentcentral
  • The concrete output of the flow
• Why MCP Clients Need a Different OAuth Setup Than a Backend Script
  • Scope design changes with the consumer
• Running the Amazon Authorization Flow in agentcentral
  • Create the connection
  • Check the callback behavior
• Creating Scoped API Keys and Connecting Your MCP Client
  • Put the key in the client boundary
• How Token Refresh Works After the Initial Setup
  • What operators should expect
• Diagnosing the OAuth Errors That Show Up in Practice
  • Read the failure stage, not just the status code
• Security Best Practices and a Final Setup Checklist
  • Controls that survive staff and agency changes
  • Final verification checklist

What Setting Up OAuth Actually Gets You with agentcentral

A seller using an AI agent usually wants a direct path from a natural-language request to structured Amazon data. The request might be “compare TACOS across the latest available period,” “show low FBA inventory,” or “check Sponsored Products performance,” without copying raw SP-API credentials into a chatbot.

The next few minutes of OAuth setup create a controlled chain:

1. The seller authorizes the requested Amazon access through Login with Amazon, rather than handing a password to the MCP client.
2. agentcentral receives the authorization result and keeps the resulting credentials behind its encrypted credential vault.
3. The MCP client receives an agent-facing API key, which it forwards on requests instead of handling the underlying Amazon refresh token.
4. agentcentral uses the authorized connection to return structured Amazon Ads and Seller Central data, including source-provided fields and guarded write results where the connection permits them.

The distinction matters. OAuth is the delegated authorization layer, while the MCP key is the application-facing credential used by the client. A practical explanation of that boundary appears in what OAuth authentication means for connected applications.

The concrete output of the flow

A completed connection should leave four identifiable artifacts:

• An LWA grant, tied to the seller's Amazon authorization.
• A refresh token, retained by agentcentral for continued access.
• An agentcentral project, representing the MCP client or operating context.
• A scoped API key, bound to that project and the authorized grant.

This setup removes several infrastructure tasks from the operator. The operator doesn't need to host a separate PII service, implement SP-API JWT signing logic, maintain a custom role-policy file for every agent request, or expose the raw Amazon refresh token to Claude, ChatGPT, Cursor, or OpenClaw.

That doesn't eliminate Amazon-side permissions. It changes where the operational boundary sits. Amazon still decides whether the grant and application roles permit a call, while agentcentral manages the connection between the MCP client and the authorized Amazon data layer.

Practical rule: Treat the API key as a revocable client credential, not as a replacement for permission design. The Amazon grant and the MCP key should be reviewed independently.

Why MCP Clients Need a Different OAuth Setup Than a Backend Script

A backend script generally has one execution path, one deployment boundary, and one credential owner. It can keep a refresh token in a secret manager, request a new access token when needed, and run a fixed job without asking a human to interpret the authorization context during every session.

An MCP client has a different consumer. A human asks an agent questions across a conversation, the agent chooses among tools, and the same connection may need to cover orders, inventory, reports, advertising, catalog, or fulfillment. The credential must survive the chat session boundary without giving the model the raw Amazon token.

Scope design changes with the consumer

Scopes should match the agent's reasoning span, but they shouldn't become a blanket permission set. Advertising access supports campaign and Sponsored Products workflows. Selling Partner API permissions cover resources such as orders, inventory, and reports. Brand analytics access belongs in a separate decision because an agent that only needs advertising performance shouldn't automatically receive every available business dataset.

The trade-off is operational convenience versus failure containment:

Amazon Ads documents a 60-minute access-token lifetime, while refresh tokens remain valid until the advertiser revokes authorization, and token endpoints differ by North America, Europe, and Far East region. Those details make the refresh model suitable for multi-turn agent work, but only when the connection is configured for the correct marketplace region. The Amazon Ads authorization examples provide the region-specific implementation context.

Sharing one refresh token across every developer, agency workspace, and MCP client is difficult to audit and difficult to revoke safely. Separate grants or separate agentcentral keys let an operator disable one integration without guessing which other workflow depends on the same secret. Teams evaluating agent access should also include security design reviews for coding agents in their broader credential review process.

Running the Amazon Authorization Flow in agentcentral

The cleanest setup starts in the agentcentral console, not in a chatbot configuration file.

Create the connection

1. Sign in to agentcentral.
2. Create a new project for the intended MCP client or workspace.
3. Select Amazon as the data source.
4. Choose Connect.
5. Review the Amazon consent request before approving it.

The consent screen should reflect the workflow the client will run. A seller pulling orders, inventory, and reports needs the relevant Selling Partner API read access. An Ads manager querying campaigns and Sponsored Products needs the corresponding Amazon Ads API authorization. If the agent will only read data, write permissions shouldn't be added for convenience.

The authorization-code sequence follows the OAuth standard. The user agent is sent to the authorization endpoint with values including client_id, scope, state, and redirect_uri. After consent, the callback returns an authorization code, and the server validates and exchanges it at the token endpoint. RFC 6749 describes the authorization-code flow and its redirect security requirements, including the need for TLS at the redirect endpoint and exact redirect URI handling.

Amazon Ads authorization codes expire after a 5-minute exchange window, so agentcentral must complete the server-side exchange promptly. Amazon states this requirement in its authorization grants documentation. The operator shouldn't leave the consent tab open while troubleshooting unrelated settings.

Check the callback behavior

The redirect URI configured in the Amazon application must match the callback registered for the agentcentral project. A trailing-character difference, an outdated environment URL, or a callback copied from a different project can stop the exchange even when the seller's Amazon login succeeds.

If the human closes the browser before approving consent, the grant fails. No refresh token is issued, and the flow must be restarted from the agentcentral project. The expected completion state is not merely “Amazon login succeeded.” The console should show a connected Amazon source and a stored credential record associated with that project.

Operators who prefer command-line workflows can compare the dashboard path with the agentcentral CLI authentication documentation, but the same authorization boundary still applies.

Once the exchange succeeds, agentcentral stores the access and refresh credentials in its protected vault. The MCP client doesn't need the underlying LWA refresh token. That separation is the handoff point between Amazon authorization and client configuration.

Creating Scoped API Keys and Connecting Your MCP Client

After Amazon consent succeeds, the client should receive an agentcentral API key, not a raw SP-API refresh token. In the dashboard, open Settings, select API Keys, choose Create, and bind the key to the intended MCP client profile.

The key should be restricted to the scopes already authorized during consent. A read-only profile for inventory, advertising, and TACOS is a sensible starting point for an analysis agent. A workflow that creates shipments or updates listings should use a separate key with explicit write guardrails, not a broader key shared with every reporting conversation.

Put the key in the client boundary

The key is prefixed with mcp_ and includes the seller account hash, which helps prevent a key created for one Seller Central context from being used as though it belonged to another Claude workspace. It still must be handled as a secret. A visible key in chat history, screenshots, or shared configuration is a credential exposure.

The connection patterns differ by client:

• Claude Desktop: place the key in the JSON configuration block under mcp_servers.
• ChatGPT: enter it in the connector configuration panel.
• Custom MCP clients: call https://api.agentcentral.ai/v1/mcp/auth and send the key in an Authorization: Bearer header.

The header order should be consistent:

1. Authorization: Bearer mcp_...
2. The MCP request headers required by the client.
3. The request body or tool payload.

After a key swap, clients perform a 30-second cache flush before the new credential is consistently used. A failed request immediately after rotation may therefore reflect cached client state rather than an invalid Amazon grant.

Teams standardizing developer-facing credential screens can also browse API key setup for interface patterns, while the agentcentral guidance on API key scoping keeps the implementation focused on least privilege.

How Token Refresh Works After the Initial Setup

The MCP client shouldn't manage Amazon's bearer-token rotation directly. When the client sends a request with its agentcentral key, agentcentral identifies the associated project and grant, obtains a usable Amazon access token from the stored refresh credential, and forwards the authorized request to the appropriate Amazon API.

Amazon Ads access tokens last 60 minutes, as documented in the Amazon Ads API usage guide. Amazon's SP-API documentation also requires applications to store the LWA refresh token and use grant_type=refresh_token, client_id, and client_secret when exchanging it for an access token, as described in Amazon's SP-API connection documentation.

What operators should expect

A normal request path is:

• The MCP client sends the scoped API key.
• agentcentral resolves the connected Amazon grant.
• The platform exchanges or reuses a valid access token.
• The Amazon request runs under the authorized scopes and application roles.
• The structured response returns to the MCP client.

The agent doesn't need to see the bearer token, and it shouldn't. If Amazon invalidates the refresh grant because the seller unlinked the application, changed an authorization condition, or revoked access, the operator should expect an authorization error associated with the agentcentral key. Re-consent is then required.

Refresh handling doesn't expand permissions. It only renews access that Amazon has already authorized. That distinction is important for governance, because a durable refresh credential remains an access surface even when no one is actively using the MCP client.

Diagnosing the OAuth Errors That Show Up in Practice

OAuth failures are usually deterministic. The fastest diagnosis starts with the exact error in the agentcentral activity feed, then checks whether the failure occurred during scope construction, callback validation, token exchange, or Amazon-side authorization.

The following table keeps the remediation path short:

Read the failure stage, not just the status code

An invalid_scope response from Login with Amazon is different from a 403 Unauthorized response after authentication. The first points to the consent request. The second means the token exists, but the Amazon application isn't permitted to use that resource.

A region mismatch can create a similar trap for Ads integrations. Amazon specifies separate token endpoints for North America, Europe, and Far East, so a connection configured for the wrong marketplace region can fail even when the seller's credentials are correct. The relevant endpoint choice belongs in the project configuration, not in a prompt sent to the agent.

Diagnostic rule: If the browser flow fails, inspect scopes and redirect configuration. If the browser flow succeeds but the tool call fails, inspect region, application roles, and resource permissions.

The most useful activity records include the project identifier, client profile, requested scope, callback result, token-exchange status, Amazon resource, and returned error. Operators shouldn't paste secrets into logs while increasing verbosity. A log should prove which stage failed without becoming another credential store.

Security Best Practices and a Final Setup Checklist

An OAuth grant attached to an Amazon seller account can remain useful long after the initial browser session. Security reporting on 22,332 OAuth-connected apps found that 47.2% had no active usage in the previous 90 days, while their authorizations remained intact, and 25.8% had not been used for 180 days or more. The same analysis found 24.5% held at least one active restricted Google scope, and 91% of AI and automation apps in the sample appeared during the previous 16 months, illustrating how quickly unused and high-risk grants can accumulate. These figures come from the Material Security OAuth study summary.

Least privilege is the starting point, not the complete control. Current OAuth security guidance says public clients MUST use PKCE, confidential clients SHOULD use it, exact redirect URI matching is recommended, implicit and password grants should be avoided, and sender-constrained tokens such as DPoP or mutual TLS should be used where possible. The OAuth security best-practice guidance also stresses transaction-specific PKCE values and detection of reused or constant verifiers.

Controls that survive staff and agency changes

• Scope narrowly: Give each agent only the Amazon resources required for its workflow, with read-only access wherever possible.
• Separate clients: Use separate agentcentral projects or keys for each client, seller, and agency workspace.
• Protect refresh credentials: Keep refresh tokens in the encrypted platform vault. Don't export them into prompts, local notes, or shared tickets.
• Review activity: Export token issuance times, scope changes, key ownership, last-used endpoints, and revocation events for a regular access review.
• Revoke promptly: Remove access when an agency engagement ends, a staff member leaves, or a client no longer uses the workflow.
• Test writes deliberately: Keep guarded writes separate from read-heavy analysis keys, and require previews or explicit confirmation before changes.

The governance gap is especially serious because legitimate consent can create durable access and may bypass the protections operators associate with an ordinary interactive login. A useful broader framing of how security drives business value is to treat access review as operating discipline, not as paperwork added after deployment.

Final verification checklist

1. Consent screen was reviewed.
2. Correct seller ID was selected.
3. Requested scopes match the intended workflow.
4. Refresh token persists after the browser closes.
5. MCP handshake returns 200.
6. A representative read call succeeds.
7. A representative write call requires the expected confirmation or re-consent.
8. API key is bound to one intended client.
9. Key isn't visible in chat history.
10. Revocation flow has been tested.
11. Backup credentials are stored offline under controlled access.
12. The next key or access review date is on the calendar.

Treating OAuth as a lifecycle gives sellers a cleaner failure boundary, a smaller blast radius, and an audit trail that maps actual agent activity to actual Amazon authorization.

agentcentral provides a hosted MCP data layer for Amazon Ads, Seller Central, inventory, orders, catalog, finance, ranking, and fulfillment workflows, with scoped keys, pre-materialized reads, and guarded writes recorded in audit logs. Connect an Amazon account through OAuth, create a client-specific key, and visit agentcentral to configure the MCP workflow without exposing raw Amazon refresh credentials to the agent.