Skip to main content
Glama
Nizoka

pkinative-mcp

by Nizoka
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Check CRL revocation (one certificate against one CRL, optional delta)

check_crl_revocation
Read-onlyIdempotent

Checks whether a certificate is revoked by validating it against a base CRL and optional delta CRL at a specific time, including signature and scope checks for a reliable verdict.

Instructions

The RFC 5280 §6.3 revocation verdict of ONE certificate against ONE base crl you fetched (this server never fetches), evaluated at at: the list must be in scope for the certificate (issuer, issuing distribution point, reasons), fresh (nextUpdate, or staleTolerance ms past it), signature-verified, and the serial must not be listed (PKI_REASON_REVOKED with the reason otherwise). delta applies a delta CRL over the base (it must carry a deltaCRLIndicator — VALIDATION_ERROR otherwise — and name the base's number). issuer is the CRL issuer certificate: the base (and delta) signatures are verified against it and reported as signatureVerified / deltaSignatureVerified; without it the engine refuses the unverified list, so pass it for a real verdict. valid:false + reasons[] is a verdict, never isError. Pin at for a reproducible, cacheable verdict. SHA-1 signatures need allowSha1:true. Token-frugal: verbosity:'summary'. inspect_crl shows the list's facts; verify_certificate_chain with crls:[…] is the whole-chain form.

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).
crlYesThe base CRL (X509 CRL PEM or DER): exactly one of pem / derBase64 / path.
deltaNoA delta CRL applied over the base: exactly one of pem / derBase64 / path. Must carry a deltaCRLIndicator (VALIDATION_ERROR otherwise); its base CRL number is checked against the base.
fieldsNoDot-paths to keep after verbosity (arrays map over elements); unmatched paths land in _meta.unmatchedFields.
issuerNoThe CRL issuer certificate: exactly one of pem / derBase64 / path. The base (and delta) signatures are verified against it and reported to the engine as signatureVerified. Omitted: the signatures are NOT verified and the engine does not accept the list as evidence (valid:false, PKI_REASON_REVOCATION_UNKNOWN) — the verdict is then only a dry run.
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
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.
verbosityNo'summary' keeps the scalar fields only (token-frugal).full
certificateYesThe certificate to check: exactly one of pem / derBase64 / path.
encodingRulesNo'der' (strict X.690 DER, default) or 'ber' (indefinite / non-minimal lengths and constructed strings, as legacy CMS producers write).der
staleToleranceNoMilliseconds past nextUpdate the evidence is still accepted (default: the engine policy, none).

Output Schema

NameRequiredDescriptionDefault
validNotrue = the certificate is not revoked according to fresh, in-scope, signature-verified evidence. false is a negative verdict (reasons[]), never an error.
isDeltaNoWhether the BASE list itself carries a deltaCRLIndicator (false for a proper base CRL).
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.
crlNumberNoThe base CRL number (decimal), null when absent.
diagnosticsNoNon-fatal concerns the engine raised (PKI_DIAG_*, de-duplicated, at most 200; explain_code explains one).
evaluatedAtNoThe ISO instant used — re-pass it as `at` to reproduce the verdict.
reasonCodesNo
deltaCrlNumberNoThe delta CRL number (present only with `delta`).
diagnosticCountNo
diagnosticCountsNoOccurrences per diagnostic code.
evaluatedAtSourceNo
signatureVerifiedNoThe base CRL signature against `issuer`; null when no issuer was given (then the engine reports the list as unverified).
diagnosticsTruncatedNotrue when distinct diagnostics beyond the 200 listed were dropped.
deltaSignatureVerifiedNoThe delta CRL signature against `issuer` (present only with `delta`).

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 read-only/non-destructive annotations: scope and freshness checks, signature verification, delta CRL requirements, issuer behavior, valid:false semantics, SHA-1 gating, and cache reproducibility via at.

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 key constraints are front-loaded, and nearly every sentence carries operational value. It is dense and slightly overstuffed as a single paragraph, but appropriate for a 13-parameter cryptographic tool.

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 this tool's complexity: it explains inputs, verdict semantics, error-as-verdict behavior, alternatives, and reproducibility. With a rich schema and output schema present, nothing essential is missing from the description.

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 explains each parameter. The description still adds meaningful cross-parameter semantics, especially why issuer is required for a real verdict and how delta must relate to the base CRL.

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, resource, scope, and standard: the RFC 5280 §6.3 revocation verdict of ONE certificate against ONE base CRL at a given time. It explicitly distinguishes itself from inspect_crl and the whole-chain verify_certificate_chain form.

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?

Names the alternatives and when to use them: inspect_crl for list facts, verify_certificate_chain with crls for whole-chain verification. It also says the server never fetches CRLs and that issuer is required for a real verdict.

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