Skip to main content
Glama
Nizoka

pkinative-mcp

Check OCSP status (one response for one certificate: CertID, responder, freshness, nonce)

check_ocsp_status
Read-onlyIdempotent

Verify one fetched OCSP response against its certificate and issuer: recompute the CertID, check signer authorization, nonce and freshness, then return a good, revoked, or unknown verdict.

Instructions

The RFC 6960 verdict of ONE OCSP response you fetched (this server never queries a responder) for ONE certificate: the CertID is recomputed from issuer (with the hash the response used, or hashAlgorithm) and must be answered; the signature is verified with responder, else the certificates embedded in the response, else the issuer itself; the signer must be authorised (RFC 6960 §4.2.2.2: the CA, a delegate the CA issued carrying id-kp-OCSPSigning, or responderTrusted:true for a trust you hold out of band); then the engine judges the status (good; PKI_REASON_REVOKED / unknown otherwise), freshness at at (thisUpdate / nextUpdate / producedAt, staleTolerance and futureTolerance ms), and the nonce (nonce must be echoed; requireNonce:true refuses a response without one). A non-successful response status is a negative verdict with status null. valid:false + reasons[] is a verdict, never isError. Pin at for a reproducible, cacheable verdict. Token-frugal: verbosity:'summary' (valid, reasonCodes, status, signatureVerified, responderAuthorized, responder). create_ocsp_request builds the request you POST; inspect_ocsp_response shows the facts without a verdict.

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).
nonceNoThe nonce you put in the request (1–32 bytes; create_ocsp_request summary.nonceHex): the response must echo it. Hexadecimal (an 0x prefix, colons and spaces are tolerated).
fieldsNoDot-paths to keep after verbosity (arrays map over elements); unmatched paths land in _meta.unmatchedFields.
issuerYesThe CA certificate that issued it: exactly one of pem / derBase64 / path. Its name and key hashes form the CertID to match, and it is the authority a responder must be (or be delegated by).
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
responseYesThe OCSP response (DER, as the responder returned it): exactly one of pem / derBase64 / path.
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.
responderNoThe responder certificate to verify the signature with: exactly one of pem / derBase64 / path. Omitted: the certificates embedded in the response are tried, then the issuer itself.
verbosityNo'summary' keeps the scalar fields only (token-frugal).full
certificateYesThe certificate whose status is asked: exactly one of pem / derBase64 / path.
requireNonceNoRefuse a response that carries no nonce (RFC 8954).
encodingRulesNo'der' (strict X.690 DER, default) or 'ber' (indefinite / non-minimal lengths and constructed strings, as legacy CMS producers write).der
hashAlgorithmNoThe CertID hash to recompute with. Default: the one the response used for this serial, else SHA-1.
staleToleranceNoMilliseconds past nextUpdate the evidence is still accepted (default: the engine policy, none).
futureToleranceNoMilliseconds a thisUpdate / producedAt may lie after `at` (clock skew) and still be accepted (default: the engine policy).
responderTrustedNoState an out-of-band trust in the responder (RFC 6960 §4.2.2.2 third case): responderAuthorized is then true whatever its certificate says.

Output Schema

NameRequiredDescriptionDefault
validNotrue = a fresh, correctly signed, authorised answer says good. false is a negative verdict (reasons[]: revoked, unknown, stale, unauthorised, unverified, nonce …), never an error.
statusNoThe status the response gives for this serial; null when the response holds no answer for it.
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.
certIdHexNoThe recomputed DER CertID (hex).
responderNoThe subject of the certificate that verified the signature.
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
hashAlgorithmNoThe hash the CertID was recomputed with.
diagnosticCountNo
responderSourceNoWhere the signer came from: the `responder` input, the certificates embedded in the response, or the issuer itself.
diagnosticCountsNoOccurrences per diagnostic code.
evaluatedAtSourceNo
signatureVerifiedNoA responder candidate verified the response signature.
responderAuthorizedNoThe signer is the CA itself, a delegate the CA issued with id-kp-OCSPSigning, or responderTrusted was set.
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?

Discloses behavior well beyond the annotations: the CertID recomputation and required match, the signature-verification fallback chain (responder, then embedded certs, then issuer), the RFC 6960 §4.2.2.2 authorization rule including responderTrusted, freshness windows with staleTolerance/futureTolerance, and nonce echo/requireNonce. It also states a crucial agent-facing contract: valid:false + reasons[] is a verdict, never isError, and offers verbosity:'summary' as a token-frugal mode.

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 verdict statement and scoping caveat, then ordered by verification pipeline, with sibling routing and the token-frugal hint appended. The middle is a single semicolon-chained paragraph with deeply nested parentheticals that is dense to parse, but nearly every clause carries non-redundant information.

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 complex 18-parameter tool with nested inputs, the description covers the decision logic an agent cannot infer: verification order, trust fallbacks, freshness policy, nonce policy, negative-status handling, and the error-vs-verdict distinction. Return shapes are handled by the output schema and safety profile by annotations, so nothing essential is missing.

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 description coverage is 100%, so the baseline is 3; the description goes beyond it by explaining cross-parameter semantics — issuer derives the CertID with either the response's hash or hashAlgorithm, nonce must be echoed by the response, and responder is only needed when the embedded chain is insufficient. It adds real interpretive value rather than restating field docs, though some 18-parameter surface (limits, encodingRules, pemMode) is left entirely to the schema.

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: it delivers the RFC 6960 verdict for one OCSP response against one certificate. It also scopes the tool sharply ('this server never queries a responder') and names the two sibling tools it is not (create_ocsp_request, inspect_ocsp_response), so an agent can route correctly 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 Guidelines4/5

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

Explicitly positions the tool in a workflow: create_ocsp_request builds the request, inspect_ocsp_response shows facts without a verdict, and this tool judges. It also advises pinning `at` for reproducible, cacheable verdicts. It does not spell out when a caller should skip OCSP checking entirely (e.g. preferring CRL via check_crl_revocation), so it falls short of full when/when-not coverage.

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