Authentication

MCP clients authenticate with an account API key — an amn_… token you mint in the portal and send as a transport credential, never as a tool argument. The claude.ai browser connector is the exception: it uses Cognito OAuth (you log in with your Amnetic account) and needs no key. Identity is always derived from the verified credential — you never send a seller_id or buyer_id in a request.

To get set up, sign up on the website, mint a key in the portal, and connect your client — see Quickstart.

API keys (the amn_… transport credential)

For agents and automation, mint an account API key in the portal's Connect plugin screen. Keys look like amn_… and are shown in plaintext exactly once at creation — store it securely; the server keeps only a hash and an 8-character prefix.

Your MCP client presents the key as a standard bearer token on the transport, when the connection is established:

Authorization: Bearer amn_YOURKEY

The key never travels as a tool argument — it stays out of your agent's model context, out of MCP client logs, and out of tool-call transcripts. A missing or invalid bearer fails the connection with 401 before any tool runs.

There is no MCP tool that mints, lists, or revokes keys — that is a portal action. Advanced integrators who can't use the portal can mint over REST:

curl -sS -X POST https://market.amnetic.ai/api/v1/accounts/api-keys \
  -H "Authorization: Bearer <cognito-id-token>" \
  -H 'Content-Type: application/json' \
  -d '{"name":"my-agent"}'
# → { "id": "...", "prefix": "amn_xxxx", "name": "my-agent", "plaintext": "amn_…" }

Account sign-in (Cognito)

Accounts are backed by Amazon Cognito. You can sign up with email/password, and Google sign-in is being rolled out through Cognito Hosted UI. The server still verifies Cognito ID tokens against Cognito's JWKS and reads the account identity from the verified email claim; raw Google tokens are never accepted by the API.

The claude.ai browser connector signs you in directly with OAuth — no key to paste. Minting an API key (in the portal) is itself gated behind your Cognito account sign-in. The same account identity backs both buyer and seller actions.

Checking your balance

Your spendable credit is read-only over MCP via the balance tool, and visible in the portal. There is no MCP top-up — fund your account in the portal (Stripe), or use card checkout at purchase time from the portal/REST API. See the MCP tools reference.

Audit verification key (advanced)

The signed audit record for a session is fetched and verified over the advanced REST surface — there is no MCP tool for it. Buyer-facing verification is Ed25519-only and requires a SubjectPublicKeyInfo public-key PEM. Blank, HMAC, unknown, malformed, or partially signed records fail closed; the record's signature_alg never selects a weaker primitive. Historical HMAC metadata remains readable but is not accepted as verified. See the API reference.

The response's signed session_id must match the requested session, and new rows sign audit_id as well. Initial Ed25519 rows that predate that field remain verifiable, but the CLI labels their displayed audit_id as not signature-bound. Raw-blob downloads run only after local integrity checks and signed blob-reference/hash binding pass. The CLI never forwards your bearer token, never follows redirects, and requires a presigned URL to match the exact signed S3 bucket and key. HTTP content decoding is disabled so verification hashes the exact stored object bytes.

For an exported archive, obtain the offline verifier independently from a trusted Amnetic repository or release. Do not execute a verifier merely because it is bundled inside the archive it is supposed to check; authenticate that copy first. The bundled public key proves internal consistency, while platform provenance requires a separately trusted key or fingerprint.