Packetrove

Certificate Bundle Checker

certificate-bundle

Read-onlyIdempotent

Use to inspect a supplied PEM certificate bundle before TLS configuration. Accept pem with 1–16 CERTIFICATE blocks and at most 49152 UTF-8 bytes, optional ASCII DNS hostname, and optional zero-based leafIndex. Reject private keys and unsupported blocks without echoing them. Return original certificate positions, Subject, Issuer, Common Name, SANs, validity, CA and Key Usage flags, SHA-256 fingerprints, independently checked candidate links, explicit leaf ambiguity, and stable findings with severity, observed evidence, and nextAction. Verify signatures cryptographically; name matching alone is not verification. Missing selected-leaf issuers and blocked requested hostname checks are warnings; other missing issuers are informational because roots are commonly omitted. All explicitly rejected supplied issuer candidates for the selected leaf produce an error. Unknown checks and key-identifier mismatches alone do not produce that error. A failed candidate does not invalidate another viable link. Verified self-issued CA key rollover is informational; verification with the certificate's own public key remains separate. Hostname checks use DNS SAN with one-label complete leftmost wildcards and no Common Name fallback. Results use this server's evaluation time and do not establish client trust, full RFC 5280 path validity, revocation status, or deployment safety. This remote call transmits certificates and hostname to the server; the website checks locally. Certificate input and details never enter application logs. Do not submit private keys. Operational events record the tool name, success or error, a controlled error code, and a traffic source classification. Verified automated checks may also record an automation run identifier. Events exclude inputs, results, raw request headers, and automation tokens. Cloudflare may attach platform metadata. Privacy policy: https://packetrove.com/privacy.

Input Schema

Name	Required	Description
`pem`	Yes	One or more PEM CERTIFICATE blocks, with only whitespace between blocks. At most 48 KiB of UTF-8 and 16 blocks. Private keys and other block types are rejected.
`hostname`	No	Optional ASCII DNS hostname, including pre-converted IDNA A-labels. No URL, port, IP address, or wildcard. Blank skips identity checking.
`leafIndex`	No	Zero-based original position of a non-CA certificate. Required to resolve multiple possible leaves for hostname checking.

Output Schema

Name	Required	Description
`findings`	Yes
`hostname`	Yes
`evaluatedAt`	Yes	Evaluation time from this runtime clock, not a deployment observation.
`leafIndexes`	Yes	First occurrences of distinct non-CA certificates; these are possible leaves, not a verified deployment selection.
`certificates`	Yes
`relationships`	Yes
`selectedLeafIndex`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 5, 2026

addedOutput schema / properties / certificates / items / properties / selfSignature / description

Added value: +"Verification with this certificate's own public key when Subject and Issuer names match. Failed or incomplete verification does not exclude a valid self-issued key-rollover certificate signed by a different key."

changedOutput schema / properties / findings / items / properties / code / enum

Previous value: -[
-  "DUPLICATE_CERTIFICATE",
-  "CERTIFICATE_EXPIRED",
-  "CERTIFICATE_NOT_YET_VALID",
-  "SELF_SIGNED_CERTIFICATE",
-  "SELF_SIGNATURE_FAILED",
-  "SIGNATURE_UNSUPPORTED",
-  "SIGNATURE_CHECK_UNAVAILABLE",
-  "ISSUER_NOT_IN_BUNDLE",
-  "CANDIDATE_SIGNATURE_FAILED",
-  "ISSUER_NOT_CA",
-  "ISSUER_KEY_USAGE_REJECTED",
-  "ISSUER_KEY_ID_MISMATCH",
-  "MULTIPLE_ISSUERS",
-  "LEAF_SELECTION_REQUIRED",
-  "NO_LEAF_CERTIFICATE",
-  "HOSTNAME_MATCH",
-  "HOSTNAME_MISMATCH"
-]New value: +[
+  "DUPLICATE_CERTIFICATE",
+  "CERTIFICATE_EXPIRED",
+  "CERTIFICATE_NOT_YET_VALID",
+  "SELF_SIGNED_CERTIFICATE",
+  "SELF_ISSUED_CERTIFICATE",
+  "SELF_SIGNATURE_FAILED",
+  "SIGNATURE_UNSUPPORTED",
+  "SIGNATURE_CHECK_UNAVAILABLE",
+  "ISSUER_NOT_IN_BUNDLE",
+  "LEAF_ISSUER_NOT_IN_BUNDLE",
+  "CANDIDATE_SIGNATURE_FAILED",
+  "LEAF_ISSUER_CANDIDATES_REJECTED",
+  "ISSUER_NOT_CA",
+  "ISSUER_KEY_USAGE_REJECTED",
+  "ISSUER_KEY_ID_MISMATCH",
+  "MULTIPLE_ISSUERS",
+  "LEAF_SELECTION_REQUIRED",
+  "NO_LEAF_CERTIFICATE",
+  "HOSTNAME_MATCH",
+  "HOSTNAME_MISMATCH"
+]

addedOutput schema / properties / findings / items / properties / severity / description

Added value: +"Error: a confirmed issue with identified certificates or all supplied issuer candidates for the selected leaf. Warning: a candidate issue or an incomplete requested check. Info: a structural or successful observation. No severity establishes client trust or invalidates every possible path."

AddedOct 4, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations cover only the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds substantial behavior beyond that: private keys and unsupported blocks are rejected without echoing, signature verification is cryptographic (name matching alone is not verification), and the warning/error semantics for missing issuers, blocked hostname checks, and rejected issuer candidates are spelled out. It also discloses what the result does NOT establish (client trust, RFC 5280 path validity, revocation, deployment safety), which is rare and valuable.

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?

The purpose and input rules are correctly front-loaded, but the paragraph is a dense wall that mixes invocation-critical rules with operational boilerplate (event fields, automation run identifiers, Cloudflare metadata, privacy policy URL) that an agent does not use when calling the tool. There is also redundancy, e.g. 'Reject private keys' restated as 'Do not submit private keys'. Correctly sized content is padded by material that does not earn its place.

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 high-complexity validation tool, the description covers everything needed to invoke it correctly: input block constraints, leaf disambiguation, hostname matching rules, and the full warning-vs-error decision surface. An output schema exists, so the description is not obligated to explain return values, and the extra detail it does give about findings and nextAction is incidental rather than a gap.

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 meaning: pem blocks are constrained to 1–16 blocks / 49152 UTF-8 bytes, hostname is ASCII DNS with IDNA A-labels and no URL/port/IP/wildcard, and leafIndex is tied to resolving multiple possible leaves for hostname checking. The hostname wildcard matching rule (one-label complete leftmost, no Common Name fallback) is semantics the schema does not carry.

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 concrete verb and resource: inspect a supplied PEM certificate bundle before TLS configuration. It is unmistakably distinct from the CIDR/IP networking siblings, and the scope (certificate blocks, hostname check, leaf selection) is stated up front rather than buried.

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 clear deployment context ('before TLS configuration') and implies the alternative path by noting 'the website checks locally'. It does not, however, state an explicit when-not condition or name an alternative tool the agent should prefer in any scenario, so it stops short of a 5.

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

All Packetrove tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.