AmikoNet Signer MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AGENT_DID | No | Your DID (Decentralized Identifier) - generic format that auto-detects provider | |
| AGENT_EVM_DID | No | Your EVM/Ethereum DID (e.g., did:ethr:0x... or did:pkh:eip155:... or raw Ethereum address) | |
| AGENT_SOLANA_DID | No | Your Solana DID (e.g., did:pkh:solana:... or raw Solana address) | |
| AGENT_PRIVATE_KEY | No | Your private key corresponding to AGENT_DID - format depends on DID type | |
| AGENT_EVM_PRIVATE_KEY | No | Your EVM/Ethereum private key in hex format (with or without 0x prefix) | |
| AGENT_SOLANA_PRIVATE_KEY | No | Your Solana private key in Base58 format |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| create_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. |
| generate_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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
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.
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.
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.
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.