pkinative-mcp

Overview Schema Source Related Servers Discussions Admin

Describe engine & server capabilities

describe_engine

Read-onlyIdempotent

Run an offline, no-input preflight to report engine/server/API versions, Web Crypto capabilities, limits, caps, error codes, and doctrine refusals, then interpret ceiling refusals in PKI sessions.

Instructions

Offline preflight (no input needed): server / engine / tool-API versions, whether this host's Web Crypto can verify, sign and decrypt (canVerify / canSign / canDecrypt) and satisfies the engine's Node floor, where randomness comes from, the engine's 22 default limits, the operator ceilings (PKINATIVE_MCP_MAX_INPUT_BYTES, PKINATIVE_MCP_MAX_KDF_ITERATIONS, PKINATIVE_MCP_MAX_PATHS_EXPLORED), every server cap, the sandbox / cache / PKINATIVE_MCP_AT state and the extension allow-lists, the 57 PKI_* error codes (with class), 43 PKI_REASON_* and 97 PKI_DIAG_* codes, the wrapper codes, the purposes and key-usage names, the doctrine refusals (what this server will NOT do and the remedy) and the engine surface deliberately not exposed as inputs. network is always 'none'. Call it first in a session, or whenever a cap / ceiling refusal needs interpreting.

Input Schema

Name	Required	Description	Default
`fields`	No	Dot-paths to keep after verbosity (arrays map over elements); unmatched paths land in _meta.unmatchedFields.
`verbosity`	No	'summary' keeps the scalar fields only (token-frugal).	full

Output Schema

Name	Required	Description	Default
`caps`	No
`engine`	No
`server`	No
`network`	No
`sandbox`	No
`ceilings`	No
`refusals`	No
`unexposed`	No
`randomness`	No
`registries`	No
`capabilities`	No
`defaultLimits`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 27, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false. Beyond that, the description adds substantive behavior: it is offline and needs no input, network is always 'none', and it exposes sandbox/cache/PKINATIVE_MCP_AT state, operator ceilings, doctrine refusals, and intentionally unexposed engine surface.

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 key framing, 'Offline preflight (no input needed)' and the first-call guidance, are front-loaded and the description is information-dense. However, it is a single enormous sentence bloated with exact inventory counts (22 limits, 57 PKI_* codes, 43 PKI_REASON_* codes, 97 PKI_DIAG_* codes) that do not help an agent select or invoke the tool and could be compressed.

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?

An output schema exists, so the description need not explain return values, and annotations cover the safety profile. The description still adds the offline/no-input behavior, the scope of exposed metadata, and the recommended first-call posture, making it complete for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both optional parameters ('fields' and 'verbosity') are already documented in the schema, including dot-path behavior and summary/full semantics. The description adds the 'no input needed' framing but does not add parameter-specific meaning beyond the schema; baseline 3 is appropriate.

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: an offline preflight describing server, engine, and tool-API capabilities. It enumerates the capability domains (versions, Web Crypto, limits, error codes, refusals) clearly enough that an agent can distinguish it from sibling tools such as inspect_certificate or explain_code.

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 gives explicit invocation guidance: 'Call it first in a session, or whenever a cap / ceiling refusal needs interpreting.' That covers both the primary use and a diagnostic fallback, which is unusually clear routing guidance.

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