Skip to main content
Glama
Nizoka

pkinative-mcp

by Nizoka
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Build certificate path (discovery to a trust anchor, signatures NOT checked)

build_certificate_path
Read-onlyIdempotent

Discovers which intermediate certificates a chain needs by building a structural path from a leaf certificate to your trust anchors. It reports the path found without verifying signatures.

Instructions

Path discovery only (RFC 5280 §6 path building): walks from leaf through the untrusted candidates to one of YOUR trustAnchors under the structural rules evaluated at at (validity, basic constraints, key usage, name constraints, the policy inputs; purposes steer discovery but the leaf's extended key usage is judged by verify_certificate_chain, not here) and reports the path it found, leaf first up to the anchor. NO signature is verified: the engine marks every link PKI_REASON_SIGNATURE_NOT_CHECKED, so valid is always false and the verdict of this tool is found (a path reached an anchor, structuralReasons empty); the leaf alone with PKI_REASON_NO_TRUST_ANCHOR when none did. Use it to learn which intermediates a chain needs, then validate_certificate_path (ordered path, signatures) or verify_certificate_chain (the full verdict with revocation). Never isError for a negative result. Pin at for a reproducible, cacheable result. Token-frugal: verbosity:'summary' (found, structuralReasonCodes, pathLength).

Input Schema

NameRequiredDescriptionDefault
atNoThe 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).
leafYesThe end-entity certificate to start from: exactly one of pem / derBase64 / path.
fieldsNoDot-paths to keep after verbosity (arrays map over elements); unmatched paths land in _meta.unmatchedFields.
limitsNoRaise 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.
policyNoRFC 5280 §6.1.1 policy inputs.
strictNoEscalate the first engine warning to a PKI_STRICT_DIAGNOSTIC error instead of listing it in diagnostics[].
pemModeNo'strict' (RFC 7468 exactly, default) or 'lax' (tolerates whitespace, line length and RFC 1421 headers).strict
purposesNoExtended key usages the leaf must allow: serverAuth, clientAuth, codeSigning, emailProtection, timeStamping, ocspSigning, any, or a dotted OID.
verbosityNo'summary' keeps the scalar fields only (token-frugal).full
candidatesNoUntrusted intermediate certificates the path may use (every PEM block of every item is taken). Optional; the certificates embedded in a CMS message are also candidates.
trustAnchorsYesTrust 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.
encodingRulesNo'der' (strict X.690 DER, default) or 'ber' (indefinite / non-minimal lengths and constructed strings, as legacy CMS producers write).der

Output Schema

NameRequiredDescriptionDefault
pathNoThe path found, leaf first, up to (and including) the trust anchor; the leaf alone (with the reason) when no anchor was reached.
foundNoA path from the leaf to one of the trust anchors was found and passes the structural rules (structuralReasons empty). This is the verdict of THIS tool; the signatures are not checked.
validNoThe engine verdict — always false here, because no signature was verified (PKI_REASON_SIGNATURE_NOT_CHECKED on every link). Read `found`.
reasonsNoWhy 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.
exploredNoCandidate paths explored (bounded by limits.maxPathsExplored).
pathLengthNo
diagnosticsNoNon-fatal concerns the engine raised (PKI_DIAG_*, de-duplicated, at most 200; explain_code explains one).
evaluatedAtNoThe ISO instant used — re-pass it as `at` to reproduce the result.
reasonCodesNo
diagnosticCountNo
diagnosticCountsNoOccurrences per diagnostic code.
evaluatedAtSourceNo
signaturesCheckedNoAlways false: run validate_certificate_path or verify_certificate_chain for the signatures.
structuralReasonsNoreasons[] without the PKI_REASON_SIGNATURE_NOT_CHECKED markers: what actually stopped the walk (empty when found).
diagnosticsTruncatedNotrue when distinct diagnostics beyond the 200 listed were dropped.
structuralReasonCodesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes far beyond the annotations (which only cover read-only/idempotent safety). It discloses that no signature is verified, that every link is marked PKI_REASON_SIGNATURE_NOT_CHECKED, that `valid` is therefore always false, that the verdict is `found` or PKI_REASON_NO_TRUST_ANCHOR, and that a negative result is never isError. These are the exact behavioral traps an agent would otherwise misread as failure.

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 purpose and the negative-result disclosure, then alternatives, then the token-frugal tip — an effective ordering. It is a single dense block with heavy parenthetical nesting, which costs some readability, but no sentence is filler.

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, deeply nested tool with an output schema, the description covers the one thing structure can't: that the verdict vocabulary here is `found`, not `valid`. Return shape is handled by the output schema and the description still calls out the summary-mode fields, so nothing an agent needs to invoke this 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 baseline is 3, but the description adds real nuance the schema does not: `purposes` only steer discovery while the leaf's EKU is judged by verify_certificate_chain, and `at` pinning buys cacheability. It also explains what verbosity:'summary' retains (found, structuralReasonCodes, pathLength).

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 — RFC 5280 §6 path building from `leaf` through untrusted `candidates` to the caller's `trustAnchors` — and explicitly scopes out signature checking. It names the sibling tools (validate_certificate_path, verify_certificate_chain) that do the other half of the job, so an agent can separate this tool from its neighbors without opening a 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?

Gives explicit when-to-use ("Use it to learn which intermediates a chain needs") and names the two successor tools with the conditions that select them: validate_certificate_path for ordered-path signature checks, verify_certificate_chain for the full verdict with revocation. It also adds an operational guideline — pin `at` for a reproducible, cacheable result.

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

Deploy Server

Other Tools