boo-mpp-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation4/5
Most tools have clearly distinct purposes, but some overlap exists: wallet_risk and wallet_sanctions both assess wallet safety, and rhchain_token_screener, rhchain_token_detail, and rhchain_trending all provide token information from different angles. Descriptions generally clarify these boundaries well enough for an agent to choose correctly.
Naming Consistency4/5
All tool names use lowercase snake_case and are grouped by domain prefixes (defi_, token_, wallet_, rhchain_, mpp_). The verb position varies (e.g., ens_resolve has verb-last, mpp_list_paid_tools has verb-first), but the overall pattern is predictable and readable.
Tool Count2/5
With 26 tools, the server exceeds the 25-tool threshold for excessive count. The set bundles general crypto data, safety checks, compliance, and 9 Robinhood Chain-specific tools, making it feel like a broad API rather than a focused MCP server.
Completeness4/5
The tool surface covers a wide range of crypto data and risk assessment needs, including market prices, yields, TVL, safety checks, wallet compliance, and chain-specific metrics. Minor gaps exist (e.g., no historical price data or general token holder lists), but the core workflows for a read-only data server are well covered.
Average 3.8/5 across 26 of 26 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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
This repository is licensed under MIT License.
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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool is paid, up to $0.008 USDC.e per call, with automatic payment from a configured wallet. This is valuable context. However, it does not disclose whether the operation is read-only, what the return data looks like, or any failure/edge-case behavior, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first states the tool's purpose, and the second warns about the cost and payment mechanism. Every word earns its place, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three optional parameters, no output schema, and no annotations, so the description must compensate for return expectations and behavioral details. While it covers purpose and cost, it does not explain what data is returned, how holder screening works, or how to configure payment. This leaves significant gaps for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters: limit, query, and stockOnly, each with clear descriptions. The tool description itself does not add parameter-specific meaning beyond the schema, but it does provide broader context about token types. Since schema coverage is high, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool screens tokens on Robinhood Chain by holders, listing tokenized stock tokens and community tokens. The verb 'Screen' and resource 'tokens' are specific, and the 'by holders' criterion adds distinction. However, it does not explicitly differentiate from sibling tools like rhchain_trending or rhchain_token_detail, though the holder-based focus provides some separation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It mentions the tool is paid, but that addresses cost, not usage context. There is no mention of alternatives, exclusions, or prerequisites, leaving the agent to infer use cases from the purpose alone.
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?
With no annotations, the description must carry the behavioral burden. It discloses the paid nature and automatic payment, which is useful cost context. However, it does not explicitly state that the tool is read-only, nor does it explain how 'recent change' is calculated or whether any rate limits apply. Some context is added but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences; the first clearly states the tool's function, the second adds essential cost information. No filler or repetition. Well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool without output schema or annotations, the description covers the basic purpose and cost but omits the meaning of 'recent change' (e.g., percentage, period) and the return format. These are notable gaps for a user to interpret the output correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully covers the single parameter with a clear description of protocol slugs. The tool description adds no additional parameter details, so the schema carries all the weight. Baseline 3 applies due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing total value locked and recent change for a DeFi protocol, distinguishing it from siblings like chain_tvl and defi_yields. However, it lacks an explicit verb like 'get' or 'query,' making the action implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternative TVL/yield tools. It does not mention that this is protocol-specific while chain_tvl is chain-level, nor does it point to defi_yields for yield data. The usage context is only implied by the word 'protocol.'
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?
With no annotations, the description carries full burden for behavioral disclosure. It prominently discloses that the tool is paid, the cost range, and that payment is automatic from the configured wallet, which is valuable. However, it does not mention whether the operation is read-only, possible failure modes, or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose, followed by a concise payment notice. Every sentence adds value; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description enumerates the expected data fields, making return values largely predictable. It also covers the cost and payment mechanism. It lacks sibling differentiation but is sufficient for a simple single-parameter detail tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single parameter (address) with a description. The description adds no additional parameter semantics, but since schema coverage is 100%, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns detailed information for a single token on Robinhood Chain, listing specific fields (symbol, holders, supply, price, market cap, 24h volume). This distinguishes it from price-only or supply-only siblings, though it lacks a strong action verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives like token_price, token_supply, or token_snapshot. The description implies it is for general token detail lookups but does not state exclusions or preferred scenarios.
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?
With no annotations, the description carries the transparency burden. It discloses the paid cost (up to $0.01 USDC.e per call) and the output range (0-100) and tier, which is useful. However, it does not state whether the operation is read-only, how the score is calculated, or any potential side effects, leaving room for ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that immediately state the tool's purpose and a critical cost caveat. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description provides enough context: what it returns (score and tier), the wallet scope, and the paid nature. It does not explain tier labels or edge cases, but these are not essential for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter 'address' as 'Wallet address (0x...).' The description adds no additional semantic detail about the parameter, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides an 'Activity score (0-100) and tier' for a Robinhood Chain wallet, specifying the resource and output. However, it lacks an explicit verb like 'get' or 'retrieve,' and does not differentiate from sibling tools such as rhchain_wallet or wallet_risk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 like rhchain_wallet or wallet_risk. The only extra information is the paid-tool notice, which is cost-related rather than usage 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?
With no annotations, the description carries the burden of disclosing behavior. It usefully notes the tool is paid and reveals the cost structure. However, it omits details such as error handling, rate limits, or whether the token parameter accepts symbols or only contract addresses, which limits full 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the core function in one sentence and adding the essential payment note in a second. No filler words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the simple two-parameter schema and lack of output schema, the description adequately covers what the tool returns (list of metrics) and the key context of it being a paid call. It could elaborate on response structure or default chain behavior, but for a low-complexity read tool, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters with 100% coverage. The description adds slight context (e.g., 'from DEX pairs') but does not offer additional parameter-level semantics beyond what the schema provides, aligning with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns live price, liquidity, 24h volume, FDV, and market cap for a token, specifying the data source as DEX pairs. This distinguishes it as a market data tool, though it doesn't explicitly contrast with sibling tools like token_supply or token_rugcheck.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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, nor are there any conditions or exclusions mentioned. The description simply states what it does, leaving the agent to infer appropriate usage.
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?
With no annotations, the description compensates by disclosing the cost per call and automatic payment from the configured wallet, which is relevant operational behavior. However, it does not mention data freshness, potential errors, or whether any prerequisites beyond a configured wallet exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core output data, the second states the payment cost and mechanism. Both are essential and directly relevant, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read-only query with two fully described parameters and no output schema, the description covers the essential information: what data is returned and the cost. It does not describe the data source or update frequency, but these are minor for this tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters (chain and token), so the description adds no additional parameter meaning. Baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: it provides total supply, circulating supply, and decimals for a token. This distinguishes it from sibling tokens like token_price (price) and token_rugcheck (risk), though it lacks an explicit verb like 'retrieves' or 'returns'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 such as token_price or token_snapshot. It only mentions the paid nature and cost, which is operational information, not selection 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?
No annotations are provided, so the description carries the full burden. It does disclose the paid nature (up to $0.01 per call) and automatic payment, which is important behavioral context beyond simply finding yields. However, it does not mention whether the operation is read-only, what the response format looks like, or any potential side effects, leaving room for uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and then a clear cost note. Every sentence earns its place; there is no fluff or repetition. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four optional parameters and no output schema, the description covers the main purpose, filters, and cost. It is not overly verbose, and the cost disclosure is valuable. However, it could be more complete by hinting at the return format or example usage, especially since no output schema exists to clarify that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description adds minimal parameter semantics beyond the schema: it mentions 'symbol, chain, or safety' in prose, which aligns with the schema properties (symbol, chain, safeOnly). It does not provide any additional format or usage details that the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Find yield/farming opportunities' with optional filters by symbol, chain, or safety. This is a specific verb+resource combination. However, it does not explicitly distinguish itself from sibling tools like defi_tvl, which also deals with DeFi metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning optional filters, but it does not provide guidance on when to use this tool versus alternatives like defi_tvl or other DeFi tools. No explicit when/when-not guidance is given, so the usage intent is somewhat implied rather than clearly directed.
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?
With no annotations, the description carries the full burden. 'Shows' implies read-only and 'FREE' indicates no cost, but side effects, rate limits, or session-specific behavior are not explicitly disclosed. For a simple status tool this is minimally viable but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a front-loaded 'FREE' prefix. Every phrase contributes value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should specify the return format or units, but it only says 'how much' and 'spend caps' without indicating the type of value or currency/unit. This ambiguity makes it incomplete for an agent interpreting the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description appropriately focuses on the output (spend and caps) without any parameter explanation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Shows' and identifies the resource as session spend and spend caps. This clearly distinguishes it from sibling tools like mpp_list_paid_tools, which lists paid tools, and the title reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor any exclusions or prerequisites. The 'FREE' prefix implies no cost but provides no usage context relative to other MPP 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?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It does disclose a significant behavioral trait: the tool is paid (cost up to $0.01 USDC.e per call, paid automatically). However, it does not clarify what 'detects a depeg event' means in terms of output (e.g., boolean, threshold, time window) or return format, leaving important behavioral aspects unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences conveying purpose and a clear pricing notice. It is front-loaded with the core function ('Peg status and market cap') and the key extra context (paid tool). No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what data is returned, but it does not. The agent is left wondering what 'peg status' looks like, whether it is a numeric value, a boolean, a list of stablecoins, or something else. The depeg detection mechanism is also vague (threshold, method). This is inadequate for a tool that presumably returns structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'symbol' is fully described in the schema ('Optional symbol (USDC, USDT, DAI...).'), so schema coverage is 100%. The description does not add any extra meaning about the parameter, such as default behavior when omitted, case sensitivity, or examples. It stays at the baseline level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool monitors stablecoin peg status and market cap, and specifically detects depeg events. This distinguishes it from sibling tools like token_price (which simply gives prices) or token_supply (which gives supply). The verb 'detects' and the resource 'stablecoin' are 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when checking stablecoin peg health or depeg risk), but offers no explicit guidance on when not to use it or alternatives. For instance, it does not mention that token_price might be sufficient for simple price lookups. There is no comparative context with siblings.
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?
With no annotations, the description carries the full burden. It discloses it reads data and includes cost details (PAID TOOL: up to $0.01), which is useful. However, it does not mention return format, latency, limitations, or any other behavioral traits, leaving some ambiguity for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core function, the second adds context, and the third discloses the paid tool cost. Every sentence serves a distinct purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no output schema, the description provides adequate context: what it reads, scope (across exchanges), and cost. However, it lacks details like whether data is real-time/historical, which exchanges are covered, or response structure, so it is not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, symbol, has a clear schema description ('Asset symbol (BTC, ETH, SOL...).') providing 100% coverage. The tool description adds no additional parameter semantics, so it meets the baseline for schema-covered parameters without enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing funding rates and open interest for perpetuals across exchanges, and adds 'Reads leverage positioning' which conveys the analytical use. This is distinct from sibling tools like token_price (spot) or defi_yields (yield), so it effectively differentiates itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used for leverage/sentiment analysis ('Reads leverage positioning') but does not explicitly state when to choose this over alternatives like token_price or wallet_risk. No exclusion criteria or alternative tool references are given, so usage guidance 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?
With no annotations, the description carries the full burden. It discloses the paid nature (up to $0.01 USDC.e) and automatic payment from the configured wallet, which is important behavioral context. However, it omits other behavioral details like error handling, return format, or explicit confirmation that this is a read-only operation, though 'snapshot' implies non-mutating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences of dense, relevant information. The first sentence lists the output fields, and the second warns about cost and payment. No fluff or redundancy; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description enumerates the key return fields (ETH balance, tx count, account type, scam/reputation flags, optional token holdings), which is substantial. However, it leaves some ambiguity about the interpretation of 'account type' and the nature of reputation flags, and does not mention other potentially relevant details. Still, for a tool with only two parameters and a straightforward output, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, and the description's mention of deep=true adds no new information beyond the schema's own description. The address parameter is self-explanatory, so the description does not enhance parameter understanding beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's action: returning a wallet snapshot on Robinhood Chain with ETH balance (+USD), transaction count, account type, reputation flags, and optional token holdings. It distinguishes itself from sibling tools like rhchain_wallet_score and rhchain_tx by the scope of its output, making the purpose 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a wallet snapshot is needed but provides no explicit comparison to alternatives or when-not scenarios. The paid-tool warning is a cost consideration, not a usage guideline, and there is no mention of cases where another tool would be more appropriate.
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?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds important cost information ('PAID TOOL: up to $0.01 USDC.e per call') and payment mechanics, which is valuable. However, it does not detail output format or edge cases, so it is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a two-sentence purpose statement plus the necessary cost notice. Every sentence earns its place, and the most important information (purpose and cost) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description covers the core purpose and cost. It adequately addresses the main use case, though it lacks explicit mention of return formatting or interaction with sibling tools, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single optional 'chain' parameter, but the description adds semantic value by explaining that the tool can operate per blockchain or for one chain, reinforcing the filter meaning. This goes beyond the schema's basic label, earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides total value locked per blockchain or for a single chain, and that it compares ecosystem size. This is a specific verb-resource pairing, but it does not explicitly differentiate from the sibling tool 'defi_tvl', so it stops 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparing ecosystem sizes, but it does not provide explicit guidance on when to choose this tool over alternatives like defi_tvl, nor does it mention exclusions or prerequisites. The context is present but not explicit.
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?
No annotations are provided, so the description, which notes the tool is paid and discloses the cost and payment method, must carry the full burden. However, it does not mention rate limits, response format, error behavior, or data quality. Since it's a read-only lookup, the lack of destructive side effects reduces the need, but important operational details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences covering purpose and use case, plus a clear pricing note. Every sentence earns its place; there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (3 params, no output schema) and the description covers purpose, usage, and cost. However, without an output schema, the description should have given at least a hint about return data (e.g., registration number, status, jurisdiction) to make it complete. It's adequate but has a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds some value by explaining the 'type' parameter values (GLEIF, UK, US), which complements the schema's terse descriptions. It doesn't add significant semantic depth for 'query' or 'country', but the schema already covers them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Look up a real company in official registries by name or id' and explicitly names the registries (GLEIF, UK Companies House, US state registries). This distinguishes it from all sibling tools, which are focused on crypto, DeFi, wallet, and chain data, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use to verify a counterparty actually exists as a registered legal entity before doing business.' It effectively tells the agent when to invoke this tool, though it doesn't explicitly exclude situations or mention alternatives. The context is sufficient given the unique purpose among siblings.
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?
No annotations are provided, so the description must disclose behavioral traits. It does disclose that the tool is paid (up to $0.02 USDC.e per call) and that it translates content. However, it does not describe output format, potential limitations, or any operational details like rate limits or data freshness, so it provides only partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured in coherent parts: function, unique value, usage, and cost. It is not overly long, but the marketing-style phrasing ('Unique source: ...') adds slight verbosity. Overall it is efficient and front-loaded, but not as minimal as the highest-tier examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 optional parameters and no output schema, the description is fairly complete. It explains what the tool does, why it is valuable, when to use it, and its cost. It could mention return format or pagination behavior, but for a news feed tool this is not critical. The level of detail matches the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with descriptions for both 'limit' and 'query'. The tool description does not add any extra meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: reports on Vietnamese media about crypto, translated into English. It uses a specific verb ('reporting', 'translated') and resource ('Vietnamese media'), and distinguishes itself from siblings by highlighting its unique source and the fact that Vietnamese media is invisible to English-language agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use to catch regional narratives and regulatory news before they reach English press,' which provides clear guidance on when to use the tool. It also notes the paid nature and cost, helping the agent decide if use is appropriate. However, it does not explicitly mention alternatives, so it stops short of a perfect score.
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?
No annotations exist, so the description carries the full burden. It discloses a key behavioral trait: the tool is paid, with a specific cost and automatic payment from the user's wallet. However, it does not describe return formatting, error cases (e.g., unresolved names), or other side effects beyond payment. The cost disclosure adds value, but coverage is incomplete for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one stating the core purpose, one disclosing the payment model. It is front-loaded with the primary functionality and wastes no words. The payment warning is relevant and necessary for a paid tool, so every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), and the description covers purpose and cost. However, it omits details about the return value structure and behavior when a lookup fails (e.g., unregistered name or address without reverse record). Given the low complexity, this is a minor gap, so the description is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'query' parameter, which fully explains valid inputs ('ENS name (vitalik.eth) or address (0x...).'). The tool description adds no further parameter detail, so it does not improve on the schema. Baseline 3 is appropriate because the schema already provides complete semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Resolve an ENS name to an address, or an address back to its ENS name.' It uses a specific verb ('resolve'), names the resource (ENS), and describes bidirectional behavior. This distinguishes it from all sibling tools, which are focused on defi, chain, and wallet data, none overlapping with ENS resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when needing ENS resolution) but does not explicitly discuss alternatives or when not to use it. However, sibling tools are all in different domains (defi, wallet, chain metrics), so there's no ambiguity about which tool to choose. The absence of explicit exclusions is a minor gap, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses that this is a paid tool with a specific cost and payment method, which is important behavioral context. It also notes there is no input, implying no side effects, though it doesn't detail data source or update frequency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the tool's purpose. The additional cost/payment section is relevant and concise. Slightly verbose with the 'PAID TOOL' block but each sentence adds necessary info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-input tool, the description sufficiently explains what it returns (index and label) and the cost. Without an output schema, it could elaborate more on the label values or update frequency, but it's adequate for a simple sentiment tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema is empty, so the baseline is 4. The description explicitly states 'No input', which removes any ambiguity and adds clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the Crypto Fear & Greed index (0-100) and label, and that it gauges market sentiment. This is specific and distinct from sibling tools, though it doesn't explicitly contrast with any siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: it's a market sentiment gauge. However, there is no explicit guidance on when to use this tool versus alternatives like chain_tvl or token_price, or any exclusions.
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?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses the paid nature ('PAID TOOL: up to $0.005 USDC.e per call', 'Paid automatically') and confirms the tool is read-only in effect. It does not mention rate limits or response format, but the cost disclosure adds significant transparency beyond the bare function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short sentences: the first states the core function, the second adds the essential payment warning. It is front-loaded and every sentence earns its place without redundant or fluffy content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no nested objects, no output schema), the description is largely complete: it states what the tool returns, the chain options, and the cost. It does not specify the units of gas prices (e.g., gwei) or detail the exact response structure, but those are minor gaps for this simple oracle tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional parameter 'chain', and the schema already describes the allowed values (eth, bnb, base) and default (eth). The description adds no extra semantic value about the parameter, so it matches the baseline expected when the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns current gas prices (slow/average/fast) on an EVM chain, using a specific verb ('gas prices') and a defined resource scope. It distinguishes itself from sibling tools, which cover different domains like yields, TVL, or token prices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for fetching gas prices on supported EVM chains (eth, bnb, base), but it does not explicitly state when to use this tool over alternatives or exclude any use cases. It offers minimal context about chain selection through the parameter description, but lacks explicit guidelines.
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?
With no annotations provided, the description carries the full burden. It discloses that the tool returns activity, exposure, and flags, and notes the paid cost. However, it does not describe the output format, data sources, or whether it is a real-time check, leaving important behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first conveys the core purpose and components, the second gives the usage context, followed by a separate line for pricing. Every sentence earns its place and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the key contextual elements: purpose, usage timing, cost, and parameter hints. It could be more complete by elaborating on what the flags represent or providing an example risk profile, but it is adequate for a simple risk-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters completely (wallet address and supported chains), giving 100% schema coverage. The description adds no additional parameter-specific meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a risk profile for a wallet, listing specific components (activity, exposure, flags) and an explicit use case ('Use before trusting or sending funds to an address'). This distinguishes it from siblings like wallet_sanctions and rhchain_wallet_score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context for when to use the tool: 'Use before trusting or sending funds to an address.' This is clear and actionable. However, it does not mention when not to use it or explicitly name alternative tools, so it falls short of a 5.
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?
No annotations are present, so description must disclose behavior. It adds important cost context (up to $0.01 per call, automatic payment) but does not mention response format or any other behavioral details. Some burden is met but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second gives cost/payment warning. Front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with full schema parameter coverage; description adds cost and usage context. Without an output schema, slightly more return-value detail would improve completeness, but the current description is adequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the single parameter with a basic 'Wallet address' description. Tool description adds no additional format or chain details, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'screens' and resource 'wallet address against OFAC sanctions lists', clearly distinguishing from sibling tools like wallet_risk or token_rugcheck. Title reinforces 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Use for compliance before accepting funds', providing clear context on when to invoke. Does not mention alternatives or when-not-to-use, so not a 5.
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?
With no annotations, the description carries the full burden. It discloses the paid nature (up to $0.005 USDC.e per call), automatic wallet payment, and 'No input' requirement. It also lists the returned metrics, giving a good behavioral overview, though it omits potential rate limits or error behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two clear sentences: the first defines the tool's output, the second provides cost/payment context. It is front-loaded with the core purpose and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool, the description covers the essential context: what the tool does, what data it returns, and its cost. The lack of an output schema is compensated by listing the specific metrics. Minor omissions like request frequency or typical latency are not critical for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so the baseline is 4. The description adds 'No input' explicitly, which directly confirms the agent needs no parameters. This is consistent and helpful, though it largely restates the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool reports live network health metrics for Robinhood Chain, specifying exact data points (latest block, block time, gas, tx counts, ETH price) and even the chain_id. This makes the tool's purpose unmistakable and distinct from sibling tools, which focus on tokens, wallets, or general market data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking Robinhood Chain health, but it does not explicitly state when to use it versus alternatives or provide any exclusions. The 'No input' note is helpful, but the tool's role among siblings is only implicit.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the cost (up to $0.008 USDC.e per call) and payment mechanism, which is crucial operational context. However, it does not disclose potential rate limits, response format, or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the tool's purpose and key filtering rule, the second states the cost. Every word earns its place, and it is front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 2 fully documented parameters and no output schema, the description is mostly complete. It covers the resource, metric, default exclusion behavior, and cost. It could be improved by stating the sort order (e.g., descending) or what fields the returned objects contain, but it is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful nuance by explaining that Stock Tokens are excluded unless includeStock=true, which goes beyond the schema's 'true to include tokenized Stock Tokens'. The 'limit' parameter is not given additional context, but the coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: returning trending tokens on Robinhood Chain sorted by 24h volume. It also specifies the scope (Stock Tokens excluded by default), which differentiates it from sibling rhchain tools like rhchain_token_screener or rhchain_token_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding high-volume trending tokens, but does not explicitly state when to prefer this over alternatives or provide exclusions beyond the Stock Token caveat. There is no reference to sibling tools or alternative scenarios, so the guidance is limited.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently reveals the cost (up to $0.005 per call) and the return fields, adding context beyond the schema. It does not mention edge cases like not-found behavior, but for a read-only lookup the disclosed information is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the purpose and return data, the second states the pricing. Every word earns its place, with no filler or repetition. The structure is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool without an output schema, the description lists the expected output fields and the cost, which covers the essential context. It does not address error handling or not-found cases, but overall it is sufficiently complete for such a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'hash' already described as 'Transaction hash (0x...).' The tool description adds no further semantic detail beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Look up' and the resource 'transaction on Robinhood Chain', and enumerates the specific data fields returned (status, method, from/to, value, fee, block, timestamp). This distinguishes it from sibling tools like rhchain_wallet or rhchain_token_screener, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description sets a clear context by specifying that this is for querying a transaction by hash, and it also notes the tool is paid, which is a relevant usage consideration. However, it does not explicitly name alternatives or state when NOT to use it, though sibling names provide some implicit guidance.
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?
With no annotations, the description carries the full transparency burden. It discloses the return categories, the chain-specific checks performed, and the automatic payment mechanism with cost. This goes beyond a simple 'safety check' by exposing what checks happen and that it is a paid operation. It does not detail failure modes or data sources, but the essential behavior is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise paragraphs. The first sentence states the main action and output, the next sentences list key checks, and the final paragraph covers cost. Every sentence adds value, and the structure is front-loaded with the most critical usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the outcome (GO/CAUTION/DANGER) and includes chain-specific criteria. It covers both supported chains and payment context, making it reasonably complete for a two-parameter tool. Some detail on the response format beyond the label would improve completeness, but it is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters fully described in JSON Schema. The description does not add much beyond the schema, though it reinforces the meaning of 'token' by showing chain-specific address formats. Baseline 3 is appropriate because the schema already documents parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Safety check') and clearly identifies the resource ('a token') and scope ('Solana / Robinhood Chain'). It explicitly states the output is a GO/CAUTION/DANGER rating, which distinguishes this safety tool from sibling price, supply, or yield tools. The phrase 'Use for any unfamiliar token' reinforces its distinct 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear when-to-use guidance: 'BEFORE buying or swapping' and 'Use for any unfamiliar token.' It does not explicitly name alternative sibling tools or explain when not to use, but the context is unambiguous enough for selection decisions. The paid-tool warning also helps the agent know cost implications.
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?
With no annotations provided, the description conveys the key behavioral trait of being a paid tool (up to $0.015 USDC.e per call, paid automatically). It also implies a read-only 'snapshot' nature. However, it does not disclose details like what happens on insufficient balance or data freshness, which would warrant a higher 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with two sentences: the first states purpose and cost advantage, the second explains payment details. Every sentence adds value and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description provides a high-level summary of what is returned (price, supply, safety flags). It also covers cost and payment, which is critical context. It doesn't elaborate on 'safety flags' or MPP specifics, but for a simple snapshot tool this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, fully defining both parameters (token contract address and chain). The description adds no additional parameter-level semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is a 'one-shot token overview' combining price, supply, and safety flags, which distinctly sets it apart from sibling tools like token_price, token_supply, and token_rugcheck. It also emphasizes the cost advantage, reinforcing its 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says it's 'cheaper than three separate calls', implying when to use this tool instead of calling the individual price, supply, and safety tools. However, it does not explicitly state when NOT to use it (e.g., if only one data point is needed), 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the paid nature ('up to $0.005 USDC.e per call') and automatic payment, which are critical behavioral traits. It also states the output (amount and percentage), but does not mention whether the call is read-only or any external side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two paragraphs: the first explains functionality in one sentence, the second provides essential cost/payment info. No fluff, and the line break aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description names the two key values returned (amount burned, % of total supply) and the verification purpose. It includes cost/payment details, making it complete for a simple single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (address described as 'Token contract address'), and the description adds no additional parameter detail beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'Burn stats for a token on Robinhood Chain: amount sent to burn addresses and % of total supply burned.' This is specific and distinguishes it from siblings like token_supply or token_rugcheck, focusing on deflationary claims.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying 'Verifies deflationary claims,' giving a clear contextual use case. It does not explicitly mention exclusions or alternative tools, but the purpose is clear enough to guide selection among similar tools.
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?
No annotations are provided, so the description carries the burden. It discloses that the tool is 'FREE' (no cost), that it lists 'every' paid tool (comprehensive scope), and that pricing is in USDC.e. This goes beyond the schema and provides useful behavioral context, though it does not explicitly state read-only nature or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key differentiator 'FREE,' immediately followed by the action and scope. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, this description is sufficiently complete. It explains what the tool does, the cost implication, and the recommended usage order. It could add a note about read-only semantics, but given the simplicity, it covers essential context well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to document. The description correctly omits parameter details. The baseline for 0-parameter tools is 4, and the description adds no unnecessary param information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lists') and resource ('every paid tool in this server') with a clear scope ('with its price in USDC.e'). It clearly distinguishes itself from sibling tools by being the only tool that lists paid tools and prices, rather than providing market data or wallet info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'Call this FIRST to see what is available and what it costs,' giving clear contextual usage. It does not mention alternatives or exclusions, but as a unique listing tool, there are no direct alternatives to compare against.
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:

[![boo-mpp-mcp MCP server](https://glama.ai/mcp/servers/lucle87/boo-mpp-mcp/badges/card.svg)](https://glama.ai/mcp/servers/lucle87/boo-mpp-mcp)

Score Badge

Copy to your README.md:

[![boo-mpp-mcp MCP server](https://glama.ai/mcp/servers/lucle87/boo-mpp-mcp/badges/score.svg)](https://glama.ai/mcp/servers/lucle87/boo-mpp-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/lucle87/boo-mpp-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server