Skip to main content
Glama
Nizoka

pkinative-mcp

by Nizoka
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Create CSR (PKCS#10 request from a JSON spec, Web Crypto signed)

create_csr

Build a PKCS#10 certification request from a subject and requested extensions, signed with a PKCS#8 or PKCS#12 key; proof of possession is verified before the CSR is returned.

Instructions

Build a PKCS#10 certification request (RFC 2986) from spec (subject; the extensions to request — subjectAltName, keyUsage, extendedKeyUsage, basicConstraints, subjectKeyIdentifier, raw — carried in extensionRequest; issuerAltName / authorityKeyIdentifier are refused as the issuer's), 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). The public key certified is the signing key's own: derived from a plain signer.key, taken from the PKCS#12 certificate, or given as subjectPublicKey (a certificate, a CSR or a PUBLIC KEY — required for an encrypted PKCS#8 key, whose type then comes from it). The proof of possession is verified BEFORE the request is returned: KEY_MISMATCH when the key and the public key differ. RSA keys need signer.rsaScheme; an encrypted key needs signer.password (or PKINATIVE_MCP_PASSWORD); SHA-1 needs allowSha1:true. ECDSA / RSA-PSS signatures are randomised (PRODUCES). Output PEM (default), DER or hex, inline or as a sandbox file (never overwritten). inspect_csr reads it back; create_certificate issues from it (subjectPublicKey = the request).

Input Schema

NameRequiredDescriptionDefault
specYesWhat to write into the request: the subject and the extensions to ask for. 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; .csr .p10 .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 public key to certify: a certificate, a CSR (CERTIFICATE REQUEST) or a PUBLIC KEY (SPKI): exactly one of pem / derBase64 / path. Omitted: derived from a PLAIN signer.key or taken from the PKCS#12 certificate; required for an encrypted PKCS#8 key. It must be the signing key's public half (a CSR is a proof of possession).

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

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

Adds substantial behavior beyond the annotations: the signing key is imported as a non-extractable Web Crypto key, proof of possession is verified before return, KEY_MISMATCH occurs on key/public-key mismatch, RSA requires `rsaScheme`, encrypted keys require a password or environment variable, SHA-1 requires `allowSha1`, and ECDSA/RSA-PSS signatures are randomised. The randomisation note is consistent with `idempotentHint=false`, and the write-like behavior is consistent with `readOnlyHint=false` and `destructiveHint=false` because output files are never overwritten.

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 is front-loaded, and the description remains dense with no obvious filler. The semicolon-heavy single paragraph is lengthy, but most of the detail is justified by the tool’s complexity and the number of cryptographic constraints.

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?

Because an output schema exists, the description need not document return values, and it still adds output-encoding, inline/file, and non-overwrite behavior. With comprehensive annotations and 100% schema coverage, there is no major gap for an agent to call the tool correctly.

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 schema already documents all 11 parameters, including the full `limits` object. The description reinforces useful cross-parameter constraints — public-key derivation from `signer.key` / PKCS#12 / `subjectPublicKey`, encrypted-key requirements, RSA `rsaScheme`, and output modes — though much of this is already present in the schema, so it adds only moderate value.

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?

Starts with a specific verb and resource — “Build a PKCS#10 certification request (RFC 2986)” — and identifies the two required inputs (`spec`, `signer`). It also distinguishes the tool from related lifecycle steps by noting that `inspect_csr` reads the result back and `create_certificate` issues from it.

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?

Explicitly names downstream alternatives (`inspect_csr`, `create_certificate`) and states important boundaries: nothing generates or exports a key here, and issuerAltName / authorityKeyIdentifier are refused because they belong to the issuer. This gives an agent clear context for when this construction step is appropriate.

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