Which integrations are available for this server?

Provides key management for Bitcoin-related signing using secp256k1 algorithm. Provides key management for Ethereum-compatible signing using secp256k1, supporting Web3 and DID flows. Supports key generation and signing for WebAuthn using ECDSA P-256 (ES256).

How do I use local-kms-mcp-server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@local-kms-mcp-server Generate a new Ed25519 signing key for agent-1" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

local-kms-mcp-server

by Diegoescalonaro

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

local-kms-mcp-server

npm version License: MIT

Local-first, lightweight MCP server for per-agent key management.

Give every agent its own signing identity - without relying on external KMS or exposing private keys.

local-kms-mcp-server generates, stores, rotates, and uses signing keypairs entirely on the local machine. Keys never leave the process, never touch the network, and stay under control.

It’s built for MCP clients and agent runtimes that need isolated, composable identities for tasks such as DID/SSI flows, auth handshakes, challenge signing, and any workflow where agents must prove something cryptographically

What It Does

Generates signing keypairs scoped to a keyId (one identity per agent or task)
Stores keys locally using a simple file-based keystore
Signs base64 payloads without ever exposing private key material
Rotates keys safely while preserving algorithm consistency
Deletes keys with optional secure wipe (overwrite with random data)
Lists available signing algorithms and keys
Optionally encrypts keys at rest using AES-256-GCM
Runs over MCP via stdio (default) or HTTP when needed

Related MCP server: Agent Identity MCP Server

Supported Algorithms

Algorithm	Tool value	Notes
Ed25519	`ed25519`	Good default for general signing and DID-style use cases
ECDSA secp256k1	`ecdsa-secp256k1`	Common for Ethereum, Bitcoin, and other Web3 flows
ECDSA P-256	`ecdsa-prime256v1`	ES256, WebAuthn, and common cloud KMS compatibility
ECDSA P-384	`ecdsa-secp384r1`	Higher-security NIST P-384 environments

Requirements

Node.js >=24.0.0
An MCP client that supports stdio or HTTP MCP servers

Quick Start

Stdio transport

Use stdio when running from Claude Desktop, Cursor, or another local MCP client.

{
  "mcpServers": {
    "local-kms": {
      "command": "npx",
      "args": ["-y", "local-kms-mcp-server"],
      "env": {
        "STORE_PATH": "/Users/yourname/.local-kms",
        "ENCRYPT_STORE": "true",
        "STORE_ENCRYPTION_KEY": "<base64-32-byte-key>"
      }
    }
  }
}

HTTP transport

Use HTTP only when you explicitly want a local network endpoint.

TRANSPORT=http PORT=8080 npx local-kms-mcp-server

Endpoint:

POST http://localhost:8080/mcp

Installation

Run directly with npx:

npx -y local-kms-mcp-server

Or install globally:

npm install -g local-kms-mcp-server
local-kms-mcp-server

Configuration

Environment variable	Default	Description
`STORE_PATH`	`./keys`	Directory used for persisted key files
`TRANSPORT`	`stdio`	MCP transport: `stdio` or `http`
`PORT`	`8080`	HTTP port used only when `TRANSPORT=http`
`ENCRYPT_STORE`	`false`	Set to `true` or `1` to encrypt key files at rest
`STORE_ENCRYPTION_KEY`	none	Base64-encoded 32-byte key required when encryption is enabled

For local development there is an example file at .env.example, but for actual MCP client usage it is better to pass values through the client's env configuration so startup is deterministic.

Generate an encryption key:

node -e "console.log(require('node:crypto').randomBytes(32).toString('base64'))"

Tool Reference

All tool inputs are validated with Zod. Public keys and signatures are returned as base64 strings.

Tool	Purpose	Input	Output
`check_keypair`	Check whether a key exists	`{ "keyId": "agent-1" }`	`{ "exists": true }`
`list_keys`	List all stored key IDs	`{}`	`{ "keys": ["agent-1", "agent-2"] }`
`list_algorithms`	List all supported signing algorithms	`{}`	`{ "algorithms": ["ed25519", ...] }`
`generate_key`	Create and persist a new keypair	`{ "keyId": "agent-1", "algo": "ed25519" }`	`{ "publicKey": "..." }`
`get_key_info`	Return the stored public key for a key ID	`{ "keyId": "agent-1" }`	`{ "publicKey": "..." }`
`rotate_key`	Rotate an existing keypair using its stored algorithm	`{ "keyId": "agent-1" }`	`{ "newPublicKey": "..." }`
`delete_key`	Delete a keypair with optional secure wipe	`{ "keyId": "agent-1", "secureWipe": true }`	`{ "success": true }`
`sign_message`	Sign a base64-encoded payload	`{ "keyId": "agent-1", "message": "aGVsbG8=" }`	`{ "signature": "..." }`

Notes:

generate_key fails if the keyId already exists
rotate_key increments the stored version
delete_key with secureWipe: true overwrites the key file with random data before deletion
sign_message expects message to already be base64-encoded
sign_message accepts an optional algo override, but in normal usage the stored algorithm is usually what you want

Typical Usage Flow

Call list_algorithms to see available signing algorithms
Call generate_key for a new keyId
Call get_key_info to retrieve the public key for registration or distribution
Call sign_message whenever the agent needs to sign a challenge or payload
Call rotate_key when you need new key material for the same keyId
Call delete_key to securely remove a keypair when no longer needed
Call check_keypair or list_keys for inventory and existence checks

Example sign_message payload:

{
  "keyId": "key-1",
  "message": "eyJub25jZSI6IjEyMyJ9"
}

Storage Model

Unencrypted keys are stored as one file per key under ${STORE_PATH}:

${STORE_PATH}/${keyId}.json

Stored records contain:

{
  "keyId": "key-1",
  "algo": "ed25519",
  "publicKey": "...",
  "privateKey": "...",
  "version": 1,
  "createdAt": "2026-04-18T12:34:56.000Z"
}

When ENCRYPT_STORE=true, the file contents are encrypted and persisted as base64 ciphertext instead of plaintext JSON.

Security Notes

Private keys never leave the server through MCP responses
Key files are written with 0600 permissions
At-rest encryption is optional but recommended for anything beyond throwaway local development
HTTP mode does not add authentication or TLS by itself; keep it behind a trusted local boundary or your own reverse proxy
keyId values become filenames, so use stable, filesystem-safe IDs

Development

pnpm install
pnpm build
pnpm test
pnpm lint
pnpm format:check

Run locally after building:

pnpm start

Watch the built output during development:

pnpm start:dev

Extending With New Algorithms

Implement a new adapter by extending KeyAlgorithmAdapter
Register it in src/keystore/index.ts
Expose the adapter name through the relevant tool schema if users should be able to select it

import { KeyAlgorithmAdapter } from '../adapter.js';
import type { KeyPair } from '../types.js';

export class MyAdapter extends KeyAlgorithmAdapter {
  readonly name = 'my-algo';

  generate(): KeyPair {
    /* ... */
  }

  sign(privateKey: string, data: Buffer): string {
    /* ... */
  }

  verify(publicKey: string, data: Buffer, signature: string): boolean {
    /* ... */
  }

  rotate(_currentKeyPair: KeyPair): KeyPair {
    return this.generate();
  }
}

Project Layout

src/
  config/               environment parsing and validation
  keystore/             adapters, registry, and file-based storage
  tools/                MCP tool registration and handlers
  utils/                crypto helpers, errors, serializers
  server.ts             MCP server construction
  main.ts               stdio and HTTP entry point
test/                   unit tests

License

MIT

Available Tools

8 tools

check_keypairA

Check if a key pair exists for the given key ID

ParametersJSON Schema

Name	Required	Description	Default
`keyId`	Yes	Unique key identifier

Output Schema

ParametersJSON Schema

Name	Required	Description
`exists`	Yes	Whether a key pair exists for this key ID

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of disclosure. It implies a read-only existence check with no side effects, but does not explicitly state that it is non-destructive, idempotent, or what happens on missing keys (e.g., returns false vs throws error). The basic behavior is conveyed, but details are lacking.

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 description is a single concise sentence that front-loads the purpose. It earns its place but could benefit from slight restructuring to include behavioral cues. However, it is not verbose and avoids redundancy.

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

Completeness4/5

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

Given the low complexity of this tool (one parameter, boolean check) and the presence of an output schema (indicated by context signals), the description is nearly complete. It could explicitly mention the return type (e.g., boolean) but the output schema likely covers that. The description is sufficient for an agent to understand the tool's core function.

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% for the single parameter keyId, described as 'Unique key identifier'. The tool description adds no additional semantic context beyond what the schema already provides. Since coverage is high, 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 clearly states the verb 'Check' and the resource 'key pair existence' for a specific key ID. It distinguishes from sibling tools like get_key_info which likely returns full details, and delete_key/generate_key which are mutations. The purpose is unambiguous and immediately understandable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. For instance, it does not mention that get_key_info could provide full details or that this tool is suitable as a precondition check before generating or deleting a key. An agent would have to infer usage from the name alone.

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

delete_keyB

Delete a key pair from the keystore

ParametersJSON Schema

Name	Required	Description	Default
`keyId`	Yes	Unique key identifier
`secureWipe`	No	Overwrite key file with random data before deletion

Output Schema

ParametersJSON Schema

Name	Required	Description
`keyId`	Yes	The deleted key ID
`success`	Yes	Whether deletion was successful

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, and description fails to disclose that deletion is destructive and irreversible, or mention the secureWipe behavior which is critical for understanding side effects.

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?

Single concise sentence, no fluff. Slightly lacks context but remains efficient.

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

Completeness2/5

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

Given the tool is destructive and has an optional secureWipe parameter, the description lacks context about consequences, output, and when to use secureWipe. Output schema exists but is not referenced.

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 coverage is 100%, so baseline is 3. Description adds no extra meaning beyond what the schema provides for keyId and secureWipe.

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?

Description clearly states the action (delete) and resource (key pair), distinguishing it from sibling tools like check_keypair, generate_key, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives (e.g., when to delete vs rotate), or any prerequisites or warnings.

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

generate_keyA

Generate and store a new key pair for the given key ID

ParametersJSON Schema

Name	Required	Description	Default
`algo`	No	Key algorithm (default: ed25519)	ed25519
`keyId`	Yes	Unique key identifier

Output Schema

ParametersJSON Schema

Name	Required	Description
`publicKey`	Yes	Generated public key (base64-encoded DER/SPKI)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided; description only states 'generate and store' without disclosing overwrite behavior, authorization needs, or error handling. Minimal transparency for a mutation tool.

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?

Single sentence of 12 words, no fluff. Front-loaded with key action.

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?

Output schema exists but not shown; description omits what is returned or stored. For a tool with 7 siblings and complex operation, more context needed.

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 coverage is 100% with parameter descriptions; description adds no extra semantic value beyond schema. Baseline is 3.

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?

Description uses specific verb ('generate and store') and resource ('new key pair') with scope ('for given key ID'). Clearly distinguishes from sibling tools like check_keypair, delete_key, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Implies usage for creating new key pairs but lacks explicit guidance on when to use vs alternatives (e.g., rotate_key) or when not to use (e.g., if key ID exists).

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

get_key_infoB

Get the key pair information for the given key ID

ParametersJSON Schema

Name	Required	Description	Default
`keyId`	Yes	Unique key identifier

Output Schema

ParametersJSON Schema

Name	Required	Description
`algo`	Yes	The algorithm used for the key pair
`keyId`	Yes	The key ID for the stored key pair
`version`	Yes	The version of the key pair
`createdAt`	No	The creation date of the key pair
`publicKey`	Yes	The public key information for the given key ID

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It lacks details on read-only nature, authentication needs, error behavior (e.g., if keyId doesn't exist), or any side effects. The description is too minimal to inform an agent about behavioral traits.

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 description is a single sentence that directly conveys the purpose. No extraneous information. However, it could be more structured (e.g., listing constraints or outputs) without harming conciseness.

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?

Given the tool's low complexity (1 parameter, output schema exists), the description is adequate but lacks usage guidelines and behavioral transparency. It covers the core action but leaves gaps that might confuse agents.

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?

The schema covers the single parameter with a description 'Unique key identifier'. The description does not add further meaning beyond what the schema provides. With 100% schema coverage, 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 clearly states the action ('Get'), the resource ('key pair information'), and the parameter ('given key ID'). It effectively distinguishes from sibling tools like 'delete_key' or 'generate_key' by indicating this is a read-only retrieval operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies usage for retrieving key info, but does not explicitly state when to use this tool over alternatives like 'list_keys' or 'check_keypair'. No when-not-to-use or prerequisites are provided.

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

list_algorithmsA

List all supported signing algorithms

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`algorithms`	Yes	List of supported algorithm names

TDQS

A4/5.0

Behavior3/5

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

Describes a read-only operation, but lacks details on whether the list is live, cached, or requires any permissions. No annotations to supplement.

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?

Single sentence, front-loaded with purpose, no wasted words.

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

Completeness4/5

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

Tool is simple, with an output schema available. Description is brief but adequate for a straightforward list operation.

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?

No parameters, so schema coverage is 100%. The description adds no extra meaning, but baseline for 0 params is 4.

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?

Clearly states the verb 'List' and the resource 'all supported signing algorithms'. Distinguishes from sibling tools that deal with key management.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Does not explicitly state when to use this tool versus alternatives, but the purpose is clear enough that an agent would know to use it before other algorithm-dependent operations.

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

list_keysA

List all key pairs in the key store

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`keys`	Yes	The key IDs for all key pairs in the key store

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries a higher burden. It states a list operation, implying it is read-only, but does not explicitly confirm non-destructive behavior or any side effects. For a simple list with no parameters, this is minimally adequate.

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?

Single sentence that directly states the purpose with no extraneous information. Efficient and front-loaded.

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 simple list operation with zero parameters and an existing output schema, the description is sufficient. It does not need to explain return values because the output schema handles that.

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?

No parameters exist, so the description does not need to add parameter info. The input schema covers 100% of parameters (none), so the description adds value by clarifying the operation scope.

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?

Description clearly states 'List all key pairs in the key store', specifying the verb (list) and resource (key pairs). It distinguishes from siblings like check_keypair, delete_key, and generate_key.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like get_key_info or check_keypair. The description does not mention when not to use it or provide context for selection.

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

rotate_keyB

Rotate the key pair for the given key ID, preserving the existing algorithm

ParametersJSON Schema

Name	Required	Description	Default
`keyId`	Yes	Unique key identifier

Output Schema

ParametersJSON Schema

Name	Required	Description
`newPublicKey`	Yes	New public public key after rotation (base64-encoded DER/SPKI)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, description must disclose side effects. It only mentions algorithm preservation but omits critical behavioral traits: whether old key is invalidated immediately, if active sessions/signatures are affected, or required permissions. This is insufficient for a security-sensitive mutation.

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?

Single sentence with no wasted words. However, the sentence could be restructured to front-load key information; it is acceptable but not perfectly optimized.

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

Completeness2/5

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

The description is too minimal for a key rotation operation. Despite presence of an output schema (not shown), it fails to mention return values, preconditions, or post-conditions. Leaves agent uncertain about the tool's impact and output.

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 covers 100% of parameters with a description ('Unique key identifier'). The tool description adds no extra meaning beyond restating the schema's purpose. Baseline of 3 is appropriate given high schema coverage.

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?

Description clearly states the action (rotate), resource (key pair), scope (by key ID), and constraint (preserve algorithm). It distinguishes from siblings like generate_key (creates new), delete_key (removes), and sign_message (uses key).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

No guidance on when to rotate vs alternatives (e.g., generate new key, check key health). The description does not mention prerequisites, best practices, or disclaimers for using this tool over others.

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

sign_messageB

Sign a base64-encoded message with the stored private key

ParametersJSON Schema

Name	Required	Description
`algo`	No	Override algorithm (uses stored algo if omitted)
`keyId`	Yes	Unique key identifier
`message`	Yes	Base64-encoded message to sign

Output Schema

ParametersJSON Schema

Name	Required	Description
`signature`	Yes	Base64-encoded signature

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden. It only states the operation without disclosing side effects, return format, or security requirements (e.g., key permissions). Minimal behavioral context.

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?

A single sentence with no unnecessary words. Front-loaded with the verb and resource. Efficient and to the point.

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

Completeness2/5

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

Despite having an output schema and 3 parameters, the description does not mention what the tool returns or the need for the key to be accessible. For a signing operation, more completeness (e.g., algorithm behavior, error conditions) is expected.

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%; the description repeats 'base64-encoded message' from the schema but adds no new meaning. Baseline 3 applies as schema already documents parameters adequately.

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 clearly states the action (sign), the resource (base64-encoded message), and the key used (stored private key). It distinguishes from sibling tools like 'generate_key' (creates keys) and 'delete_key' (removes keys).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives (e.g., check_keypair, rotate_key). It lacks prerequisites (e.g., key must exist) or exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv1.1.0May 26, 2026
- First observedcheck_keypair
- First observeddelete_key
- First observedgenerate_key
- First observedget_key_info
- First observedlist_algorithms
- First observedlist_keys
- First observedrotate_key
- First observedsign_message

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored 2026-05-26 17:40 across 8 tools

Disambiguation5/5

Each tool has a distinct purpose: checking existence, deleting, generating, getting info, listing algorithms, listing keys, rotating, and signing. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, such as generate_key, list_keys, rotate_key, etc. No deviations.

Tool Count5/5

8 tools is within the ideal range (3-15) for a KMS server, covering key lifecycle and signing without bloat or scarcity.

Completeness4/5

The tool set covers key generation, deletion, rotation, listing, info retrieval, and signing. Missing encrypt/decrypt or import/export, but core key management is well-covered for a signing-focused KMS.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Proofable MCPOAuth
io.github.proofable
Hosted MCP server for AI agent identity, permissions, verification, and reusable proof.
Security Agent Orchestration Autonomous Agents
1
MANDATE Credential Broker B
io.github.projetnanocorp
MCP server for mandates, delegation, policy-gated execution, credential grants, and audit.
Security
111
AgentLux B
io.github.agentlux
Hosted AgentLux MCP server for marketplace, identity, creator, services, and social flows.
Agent Orchestration Autonomous Agents Social Media
7921
Word Of Clout ACN MCP Server
io.github.wordofclout
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
CRM Customer Data Platforms
2

Related MCP Servers

aip-identity
Autonomous Agents Security
The-Nexus-Guard
A
license
A
quality
D
maintenance
MCP server for AI agent identity — verify agents with Ed25519 signatures, check trust scores, sign and verify content, exchange encrypted messages. Built on the Agent Identity Protocol (AIP).
Updated 6 months ago (2026-03-09 12:03 UTC)
8
MIT
Agent Identity MCP Server
Security Autonomous Agents
AiAgentKarl
A
license
Not graded
quality
D
maintenance
MCP Server for AI agent identity and authorization. Create, verify, and manage agent identities with trust scores and scoped authorization tokens.
Updated 5 months ago (2026-04-03 16:05 UTC)
MIT
touchstone-mcpofficial
Security Autonomous Agents
Touchstone-CV
A
license
Not graded
quality
B
maintenance
Local MCP server that signs and records agent actions into a tamper-evident log using Ed25519 keys for frictionless integration with Touchstone.
Updated 10 days ago (2026-09-03 09:51 UTC)
29
Apache 2.0
fallpharm-mcp
Developer Tools App Automation
sjgant80-hub
A
license
Not graded
quality
C
maintenance
Provides a sovereign, MIT-licensed MCP server for professional-service workflows, running entirely on your infrastructure with Ed25519 cryptographic signing for every action.
Updated a month ago (2026-08-17 17:10 UTC)
MIT

local-kms-mcp-server

What It Does

Supported Algorithms

Requirements

Quick Start

Stdio transport

HTTP transport

Installation

Configuration

Tool Reference

Typical Usage Flow

Storage Model

Security Notes

Development

Extending With New Algorithms

Project Layout

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

touchstone-mcpofficial