pkinative-mcp

Overview Schema Source Related Servers Discussions Admin

Inspect certificate (RFC 5280 report, extensions, fingerprints, signature check)

inspect_certificate

Read-onlyIdempotent

Decode one X.509 certificate into an RFC 5280 report—issuer, subject, validity, public key, extensions, fingerprints, and diagnostics—with optional signature checks against an issuer or self key.

Instructions

Read-only RFC 5280 report of ONE certificate in one call: version, serial, signature algorithm, issuer and subject (RFC 4514 + RDNs), validity (epoch ms + ISO), public key (kind, bits, curve / modulus / exponent), every extension decoded (the 19 kinds pkinative knows; rawExtensions:true keeps them undecoded), self-issued flag, fingerprints (SHA-256 by default), and every engine diagnostic. extension:'subjectAltName' returns that one extension. issuer or checkSelfSignature:true adds a signature check — ONE signature against ONE key, which is NOT trust: verify_certificate_chain is the RFC 5280 §6 verdict (anchors, validity at an instant, names, policies, revocation). Token-frugal: verbosity:'summary', fields:[…]. Input: pem / derBase64 / path.

Input Schema

Name	Required	Description	Default
`fields`	No	Dot-paths to keep after verbosity (arrays map over elements); unmatched paths land in _meta.unmatchedFields.
`issuer`	No	The issuer certificate to check the signature against: exactly one of pem / derBase64 / path. Exclusive with checkSelfSignature. A valid signature is NOT trust: run verify_certificate_chain for that.
`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.
`extension`	No	Return only this decoded extension (NOT_FOUND when absent). Exclusive with rawExtensions.
`verbosity`	No	'summary' keeps the scalar fields only (token-frugal).	full
`certificate`	Yes	The certificate (CERTIFICATE PEM or DER): exactly one of pem / derBase64 / path.
`fingerprints`	No	Digests of the DER to report.
`encodingRules`	No	'der' (strict X.690 DER, default) or 'ber' (indefinite / non-minimal lengths and constructed strings, as legacy CMS producers write).	der
`rawExtensions`	No	Keep every extension undecoded (kind raw, valueDer as hex) — the way past PKI_X509_EXTENSION_MALFORMED.
`checkSelfSignature`	No	Check the certificate against its own key (a self-signed root). Exclusive with issuer.
`requireAlgorithmMatch`	No	Require the outer signatureAlgorithm to equal the TBS signature algorithm (RFC 5280 §4.1.1.2).

Output Schema

Name	Required	Description
`issuer`	No
`subject`	No
`version`	No
`notAfter`	No
`validity`	No
`extension`	No	The one extension asked for with `extension`.
`notBefore`	No
`publicKey`	No
`signature`	No	The signature check asked for (issuer or self). ONE signature against ONE key — not a trust verdict.
`sizeBytes`	No
`extensions`	No
`selfIssued`	No	issuer DER equals subject DER (self-issued; a self-SIGNATURE is a separate check).
`diagnostics`	No	Non-fatal concerns the engine raised (PKI_DIAG_*, de-duplicated, at most 200; explain_code explains one).
`fingerprints`	No	Colon-separated uppercase hex digests of the DER, by algorithm.
`issuerString`	No	RFC 4514 issuer.
`serialNumber`	No
`subjectString`	No	RFC 4514 subject.
`extensionKinds`	No
`signatureValid`	No
`diagnosticCount`	No
`serialNumberHex`	No
`diagnosticCounts`	No	Occurrences per diagnostic code.
`signatureAlgorithm`	No
`diagnosticsTruncated`	No	true when distinct diagnostics beyond the 200 listed were dropped.
`subjectPublicKeyInfo`	No

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior, and the description adds substantial context beyond them: one-call reporting, engine diagnostics, the rawExtensions escape hatch for malformed extensions, and an explicit warning that signature checking is not trust validation. No contradiction with annotations.

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 description is front-loaded with the report contents and remains dense with useful information throughout. It is a single long run-on paragraph, but nearly every clause earns its place and supports correct tool selection or invocation.

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 the rich schema, existing output schema, and annotations, the description is complete enough for correct invocation. It covers input modes, key optional behaviors, token-frugal options, diagnostics, and the critical distinction from chain verification.

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, but the description adds useful semantics for choosing extension, issuer, checkSelfSignature, verbosity, fields, and the pem/derBase64/path input modes. It does not fully explain every one of the 14 parameters, but it adds meaningful meaning beyond 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?

The description states a specific verb and resource: a read-only RFC 5280 report of ONE certificate in one call. It enumerates the reported fields and explicitly distinguishes itself from verify_certificate_chain, so an agent can identify it 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 Guidelines5/5

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

It explicitly says what this tool is not for: the signature check is ONE signature against ONE key and is NOT trust, and verify_certificate_chain is named as the RFC 5280 §6 verdict alternative. It also gives concrete when-to-use guidance for extension, issuer, checkSelfSignature, verbosity, and fields.

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