pkinative-mcp

Overview Schema Source Related Servers Discussions Admin

Inspect CSR (RFC 2986 report, requested extensions, proof of possession)

inspect_csr

Read-onlyIdempotent

Decode a PKCS#10 certificate request to read its subject, public key, attributes and requested extensions, and verify its proof-of-possession signature before issuing a certificate.

Instructions

Read-only RFC 2986 report of ONE PKCS#10 certification request: subject (RFC 4514 + RDNs), public key (kind, bits, curve / modulus), every attribute, the extensions requested through extensionRequest decoded as a certificate's would be (rawExtensions:true keeps them undecoded), whether a challengePassword is present (never its text), the signature algorithm, and — by default (verify, one Web Crypto verification) — the proof of possession: signature.valid tells whether the request was signed by the key it carries, with reasons[] (PKI_REASON_SIGNATURE_NOT_CHECKED for SHA-1 without allowSha1:true). That is NOT trust: no CA signed a CSR, and a CA is free to ignore every extension it asks for. Pair with create_certificate (subjectPublicKey = the request) to issue from it. Token-frugal: verbosity:'summary' (subject, key kind, extension kinds, signatureValid), fields:[…]. Input: pem / derBase64 / path (.csr .p10 .der .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[].
`verify`	No	Verify the request's signature under the key it carries (proof of possession; one Web Crypto verification). false skips it.
`pemMode`	No	'strict' (RFC 7468 exactly, default) or 'lax' (tolerates whitespace, line length and RFC 1421 headers).	strict
`request`	Yes	The PKCS#10 request (CERTIFICATE REQUEST PEM or DER): exactly one of pem / derBase64 / path.
`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
`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 requested extension undecoded (kind raw, valueDer as hex) — the way past PKI_X509_EXTENSION_MALFORMED.

Output Schema

Name	Required	Description
`subject`	No
`version`	No	v1 (encoded 0), the only version RFC 2986 defines.
`publicKey`	No
`signature`	No	The proof of possession (verify:true): the signature under the key the request carries. Not trust — a CSR is unsigned by any CA.
`sizeBytes`	No
`attributes`	No	Every attribute in encoded order (extensionRequest, challengePassword, …).
`extensions`	No	The extensions requested through extensionRequest (RFC 2985 §5.4.2), decoded; null when the request asks for none. A CA is free to ignore them.
`diagnostics`	No	Non-fatal concerns the engine raised (PKI_DIAG_*, de-duplicated, at most 200; explain_code explains one).
`subjectString`	No	RFC 4514 subject.
`extensionKinds`	No
`signatureValid`	No
`diagnosticCount`	No
`diagnosticCounts`	No	Occurrences per diagnostic code.
`challengePassword`	No	Whether a challengePassword attribute is present (its text is attacker-controlled and never reported).
`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 read-only/idempotent/non-destructive, but the description adds material context beyond them: verify runs exactly one Web Crypto verification, signature.valid means signed-by-carried-key, PKI_REASON_SIGNATURE_NOT_CHECKED is emitted for SHA-1 without allowSha1, challengePassword text is never returned, and CSR extensions carry no CA authority. Those are precisely the behavioral caveats an agent needs and none are in the 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 definition is front-loaded with the report contents and ends with the token-frugal options and input forms, so scanning order is sound. The first sentence is a long comma-chained enumeration that runs on, and a few clauses (the RFC 4514 / modulus detail) could be trimmed without loss.

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 10-parameter, nested-input inspection tool with an output schema, the description covers everything an agent must know before calling: acceptable input encodings, PEM mode, default verification cost, degradation paths, and the trust caveat. Return-value shape is left to the output schema, which is the correct division of labor.

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 baseline is 3; the description earns above that by defining verbosity:'summary' contents (subject, key kind, extension kinds, signatureValid), the rawExtensions escape hatch, the three request input forms with typical file extensions, and the verify default. It does not touch limits, strict, pemMode, encodingRules, or allowSha1 semantics, so it is not exhaustive.

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 opens with a specific verb and resource: 'Read-only RFC 2986 report of ONE PKCS#10 certification request', then enumerates exactly what is reported (subject, public key, attributes, requested extensions, challengePassword presence, signature algorithm, proof of possession). That precision separates it from siblings like inspect_certificate and decode_asn1 without requiring the schema to be opened.

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 tells the agent when to reach for which mode: verbosity:'summary' for token-frugal calls, rawExtensions:true when PKI_X509_EXTENSION_MALFORMED blocks decoding, verify:false to skip proof of possession, and it names the follow-on sibling 'Pair with create_certificate (subjectPublicKey = the request) to issue from it'. It also warns what this tool is NOT (trust) so the agent does not use it as a substitute for chain validation.

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