Skip to main content
Glama
Nizoka

pkinative-mcp

Verify certificate chain (the RFC 5280 §6 verdict, offline revocation)

verify_certificate_chain
Read-onlyIdempotent

Validates a leaf certificate chain against your trust anchors, checking signatures, validity, name constraints, policies, server hostname/IP, key purposes, and offline CRL/OCSP revocation.

Instructions

The one-call trust verdict for a certificate: builds a path from leaf through candidates to one of YOUR trustAnchors, verifies every signature, validates the path at at (RFC 5280 §6: validity, basic constraints, key usage, name constraints, policies — policy inputs), checks serverName (RFC 6125 host or IP) and purposes (extended key usage along the path), and judges revocation from the CRL / OCSP bytes YOU supply (crls, ocspResponses; requireRevocation:true demands evidence for every certificate below the anchor; this server never fetches). A negative verdict is valid:false + reasons[] (PKI_REASON_* codes) in structuredContent — never isError; isError is reserved for inputs the engine refuses. Pin at (ISO 8601) for a reproducible, cacheable verdict; evaluatedAt echoes the instant used. Token-frugal: verbosity:'summary' (valid, reasonCodes, pathLength). Prefer it over inspect_certificate.signature for any trust question; build_certificate_path / validate_certificate_path explain a failing path.

Input Schema

NameRequiredDescriptionDefault
atNoThe instant the verdict is evaluated at. An ISO 8601 date-time (UTC unless zoned; e.g. 2027-01-01T00:00:00Z), epoch milliseconds as digits, or 'now'. Omitted: PKINATIVE_MCP_AT when the operator pinned it, else the wall clock (a clock-dependent result is never cached).
crlsNoCRLs (DER or X509 CRL PEM) for offline revocation (every PEM block of every item is taken). Optional; this server never fetches a CRL — pass the bytes you obtained.
leafYesThe end-entity certificate to judge: exactly one of pem / derBase64 / path.
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.
policyNoRFC 5280 §6.1.1 policy inputs.
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
purposesNoExtended key usages the leaf must allow: serverAuth, clientAuth, codeSigning, emailProtection, timeStamping, ocspSigning, any, or a dotted OID.
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.
ocspNonceNoThe nonce you put in the OCSP request (1–32 bytes), to be matched in the responses. Hexadecimal (an 0x prefix, colons and spaces are tolerated).
verbosityNo'summary' keeps the scalar fields only (token-frugal).full
candidatesNoUntrusted intermediate certificates the path may use (every PEM block of every item is taken). Optional; the certificates embedded in a CMS message are also candidates.
serverNameNoThe identity the leaf must be valid for (RFC 6125): exactly one of host / ip.
trustAnchorsYesTrust anchors (root certificates you trust) (every PEM block of every item is taken). At least one is required: a verdict is relative to the anchors you name.
encodingRulesNo'der' (strict X.690 DER, default) or 'ber' (indefinite / non-minimal lengths and constructed strings, as legacy CMS producers write).der
ocspResponsesNoOCSP responses (DER) for offline revocation (every PEM block of every item is taken). Optional; this server never queries a responder — pass the bytes you obtained.
requireOcspNonceNoRefuse an OCSP response that does not echo the nonce.
requireRevocationNoRequire fresh revocation evidence for the end-entity certificate (PKI_REASON_REVOCATION_UNKNOWN otherwise — the engine demands it for the leaf; an intermediate is judged from the evidence you pass); default false = revocation is checked when evidence is given.

Output Schema

NameRequiredDescriptionDefault
pathNoThe path found, leaf first, up to (and including) the trust anchor.
validNoThe verdict. false is a negative verdict (reasons[]), never an error.
reasonsNoWhy the verdict is negative (empty when valid): the engine PKI_REASON_* codes, each with the standard it cites and the path of the offending element. A reason is returned, never thrown.
exploredNoCandidate paths explored (bounded by limits.maxPathsExplored).
pathLengthNo
diagnosticsNoNon-fatal concerns the engine raised (PKI_DIAG_*, de-duplicated, at most 200; explain_code explains one).
evaluatedAtNoThe ISO instant the verdict was evaluated at — re-pass it as `at` to reproduce the verdict.
reasonCodesNo
diagnosticCountNo
diagnosticCountsNoOccurrences per diagnostic code.
evaluatedAtSourceNo
revocationEvidenceNo
diagnosticsTruncatedNotrue when distinct diagnostics beyond the 200 listed were dropped.
signatureVerificationsNo

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds non-obvious behavior: negative verdicts return valid:false + PKI_REASON_* reasons in structuredContent and are never isError, isError is reserved for engine-refused inputs, and a verdict is only cached when `at` is pinned. These are exactly the things an agent cannot infer from annotations.

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 verdict statement and with no filler sentences; every clause maps to a real behavior (path build, signature verify, RFC 5280 validation, name check, revocation, caching, verbosity). It is dense to the point of being a single long run-on sentence with heavy parenthetical nesting, which costs a little skimmability.

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?

For a 19-parameter tool with nested input unions, an output schema, and a complex trust model, the description covers the whole decision surface an agent needs: what is verified, what must be supplied versus fetched, how failures are surfaced, how to get deterministic/cacheable results, and the token-frugal mode. Return-value detail is correctly left to the output schema.

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; the description earns above that by framing `policy` as RFC 5280 §6.1.1 inputs, `serverName` as an RFC 6125 host-or-IP, `purposes` as EKU along the path, and `requireRevocation:true` as demanding evidence for every certificate below the anchor. Minor friction: the schema text for `requireRevocation` scopes the demand to the leaf and judges intermediates from supplied evidence, which reads slightly differently from the description's blanket phrasing.

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?

States a specific verb and resource ('one-call trust verdict for a certificate') and enumerates the distinct sub-operations it performs: path building, signature verification, RFC 5280 §6 validation, RFC 6125 name check, EKU check, and revocation judging. It also explicitly contrasts itself with siblings ('Prefer it over inspect_certificate.signature for any trust question; build_certificate_path / validate_certificate_path explain a failing path'), so an agent can place it among the 30+ siblings without opening 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit selection rule against the nearest alternatives ('prefer it over inspect_certificate.signature for any trust question') and assigns the diagnostic role to build_certificate_path / validate_certificate_path. It also states the scope constraint that makes it usable: 'this server never fetches' — the caller must supply CRL/OCSP bytes.

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