Skip to main content
Glama

create_key

Create a new cryptographic key for AWS Payment Cryptography, specifying algorithm, TR-31 usage, key class, exportability, and KCV method. Ensures compliance for AES using CMAC.

Instructions

Call this when creating a new cryptographic key — BDK, ZPK, CVK, MAC key, KEK, etc. Call explain_key_usage first to confirm the right key usage code — APC keys are typed at creation and the type cannot change.

AES keys must use CMAC for KCV (not ANSI_X9_24). Enforced here.

Args: key_algorithm: AES_128, AES_256, TDES_3KEY, RSA_2048, RSA_3072, RSA_4096, ECC_NIST_P256, etc. key_usage: TR-31 key usage code, e.g. TR31_P0_PIN_ENCRYPTION_KEY key_class: SYMMETRIC_KEY, ASYMMETRIC_KEY_PAIR, or PRIVATE_KEY exportable: Whether the key can be exported via TR-31 or TR-34 enabled: Whether the key is immediately active (default true) key_check_value_algorithm: CMAC, ANSI_X9_24, HMAC, or SHA_1. AES keys must use CMAC (ANSI_X9_24 is rejected here per PCI PIN Annex C); TDES may use either. HMAC keys use HMAC — the construction is fixed but the hash is the one bound to the key at creation, over a zero-length message, so reproducing the KCV outside APC requires knowing that hash. Asymmetric keys use SHA_1. tags: Optional list of {Key, Value} tag dicts derive_key_usage: For a BDK (B0) only — the TR-31 usage the derived DUKPT working keys will carry, e.g. TR31_P0_PIN_ENCRYPTION_KEY. APC binds this at creation, so a BDK created without it cannot later derive keys of that usage. replication_regions: Optional list of regions to replicate this key into, e.g. ["us-west-2", "eu-west-1"]. Omit to use the account default (see get_default_key_replication_regions). Replication is a property of the key, so set it here or via add_key_replication_regions afterwards.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNo
enabledNo
key_classYes
key_usageYes
exportableYes
key_algorithmYes
derive_key_usageNo
replication_regionsNo
key_check_value_algorithmNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.2.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses important constraints: key usage type is fixed at creation, AES keys require CMAC and reject ANSI_X9_24, BDK derive_key_usage is bound at creation, and replication is a persistent key property. This goes well beyond a generic create operation.

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?

The description is long, but the domain is complex and every paragraph adds essential information. The usage-first instruction is front-loaded, followed by an enforcement warning, and then a clearly structured Args block. A slight trim in wording would improve it, but the structure is effective.

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?

For a 9-parameter, high-stakes key creation tool with no annotations and no output schema, the description covers parameter semantics, constraints, prerequisites, and side effects thoroughly. It does not describe the response format or what identifiers are returned, which would make it fully complete, but this is a minor gap relative to the rich guidance already present.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must fully compensate, and it does. It provides concrete allowed values or formats for every parameter, explains algorithm-specific KCV rules, clarifies the BDK-only derive_key_usage, and gives examples for replication_regions. This is exemplary parameter documentation.

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 specific action—'creating a new cryptographic key'—and enumerates concrete examples (BDK, ZPK, CVK, MAC key, KEK). This clearly distinguishes create_key from the many sibling tools focused on getting, listing, deleting, importing, or exporting keys.

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 states when to call the tool and even directs the agent to call explain_key_usage first to validate the key usage code. It does not explicitly name alternatives like import_key for when key material already exists, but the creation context and prerequisite guidance are clear and actionable.

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

Latest Blog Posts

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/J8k3/aws-payment-cryptography-mcp'

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