Skip to main content
Glama
Nizoka

pkinative-mcp

by Nizoka
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Encode ASN.1 (JSON node spec to DER)

encode_asn1
Idempotent

Encode a JSON ASN.1 node specification into DER, PEM, or hex output, with validation and deterministic bytes for certificate and PKI workflows.

Instructions

Encode a JSON node spec into DER through the engine's own encoders: spec is one node { type, … } — boolean (value), integer / enumerated (value: integer, decimal or 0x-hex string, negative allowed), null, bit-string (hex, unusedBits), named-bits (bits[]), octet-string (hex), oid / relative-oid (value), string (stringType utf8|numeric|printable|teletex|ia5|visible|universal|bmp, value), time (value: ISO instant or epoch ms; timeType UTCTime|GeneralizedTime|rfc5280 — the RFC 5280 rule by default), sequence / set / set-of (children[]; set-of is sorted as DER requires), explicit / implicit (tag, class universal|application|context|private, inner), tlv (class, tag, constructed, hex) and der (hex of one pre-encoded value, checked). Nesting is bounded by limits.maxDepth (PKI_LIMIT_EXCEEDED). The bytes are decoded back for the summary (root tag, node count). Output DER (default), hex (inline, ≤ 64 KiB) or PEM under label, inline as an embedded resource or as a sandbox file (never overwritten). Refuses a malformed node naming its JSON path ($.children[1].value …), a PEM encoding without label, a private-key label, a value that parses as a PKCS#8 key or a PKCS#12 file (SECURITY_VIOLATION — nothing here produces key material); a value the engine cannot encode is PKI_ASN1_* / PKI_OID_INVALID. Deterministic: the same spec gives the same bytes. The inverse of decode_asn1 (its tree uses the same vocabulary).

Input Schema

NameRequiredDescriptionDefault
specYesAn ASN.1 node spec: { type, … } with type one of boolean (value), integer / enumerated (value: integer or decimal / 0x-hex string), null, bit-string (hex, unusedBits), named-bits (bits[]), octet-string (hex), oid / relative-oid (value), string (stringType utf8|numeric|printable|teletex|ia5|visible|universal|bmp, value), time (value instant, timeType UTCTime|GeneralizedTime|rfc5280), sequence / set / set-of (children[] of nodes), explicit / implicit (tag, class universal|application|context|private, inner node), tlv (class, tag, constructed, hex), der (hex of one DER object). Nesting is bounded by limits.maxDepth.
labelNoThe PEM label for encoding:'pem' (required then; upper-case words and digits). A private-key label is refused.
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: 'pem' (RFC 7468 text), 'der' (raw bytes), 'hex' (lowercase hex in structuredContent, inline only, ≤ 64 KiB). Default 'der'.der
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 .bin .asn1 for der; .pem for pem). Key-bearing extensions (.key .p8 .p12 .pfx) are refused: nothing here writes a private key.
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
hexNoThe artefact as lowercase hex (when encoding='hex').
modeYes
sha256YesSHA-256 of the DER bytes (lowercase hex) — the reproducibility proof.
summaryYes
encodingYes
filePathNoSandboxed absolute path (when outputMode='file').
sizeBytesYesSize of the DER artefact.
diagnosticsYesNon-fatal concerns the engine raised (PKI_DIAG_*, de-duplicated, at most 200; explain_code explains one).
diagnosticCountsYesOccurrences 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.4/5.0
Behavior5/5

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

Beyond annotations (idempotent, non-destructive), the description discloses nesting bounds (limits.maxDepth, PKI_LIMIT_EXCEEDED), output modes and size limits, security refusals (PKCS#8 key, PKCS#12, private-key labels, SECURITY_VIOLATION), error code families (PKI_ASN1_*, PKI_OID_INVALID), and determinism. This is rich context an agent could not infer from the annotations alone.

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 purpose and the decode_asn1 relationship are front-loaded, and every clause carries information. The single dense block is somewhat run-on, mixing node vocabulary, output modes, and error behavior without visual separation, but no sentence is wasted.

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 an output schema exists, the description need not explain return values, and it covers the remaining complexity: encoding formats, sandbox file behavior, limit escalation, strict mode, PEM modes, and security refusals. Nothing an agent needs to call it safely is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents every parameter in detail. The description largely restates the node-type enumeration and fields, adding only small clarifications (negative integer values allowed, the rfc5280 time default) that are already present or implied in the schema. Baseline 3 is appropriate.

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 precise verb and resource ('Encode a JSON node spec into DER') and explicitly identifies itself as the inverse of the sibling decode_asn1. The node vocabulary is enumerated, so an agent knows exactly what this tool accepts before opening the schema.

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 clearly signals when to use this tool by naming the counterpart decode_asn1 and the shared node vocabulary. However, it does not explicitly exclude alternatives (e.g., encode_x509_structure) or state when not to use it, leaving a small inference gap.

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

Deploy Server

Other Tools