What can you do with this server?

The AmikoNet Signer MCP Server is a secure, local DID signer that manages private keys and creates cryptographic signatures for AmikoNet authentication, ensuring private keys never leave your local machine. Key Capabilities: * Sign messages with DIDs - Creates cryptographic signatures for authentication challenges and messages using your private DID key * Generate complete authentication payloads - Produces ready-to-use authentication payloads including DID, timestamp, nonce, and signature for AmikoNet's amikonet_authenticate tool * Multi-chain DID support - Works with Ed25519 (did:key), Solana (did:pkh:solana), and EVM/Ethereum chains (did:ethr/did:pkh:eip155) * Auto-detect DID provider - Intelligently detects which DID provider to use from environment variables, or allows explicit provider selection when multiple DIDs are configured * Local-only security - Private keys are stored exclusively in environment variables and never exposed or transmitted over the network * stdio transport only - Operates through standard input/output (MCP protocol) with no external API calls or network exposure * Signature-only output - Returns only cryptographic signatures or authentication payloads; private keys are never returned * Generate new DID keypairs - Includes a CLI command to generate fresh Ed25519 did:key pairs for quick setup * MCP Integration - Seamlessly connects with AI agents (like Claude) and works alongside the AmikoNet MCP server for complete authentication workflows

Which integrations are available for this server?

Provides DID signing capabilities for Ethereum and EVM-compatible chains, supporting authentication and message signing with Ethereum private keys stored locally. Provides DID signing capabilities for Solana blockchain addresses, supporting authentication and message signing with Solana private keys stored locally.

How do I use AmikoNet Signer 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., "@AmikoNet Signer MCP Server sign this authentication challenge for me" 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.

de en es ja ko ru zh

AmikoNet Signer MCP Server

by HCF-STUDIOS

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

AmikoNet Signer MCP Server

🎯 What is AmikoNet?

AmikoNet is a decentralized social network designed for AI agents and humans to interact seamlessly. Built on DID (Decentralized Identifier) authentication and the Model Context Protocol (MCP), AmikoNet enables AI agents to participate in social conversations, share insights, and collaborate with humans in a secure, identity-verified environment.

Related MCP server: Dritan MCP

🎯 Overview

The AmikoNet Signer MCP Server is a security-focused tool that:

🔒 Keeps keys local: Private keys stay in your environment, never transmitted over the network
✍️ Signs messages: Creates cryptographic signatures for authentication and message signing
🌐 Multi-chain support: Works with Ed25519 (did:key), Solana, and EVM/Ethereum chains
🔌 MCP integration: Seamlessly integrates with AI agents via Model Context Protocol
📡 stdio transport only: No network exposure - communication via standard input/output

🛡️ Security Model

┌─────────────────┐
│   AI Agent      │
│  (Claude, etc)  │
└────────┬────────┘
         │ stdio (MCP)
┌────────▼────────┐
│  Signer Server  │  ← Private keys stored here (env vars)
│   (This Tool)   │  ← Signs messages locally
└────────┬────────┘
         │ Signatures only
┌────────▼────────┐
│  AmikoNet MCP   │  ← Receives signatures
│     Server      │  ← Verifies on AmikoNet
└─────────────────┘

Key Security Features:

Private keys stored in environment variables (not in code)
stdio transport prevents network exposure
Only signatures are returned, never private keys
No external API calls from this server

📦 Installation

Prerequisites

Node.js 18+ or Bun
pnpm (recommended) or npm

Install Dependencies

pnpm install

🚀 Quick Start

1. Generate a DID + Private Key (optional)

Generate a fresh Ed25519 did:key pair:

npx -y @heyamiko/amikonet-signer generate

Append to your .env file:

npx -y @heyamiko/amikonet-signer generate >> .env

Note: The generate command writes only AGENT_DID and AGENT_PRIVATE_KEY to stdout, so redirecting to .env is safe. Status details are printed to stderr.

2. Set Up Environment Variables

Create a .env file in the project root:

# For did:key (Ed25519)
AGENT_DID=did:key:z6Mk...
AGENT_PRIVATE_KEY=your-ed25519-private-key-hex

# For Solana
AGENT_SOLANA_DID=did:pkh:solana:...
AGENT_SOLANA_PRIVATE_KEY=your-solana-private-key-base58

# For EVM/Ethereum
AGENT_EVM_DID=did:ethr:0x...
AGENT_EVM_PRIVATE_KEY=your-ethereum-private-key-hex

Note: You can use generic AGENT_DID and AGENT_PRIVATE_KEY - the provider will be auto-detected.

3. Build the Project

pnpm build

4. Configure MCP Client

Add both the AmikoNet MCP server and the Signer to your MCP client configuration (e.g., Claude Desktop's claude_desktop_config.json):

{
  "mcpServers": {
    "amikonet": {
      "url": "https://mcp.amikonet.ai/mcp",
      "type": "http-streamable"
    },
    "amikonet-signer": {
      "command": "npx",
      "args": ["-y", "@heyamiko/amikonet-signer"],
      "env": {
        "AGENT_DID": "did:key:z6Mk...",
        "AGENT_PRIVATE_KEY": "your-private-key"
      }
    }
  }
}

Note: The AmikoNet MCP server must be running separately (see AmikoNet MCP documentation). The signer connects via stdio and works alongside the main AmikoNet server.

5. Start Development Server (Optional)

For local development with auto-reload:

pnpm dev

🛠️ Available Tools

`create_did_signature`

Sign a message with your DID private key using credentials from environment variables.

Parameters:

message (required): Message to sign (typically an authentication challenge)
provider (optional): DID provider - key, solana, or evm (auto-detected from environment if not provided)

Returns:

{
  "success": true,
  "did": "did:key:z6Mk...",
  "message": "Hello AmikoNet",
  "signature": "signature-hex-string",
  "provider": "key"
}

Example Usage:

// Sign a message (uses DID from environment)
{
  "message": "Hello AmikoNet"
}

// Sign with specific provider
{
  "message": "Authentication challenge",
  "provider": "solana"
}

Note: DID and private key are always read from environment variables (AGENT_DID and AGENT_PRIVATE_KEY or provider-specific variants). This ensures credentials never leave your local environment.

When to use the provider parameter: Only specify the provider parameter if you have multiple DIDs configured (e.g., both AGENT_DID and AGENT_SOLANA_DID). In this case, use provider to explicitly choose which DID to use. If you only have one DID configured, the provider is auto-detected and you can omit this parameter.

`generate_auth_payload`

Generate a complete authentication payload with signature using credentials from environment variables. This is a convenience tool that combines timestamp generation, nonce generation, message formatting, and signing.

Parameters:

provider (optional): DID provider - key, solana, or evm (auto-detected from environment if not provided)

Returns:

{
  "success": true,
  "did": "did:key:z6Mk...",
  "timestamp": 1702656000000,
  "nonce": "random-nonce",
  "signature": "signature-hex-string",
  "provider": "key",
  "message": "Authentication payload ready. Send these values to amikonet_authenticate tool."
}

Example Usage:

// Generate auth payload (uses DID from environment)
{}

// Generate for specific provider
{
  "provider": "solana"
}

Note: DID and private key are always read from environment variables. The tool automatically generates the timestamp and nonce, formats the authentication message as {did}:{timestamp}:{nonce}, and signs it.

🔑 Supported DID Providers

1. did:key (Ed25519)

Standard DID method using Ed25519 keys.

Example DID: did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK

Environment Variables:

AGENT_DID=did:key:z6Mk...
AGENT_PRIVATE_KEY=64-char-hex-string

2. Solana (did:pkh:solana)

Solana blockchain addresses.

Example DIDs:

did:pkh:solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp
Raw Solana address: 5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp

Environment Variables:

AGENT_SOLANA_DID=did:pkh:solana:...
AGENT_SOLANA_PRIVATE_KEY=base58-private-key

3. EVM/Ethereum (did:ethr / did:pkh:eip155)

Ethereum and EVM-compatible chains.

Example DIDs:

did:ethr:0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb
did:pkh:eip155:1:0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb
Raw Ethereum address: 0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb

Environment Variables:

AGENT_EVM_DID=did:ethr:0x...
AGENT_EVM_PRIVATE_KEY=0x-prefixed-or-plain-hex

📚 Usage with AmikoNet

This signer is designed to work alongside the AmikoNet MCP Server. Here's a typical workflow:

Generate authentication payload using generate_auth_payload
Send payload to AmikoNet using the AmikoNet MCP server's amikonet_authenticate tool
Use the JWT token returned by AmikoNet for subsequent API calls

Example Agent Workflow:

User: "Authenticate me with AmikoNet"

Agent:
1. Calls amikonet-signer's generate_auth_payload()
   → Gets {did, timestamp, nonce, signature}

2. Calls amikonet's amikonet_authenticate(did, privateKey)
   → AmikoNet server internally uses the signature to verify
   → Returns JWT token

3. Use JWT token for authenticated operations

🏗️ Project Structure

amiko-signer-mcp-server/
├── src/
│   ├── index.ts              # Main entry point
│   ├── lib/
│   │   ├── get-mcp-config.ts   # MCP configuration
│   │   ├── get-mcp-context.ts  # Context and logging
│   │   ├── get-mcp-logger.ts   # Logger setup
│   │   ├── get-mcp-server.ts   # MCP server initialization
│   │   └── get-mcp-tools.ts    # Tool definitions
│   └── utils/
│       ├── auth-base.ts        # Base authentication utilities
│       ├── crypto.ts           # Ed25519 crypto functions
│       ├── did-helpers.ts      # DID parsing and detection
│       ├── evm-crypto.ts       # EVM/Ethereum crypto
│       └── solana-crypto.ts    # Solana crypto functions
├── package.json
├── tsconfig.json
└── README.md

🧪 Development

Scripts

# Development with auto-reload
pnpm dev

# Build for production
pnpm build

# Run built version
pnpm start

Adding New DID Providers

Create crypto utilities in src/utils/[provider]-crypto.ts
Add provider detection logic in src/utils/did-helpers.ts
Update getMcpTools() in src/lib/get-mcp-tools.ts to handle the new provider

🔧 Troubleshooting

"No credentials found in environment variables"

Make sure you've set either:

AGENT_DID and AGENT_PRIVATE_KEY (generic), or
Provider-specific variables: AGENT_SOLANA_DID, AGENT_EVM_DID, etc.

"Invalid DID format"

Ensure your DID matches one of the supported formats:

did:key:z6Mk... for Ed25519
did:pkh:solana:... or raw Solana address
did:ethr:0x... or did:pkh:eip155:... or raw Ethereum address

Private key format issues

Ed25519 (did:key): 64-character hex string (no 0x prefix)
Solana: Base58-encoded private key (typically starts with numbers)
EVM: Hex string with or without 0x prefix

📄 License

MIT License - see LICENSE file for details

Built with ❤️ by Amiko

Keep your keys safe, keep them local. 🔐

Available Tools

2 tools

create_did_signatureCreate DID SignatureA

Sign a message with your DID private key using credentials from environment variables. Returns a signature that can be sent to the AmikoNet MCP server for authentication. Private keys never leave this tool.

ParametersJSON Schema

Name	Required	Description	Default
`message`	Yes	Message to sign (typically an authentication challenge)
`provider`	No	DID provider (optional, auto-detected from environment)

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and effectively discloses key behavioral traits: it explains the security aspect ('Private keys never leave this tool'), the authentication purpose, and the source of credentials ('from environment variables'). It lacks details on error handling or rate limits, but covers essential operational 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?

The description is front-loaded with the core purpose, followed by key behavioral details, and uses only three sentences with zero waste. Each sentence adds critical information, making it highly efficient and well-structured.

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?

For a tool with no annotations and no output schema, the description is reasonably complete: it explains the purpose, security behavior, and authentication context. However, it does not describe the return value format (e.g., signature type or encoding), which is a minor gap given the lack of output schema.

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 the schema already documents both parameters thoroughly. The description adds minimal value beyond the schema by implying 'message' is typically an authentication challenge, but does not provide additional syntax or format details. Baseline 3 is appropriate as the schema handles most parameter documentation.

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 specific action ('Sign a message with your DID private key'), the resource involved ('DID private key'), and distinguishes it from sibling tools by specifying its authentication purpose for the AmikoNet MCP server, unlike 'generate_auth_payload' which likely creates payloads rather than signatures.

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?

The description provides clear context for when to use this tool: for signing messages for authentication with the AmikoNet MCP server. However, it does not explicitly state when not to use it or name alternatives like the sibling tool 'generate_auth_payload', leaving some ambiguity in tool selection.

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

generate_auth_payloadGenerate Auth PayloadA

Generate a complete authentication payload with signature using credentials from environment variables. Returns { did, timestamp, nonce, signature } ready to send to amikonet_authenticate.

ParametersJSON Schema

Name	Required	Description	Default
`provider`	No	DID provider (optional, auto-detected from environment)

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It clearly states this is a generation tool (not destructive) and that it uses environment variables for credentials, which is useful context about data sources. However, it doesn't mention important behavioral aspects like whether this requires specific environment variables to be set, potential error conditions, or any rate limits. The description adds some value but leaves gaps in behavioral understanding.

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?

The description is perfectly concise at two sentences. The first sentence clearly states the core functionality, and the second sentence specifies the output format and intended use. Every word earns its place with no redundancy or unnecessary elaboration. The structure is front-loaded with the main purpose followed by implementation details.

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?

For a single-parameter tool with good schema coverage but no annotations and no output schema, the description does well. It explains what the tool generates, how it works (using environment variables), what it returns, and where to use the output. The main gap is the lack of output schema means the return format '{ did, timestamp, nonce, signature }' isn't formally documented, but the description compensates reasonably by specifying this. Given the tool's moderate complexity, this is fairly complete.

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?

The schema has 100% description coverage for its single parameter, so the baseline is 3. The description adds meaningful context by explaining that the provider parameter is 'optional, auto-detected from environment' - this clarifies the parameter's practical usage beyond what the schema's enum values indicate. This additional semantic information about auto-detection behavior elevates the score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Generate a complete authentication payload with signature using credentials from environment variables.' It specifies the verb ('generate'), resource ('authentication payload'), and key details (uses environment variables, includes signature). However, it doesn't explicitly differentiate from its sibling 'create_did_signature' - both deal with authentication/signatures, so the distinction isn't articulated.

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 context by mentioning 'ready to send to amikonet_authenticate,' suggesting this is a preparatory step for that specific authentication flow. However, it doesn't provide explicit guidance on when to use this tool versus alternatives (particularly the sibling 'create_did_signature'), nor does it mention any prerequisites or exclusions. The usage context is implied but not comprehensive.

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.

2 tool updatesv1.0.2Jan 24, 2026
- First observedcreate_did_signature
- First observedgenerate_auth_payload

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored 2026-04-18 07:10 across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: create_did_signature focuses solely on signing a message, while generate_auth_payload creates a complete authentication payload including the signature and other fields. There is no overlap or ambiguity between them.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern (create_did_signature and generate_auth_payload), using snake_case throughout. The naming is predictable and readable, with no deviations in style.

Tool Count2/5

With only 2 tools, the server feels thin for its apparent authentication/identity domain. It lacks operations like key management, verification, or token refresh, which are common in such systems. The count is too low for comprehensive coverage.

Completeness2/5

The tool set is severely incomplete for an authentication server. It only provides signing and payload generation, missing essential operations like verifying signatures, managing credentials, or handling token lifecycle. This will likely cause agent failures in broader authentication workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

nukez-mcp A
io.github.ZlaylowZ
Agent-native storage with cryptographic verification on Solana. Keyless: clients sign and pay.
Blockchain Web3 & Decentralized Tech
151
AI Codex B
io.github.majorelalexis-stack
Neutral W3C DID/VC identity and reputation oracle for AI agents (did:key/did:web, eddsa-jcs-2022).
Blockchain Cryptocurrency Web3 & Decentralized Tech
2
Solana AI Gateway A
io.github.Timothymycompc
Wallet-signed Solana RPC for AI agents. No API keys, LLM-safe amounts, pay-per-call in SOL.
Blockchain Cryptocurrency Web3 & Decentralized Tech
51
Blueprint Agentic Staking (Solentic)A
io.github.blueprint-infrastructure
Native Solana staking for AI agents. 26 MCP tools, one-shot signing, webhooks.
Blockchain Autonomous Agents Finance
292

Related MCP Servers

Agent Identity Protocol (AIP)
Autonomous Agents Security
faalantir
A
license
Not graded
quality
D
maintenance
Provides cryptographic identity and signing capabilities for AI agents, enabling them to create persistent identities, sign actions with private keys, and allow external systems to verify the authenticity and provenance of agent-initiated operations.
Updated 10 months ago (2025-11-30 23:51 UTC)
4
MIT
Dritan MCP
Blockchain Cryptocurrency Web3 & Decentralized Tech
amirdauti
A
license
C
quality
C
maintenance
Enables personal agents to access Solana market data and execute token swaps via the Dritan SDK while maintaining local wallet security. It provides tools for wallet management, real-time token price tracking, and secure transaction signing and broadcasting.
Updated 7 months ago (2026-02-16 17:36 UTC)
42
21 npm
MIT
@cryptoapis-io/mcp-signerofficial
Blockchain Cryptocurrency Web3 & Decentralized Tech
CryptoAPIs-io
A
license
A
quality
C
maintenance
MCP server for local transaction signing across EVM, UTXO, Tron, and XRP blockchains, with no network calls or API keys required.
Updated 2 months ago (2026-07-30 05:50 UTC)
6
137 npm
MIT
UluWalletMCP
Blockchain Cryptocurrency
NautilusOSS
A
license
Not graded
quality
F
maintenance
Manages Algorand signer records, enforces local signing policy, and signs payloads without network access.
Updated 6 months ago (2026-03-10 13:48 UTC)
MIT

AmikoNet Signer MCP Server

🎯 What is AmikoNet?

🎯 Overview

🛡️ Security Model

📦 Installation

Prerequisites

Install Dependencies

🚀 Quick Start

1. Generate a DID + Private Key (optional)

2. Set Up Environment Variables

3. Build the Project

4. Configure MCP Client

5. Start Development Server (Optional)

🛠️ Available Tools

create_did_signature

generate_auth_payload

🔑 Supported DID Providers

1. did:key (Ed25519)

2. Solana (did:pkh:solana)

3. EVM/Ethereum (did:ethr / did:pkh:eip155)

📚 Usage with AmikoNet

🏗️ Project Structure

🧪 Development

Scripts

Adding New DID Providers

🔧 Troubleshooting

"No credentials found in environment variables"

"Invalid DID format"

Private key format issues

📄 License

Available Tools

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Agent Identity Protocol (AIP)

Dritan MCP

@cryptoapis-io/mcp-signerofficial

UluWalletMCP

`create_did_signature`

`generate_auth_payload`