Skip to main content
Glama
Nizoka

pkinative-mcp

Create certificate (CA or leaf, from a JSON spec, Web Crypto signed)

create_certificate

Issues a signed X.509 v3 certificate from a subject and validity spec, self-signed or issued by a given CA, with extensions and PEM, DER or hex output. Verifies the signature against the issuer before returning.

Instructions

Issue an X.509 v3 certificate from spec (subject, validity, extensions — basicConstraints, keyUsage, extendedKeyUsage, subjectAltName, issuerAltName, SKI / AKI, raw), signed through signer (a PKCS#8 key or a PKCS#12 file, imported as a NON-EXTRACTABLE Web Crypto key — nothing generates or exports a key here). Self-signed when no issuerCertificate is given (the subject key is derived from a plain signer.key, or taken from subjectPublicKey); issued when issuerCertificate is given (subjectPublicKey = a certificate, a CSR or a PUBLIC KEY is then required; the AKI is computed from the issuer). Serial 'random' by default (node:crypto, reported as summary.randomSerial), notBefore defaults to PKINATIVE_MCP_AT or now (whole seconds) — pin both for reproducible bytes. The new certificate is verified against the issuer (or itself) BEFORE it is returned (KEY_MISMATCH otherwise). RSA keys need signer.rsaScheme; SHA-1 needs allowSha1:true. Output PEM (default), DER or hex, inline or as a sandbox file (never overwritten).

Input Schema

NameRequiredDescriptionDefault
specYesWhat to write into the certificate. Unknown members are 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.
signerYesThe signing key: exactly one of `key` (a PKCS#8 private key, plain or PBES2-encrypted, PEM or DER) or `p12` (a PKCS#12 file, PBES2 + PBMAC1 only). The key is imported into a NON-EXTRACTABLE Web Crypto key and never leaves the engine; no result ever carries a key byte. The algorithm follows the key: ECDSA on the key's curve, Ed25519/Ed448 (no hash), RSA REQUIRES rsaScheme ('pkcs1' | 'pss' — pkinative has no default). SHA-1 only with the tool's allowSha1:true.
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 'pem'.pem
allowSha1NoAccept or produce SHA-1 signatures (legacy material you already trust). Default false: refused with PKI_CRYPTO_ALGORITHM_REFUSED on read, VALIDATION_ERROR on write.
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 (.pem for pem; .crt .cer .der for der). 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
subjectPublicKeyNoThe subject public key: a certificate, a CSR (CERTIFICATE REQUEST) or a PUBLIC KEY (SPKI): exactly one of pem / derBase64 / path. Omitted: derived from a PLAIN signer.key (self-signed only).
issuerCertificateNoThe issuing CA certificate: exactly one of pem / derBase64 / path. Omitted: the certificate is self-signed (issuer = subject, the signing key must be the subject's).

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.6/5.0
Behavior5/5

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

Goes well beyond the annotations: the key is imported as a NON-EXTRACTABLE Web Crypto key, nothing generates or exports key material, the certificate is verified against the issuer BEFORE returning (KEY_MISMATCH otherwise), serial randomness comes from node:crypto and is reported as summary.randomSerial, and sandbox files are never overwritten. That is exactly the write/verify/irreversibility context annotations cannot express.

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?

Front-loaded with the core action and scoped tightly to what matters, with no filler sentences. It is a single dense paragraph with nested parentheticals and semicolon-chained clauses, which makes it harder to scan than a short labelled list would be.

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?

Complete for a 12-parameter, deeply nested, mutation tool: mode selection, key handling, verification, encoding, output destination and limit-ceiling behavior are all covered, and with an output schema present it does not waste space describing return values beyond the one field an agent must know (summary.randomSerial).

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 already 100%, yet the description adds cross-field meaning the schema states only piecemeal: which inputs are mutually exclusive, that the subject key is derived from a plain signer.key or from subjectPublicKey depending on mode, and that AKI is computed from the issuer. Pinning notBefore/notAfter for reproducible bytes is a genuinely non-obvious usage note.

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?

Opens with a specific verb and resource: 'Issue an X.509 v3 certificate from `spec` ... signed through `signer`', and immediately distinguishes the two modes (self-signed vs issued) and the format set. An agent can tell this apart from create_csr, sign_cms and verify_certificate_chain without inspecting any 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?

States the conditions that switch modes ('Self-signed when no issuerCertificate is given ... issued when issuerCertificate is given'), the prerequisite for RSA ('RSA keys need signer.rsaScheme') and the SHA-1 gate. It never explicitly names a sibling alternative ('use create_csr instead when ...'), so routing guidance is implied through conditions rather than stated.

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