Skip to main content
Glama
Nizoka

pkinative-mcp

Convert PEM (list and extract blocks, or wrap DER)

convert_pem
Idempotent

Decodes PEM text into its blocks with labels, sizes and hashes, extracting one as DER, PEM or hex; encodes DER bytes into a strict PEM block. Private keys are never extracted or produced.

Instructions

The RFC 7468 layer. mode:'decode' lists every block of a PEM text (index, label, DER size, offset, RFC 1421 headers under pemMode:'lax', SHA-256 of the DER) — label keeps one kind, extractIndex also delivers that block as an artefact (encoding 'der' by default, 'pem' or 'hex'; inline as an embedded resource, or as a sandbox file with outputMode:'file' + outputPath, never overwritten). mode:'encode' wraps DER bytes (derBase64 or a DER file path) into one strict PEM block under label (required) and delivers it as the artefact (64-character lines, LF). A private-key block (PRIVATE KEY, ENCRYPTED PRIVATE KEY, RSA/EC/DSA PRIVATE KEY) is listed by label and size but never extracted, and never produced: SECURITY_VIOLATION (use inspect_private_key) — DER that parses as a PKCS#8 key or a PKCS#12 file is refused under ANY label. Refuses: derBase64 in decode, pem in encode, an encoding other than 'pem' in encode, a file output without extractIndex (VALIDATION_ERROR); an index past the last block (NOT_FOUND); a label absent from the text (PKI_PEM_UNEXPECTED_LABEL); a malformed text (PKI_PEM_* — pemMode:'lax' tolerates whitespace, line length and headers; a missing base64 padding is refused in both modes). Token-frugal: verbosity:'summary' (count + labels), fields:[…].

Input Schema

NameRequiredDescriptionDefault
modeYes'decode' lists the blocks of a PEM text (and extracts one with extractIndex); 'encode' wraps DER bytes into one PEM block.
inputYesThe PEM text (decode: pem or a path to a PEM file) or the DER bytes (encode: derBase64 or a path to a DER file): exactly one of pem / derBase64 / path.
labelNodecode: list only the blocks with this label. encode: the label of the block (required; e.g. 'CERTIFICATE'). Upper-case words and digits separated by single spaces; a private-key label is refused (SECURITY_VIOLATION).
fieldsNoDot-paths to keep after verbosity (arrays map over elements); unmatched paths land in _meta.unmatchedFields.
limitsNoRaise pkinative's 22 named security bounds for this call (trusted input only; absent keys keep the engine defaults). A value above an operator ceiling (PKINATIVE_MCP_MAX_INPUT_BYTES, PKINATIVE_MCP_MAX_KDF_ITERATIONS, PKINATIVE_MCP_MAX_PATHS_EXPLORED) is LIMIT_CEILING_EXCEEDED; describe_engine lists the defaults and the ceilings.
strictNoEscalate the first engine warning to a PKI_STRICT_DIAGNOSTIC error instead of listing it in diagnostics[].
pemModeNo'strict' (RFC 7468 exactly, default) or 'lax' (tolerates whitespace, line length and RFC 1421 headers).strict
encodingNoArtefact encoding. decode + extractIndex: 'der' (default, raw bytes), 'pem' (the block re-emitted strictly) or 'hex' (inline only, ≤ 64 KiB). encode: always 'pem' (anything else is VALIDATION_ERROR).
verbosityNo'summary' keeps the scalar fields only (token-frugal).full
outputModeNo'base64' (default) returns the artefact inline as an embedded resource (≤ 50 MiB). 'file' writes it inside PKINATIVE_MCP_OUTPUT_DIR (never overwrites; ≤ 1 GiB) and returns a resource_link.base64
outputPathNoRelative path inside the sandbox (only when outputMode='file'); the extension must match the encoding (.der .crt .cer .csr .crl .p7s .bin … for der; .pem for pem). Key-bearing extensions (.key .p8 .p12 .pfx) are refused: nothing here writes a private key.
extractIndexNodecode: also deliver the block with this index (its position in the text, as listed) as an artefact in `encoding`. A private-key block cannot be extracted (SECURITY_VIOLATION).
encodingRulesNo'der' (strict X.690 DER, default) or 'ber' (indefinite / non-minimal lengths and constructed strings, as legacy CMS producers write).der

Output Schema

NameRequiredDescriptionDefault
modeNo
countNodecode: number of blocks listed.
labelNoencode: the label written.
blocksNodecode: every block of the text (or those with `label`), in order. A private-key block is listed by label and size only.
labelsNodecode: the label of every block listed.
sha256Noencode: SHA-256 of the DER wrapped (lowercase hex).
artefactNoThe artefact delivered alongside the report: its facts here, its bytes once as the embedded resource (or the resource_link in file mode).
extractedNodecode: the block delivered as the artefact.
sizeBytesNoencode: the DER size wrapped.
diagnosticsNoNon-fatal concerns the engine raised (PKI_DIAG_*, de-duplicated, at most 200; explain_code explains one).
diagnosticCountNo
diagnosticCountsNoOccurrences per diagnostic code.
diagnosticsTruncatedNotrue when distinct diagnostics beyond the 200 listed were dropped.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Far beyond the annotations: it discloses the SECURITY_VIOLATION refusal for any private-key block (listed but never extracted or produced), the PKCS#8/PKCS#12 rejection under any label, the never-overwrite file behaviour, and the exact error codes for each invalid combination. Annotations only say it's non-readOnly, idempotent and non-destructive, so this description carries real behavioral weight.

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?

It is front-loaded with the two modes and scoping, and every clause carries information (no filler). The long em-dash chains make it dense to parse, which costs it a point, but nothing is redundant.

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?

With a full output schema, rich annotations, and 100% schema coverage, the description still supplies everything an agent needs: mode semantics, artefact/encoding behaviour, security refusals, error taxonomy, and token-frugal options. Nothing required to call it correctly is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter rules the schema does not state: derBase64 is refused in decode, pem is refused in encode, a file output without extractIndex is a VALIDATION_ERROR, and encoding must be 'pem' in encode. These conditional interactions materially improve parameter understanding.

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?

It names the exact standard layer ('RFC 7468') and states both verbs precisely: decode lists/ extracts every PEM block, encode wraps DER into one strict PEM block. The distinction between the two modes is unmistakable and it explicitly routes private-key handling to the inspect_private_key sibling.

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?

It gives clear conditions for each mode and names one alternative ('use inspect_private_key') for the private-key case, plus a detailed refusal list that defines misuse. It doesn't differentiate itself from other DER/PEM-adjacent siblings like decode_asn1 or encode_asn1, so it stops short of full when/when-not coverage.

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