Apier MCP Server

Redeem an owner-issued key-issuance token (keyless)

redeem_issuance_token

Convert an owner-issued one-time token into your own API key, enabling headless onboarding for agents without credentials. Redeem the single-use token atomically to receive your key exactly once, then use it for subsequent API calls.

Instructions

Convert an owner-issued key-issuance token into your own API key — the headless onboarding step for an agent that holds no credential yet. Keyless: the one-time token IS the credential. Minting and revocation are dashboard-only by design, so an agent can never self-issue authority. Redemption is strictly SINGLE-USE and atomic: on success (201) the token is consumed and the result carries {id, name, scopes, created_at, plaintext_key} — returned EXACTLY ONCE; store it immediately. Failure modes: an expired / used / revoked / unknown token yields ONE uniform ISSUANCE_TOKEN_INVALID failure (ask the owner for a fresh token, never retry); MAX_KEYS_REACHED (409) means 3 active keys — the token was NOT consumed, retry with the SAME token after the owner revokes a key. After onboarding, use get_pricing (keyless) to price metered work and get_credit_balance (with your new key) for the balance. Docs: https://www.apier.no/docs/authentication

Input Schema

TableJSON Schema

Name	Required	Description	Default
`token`	Yes	The one-time key-issuance token the account owner minted in the Apier dashboard (Agent issuance tokens) and handed to you out-of-band. Single-use: it is consumed atomically on success. Never logged by Apier.

Output Schema

TableJSON Schema

Name	Required	Description
`_meta`	No
`result`	Yes	The freshly issued API key: id, fixed name, read:* scopes, creation time, and the one-time plaintext_key.
`metadata`	Yes
`justification`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.2.1Sep 26, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only state readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description goes far beyond: it discloses single-use atomic consumption, exact-once delivery of the plaintext_key, uniform error behavior for expired/used/revoked/unknown tokens, and the MAX_KEYS_REACHED 409 case where the token is NOT consumed. It also notes the token is never logged, adding security-relevant context. This fully discloses behavioral traits, and no annotation contradiction exists.

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?

Although the description is relatively long, every sentence conveys critical operational detail. It is front-loaded with the core action, then covers keyless nature, single-use, failure modes, and next steps, each earning its place. There is no filler or redundant repetition of the schema; the text is dense with actionable information.

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?

Given the tool's complexity (onboarding, single-use credential, failure modes) and the presence of an output schema, the description is complete: it specifies success payload and status, exactly-once storage imperative, all relevant failure modes with proper agent behavior, and a docs link. It also situates the tool within the broader workflow by naming subsequent tools. No gaps remain for the agent to safely invoke the tool.

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?

Input schema already has 100% coverage with a detailed description of the token parameter, including single-use, not-logged, and example format. The description adds broader meaning by explaining the token IS the credential in keyless onboarding and that minting/revocation are dashboard-only, enriching the agent's understanding of the parameter's role. It also clarifies retry semantics with the same token on 409. This goes beyond the schema, hence a 4 rather than a 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?

The description opens with a clear, specific verb+resource: 'Convert an owner-issued key-issuance token into your own API key.' It explicitly positions this as the headless onboarding step, distinguishing it from all sibling tools in the context (none of which cover key redemption). This is unambiguous and uniquely identifies the tool's purpose.

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?

Provides explicit when and when-not: 'for an agent that holds no credential yet' and 'Minting and revocation are dashboard-only by design, so an agent can never self-issue authority.' It also names direct post-onboarding alternatives: 'use get_pricing (keyless) ... and get_credit_balance (with your new key).' Even failure handling instructs when to retry vs. never retry, making use conditions crystal clear.

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