pkinative-mcp

Overview Schema Source Related Servers Discussions Admin

Inspect CRL (RFC 5280 §5 report, one entry lookup, signature check)

inspect_crl

Read-onlyIdempotent

Parse one X.509 CRL to report its issuer, dates, number, extensions and revocation entries, look up a serial, and optionally verify its signature against an issuer certificate.

Instructions

Read-only RFC 5280 §5 report of ONE certificate revocation list: version, issuer (RFC 4514 + RDNs), signature algorithm, thisUpdate / nextUpdate, CRL number, delta indicator and base CRL number, issuing distribution point, entry count (the entries are counted by walking, never all decoded — bounded by limits.maxRevokedCertificates), every extension decoded, size, diagnostics. find looks ONE serial up (serialHex, or a certificate whose serial and issuer are used) and returns entry (revoked, revocationDate, reason, invalidityDate, entry extensions). issuer adds a signature check — ONE signature against ONE key, not a verdict: check_crl_revocation judges a certificate against the list (freshness, scope, delta), verify_certificate_chain judges the whole chain. Token-frugal: verbosity:'summary' (issuerString, thisUpdateIso, nextUpdateIso, crlNumber, entryCount, isDelta, revoked, signatureValid). Input: pem / derBase64 / path.

Input Schema

Name	Required	Description	Default
`crl`	Yes	The CRL (X509 CRL PEM or DER): exactly one of pem / derBase64 / path.
`find`	No	Look one serial up in the list (the entries are walked, never all decoded): exactly one of serialHex / certificate.
`fields`	No	Dot-paths to keep after verbosity (arrays map over elements); unmatched paths land in _meta.unmatchedFields.
`issuer`	No	The CRL issuer certificate to check the signature against: exactly one of pem / derBase64 / path. A valid signature is NOT trust: check_crl_revocation / verify_certificate_chain judge revocation.
`limits`	No	Raise 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.
`strict`	No	Escalate the first engine warning to a PKI_STRICT_DIAGNOSTIC error instead of listing it in diagnostics[].
`pemMode`	No	'strict' (RFC 7468 exactly, default) or 'lax' (tolerates whitespace, line length and RFC 1421 headers).	strict
`allowSha1`	No	Accept or produce SHA-1 signatures (legacy material you already trust). Default false: refused with PKI_CRYPTO_ALGORITHM_REFUSED on read, VALIDATION_ERROR on write.
`verbosity`	No	'summary' keeps the scalar fields only (token-frugal).	full
`encodingRules`	No	'der' (strict X.690 DER, default) or 'ber' (indefinite / non-minimal lengths and constructed strings, as legacy CMS producers write).	der

Output Schema

Name	Required	Description
`entry`	No	The lookup asked for with `find`: whether the serial is listed, and the entry when it is.
`issuer`	No
`isDelta`	No	Carries a deltaCRLIndicator (RFC 5280 §5.2.4).
`revoked`	No
`version`	No
`crlNumber`	No	Decimal (RFC 5280 §5.2.3); null when absent.
`signature`	No	The signature check asked for with `issuer`. ONE signature against ONE key — not a trust verdict.
`sizeBytes`	No
`entryCount`	No	Entries in revokedCertificates (counted by walking, bounded by limits.maxRevokedCertificates).
`extensions`	No
`nextUpdate`	No
`thisUpdate`	No
`diagnostics`	No	Non-fatal concerns the engine raised (PKI_DIAG_*, de-duplicated, at most 200; explain_code explains one).
`issuerString`	No	RFC 4514 issuer.
`baseCrlNumber`	No	The base CRL number a delta applies to (decimal); null otherwise.
`nextUpdateIso`	No
`thisUpdateIso`	No
`signatureValid`	No
`diagnosticCount`	No
`diagnosticCounts`	No	Occurrences per diagnostic code.
`signatureAlgorithm`	No
`diagnosticsTruncated`	No	true when distinct diagnostics beyond the 200 listed were dropped.
`issuingDistributionPoint`	No	RFC 5280 §5.2.5, decoded (fullName, onlyContainsUserCerts, onlyContainsCACerts, onlySomeReasons, indirectCRL, onlyContainsAttributeCerts); null when absent = the list covers everything its CA issued.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 27, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Adds non-obvious behavior well beyond the readOnly/idempotent annotations: the entry count comes from walking the list, never decoding all entries, and is bounded by limits.maxRevokedCertificates; `find` walks for exactly one serial; `issuer` performs a single-key signature check whose success is not a trust verdict. These are precisely the over-interpretation traps an agent would otherwise fall into.

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 purpose and scope, then the per-parameter behaviors, then the token-frugal summary contract — every sentence carries information. The long enumeration of reported fields is useful but dense, and the closing 'Input: pem / derBase64 / path' partially repeats the schema.

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 10-parameter tool with nested inputs, enums and an output schema, the description covers input modes, the bounded-walk behavior, the single-key signature caveat, sibling routing, and the summary-mode field set. Return-value detail is legitimately delegated 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 goes beyond it by explaining `find` (one serial up, via serialHex or a certificate whose serial and issuer are used), what `issuer` consumes and returns, and exactly which fields verbosity:'summary' retains. It does not mention the `fields` dot-path projection or the `limits`/`strict`/`pemMode` knobs, so not fully additive.

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 with scope ('Read-only RFC 5280 §5 report of ONE certificate revocation list') and enumerates exactly what is reported (version, issuer, signature algorithm, validity windows, CRL number, delta, IDP, entry count, extensions, diagnostics). The singular 'ONE' plus the named sibling comparison makes it distinguishable from check_crl_revocation and verify_certificate_chain at a glance.

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 bounds what `issuer` does ('ONE signature against ONE key, not a verdict') and routes the agent elsewhere by name and condition: check_crl_revocation judges a certificate against the list on freshness/scope/delta, verify_certificate_chain judges the whole chain. That is an explicit when-to-use-this vs when-to-use-alternatives statement.

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