Somnia MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AUTH_TOKEN | Yes | Your auth token (ORMI API KEY) from https://subgraph.somnia.network/ |
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 |
|---|---|
| getOneBlockC | Get a single block |
| getBlockHeightsA | Get all block heights between two dates |
| getBlockTransactionsB | Get transactions in a block |
| getERC20BalanceB | Get ERC20 tokens balance of a wallet |
| getERC721BalanceB | Returns a list of ERC-721 token balances |
| getERC1155BalanceB | Returns a list of ERC-1155 token balances |
| getHistoricalBalanceB | Commonly used to fetch the historical native, fungible (ERC20), and non-fungible (ERC721 & ERC1155) tokens held by an address at a given block height or date |
| getTokenBalancePortfolioB | Commonly used to render a daily portfolio balance for an address broken down by the token. The timeframe is user-configurable, defaults to 30 days. |
| getERC20TransfersA | Get ERC20 transfers for a specific wallet address |
| getERC721TransfersA | Get ERC721 transfers for a specific wallet address |
| getERC1155TransfersA | Get ERC1155 transfers for a specific wallet address |
| getContractsWithHoldingsC | Gets a list of contracts containing specific token with defined threshold. |
| getTokenHoldersA | Commonly used to get a list of all the token holders for a specified ERC20 or ERC721 token. Returns historic token holders when block-height is set (defaults to latest). Useful for building pie charts of token holders. |
| getTransactionLogsC | Get logs from blocks |
| getTransactionLogsForAddressC | Get logs for transaction created by the provided address |
| getTopicTransactionLogsB | Get logs for transactions matching the provided topic |
| getNFTtokensByAddressC | Lists tokens for an NFT contract |
| getNFTtokensByIdForAddressA | Gets token details for a specific token of an NFT contract. |
| getTransactionsForAddressB | Get transactions to and from the wallet address |
| getWalletTransactionSummaryB | Get a summary of transactions for a specific wallet address |
| getBulkTransactionsA | This API provides bulk transaction data for a wallet address in a 15-minute time bucket interval |
| getEarliestTransactionB | Get the earliest transaction for an address |
| getRecentTransactionsD | Get recent transactions |
| getOneTransactionA | Get a single transaction by its hash |
| getLatestTransactionsC | Get latest transactions |
| getTokenBalanceC | Get token balance for address for provided token address in query params |
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 26 tools
Many tools have overlapping functionality, e.g., getERC20Balance, getTokenBalance, getHistoricalBalance, and getTokenBalancePortfolio all relate to balances. Similarly, getRecentTransactions, getLatestTransactions, getTransactionsForAddress, and getBulkTransactions all fetch transactions, making it difficult for an agent to select the correct tool.
All tools consistently follow the 'get' + CamelCase noun phrase pattern (e.g., getERC20Balance, getBlockHeights, getTokenHolders). Minor variations like getNFTtokensByAddress with mixed casing are slight deviations, but the overall naming convention is uniform and predictable.
With 26 tools, the server is over the recommended range and feels bloated. Many tools could be consolidated (e.g., balance queries could be unified into fewer endpoints), and the redundancy makes the tool set heavier than necessary for its domain.
The blockchain data retrieval domain is well covered, including blocks, transactions, balances, transfers, logs, and token holders. Minor gaps such as a direct native balance endpoint or token metadata search can be worked around, but core operations are present.