pkinative-mcp

Overview Schema Source Related Servers Discussions Admin

Inspect CMS SignedData (RFC 5652 report, signers, attributes, signature values)

inspect_cms

Read-onlyIdempotent

Parse CMS SignedData from .p7s, .p7m, .p7b, PEM, or PDF /Contents to review signers, certificates, algorithms, attributes, and check one signer's signature against a supplied certificate.

Instructions

Read-only RFC 5652 report of ONE CMS SignedData (.p7s / .p7m / .p7b, CMS or PKCS7 PEM, or a PDF /Contents): version, content type, attached content length (null = detached), digest algorithms, the embedded certificates (subject / issuer / serial), CRL and OCSP counts, and every signer — identifier (issuer + serial or key id), algorithms, signing time as CLAIMED, ESS signing-certificate, CMSAlgorithmProtection, signed and unsigned attributes (oid, name, value count), counter time-stamp count and the signature value as hex (what a counter time-stamp stamps: fields:['signerInfos.signature'], hash it, create_timestamp_request digestHex). signerCertificate (+ signerIndex, and content for a signer without signed attributes) adds signerSignature.valid — ONE signer against ONE key, a key check and NOT the verdict: verify_cms judges trust, digests, time-stamps and revocation. Trailing bytes are refused unless allowTrailingData:true; BER producers need encodingRules:'ber'. Refuses: NOT_FOUND for a signerIndex past the last signer, PKI_* for an unreadable structure. Token-frugal: verbosity:'summary', fields:[…].

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[].
`content`	No	The detached content, for a signer WITHOUT signed attributes (such a signer signs the content itself); ignored otherwise: exactly one of text / base64 / path.
`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
`signedData`	Yes	The CMS SignedData (CMS / PKCS7 PEM, or DER: .p7s .p7m .p7b): exactly one of pem / derBase64 / path.
`signerIndex`	No	Which signer the signature check targets (encoded order; NOT_FOUND past the last).
`encodingRules`	No	'der' (strict X.690 DER, default) or 'ber' (indefinite / non-minimal lengths and constructed strings, as legacy CMS producers write).	der
`allowTrailingData`	No	Ignore bytes after the ContentInfo (the zero padding of a PDF /Contents). Default false: trailing bytes are PKI_ASN1_TRAILING_DATA.
`signerCertificate`	No	The certificate to check ONE signer's signature against: exactly one of pem / derBase64 / path. A valid signature is a key check, NOT trust: verify_cms is the verdict.

Output Schema

Name	Required	Description
`signers`	No
`version`	No
`crlCount`	No
`sizeBytes`	No
`contentType`	No
`diagnostics`	No	Non-fatal concerns the engine raised (PKI_DIAG_*, de-duplicated, at most 200; explain_code explains one).
`signerCount`	No
`signerInfos`	No
`certificates`	No	The embedded certificates (a claim by whoever assembled the message).
`contentLength`	No	Bytes of the encapsulated content; null when the signature is detached.
`contentTypeOid`	No
`diagnosticCount`	No
`signerSignature`	No	The signature check asked for with signerCertificate: ONE signer against ONE key. A key check, not the verdict (verify_cms).
`diagnosticCounts`	No	Occurrences per diagnostic code.
`digestAlgorithms`	No
`ocspResponseCount`	No
`diagnosticsTruncated`	No	true when distinct diagnostics beyond the 200 listed were dropped.
`signerSignatureValid`	No

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 cover read-only/idempotent safety, and the description adds real behavioral context on top: trailing bytes are refused by default, BER input needs an explicit flag, NOT_FOUND for an out-of-range signerIndex, PKI_* for unreadable structures, and the token-frugal verbosity/fields path. It doesn't discuss output shape or size limits on returned data, but with an output schema present that is forgivable.

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 resource and the payload of what is reported, and every clause is substantive rather than filler. The single dense paragraph with nested parentheticals, embedded call syntax and field paths is hard to scan, so it stops short of full marks.

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 12-parameter read tool with an output schema and annotations, nothing an agent needs is missing: input forms, report contents, the signature-check side path, error modes, encoding and trailing-data escape hatches, and token-frugality options. Return values are covered by the output schema, so the description doesn't need to repeat them.

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 baseline is 3; the description still adds value by tying parameters to a workflow — fields:['signerInfos.signature'] for the counter time-stamp digest, verbosity:'summary', signerIndex pointing at one signer, content only for signers without signed attributes. It restates a fair amount of what the schema already says (allowTrailingData, encodingRules), which keeps it off a 5.

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?

Names the exact operation (read-only RFC 5652 report of ONE CMS SignedData), enumerates the accepted input forms, and lists precisely what gets reported (signers, attributes, signature hex). It draws an explicit line against verify_cms, so an agent can distinguish it from the sibling 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?

Says when to reach for the signature check (signerCertificate + signerIndex, one signer, one key) and immediately states that this is not the verdict and that verify_cms judges trust, digests, time-stamps and revocation. It also names the triggering conditions for allowTrailingData (PDF /Contents padding) and encodingRules:'ber' (legacy producers), which is exactly the when-to-use guidance an agent needs.

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