pkinative-mcp

Overview Schema Source Related Servers Discussions Admin

Inspect OCSP response (RFC 6960 report, signature check)

inspect_ocsp_response

Read-onlyIdempotent

Inspect one OCSP response to see status, SingleResponses, responder ID, extensions, certificates, signature algorithm and nonce echo; optionally verify the signature against a responder certificate.

Instructions

Read-only RFC 6960 §4.2 report of ONE OCSP response (the DER a responder returned): the response status (only successful carries an answer), the BasicOCSPResponse — responder id (by name or by key hash), producedAt, every SingleResponse (CertID: hash algorithm, issuer name / key hashes, serial; status good / revoked with time and reason / unknown; thisUpdate, nextUpdate, extensions), response extensions, the embedded certificates, the signature algorithm — whether an RFC 8954 nonce is echoed, and diagnostics (bounded by limits.maxOcspSingleResponses). responder adds a signature check against that certificate; omitted, the embedded certificates are tried and the one that verifies is named. ONE signature against ONE key is NOT a status verdict: check_ocsp_status matches the CertID, judges the responder's authorisation (RFC 6960 §4.2.2.2), freshness and nonce. Token-frugal: verbosity:'summary' (status, responses[serialNumber, status], noncePresent, signatureValid). Input: derBase64 / path (or PEM).

Input Schema

Name	Required	Description	Default
`fields`	No	Dot-paths to keep after verbosity (arrays map over elements); unmatched paths land in _meta.unmatchedFields.
`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
`response`	Yes	The OCSP response (DER, as the responder returned it): exactly one of pem / derBase64 / path.
`responder`	No	The responder certificate to check the signature against: exactly one of pem / derBase64 / path. Omitted: the certificates embedded in the response are tried (signature.source embedded). A valid signature is NOT authorisation: check_ocsp_status judges the responder (RFC 6960 §4.2.2.2).
`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
`status`	No	OCSPResponseStatus (RFC 6960 §4.2.1). Only successful carries a signed answer.
`responses`	No
`signature`	No	The signature check: against `responder`, or the first embedded certificate whose key verifies. ONE signature against ONE key — authorisation is judged by check_ocsp_status.
`sizeBytes`	No
`diagnostics`	No	Non-fatal concerns the engine raised (PKI_DIAG_*, de-duplicated, at most 200; explain_code explains one).
`noncePresent`	No	A nonce extension is present on the response.
`basicResponse`	No	The BasicOCSPResponse; null when the status is not successful.
`signatureValid`	No
`diagnosticCount`	No
`diagnosticCounts`	No	Occurrences per diagnostic code.
`diagnosticsTruncated`	No	true when distinct diagnostics beyond the 200 listed were dropped.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 27, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/closed-world. The description adds substantive behavior: signature checking against an explicit responder or the embedded certificates, the caveat that a valid signature is not authorisation, and the bounded `maxOcspSingleResponses` limit. It does not discuss error modes, but `strict` and diagnostic behavior are documented in the schema.

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 purpose and the sibling distinction. It is dense and long, but every clause carries information relevant to calling the tool correctly; no filler or tautology.

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?

Given a complex tool with 8 parameters and a nested schema, the description covers what is returned, the signature-check semantics, token-frugal mode, and the critical distinction from the sibling status-checking tool. An output schema exists, so return-value detail is appropriately delegated.

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% and already documents all parameters, so the baseline is 3. The description adds useful semantics beyond the schema: the exactly-one-of derBase64/path/PEM input shape, the `responder` omission fallback, and the exact content of `verbosity:'summary'`.

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 ('Read-only RFC 6960 §4.2 report of ONE OCSP response') and enumerates exactly what is reported (response status, BasicOCSPResponse fields, SingleResponse details, nonce echo, signature algorithm). It explicitly distinguishes itself from sibling `check_ocsp_status` by noting that a signature check is not a status verdict.

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 alternative tool and the condition that selects it: `check_ocsp_status` matches the CertID and judges responder authorisation, freshness and nonce. It also states the omitted-`responder` fallback behavior, giving the agent a clear when-to-use narrative.

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