Skip to main content
Glama
Sign In
Post-Quantum Cryptography MCP Server

Post-Quantum Cryptography MCP Server

by scottdhughes
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

pqc_hybrid_auth_verify

Verify sender signatures and fingerprint binding on sealed envelopes without decryption or secret keys, including ML-DSA-65 checks and timestamp freshness.

Instructions

Verify sender signature on an authenticated envelope WITHOUT decrypting. No secret keys needed. Checks sender binding, fingerprint consistency, ML-DSA-65 signature, and timestamp freshness.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "envelope": "<envelope>"
    },
    "name": "pqc_hybrid_auth_verify"
  }
}

Input Schema

NameRequiredDescriptionDefault
envelopeYesAuthenticated envelope from pqc_hybrid_auth_seal
max_age_secondsNoMax envelope age in seconds for freshness check (default 86400 = 24h; must be positive). v2 envelopes have signed timestamps; v1 envelopes skip freshness regardless. Clock skew tolerance: 5 min.
expected_sender_public_keyNoBase64-encoded ML-DSA-65 public key (exactly one of this or expected_sender_fingerprint required)
expected_sender_fingerprintNoSHA3-256 hex fingerprint of sender public key

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.10.0

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full burden. It does disclose useful behavior beyond the schema: it is non-decrypting, requires no secret keys, and enumerates the four checks performed. However, it never says what a failed verification looks like (raised error vs. a false/negative result), nor that the operation is read-only and side-effect free.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the primary action and the critical 'WITHOUT decrypting' qualifier, followed by authentication requirements and the enumerated checks. No filler and nothing to trim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a verification tool with no output schema, the description should indicate what the caller receives and how failure surfaces; it instead only implies the checks that presumably map to results. The input side is fully covered by a rich schema, and the no-secret-key note covers the auth model, leaving a moderate gap on the return/failure contract.

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% and each parameter (envelope, max_age_seconds, expected_sender_public_key, expected_sender_fingerprint) is documented in the schema itself, including defaults, the v1/v2 freshness distinction, and the 'exactly one of' constraint. The description adds nothing parameter-specific beyond the general statement that no secret keys are required, so the baseline 3 applies.

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 ('Verify sender signature on an authenticated envelope') and immediately scopes it with 'WITHOUT decrypting', which separates it from pqc_hybrid_auth_open. The follow-on list of what is checked (sender binding, fingerprint consistency, ML-DSA-65 signature, timestamp freshness) makes the tool's job unambiguous 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'WITHOUT decrypting. No secret keys needed' gives a clear selection signal: use this when you only need sender authenticity and hold no secret material, versus the open/decrypt path. It stops short of naming pqc_hybrid_auth_open or pqc_verify as the explicit alternative, so there is no hard exclusion rule.

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