Somnia MCP Server
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation2/5
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.
Naming Consistency4/5All 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.
Tool Count2/5With 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.
Completeness4/5The 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.
Average 3.1/5 across 26 of 26 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation but adds no behavioral information beyond it. It does not disclose auth requirements, return shape, pagination, or any constraints like 'recent' meaning last 30 days.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
Though extremely short, this is under-specification rather than effective conciseness. The single sentence simply restates the tool name and contributes no new information, so it fails to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three required parameters and no output schema, the description should explain what data is returned and under what conditions. It does not specify the transaction fields, time window, or wallet scope, leaving the agent with insufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only walletAddress is described). The description does nothing to explain or contextualize the parameters, leaving authToken and chainName completely undocumented at the description level, and fails to clarify that 'recent' is relative to walletAddress.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get recent transactions' is a near-verbatim restatement of the tool name 'getRecentTransactions' and title 'Get Recent Transactions'. It provides no scope (e.g., which wallet or chain) and does not differentiate among sibling tools like getLatestTransactions or getTransactionsForAddress.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention the required walletAddress, chainName, or authToken context, nor does it explain any exclusions or reasons to prefer a sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds no additional behavioral context and even introduces confusion by referencing a non-existent parameter. It does not contradict annotations but fails to disclose any meaningful behavior beyond what annotations offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is unclear and misleading. It wastes the opportunity to convey essential details and includes an erroneous reference to 'query params' that is not accurate for the tool's structured parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and is surrounded by many sibling tools with similar purposes. The description is too sparse to distinguish it, omits how the token is specified, and does not clarify return format or auth requirements beyond parameter names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (authToken and walletAddress have descriptions; chainName has only a const). The description adds no value to existing parameters and instead refers to a 'token address' parameter that is not in the schema, potentially misleading the agent into passing an invalid parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb and resource ('Get token balance for address') but incorrectly mentions a 'token address in query params' that does not exist in the schema. This makes the tool's purpose ambiguous and misleading, especially given sibling tools like getERC20Balance and getTokenBalancePortfolio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention supported token standards, prerequisites, or exclusions, leaving the agent without criteria for selecting this tool over similar siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the tool is known to be read-only. The description adds no additional behavioral context such as pagination, authentication requirements, or return format, and it neither contradicts nor enriches beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, but it is under-specified and lacks structure. While concise, it does not provide enough substance to be fully effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and a large set of sibling tools, the description is too brief. It omits key details like the constrained chainName value, the purpose of authToken, and what the returned tokens look like, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with authToken and chainName undocumented. The description only clarifies that 'address' refers to an NFT contract, but does nothing to explain the other two parameters, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Lists tokens for an NFT contract'), clearly indicating the tool's function. However, it does not explicitly distinguish itself from sibling tools like getNFTtokensByIdForAddress, which is closely related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no mentions of exclusions, prerequisites, or comparisons to sibling tools, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include readOnlyHint: true, so the safety profile is known, but the description adds no behavioral context beyond that. It does not mention ordering, pagination, limits, or what 'latest' means in terms of time or block, which would be useful for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, effectively restating the tool name. While it has no fluff, it is under-specified and doesn't earn its place by adding value, making it more an under-specification than a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with no output schema, the description should explain what kind of transactions are returned, in what order, and any limits. It does none of this, so the agent is left without enough information to invoke the tool correctly in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two required parameters (authToken, chainName) with 0% description coverage. The description provides no explanation of what authToken is for or how to use it, and while chainName has a const 'somnia' in the schema, the description doesn't clarify any semantic meaning. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get latest transactions' clearly states the verb (get) and resource (transactions), and the qualifier 'latest' gives some scope. However, it does not distinguish this from sibling tools like getRecentTransactions or getTransactionsForAddress, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There are no exclusions, prerequisites, or context about what makes 'latest' different from other transaction-fetching tools, leaving the agent to guess.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so the safety profile is already disclosed. The description adds no behavioral context beyond what annotations provide—no mention of return format, pagination, or block range semantics. It does not contradict annotations, so a baseline 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short at five words, but brevity here is under-specification rather than efficient conciseness. It fails to convey the tool's scope or behavior, so while it is compact, it does not earn a higher score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, no usage context, and a large set of sibling log/block tools, the description is insufficient. It does not explain what 'logs from blocks' means, how blocks are specified (e.g., block height, range), or how it differs from getTransactionLogsForAddress. The complexity of the domain demands more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: authToken is described, but chainName is only declared via a const value. The description adds no meaning beyond the schema. With 2 simple parameters and a const enum, baseline 3 is fair since the schema already defines chainName's constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get logs from blocks' is a vague noun-phrase restatement of the tool name. It does not specify what kind of logs, which blocks, what filtering or scope, or how it differs from sibling tools like getTransactionLogsForAddress, getTopicTransactionLogs, or getBlockTransactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. With 25 sibling tools including several log-related ones, the description offers no context on selecting this tool, no exclusions, and no mention of required parameters like chainName and authToken.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the readOnlyHint annotation. It does not disclose return format, pagination, or the nature of the logs, and its wording introduces confusion about whether the address is a contract or a transaction originator.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, making it concise and front-loaded. However, the awkward phrasing could be improved without adding length, so it is not perfect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and minimal annotations, the description is insufficiently informative. It fails to clarify what logs are returned, how the address is interpreted, or any prerequisites or edge cases, making it incomplete for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema coverage, the description needed to compensate for undocumented authToken and chainName, but it does not. The phrase 'provided address' loosely maps to contractAddress but is not explicit, and the other parameters remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb ('Get') and a resource ('logs for transaction'), but the phrase 'created by the provided address' is ambiguous and conflicts with the schema's contractAddress. It does not clearly distinguish from sibling tools like getTransactionLogs or getTopicTransactionLogs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools exist, but no exclusions or contextual triggers are mentioned, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, covering the read-only nature. However, the description introduces 'defined threshold' without explaining what it is or how it is determined, and it does not disclose pagination or return structure. This is a gap beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no filler, front-loaded with action and resource. However, the ambiguity around 'threshold' reduces its effectiveness in conveying the full picture.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with no output schema, the description should clarify the threshold, return value, and list limits. It only says 'list of contracts,' leaving the threshold concept undefined and failing to explain expected response content. Incomplete for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 67% of parameters with descriptions (authToken and token_address). The description references 'specific token' mapping to token_address and mentions a threshold but provides no parameter to define it, nor does it explain chainName's const value. It adds little meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Gets' and identifies resource 'contracts' filtered by token and threshold. It distinguishes from siblings like getTokenHolders by focusing on contracts, but the phrase 'defined threshold' is ambiguous because no threshold parameter appears in the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Sibling tools such as getTokenHolders or getTokenBalance may be similar, but the description does not mention them or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds no behavioral context, such as whether the response includes transactions, the format of block data, or any rate limits. With annotations present the bar is lower, but zero added context yields a below-average score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no unnecessary words. It is appropriately concise and front-loaded, stating the core purpose without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and numerous sibling tools, the description is too sparse. It does not specify what 'a single block' entails (e.g., full block vs. header, inclusion of transactions), nor does it provide context on how to choose this tool among siblings. The schema provides some param details, but the overall tool behavior remains under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (authToken and blockHeight are described, chainName only has a const). Since coverage is not above 80%, the description should compensate for missing parameter details, but it adds none. The schema itself is mostly clear, but the description fails to enhance parameter understanding for the undocumented chainName.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get') and the resource ('a single block'), with a scope modifier ('single') that distinguishes it from multi-block tools. However, it does not explicitly differentiate from sibling tools like getBlockHeights or getBlockTransactions, which also relate to blocks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios for using getBlockHeights, getBlockTransactions, or other sibling tools, nor does it state any exclusions. The agent is left without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already signals a safe read operation, and the description's 'Get logs' aligns with that. No additional behavioral details are given (e.g., pagination, return format, or authorization constraints), but the annotation lowers the burden of disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that leads with the verb and resource. It contains no filler or redundant information, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and only a readOnly annotation, so the description must carry more contextual weight. It fails to mention that chainName is fixed to 'somnia', that authToken is required, or any details about the logs returned. The description is minimally viable but incomplete for a tool in a large family of similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only topicHash has a description). The description reinforces topicHash as the filter but does not explain authToken or chainName. chainName has a const in the schema, but the description fails to compensate for the low coverage overall.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get logs') and the resource ('transactions matching the provided topic'). The topic qualifier differentiates it from generic log tools, though it does not explicitly name alternatives. It is specific and understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of the many sibling tools such as getTransactionLogs or getTransactionLogsForAddress. There are no exclusions, prerequisites, or alternative recommendations, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes that this is a safe read operation. The description adds no additional behavioral context such as response format, pagination, summary scope (e.g., time range, transaction count), or authentication requirements. No contradictions, but no extra value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that gets straight to the point. No filler, redundant phrasing, or unnecessary detail. Excellent size for the content provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description does not explain what the summary contains (e.g., totals, ranges). It also omits required parameter context (authToken, chainName constraint) and provides no guidance on expected behavior. Given a 3-parameter tool and minimal structured metadata, the description is too thin to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only walletAddress has a description). The tool description reiterates wallet address but says nothing about chainName (with const 'somnia') or authToken, which are required but undocumented. The description does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('summary of transactions') with a clear scope ('for a specific wallet address'). It implies a distinction from sibling transaction-list tools via 'summary', but does not explicitly name alternatives, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'summary' implies the tool is for aggregated or high-level transaction data rather than full raw lists, but there is no explicit when-to-use vs. alternatives or exclusions. Usage context is only inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description adds the scope of 'to and from' but does not disclose pagination, return format, or any potential differences from other transaction tools. It adds some context beyond the name but little else.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the core purpose without unnecessary words or restating the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the large number of similar sibling tools, the description is too minimal to fully inform an agent about what to expect. It does not explain what a 'transaction' includes, whether internal transactions are covered, or how this differs from getBulkTransactions or getWalletTransactionSummary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the parameters other than implicitly referring to the address. Schema coverage is only 33% (only address has a description), and authToken and chainName are left undocumented. The description fails to compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves transactions to and from a wallet address, using a specific verb and resource. It distinguishes from sibling tools like getERC20Transfers or getOneTransaction by indicating bidirectional transaction retrieval for an address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is the general transaction fetcher for an address or that specific transfer types should use other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. The readOnlyHint=true and destructiveHint=false already communicate the safety profile, but the description doesn't mention return format, potential errors, or authentication requirements. With annotations covering the key safety trait, the minimal description is acceptable but leaves room for added 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action. Every word contributes meaning, with no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should clarify what the tool returns (e.g., balance in wei or a number). It only says it gets a balance, leaving the return format ambiguous. Given the simplicity of the tool, a brief mention of the return value would complete the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents authToken and walletAddress with descriptions, and chainName is constrained to 'somnia' via a const, making it self-explanatory. The description adds nothing beyond the phrase 'of a wallet,' which is redundant with the walletAddress parameter description, but the schema already provides sufficient parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'ERC20 tokens balance of a wallet,' making the tool's purpose unambiguous. It distinguishes from NFT and ERC1155 balance tools, though it doesn't explicitly differentiate from the sibling 'getTokenBalance' which may also be relevant for general token balances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that this is specifically for ERC20 tokens and that other standards (ERC721, ERC1155) require different tools, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readOnly and idempotent, so the safety profile is clear. The description adds context about historical scope and token types, but doesn't disclose limitations such as what happens if a block height/date is invalid or if the address has no holdings. This is acceptable given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is reasonably concise. It front-loads the main purpose, though 'Commonly used to' adds little value and could be removed. Overall, it is efficient and not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete due to the phantom block height/date parameter and lack of any output/return description. For a read-only tool with no output schema, the description should at least indicate what data is returned. The mismatch between description and schema further hampers completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description references a 'block height or date' parameter, but the input schema only includes chainName, walletAddress, and authToken — with additionalProperties false. This is a critical mismatch that would mislead the agent into trying to pass an unsupported parameter. Schema coverage is only 67% and the description fails to clarify existing params, instead inventing a phantom one.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches historical balances (native, ERC20, ERC721, ERC1155) for an address at a specified block height or date. It uses a specific verb ('fetch') and resource ('tokens held by an address'), distinguishing it from sibling tools that focus on current balances or single token types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for historical balance queries but does not explicitly compare with alternatives like getTokenBalance or getERC20Balance. It lacks clear 'when to use' or 'when not to use' guidance, though the historical/block context provides some implied direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so this is a safe read operation. The description adds no additional behavioral context such as pagination, limits, return format, or error conditions. It does not contradict annotations, but it also adds no value beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, which is appropriate for a simple getter tool. It avoids unnecessary verbosity and is front-loaded, though it gives minimal information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no nested objects, no output schema), the description is minimally adequate. Annotations cover the safety profile, but the description does not mention return type or any special behaviors. For a straightforward getter, this is acceptable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, meaning two of three parameters (authToken, blockNumber) have descriptions, but chainName lacks description. The tool description adds no parameter semantics; it only mentions 'block' which implicitly refers to blockNumber but does not clarify the other parameters. Since coverage is not high and description does not compensate, it falls below baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get transactions in a block' clearly states the action (get transactions) and the scope (in a block), which is specific and distinguishes it from sibling tools like getTransactionsForAddress or getBulkTransactions. The verb and resource are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need transactions in a specific block) but does not explicitly state when not to use it or mention alternatives. It provides basic context without clear exclusions or guidance on sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the readOnlyHint annotation. It does not disclose authToken requirements, return format, or any side effects, but the annotation covers read-only safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence states the purpose clearly without unnecessary words. It is front-loaded with the action and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so a description of the return value would be valuable. The description is too sparse given the three required parameters and the large sibling tool set, lacking enough context for an agent to select it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only walletAddress described. The tool description does not compensate for chainName or authToken, offering no additional semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies the resource 'earliest transaction' for an address, making the purpose clear. It distinguishes from siblings like getLatestTransactions by focusing on 'earliest'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no prerequisites. The usage context must be inferred entirely from the tool name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. However, the description adds no behavioral context beyond what the annotations provide—no mention of pagination, balance formatting, whether zero balances are included, or any edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of eight words, front-loaded with the verb 'Returns'. It is perfectly concise and free of unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with no output schema, so the description must clarify the return shape. 'List of ERC-1155 token balances' is vague—it does not specify whether each item includes token address, token ID, balance amount, or metadata. The description is insufficient for an agent to anticipate the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (authToken and walletAddress have descriptions; chainName has a const but no prose description). The tool description contributes no parameter information, but the schema already provides adequate descriptions for the two key parameters. The description does not add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Returns a list of ERC-1155 token balances' uses a specific verb (Returns), identifies the resource (ERC-1155 token balances), and clearly distinguishes this tool from siblings like getERC20Balance and getERC721Balance by specifying the token standard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The token standard (ERC-1155) in the description implies when to use this tool vs. alternatives, but there is no explicit guidance on when not to use it or which sibling tool to prefer for other token types. The context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds that it returns a 'list' of balances, which is somewhat beyond the name, but it does not disclose any other behavioral traits such as pagination, return format details, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words, front-loaded with the primary purpose. It is appropriately sized for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too brief to be complete. It does not clarify what 'token balances' means for ERC-721 (number of tokens vs. list of token IDs), nor does it describe the structure of the returned list, error handling, or pagination. With no output schema, this ambiguity is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (authToken and walletAddress have descriptions; chainName has a const). The tool description does not add any additional parameter meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Returns a list') and the specific resource ('ERC-721 token balances'), which differentiates it from sibling tools like getERC20Balance and getERC1155Balance. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is specifically for ERC-721 tokens or that other tools (e.g., getERC20Balance) should be used for other token standards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent true, and the description adds meaningful behavior: the timeframe is user-configurable with a 30-day default. This goes beyond the structured metadata, although it does not cover pagination or exact response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose. The phrase 'Commonly used' is filler, but overall it avoids unnecessary detail and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool, the description communicates the primary result and adds a useful default timeframe. However, the missing timeframe parameter in the schema creates a mismatch, and the lack of any return value description (no output schema) leaves some ambiguity about the exact output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, but the description adds little to parameter understanding. It mentions a configurable timeframe that is not present in the schema (which only has chainName, walletAddress, authToken), and it does not clarify authToken or chainName usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool renders a daily portfolio balance broken down by token, which clearly distinguishes it from single-token balance tools like getTokenBalance. However, the verb 'render' is imprecise and it does not explicitly differentiate from getHistoricalBalance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
'Commonly used to render a daily portfolio balance' implies a use case but gives no explicit guidance on when to choose this over alternatives or when not to use it. The context is clear but exclusions and alternative tool references are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds no additional behavioral context such as return format, pagination, rate limits, or chain restrictions, and merely restates the function without going beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded with the key action and resource, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema, and the description does not specify what the response contains. While the purpose is clear and annotations cover safety, the absence of return-value details and explicit chain support makes the description only minimally complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 67%, with walletAddress and authToken described and chainName constrained via a const value 'somnia'. The description itself does not elaborate on parameter meaning, so it adds no value beyond the schema's own documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (Get), the resource (ERC1155 transfers), and the scope (for a specific wallet address). This unambiguously differentiates it from sibling tools like getERC20Transfers and getERC721Transfers, which fetch transfers for different token standards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to fetch ERC1155 transfers for a wallet, but it does not explicitly state when to use it over alternatives or mention any exclusions. No alternative tools are referenced, so the guidance is limited to the obvious use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral context such as return format, pagination, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's purpose with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four required parameters and no output schema. The description is minimal and does not explain what 'token details' includes, leaving gaps for an agent to know what to expect from the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 50% of parameters have schema descriptions, and the description itself provides no parameter details. The authToken and chainName parameters remain undocumented, so the description does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets token details for a specific token of an NFT contract, using a specific verb and resource. This distinguishes it from sibling tools like getNFTtokensByAddress, which likely retrieves tokens by address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a specific NFT token ID is known, but it does not explicitly state when to use this tool over alternatives or when not to use it. No sibling alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation. The description adds the time-bucket interval context, but does not disclose response format, pagination, or any rate limiting. With annotations covering the read-only nature, the description adds modest value but remains thin on behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that wastes no words and front-loads the core purpose. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four required parameters, no output schema, and a read-only annotation. The description is minimal but covers the essential function. However, it omits the response format, authentication requirements, and any caveats about the 'bulk' nature of data, leaving some ambiguity for an agent deciding whether to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with walletAddress and timeBucket described in the schema. The description reinforces these by mentioning 'wallet address' and '15-minute time bucket interval,' adding clarity. However, it does not address authToken at all, and chainName's fixed value 'somnia' is only represented by a schema const, leaving two of four parameters with incomplete guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'provides bulk transaction data for a wallet address in a 15-minute time bucket interval,' specifying both the resource (bulk transaction data) and the unique time-bucket granularity. This distinguishes it from sibling tools like getTransactionsForAddress or getRecentTransactions, which do not mention bulk data or a 15-minute interval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for bulk transaction data aggregated into 15-minute buckets, but it does not explicitly state when to use it over alternatives or provide exclusions. No guidance is given about prerequisites or comparison with sibling tools, so usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral details (e.g., response format, pagination) beyond stating the resource, so it meets the baseline without enhancing transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It efficiently communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with strong annotations, the description is adequate but does not explain return values (since no output schema exists). It lacks details about what data is returned (e.g., transfer events, token IDs, timestamps), which would be helpful given the tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (authToken and walletAddress are described). The description adds meaning to walletAddress by specifying 'a specific wallet address,' but does not clarify authToken or chainName beyond schema/const. Since coverage is not high, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource+scope: 'Get ERC721 transfers for a specific wallet address.' It clearly distinguishes from sibling tools like getERC20Transfers and getERC1155Transfers by specifying the ERC721 standard and wallet-address scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for fetching ERC721 transfers for a given wallet, but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or conditions. It relies on the tool name and resource type to convey context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the date-range scoping constraint but does not disclose return format, pagination, or rate limits. It provides modest value beyond annotations, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant wording. It is front-loaded and efficient, saying exactly what the tool does in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool, the description adequately conveys the scope and implied return of block heights. Annotations cover safety, schema covers parameters, and the resource type is clear. Minor missing details like inclusivity or ordering are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, with startDate and endDate described as YYYY-MM-DD. The description adds no parameter-specific semantics beyond referencing 'between two dates', which the schema already captures. Baseline 3 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'all block heights' and a date-range scope. It readily distinguishes itself from sibling tools like getOneBlock or getBlockTransactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving block heights between two dates, but it does not explicitly mention when to prefer this tool over alternatives or any exclusions. This is implied usage, not explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the read-only nature is already known. The description does not add additional behavioral details such as error handling, rate limits, response format, or authentication nuances. It does not contradict the annotation, but it also does not go beyond what annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of five words, front-loading the key action and condition. There is no wasteful wording; every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only lookup with three parameters, one constrained by a const, and one described in the schema. The description plus annotations cover the basic use case, but authToken remains undefined, there is no output schema, and no mention of what happens if the transaction is not found. The description is minimal and does not add meaningful context beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% — only txHash has a description. The tool description merely reinforces txHash via 'by its hash' and provides no clarification for authToken or chainName. Given the low schema coverage, the description should compensate, but it fails to explain these parameters, leaving their semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('single transaction') and a specific scoping condition ('by its hash'), which clearly distinguishes it from sibling tools like getBulkTransactions, getRecentTransactions, or getTransactionsForAddress. The qualifier 'single' and the hash condition leave no doubt about the tool's specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: when you have a specific transaction hash and want exactly one transaction. This provides clear context without explicitly naming alternatives or exclusions. It lacks an explicit 'when-not-to-use' or alternative tool reference, but the 'by its hash' condition is a strong usage signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which fully covers the safety profile. The description adds the wallet-address scoping constraint but does not disclose return format, pagination, or rate limits. Given the strong annotation support, the description provides acceptable but not rich behavioral context, aligning with a baseline score of 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant context. It front-loads the core behavior ('Get ERC20 transfers') and immediately follows with the key scope ('for a specific wallet address'). Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the annotations cover safety, and the schema covers all required parameters (including the chain constraint via const 'somnia'), the description needs only to state what is returned and for whom. It does that clearly. A note on return format (e.g., list of transfer objects) would slightly improve completeness, but the description is adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, with authToken and walletAddress already well-described. The description essentially repeats the walletAddress schema text ('for a specific wallet address') without adding new meaning. It does not explain chainName (though its const value 'somnia' is self-explanatory) or authToken, and it fails to compensate for the missing chainName description. Since coverage is not high and the description adds no parameter insights, a score of 2 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a specific resource ('ERC20 transfers'), and a clear scope ('for a specific wallet address'), making it immediately obvious what the tool does. It distinguishes itself from sibling tools like getERC20Balance and getERC721Transfers by specifying both the asset type and the event type, so an agent can differentiate it from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: to retrieve ERC20 transfer events for a given wallet. It does not explicitly mention alternatives or exclusions (e.g., use getERC721Transfers for NFTs), but the sibling list and the precise wording give enough context for an agent to infer the correct use case. A slight deduction for not naming alternative tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to reiterate safety. It adds useful context about returning historic holders when block-height is set and defaulting to latest, but it introduces a mismatch: the input schema has no block-height parameter (additionalProperties: false). This inconsistency creates ambiguity about how to actually set that value. The description also does not mention pagination or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences and front-loaded with the core function. It is concise but includes a filler phrase 'Commonly used' and an optional use-case sentence. The key behavioral details (historic vs. latest) are present, and no sentences are redundant with the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no output schema, the description covers the main purpose, the token types, the historic/latest distinction, and a use case. It is missing details like potential pagination limits or the exact structure of the returned holder list, but the tool appears simple enough that the description is largely adequate. The block-height discrepancy with the schema is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (authToken and tokenAddress have descriptions, chainName has a const but no description). The description adds meaning by specifying that the tokenAddress is for an ERC20 or ERC721 token, which helps clarify the parameter's purpose. However, it does not explain authToken or chainName, and the mention of block-height is not reflected in the schema, potentially confusing parameter invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('get a list of all the token holders') and the resource (a specified ERC20 or ERC721 token). It also differentiates the tool by emphasizing 'all' holders and the historic behavior, distinguishing it from sibling tools like getTokenBalance or getERC20Balance that focus on balances rather than holder lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: to fetch token holders for ERC20/ERC721, including historical holders. It does not explicitly state exclusions or alternatives, but the mention of 'Commonly used' implies it is the standard choice for this purpose, and the use case 'building pie charts' provides practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vastavikadi/somnia-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server