SSIG MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SSIG_HOST | No | Bind address for the UI/API. Default is '127.0.0.1'. LAN mode accepts '0.0.0.0' or a private IPv4 address. | 127.0.0.1 |
| SSIG_PORT | No | UI/API port. Use '0' to choose a free port. Default is '3721'. | 3721 |
| SSIG_WEB_DIR | No | Override the static browser build location. Default is bundled 'dist/web'. | dist/web |
| SSIG_DATA_DIR | No | Persistent request-state directory. Default is '~/.ssig'. | ~/.ssig |
| SSIG_ALLOW_LAN | No | Required explicit opt-in for non-loopback binding. Set to 'true' to allow LAN access. | false |
| SSIG_PUBLIC_HOST | No | Exact RFC1918 address advertised and allowed in LAN mode. | |
| SSIG_EVM_RPC_URLS | No | JSON map of chain IDs to EVM RPC URLs for eth_call/eth_estimateGas fallback simulation. Example: '{"1":"https://ethereum.example/rpc"}' | |
| SSIG_REQUEST_LIMIT | No | Maximum retained requests; pending requests are never pruned. Default is '1000'. | 1000 |
| SSIG_SUI_GRPC_URLS | No | JSON map of Sui chain identifiers to gRPC endpoints for simulateTransaction. Example: '{"sui:mainnet":"https://fullnode.mainnet.sui.io:443"}' | |
| SSIG_SOLANA_RPC_URLS | No | JSON map of Solana chain identifiers to RPC URLs for simulateTransaction. Example: '{"solana:mainnet":"https://solana.example/rpc"}' | |
| SSIG_TENDERLY_ACCOUNT | No | Tenderly account name for EVM simulation. Must be used with SSIG_TENDERLY_PROJECT and SSIG_TENDERLY_ACCESS_KEY. | |
| SSIG_TENDERLY_PROJECT | No | Tenderly project name for EVM simulation. | |
| SSIG_REQUIRE_SIMULATION | No | When 'true', refuse requests when simulation is unavailable or errors. Default is 'false'. | false |
| SSIG_TENDERLY_ACCESS_KEY | No | Tenderly access key for EVM simulation. | |
| SSIG_BLOCK_FAILED_SIMULATION | No | When 'true', refuse to sign if simulation executes and reports failure. Default is 'true'. | true |
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 |
|---|---|
| request_evm_transactionA | Simulate and queue an EVM transaction for explicit browser-wallet approval. Never claims that a transaction is signed before the user approves it. asciiExplanation is mandatory, ASCII-only, and must explain amounts, destination, outcome, and risk. |
| request_solana_transactionA | Simulate and queue a serialized Solana transaction for explicit approval with a Wallet Standard browser extension. asciiExplanation is mandatory, ASCII-only, and must explain instructions, assets, destination, outcome, and risk. |
| request_sui_transactionA | Simulate and queue serialized Sui TransactionData for explicit approval with a Sui Wallet Standard extension. asciiExplanation is mandatory, ASCII-only, and must explain commands, objects/assets, destination, outcome, and risk. |
| get_transaction_requestA | Read the latest status and wallet result for one transaction request. |
| list_transaction_requestsA | List recent approval requests. Serialized transaction payloads are omitted. |
| cancel_transaction_requestA | Cancel a still-pending browser approval request. |
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 6 tools
Each tool has a distinct role: three chain-specific request tools, one status getter, one list, and one cancel. No two tools overlap in function; even the three request tools are clearly differentiated by chain.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., request_evm_transaction, get_transaction_request, list_transaction_requests). The pattern is uniform and predictable.
Six tools is well-scoped for a transaction request manager: three chain-specific creation methods plus three lifecycle operations. Each tool earns its place without unnecessary duplication.
The tool surface covers the full lifecycle of transaction requests: create (for each supported chain), read (single and list), and cancel. No obvious gaps for the stated purpose.