- Home
- MCP servers
- AmikoNet Signer
AmikoNet Signer
- typescript
0
GitHub Stars
typescript
Language
6 months ago
First Indexed
3 months ago
Catalog Refreshed
Documentation & install
Readme and setup notes from the catalogue, plus a client-ready config you can copy for your MCP host.
You use the AmikoNet Signer MCP Server to securely sign messages and authentication data for AmikoNet while keeping all private keys on your machine. It integrates with the Model Context Protocol (MCP) and communicates through stdio, so your keys never leave your environment and you maintain full control over cryptographic signing.
How to use
You will run the signer alongside the AmikoNet MCP Server. The signer provides signatures for authentication and message signing while your private keys stay local. Your MCP client will request signatures via the MCP channel, and the signer will return only the signatures.
Typical workflow with your MCP client looks like this: you generate a signing payload using the signer, send the payload to AmikoNet for verification, and receive a JWT or similar authenticated token to use in subsequent requests. All cryptographic material remains in your environment; no private keys or sensitive data are transmitted over the network.
How to install
Prerequisites you need before installing: you must have Node.js 18+ or Bun installed, and a package manager such as pnpm or npm.
Install dependencies for the project with your preferred package manager.
pnpm install
Build the project so you can run the local signer.
pnpm build
Configure the MCP client to connect to the AmikoNet MCP Server and include the signer as a stdio-based MCP tool.
{
"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"
}
}
}
}
Start the development environment to run locally with auto-reload if you are actively developing.
pnpm dev
Additional notes and setup details
Environment variables define which DIDs and private keys you will use. The signer supports did:key (Ed25519), Solana, and EVM/Ethereum providers. You may set either provider-specific variables or generic ones; the provider will be auto-detected if only generic variables are present.
The signer communicates strictly via stdio and returns only signatures, never exposing private keys or enabling external API calls. This preserves a strong security boundary for your signing operations.
Security model highlights include local key storage in environment variables, a stdio transport to prevent network exposure, and no outbound API calls from the signer.
Security model overview
Private keys are stored in environment variables rather than in code. Communication with the MCP ecosystem is via standard input/output, so there is no direct network exposure for signing operations. Only signatures are returned to the MCP client.
Troubleshooting
If you see a message about missing credentials, ensure you have either the generic environment variables AGENT_DID and AGENT_PRIVATE_KEY or the provider-specific variables such as AGENT_SOLANA_DID and AGENT_EVM_DID set.
If a DID format is reported as invalid, verify your DID matches one of the supported formats (did:key for Ed25519, did:pkh:solana or a Solana address, did:ethr/did:pkh:eip155 for Ethereum, or a raw address).
License
MIT License - see LICENSE file for details.
Available tools
create_did_signature
Sign a message with your DID private key using credentials from environment variables and return the signature along with the DID and provider used.
generate_auth_payload
Create a complete authentication payload with a signature, timestamp, and nonce using credentials from environment variables.