pkinative-mcp

Overview Schema Source Related Servers Discussions Admin

Verify time-stamp (the RFC 3161 verdict: imprint, TSA signature, chain, revocation)

verify_timestamp

Read-onlyIdempotent

Verify an RFC 3161 timestamp token or response against your trust anchors, checking imprint, nonce, policy and revocation to return a valid or invalid verdict.

Instructions

The one-call verdict on an RFC 3161 time-stamp: exactly one of token (a TimeStampToken, .tst) or response (the whole TimeStampResp, .tsr — a declined response is PKI_REASON_TSP_NOT_GRANTED), judged against what YOU say was stamped — request (the .tsq you sent: imprint, nonce and policy are all checked, the only way to catch a replay), data (hashed with the token's own algorithm) or digestHex; at least one is required, because a token verified without what it stamps proves nothing (VALIDATION_ERROR otherwise). The TSA's signature is verified, its certificate must chain to one of YOUR trustAnchors (through candidates and the certificates the token carries) at at with a critical timeStamping EKU (allowNonCriticalTimeStampingEku:true for deployed TSAs that are not), and revocation is judged from the CRL / OCSP bytes YOU supply (requireRevocation:true demands evidence). A negative verdict is valid:false + reasons[] (PKI_REASON_* codes) — never isError. genTime / earliest / latest (accuracy applied) are established only when valid. Pin at for a reproducible, cacheable verdict. Token-frugal: verbosity:'summary'.

Input Schema

Name	Required	Description	Default
`at`	No	The 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).
`crls`	No	CRLs (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.
`data`	No	The data that was stamped (hashed with the token's own imprint algorithm): exactly one of text / base64 / path.
`token`	No	The TimeStampToken (a ContentInfo over a TSTInfo; .tst): exactly one of pem / derBase64 / path. Exclusive with response.
`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
`request`	No	The TimeStampReq you sent (.tsq): exactly one of pem / derBase64 / path. The strongest statement of what was stamped: imprint, nonce and policy are all checked; the only way to catch a replayed response.
`response`	No	The whole TimeStampResp the TSA returned (.tsr): exactly one of pem / derBase64 / path. Exclusive with token. A response that granted nothing is PKI_REASON_TSP_NOT_GRANTED.
`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.
`digestHex`	No	The digest that was stamped, when you hold that rather than the data. Exclusive with data. Hexadecimal (an 0x prefix, colons and spaces are tolerated).
`verbosity`	No	'summary' keeps the scalar fields only (token-frugal).	full
`candidates`	No	Untrusted certificates the TSA's path may use (every PEM block of every item is taken). Optional; the certificates the token carries are also candidates.
`trustAnchors`	Yes	Trust 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.
`encodingRules`	No	'der' (strict X.690 DER, default) or 'ber' (indefinite / non-minimal lengths and constructed strings, as legacy CMS producers write).	der
`ocspResponses`	No	OCSP 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.
`requireRevocation`	No	Require 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.
`allowNonCriticalTimeStampingEku`	No	Accept a TSA whose extKeyUsage names timeStamping but is not critical (RFC 3161 §2.3 requires it critical; some deployed TSAs are not).

Output Schema

Name	Required	Description
`tsa`	No	The TSA certificate whose key verified the token, or null.
`chain`	No	The chain judged by verify_certificate_chain, or null when there was no certificate to judge.
`valid`	No	Whether the token is evidence that the expected hash existed at genTime. false is a negative verdict (reasons[]), never an error.
`latest`	No	genTime plus the declared accuracy — the instant an LTV check compares against.
`genTime`	No	The time the TSA asserts (ISO 8601) — established only when valid.
`reasons`	No	Why 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.
`earliest`	No	genTime minus the declared accuracy.
`diagnostics`	No	Non-fatal concerns the engine raised (PKI_DIAG_*, de-duplicated, at most 200; explain_code explains one).
`evaluatedAt`	No	The ISO instant the TSA chain was judged at — re-pass it as `at` to reproduce the verdict.
`reasonCodes`	No
`diagnosticCount`	No
`diagnosticCounts`	No	Occurrences per diagnostic code.
`evaluatedAtSource`	No
`diagnosticsTruncated`	No	true when distinct diagnostics beyond the 200 listed were dropped.
`signatureVerifications`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 27, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial context beyond them: a failed verification returns valid:false + PKI_REASON_* reasons and never isError, the server never fetches CRLs or queries a responder (offline-only), requireRevocation is enforced for the leaf, and clock-dependent results are never cached. It also discloses the timeStamping EKU criticality rule and the escape hatch for deployed TSAs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, but the body is a single dense paragraph of em-dash-chained clauses that an agent must parse in one pass. Every fact it contains is relevant, yet the mental model (inputs → checks → verdict → caching) would land faster as separate sentences or a short list.

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 objects and an output schema, the description covers what an agent still needs: mandatory inputs, the exclusivity rules, what is verified, what error codes a negative verdict carries, and how caching interacts with `at`. Nothing material to calling it correctly 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 coverage is 100%, so the schema carries the per-field burden and a 3 would be the baseline. The description still adds relational semantics the schema alone doesn't make obvious: at least one of token/response is required, at least one of request/data/digestHex is required, trustAnchors are mandatory because 'a verdict is relative to the anchors you name', and data is hashed with the token's own algorithm.

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?

The opening clause states a specific verb and resource: 'the one-call verdict on an RFC 3161 time-stamp', with the checks (imprint, TSA signature, chain, revocation) named up front. It distinguishes itself from decoding siblings by framing the output as a verdict (valid:false + reasons[]) rather than an inspection, so an agent can tell verify_timestamp from inspect_timestamp without opening the 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?

It gives strong mode-selection guidance: token vs response exclusivity, and why `request` beats `data` ('the only way to catch a replay'), plus 'pin `at` for a reproducible, cacheable verdict' and 'verbosity: summary' for token economy. It never explicitly says when to reach for inspect_timestamp or create_timestamp_request instead, so it stops short of the 5 bar.

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