Carbon Cashmere MCP Server

Official

by CarbonCashmere

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v0.2.2
Disambiguation5/5
Each tool targets a distinct metric or action across Bitcoin, Kaspa, Bittensor, and safety domains. Despite many tools, descriptions clearly specify unique data (e.g., per-subnet metrics vs. overall network fundamentals), so an agent can reliably select the correct one.
Naming Consistency5/5
All tools follow a rigid pattern: HTTP method (get_/post_) + version (v1) + category path + specific resource. This uniform convention makes the API predictable and easy to navigate programmatically.
Tool Count3/5
59 tools is well above the typical 3-15 range, but each provides a distinct piece of crypto data or a specific safety check. The count is justified by the server's broad scope (multiple blockchains and safety), though it borders on excessive.
Completeness4/5
The server covers core analytics for Bitcoin, Kaspa, and Bittensor, plus safety checks. Gaps are minimal given its read-only nature; missing endpoints (e.g., a generic search) are not core to the stated purpose.
Average 3.7/5 across 59 of 59 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed 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
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose read-only nature, rate limits, or what data is returned (e.g., time granularity, historical depth). The disclaimer 'not investment advice' is unrelated to behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Relatively short but includes extraneous details like 'Price: $0.02' and 'Category: kaspa' which do not help tool selection. Core purpose could be front-loaded better.
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 the output format, time range, or units. It only states 'transaction count over time' but lacks specifics, leaving the agent uncertain about what data to expect.
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?
No parameters exist, so schema coverage is 100%. The description adds no parameter info (none needed). Baseline 4 applies per guidance.
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 'Kaspa mempool transaction count over time' which identifies the specific resource and action. It distinguishes from sibling tools like get_v1_kaspa_derivatives_supply_trend or get_v1_kaspa_derivatives_recent_blocks by focusing on mempool pulse. However, phrases like 'AI agent API' and 'not investment advice' add noise.
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 on when to use this tool versus alternatives. Among siblings, there are other mempool-related tools (e.g., fee estimates) but no explicit comparison or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the tool is sub-second, anonymous, and pay-per-use at $0.50. However, there is a critical contradiction: the input schema is empty (no parameters), but the description implies that the tool accepts URLs, crypto wallets, messages, or phone numbers as input. This inconsistency undermines transparency and could mislead an AI agent about how to invoke the tool.
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 concise, front-loading key functions and outcomes. Each sentence serves a purpose, though some details like 'Pay-per-use, multi-chain settlement' could be streamlined. It remains easily readable and scannable.
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?
Given the absence of an output schema and the contradiction regarding input, the description is incomplete. It explains what the tool does and outputs but fails to clarify how to provide the required input (URL, wallet, etc.), which is essential for invocation. The empty input schema suggests the tool takes no arguments, contradicting the description.
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, and the schema coverage is 100% (empty). The description adds context about the types of inputs it processes (URLs, wallets, etc.), which goes beyond the schema. With no parameters, the baseline score is 4, and the description provides useful but non-parameter-specific guidance.
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's function: providing an instant fraud and phishing verdict for URLs, crypto wallets, messages, or phone numbers. It specifies the return values (safe, warning, scam, uncertain) with confidence and reasons. However, it does not explicitly differentiate from similar sibling tools like post_v1_safety_check_deep or post_v1_safety_check_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that it is built for autonomous agents to screen counterparties before acting, providing a clear use case. However, it fails to specify when not to use this tool or suggest alternative siblings (e.g., batch or deep check) for different needs, leaving some ambiguity about tool selection.
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 lists included metrics and mentions data source ('continuous own price observation') but does not disclose computational cost, caching behavior, or permission requirements. With no annotations, the description carries burdens it partially meets.
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 three sentences with clear structure: core functionality, disclaimer, metadata. No fluff, though the price and category could potentially be omitted without loss of clarity.
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 description lists metrics but does not describe the output format or structure. With no output schema, the agent lacks information on how to interpret the response. The simple single-parameter input is well-covered.
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% and the parameter 'netuid' is described with examples. The tool description adds no additional parameter context, so baseline 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 provides a risk profile for Bittensor alpha-tokens including specific metrics like volatility and drawdown. It distinguishes itself from sibling tools by focusing on risk, but does not explicitly differentiate from similar subnet-specific tools.
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 on when to use this tool versus alternatives. The disclaimer about research data hints at context but does not specify prerequisites or exclusion 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?
With no annotations, the description carries full burden. It explains the analysis (contract analysis, deployer reputation) and output (verdict types). However, it does not specify the input mechanism (token identification) despite implying input is needed. This omission reduces transparency, as the empty schema suggests no input, conflicting with the description's narrative.
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 well-structured and front-loaded with the key term. Each sentence adds value, covering purpose, method, target users, price, and category. It is concise for the information it conveys. However, the omission of input specification is a structural flaw that prevents a perfect score.
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?
Given no output schema and no annotations, the description must be self-contained. It provides output format (verdict types) and analysis factors, but fails to clarify how the tool receives the token identifier. This is a significant gap for a tool that seemingly requires input. The description is incomplete in a critical aspect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage (trivially), so baseline is 3. The description adds no parameter semantics and instead introduces confusion by implying a token input without specifying how it is provided. It fails to add meaning beyond the schema and actually undermines clarity.
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's purpose: providing a rug-pull and honeypot verdict for ERC-20 tokens across 7 EVM chains. It specifies the action (safety check), resource (token), and output (verdict with reasons). However, the input schema has no parameters, creating ambiguity about how the token is specified, which slightly diminishes clarity.
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 indicates the tool is 'built for trading agents to vet a token before they buy,' providing context. It also mentions price and category. However, it does not explicitly differentiate itself from sibling safety check tools (e.g., post_v1_safety_check_standard) or state when not to use it (e.g., for batch checks). Guidance is present but minimal.
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?
No annotations provided; the description does not disclose behavioral traits such as authentication needs, rate limits, or error handling. It only mentions data source and informational nature.
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 relatively concise with key information upfront. However, it includes extraneous details like price and category that may not be essential for an AI agent.
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 tool with no output schema, the description covers what it returns (emission/stake trend) and available windows, but lacks details on output format, pagination, or limits.
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 parameter description already mentioning example identifiers. The tool description adds no significant extra 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns hourly emission and stake trend for a Bittensor subnet with time windows. It distinguishes from sibling tools by specifying the exact resource and action, e.g., subnet-momentum tracking.
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 like other subnet-specific tools. It only implies usage for momentum tracking but lacks exclusions or sibling differentiation.
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 provided. The description lists return metrics and notes price and category, but does not disclose behavioral traits like read-only nature, rate limits, or side effects. It provides some transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence listing many metrics plus two short sentences for price and category. It is concise and front-loads the key information, but the list could be more structured (e.g., bullet points).
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?
Given the single parameter and no output schema, the description covers the return values adequately but lacks context on how the height parameter works exactly (e.g., numeric block height vs. asset symbol). The schema description for 'height' is ambiguous, but the description does not clarify.
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 parameter 'height', so baseline is 3. The description does not add any additional meaning about the parameter beyond what the schema provides. It mentions 'per-block' implying height, but no extra detail.
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?
Description clearly states it returns per-block Bitcoin data with a specific list of metrics. The verb 'returns' and resource 'per-block Bitcoin extract' are clear. It somewhat distinguishes from sibling 'get_v1_btc_derivatives_blocks_range' by focusing on a single block by height, but does not explicitly differentiate.
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 on when to use this tool vs alternatives. It does not mention prerequisites, when not to use, or which sibling tools might be better for different scenarios.
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?
No annotations are provided, so the description must carry full behavioral disclosure. It mentions 'filtered' and 'finalized blocks' but omits details on authentication, rate limits, stream format, or data retention. The claim of 'filters supported' contradicts the empty input schema, leaving behavior unclear.
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 concise at five sentences, including unique selling point and pricing. It front-loads the core function and avoids unnecessary elaboration, though price and category may be extraneous for tool selection.
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?
For a streaming tool with no output schema, the description misses key context: how to consume the stream, filter syntax, and what events are included. The mention of filters without schema parameters further reduces completeness.
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?
With zero parameters and 100% schema description coverage, the description adds no parameter information beyond the schema. Per guidelines, baseline is 4 for no parameters, and there is no contradiction or missing info.
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?
Description clearly states it provides a filtered event stream from finalized Bittensor blocks, with module/event filters supported. It distinguishes itself by capturing events that disappear from public lite-node APIs, which sets it apart from sibling tools like get_v1_subtensor_derivatives_block_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 for accessing events that are otherwise unavailable, but it does not explicitly state when to use this tool versus siblings like get_v1_btc_derivatives_reorg_stream or other event-related tools. No exclusions or 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes the data source (node estimator) and nature (informational research), but fails to mention key traits like whether it is read-only, data freshness, caching behavior, or any required permissions. It does not contradict any annotations because none exist.
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 concise, front-loading the core function ('Kaspa live fee market') in one sentence, followed by a disclaimer and metadata. The inclusion of 'Price: $0.03' and 'Category: kaspa' is slightly extraneous but does not significantly harm readability. It could be trimmed, but overall it is efficient.
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?
Given the tool's simplicity (no parameters, no output schema), the description provides moderate completeness. It indicates the tool returns feerate buckets but does not specify the exact structure (e.g., object with fields priority, normal, low). For a zero-parameter tool, this is adequate but not highly informative. An explicit format would improve completeness.
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 and schema coverage is trivially 100%. The description adds context by naming the output fields (priority/normal/low feerate buckets) and source (Toccata RPC), which goes beyond the empty schema. According to guidelines, 0 parameters baseline is 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 retrieves live fee estimates (priority/normal/low) from Kaspa's node estimator (Toccata RPC). It specifies the source and scope, making the purpose clear. While it distinguishes from unrelated tools, it does not explicitly differentiate from sibling Kaspa fee tools like get_v1_kaspa_derivatives_fee_regime, which might have a similar 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?
The description provides no guidance on when to use this tool vs alternatives, nor does it mention prerequisites or limitations. The disclaimer 'not investment advice' is not a usage guideline. Agents are left without context for appropriate invocation.
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?
No annotations provided, so description carries full burden. It does not disclose behavioral traits like read-only nature, response format, or rate limits. The 'Informational research data' label is too vague about 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?
Four sentences are efficient and front-loaded. Each sentence adds meaningful info: data description, unique aspect, disclaimer, pricing/category. No wasted words.
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, the description adequately covers the purpose and data content. Includes pricing and category. Could mention that response is a JSON object, but not strictly necessary.
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?
No parameters, so schema coverage is 100%. Description adds value by explaining the data content (fee-bucket distribution, hardfork analytics), which goes beyond the empty 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?
Description clearly states it provides fee-bucket distribution and pre/post-hardfork fee analytics, distinguishing it from sibling tools like fee_estimate and toccata_status. The verb is implied, but the resource and scope are specific.
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 on when to use this tool vs alternatives. The disclaimer 'not investment advice' is not usage guidance. No comparison to sibling tools such as fee_estimate or toccata_status.
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 full burden. It states the tool returns recent blocks with max 144 and optional filter but does not disclose return format auth needs or rate limits. For a read-only endpoint this is minimally adequate but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but includes unnecessary details like price and category. The mention of a nonexistent parameter harms clarity. Structure is acceptable but accuracy is compromised.
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?
Given zero parameters and no output schema the description should fully document the tool. It omits the definition of the mentioned 'chain_only' parameter and does not describe the response format. This leaves the agent without critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties but the description mentions an optional 'chain_only' flag which is not present in the schema. This is misleading and contradictory thus the description fails to add meaningful parameter 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 returns recent Kaspa blocks with a maximum of 144 per call an optional chain_only filter. It distinguishes itself from sibling tools like get_v1_kaspa_derivatives_blocks_block_hash which fetches specific blocks.
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 indicates it is for backtesters and indexers and includes note about informational research data. However it does not explicitly compare to sibling tools or state when not to use this tool.
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 provided, so the description carries full burden. It discloses it is historical, server-side aggregated, max 1000 points, and informational only. It also mentions months of collection and price. However, it lacks details about potential side effects, response format, or data freshness.
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?
Description is a single sentence with a list of metrics, concise and front-loaded. It includes key info like max points and price. Could be slightly more structured with line breaks, but it is efficient.
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?
No output schema, but description lists metrics and limits. However, it does not specify time units, data format, or whether data is daily, hourly, etc. More detail would improve completeness.
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?
Input schema has zero parameters, so description does not need to add parameter semantics. It compensates by listing the metrics returned, which gives meaning to the output. Baseline for 0 parameters is 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 it returns historical timeseries of Kaspa network metrics and lists specific metrics like hashrate, difficulty, etc. It distinguishes from other Kaspa tools by being a broad aggregated timeseries, though it could explicitly differentiate from similar sibling tools like supply_trend.
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. It does not mention prerequisites, limitations, or cases where other tools 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like recency, pagination, or permissions. It only lists events and mentions price/category, but does not explain how 'recent' is defined, whether data is cumulative, or the output 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of one sentence plus metadata. It is front-loaded with the purpose, though the list of events could be more structured. Still, it efficiently conveys core information.
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?
For a tool with no output schema and no annotations, the description lacks details on the output structure, time range, or update frequency. The agent cannot fully understand what the response looks like or how recent the data is.
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?
There are no parameters (schema coverage 100% trivially). The description adds context about the returned data (list of events and total TAO), which is valuable given no output 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 the tool returns a recent per-block aggregation of Bittensor events, listing specific event types. This distinguishes it from sibling tools that focus on individual event types or broader aggregations.
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 such as get_v1_subtensor_derivatives_event_stream or get_v1_subtensor_derivatives_registration_pulse. The description lacks when-to-use or when-not-to-use instructions.
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?
No annotations are provided, so the description must fully convey behavioral traits. It mentions the data is per hour and research-oriented, but does not disclose idempotency, rate limits, or whether the tool is safe (read-only). The lack of annotations and behavioral detail makes it insufficient for 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core purpose in the first sentence. However, it includes pricing and category which, while potentially useful, add minor length. Overall, it is efficient with minimal fluff.
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?
Given the low complexity (no parameters, no output schema), the description covers the basic data and audience. However, it lacks details on response format, time range, or pagination, leaving some ambiguity about what the agent will receive.
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 has zero parameters, so schema coverage is effectively 100%. The description adds value by explaining what data the tool returns (weights activity per hour), which is useful context beyond the empty 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 it tracks 'Bittensor WeightsSet + TimelockedWeightsCommitted/Revealed activity per hour' and mentions validator weight-setting cadence and anti-frontrun mechanism. The purpose is specific and distinguishable from sibling tools like registration_pulse or block_metrics, though it does not explicitly differentiate them.
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?
It identifies the target audience as 'AI agent API for validator-behavior analysts' and notes it is 'informational research data — not investment advice.' This implies usage context but lacks explicit when-to-use or when-not-to-use guidance, nor does it compare with alternatives.
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?
No annotations provided; description carries full burden. Disclaims 'not investment advice' and notes data frequency (every 10 minutes), but does not disclose return format, pagination, error handling, or rate limits. Missing behavioral traits beyond basic data source.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences plus disclaimers and price/category. It is relatively concise but includes extraneous info (price, category) that could be omitted or structured better. Not excessively long.
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?
Tool has 1 param, no output schema, and low complexity, but description omits critical details: return structure (list of price points? timestamps?), pagination, and error handling. For a time-series tool, return format is essential and missing.
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 has 100% coverage for netuid with a generic example list. Description adds domain context ('Bittensor subnet'), clarifying that netuid refers to a subnet identifier. This adds meaningful value beyond the schema's minimal description.
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 clearly states verb ('Time-series of alpha-token price'), resource ('single Bittensor subnet'), and scope (window options: 1h/24h/7d/30d). It distinguishes from sibling tools by specifying 'single subnet' and data source (bittensor_alpha_prices every 10 minutes).
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?
Provides context ('alpha-token trading signals') and window options, but no explicit when-to-use vs alternatives (e.g., when to use this over get_v1_bittensor_derivatives_alpha_prices or other subnet-specific tools). Lacks exclusions or preconditions.
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?
With no annotations, the description carries full burden. It only includes a disclaimer ('not investment advice') but does not disclose behavioral traits such as read-only nature, rate limits, caching, or response size. The tool is likely a read operation, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences. The purpose is front-loaded, but it includes extraneous elements like price and category which are not essential for understanding the tool's function. Could be more concise.
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?
For a tool with no output schema and no annotations, the description should explain expected output structure (e.g., list of validators with fields). It does not mention return format, ordering, or pagination, leaving the AI agent with gaps.
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% (one parameter with description). The tool description adds the context of 'Top-N' and 'incentive ranking' but does not elaborate on accepted netuid values beyond the schema's examples. It meets the baseline for a well-covered 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 'Top-N validators ranked by incentive for tracked Bittensor subnets' and specifies a filter ('validator_permit=true'). This distinguishes it from sibling tools like get_v1_bittensor_derivatives_subnet_netuid (general subnet data) and get_v1_bittensor_derivatives_top_validators_cross_subnet (cross-subnet).
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?
It explicitly says 'AI agent API for validator-selection and stake-delegation decisions', providing a clear use case. However, it does not explicitly mention when not to use it or name alternatives like the cross-subnet tool, missing some exclusion 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 provided, so the description carries the full burden. It mentions 'Informational research data — not investment advice' and 'Price: $0.02', which are minor behavioral traits. However, it lacks details on side effects, rate limits, authentication requirements, or idempotency. Given the absence of annotations, more transparency is expected.
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 with two sentences plus price and category. It is front-loaded with the core purpose and key details. No unnecessary words.
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?
Given it's a single-parameter tool with no output schema, the description offers a reasonable overview of the response content (DAG topology fields). However, the parameter confusion and lack of guidance on expected block_hash format reduce completeness. It also doesn't mention whether the full block data is included.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one parameter 'block_hash' with description mentioning examples like BTC, ETH, SOL, which is confusing for a Kaspa-specific tool. The main description does not clarify the correct format or expected values. Schema description coverage is 100%, but the provided description is misleading, and the main text adds no additional meaning.
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 it extracts a single Kaspa block with full DAG topology, including specific fields like parents, selected-parent, blue/daa score, and chain-block flag. It distinguishes itself from sibling tools by specifying 'single block extract' and 'full DAG topology', contrasting with other Kaspa tools that cover recent blocks, supply trends, etc.
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 on when to use this tool vs. alternatives. It says 'AI agent API for DAG-aware indexers' but does not mention when not to use it or point to sibling tools like get_v1_kaspa_derivatives_recent_blocks or get_v1_kaspa_derivatives_dag_state for different use cases.
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?
No annotations are provided, so the description must fully disclose behavioral traits. It does not state read-only nature, side effects, authentication needs, or data freshness. The disclaimer about 'not investment advice' is a legal note, not a behavioral trait. Some transparency on data source (archival node) but insufficient.
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?
Description is two sentences plus a trailing note about price and category. It is front-loaded with the key metrics. Could be slightly more concise by removing 'Informational research data — not investment advice.' but overall efficient.
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?
Given zero parameters and no output schema, the description is the sole source. It lists many specific outputs, which is helpful, but lacks any indication of the response structure (e.g., data format, units) or pagination. Adequate but not 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?
There are zero parameters, so baseline is 4. The description adds no parameter information because none exist. It does not mislead or omit anything in this dimension.
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 explicitly lists specific metrics (KAS/USD revenue per TH/s/day, block subsidy, DAG-aware emission rate, electricity-cost model) and clearly states it provides Kaspa mining economics from their own archival node. It distinguishes itself from sibling tools like get_v1_kaspa_derivatives_supply_trend or get_v1_kaspa_derivatives_network_hashrate by focusing on economics.
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 on when to use this tool versus alternatives. It does not mention any prerequisites, scenarios, or exclusions. Usage is only implied by the description of what data it returns.
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 data source (Toccata RPC), the cost ($0.05), and notes that it is informational research data not investment advice. This provides useful behavioral context beyond the obvious 'read-only' nature of a GET endpoint. However, it does not specify data freshness, error conditions, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise but includes some redundant or jargon-heavy phrases like 'Post-fork mining-security telemetry' and 'Informational research data — not investment advice.' While these add context, they could be trimmed to improve clarity and directness.
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 description states what the tool returns (hashrate and difficulty trend) but does not specify the output format (e.g., single value or time series) or whether it returns current or historical data. For a zero-parameter tool with no output schema, more detail on the response structure would improve completeness.
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?
There are zero parameters, so the schema is empty. Baseline for 0 parameters is 4. The description does not need to add parameter meaning, and it does not attempt to do so.
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 it returns Kaspa network hashrate (H/s) and difficulty trend from direct node measurement (Toccata RPC). It specifies the source and context (post-fork mining-security telemetry). However, it does not explicitly differentiate itself from sibling tools like get_v1_kaspa_derivatives_supply_trend or get_v1_kaspa_derivatives_recent_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (post-fork monitoring) but no explicit guidance on when to use this tool versus alternatives. There is no mention of scenarios where this tool is appropriate or inappropriate, nor any comparison to sibling tools. The agent must infer usage from the tool's name and description alone.
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?
No annotations are provided, so the description must disclose behavioral traits. It mentions the tool is informational and not investment advice, but it does not explicitly state that the tool is read-only, specify data freshness, rate limits, or what happens if data is unavailable. The price is given but not a behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (5 sentences) but includes extraneous details like 'AI agent API for cross-VM adoption analysts' and 'Category: general', which are not essential. The first sentence has a typo (missing space after period). It could be more tightly worded while maintaining clarity.
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?
Given no output schema and minimal annotations, the description lacks details about the response format, time range, or data interpretation. It states it returns 'call count per hour' but does not specify if the response includes timestamps or other fields, leaving the agent uncertain.
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 no parameters, so parameter semantics are trivially handled. Baseline is 4 due to 0 parameters; the description adds no parameter information but none is 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 clearly states the tool returns 'Executed call count per hour' for 'EVM-on-Bittensor Ethereum', distinguishing it from sibling tools focused on other metrics (e.g., registration, blocks, events). It specifies tracking 'TaoEVM dApp adoption', which is a specific resource and action.
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 use for EVM activity analysis, but it does not explicitly state when to use this tool over alternatives (e.g., other subtensor derivatives tools). No when-not or exclusion criteria are provided, leaving the agent to infer 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 must disclose behavior. It lists return fields (neurons and stats) but does not mention read-only nature, authentication, rate limits, or potential size of the snapshot. It includes non-behavioral details like price and category.
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 a single sentence that efficiently conveys scope, fields, and limitations. It is front-loaded with key information, though it includes non-essential price and category, which slightly reduce conciseness.
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?
Given no output schema, the description explains return fields but omits potential size, pagination, or rate limits. It addresses the subnet list but fails to clarify the parameter mismatch, leaving ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's description for netuid uses examples (BTC, ETH, SOL) that contradict the tool's purpose of fetching Bittensor subnet metagraphs with numeric IDs. This misalignment adds confusion instead of clarity, despite 100% schema coverage.
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 it provides a 'Full metagraph snapshot' for specified Bittensor subnets and lists the fields included, distinguishing it from siblings like get_v1_bittensor_derivatives_subnet_netuid_validators which focus on specific aspects.
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 the 13 listed subnet UIDs but does not explicitly state when to avoid or suggest alternatives. It lacks guidance on selecting this over sibling tools that provide related but different data.
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?
No annotations are provided, so the description carries the full burden. It discloses that the data is informational and not investment advice, and mentions a price of $0.10, but does not reveal behavioral traits such as whether the tool is read-only, requires authentication, has rate limits, or any side effects. The description focuses on content, not 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 concise, with no unnecessary words. It front-loads the key metrics (throughput, DAG-width) and includes practical meta-information (price, category, disclaimer). Every sentence adds value.
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?
Given the absence of an output schema and annotations, the description should fully specify the return structure. It lists the metrics ('chain-block rate, estimated total DAG rate, TPS vs multi-month pre-fork baseline') but does not describe the format (e.g., JSON keys, data types, pagination). While it gives a good high-level overview, an agent might need more detail to parse the response correctly.
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 has zero parameters, so schema coverage is trivially 100%. With 0 parameters, the baseline score is 4. The description does not need to add parameter semantics, but it adds context about the returned data (e.g., chain-block rate, TPS baseline) which indirectly helps the agent understand the tool's output.
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 purpose: returning Kaspa throughput and DAG-width metrics, including chain-block rate, estimated total DAG rate, TPS vs pre-fork baseline, and hardfork impact tracking. It is distinct from sibling tools like get_v1_kaspa_derivatives_supply_trend or get_v1_kaspa_derivatives_recent_blocks, which focus on different aspects.
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 its many Kaspa siblings (e.g., get_v1_kaspa_derivatives_dag_state, get_v1_kaspa_derivatives_chain_density). It only states it is informational research data and not investment advice, but does not explain under what circumstances a user should choose this particular endpoint.
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 full burden. It notes the data is from finalized blocks and includes a disclaimer ('not investment advice') and pricing. However, it lacks disclosure of side effects (none expected), authentication needs, rate limits, or output format details, leaving gaps in 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 composed of four short, clear statements. The first sentence efficiently conveys the tool's function and key fields in parentheses. No redundant information, but the structure could be improved by separating the fields list more explicitly.
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?
Given the tool has one parameter and no output schema, the description lists the returned fields (event_idx, phase, module_id, event_id, attributes) which is helpful. However, it does not describe the response count or format (array vs object), and the parameter confusion is not resolved. For a simple tool, it is partially complete but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's parameter description for block_number is misleading (giving BTC/ETH/SOL as examples, which are not block numbers). The tool description does not clarify this, nor does it explain the valid range or format of block_number. With only one parameter and 100% schema coverage, the description adds no value to parameter 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 states the tool retrieves all Bittensor substrate events for a single finalized block and lists the included fields (event_idx, phase, module_id, event_id, attributes). This specific verb-resource pairing distinguishes it from siblings like get_v1_subtensor_derivatives_event_stream (streaming events) and other block-focused tools.
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 provides context ('AI agent API for detailed forensic analysis of specific blocks') but does not explicitly state when to use this tool versus alternatives (e.g., the event stream endpoint). No exclusion criteria or alternative references are given, limiting guidance for an AI agent.
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 discloses cost ($0.02) and category (bittensor-mantis), but does not explain what Tier-A metrics entail, data freshness, authentication, or rate limits. It is adequate but lacks depth.
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?
Two sentences, front-loaded with key information (static metadata, metrics, price). Could be slightly more structured but is concise and efficient.
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?
No output schema is provided, so the description should explain return structure. It lists components but does not specify format or fields. For a data retrieval tool, this is a notable gap, but the parameter is simple and the purpose is clear.
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 parameter (netuid), with the schema providing examples. The description adds no extra semantic value beyond the schema, so 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 provides a per-subnet snapshot including static metadata, latest Tier-A metrics, and current alpha-token price. It distinguishes itself from siblings like get_v1_bittensor_derivatives_subnets_all (all subnets) and get_v1_bittensor_derivatives_alpha_prices (prices only).
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 use for a single subnet (netuid) and mentions it covers all 129 mainnet subnets, but does not explicitly state when to use this tool versus alternatives or provide conditions for use.
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 the description must fully disclose behavior. It mentions 'Neutral' to indicate no bias, and 'Informational research data' to clarify the nature of results. However, it does not disclose whether the tool is read-only, any authentication needs, rate limits, or potential side effects. The 7d comparison hint adds some transparency but is insufficient.
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 sentence immediately lists the metrics returned, and the second adds a disclaimer and metadata (price, category). No unnecessary words; 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?
Given the tool has only one parameter, no output schema, and moderate complexity, the description adequately explains what metrics are returned. It does not specify the return format (e.g., JSON structure), but without an output schema, this is acceptable. The presence of many sibling tools makes the specific listing of metrics valuable.
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% (the only parameter 'netuid' has a clear description in the schema: 'Path parameter netuid (e.g. BTC, ETH, SOL, or other supported identifier)'). The tool description adds no further information about the parameter, so it does not provide additional value beyond the schema. Baseline 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 returns 'concentration & synchrony metrics' for a Bittensor subnet, specifically listing stake/emission concentration, validator dominance, and update-synchrony with 7d comparison. This differentiates it from sibling tools like get_v1_bittensor_derivatives_subnet_netuid which likely provides general subnet info, and other metric-specific tools.
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. It only includes a disclaimer about investment advice and pricing. There are many sibling tools related to subnets, but no explicit when-to-use or when-not-to-use conditions are stated.
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?
No annotations are provided, so the description carries full burden. It only states the data is 'informational research data — not investment advice', but does not disclose if the tool is read-only, destructive, or any auth/rate-limit details.
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 concise, front-loaded with core functionality, and includes helpful metadata (price, category). It is efficient with minimal waste.
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?
Given no parameters and no output schema, the description should clarify the output format. It mentions 'breakdown' and 'distribution' but does not specify structure. Use cases help but completeness is moderate.
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 with 0 parameters, so schema coverage is trivially 100%. The description adds no parameter details, but baseline for 0 parameters is 4.
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 'Kaspa own-node peer-network breakdown (IPv4/IPv6) + user-agent distribution', which is a specific verb+resource. It distinguishes from siblings like 'get_v1_btc_derivatives_diversity' by asset (Kaspa).
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 mentions use cases ('network-health monitoring, node-operator analytics') but does not provide explicit when-to-use or when-not-to-use guidance, nor does it differentiate from other Kaspa health tools 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 carries full burden. It discloses that the data is informational, not investment advice, and mentions a price. It also specifies the retrospective nature. However, it does not cover error behavior, rate limits, or authentication requirements, which are typical 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 a single paragraph of three sentences, covering the tool's purpose, content, constraints, disclaimers, and price. Every sentence adds value with no redundancy or wasted words.
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 one parameter and no output schema, the description explains what the output contains (distributions, scores, features) and categorizes it as a benchmark dataset. It lacks a full list of supported 'challenge' values, but examples are given. Overall, it is nearly complete for 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?
Schema coverage is 100% with one parameter 'challenge'. The description gives examples (BTC, ETH, SOL) but adds no semantics beyond the schema. Baseline of 3 is appropriate as the schema already defines the parameter adequately.
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 historical AI forecast outputs with realized outcomes, specifying content (5-bucket distributions, scores, features) and that it is a benchmark dataset. However, it does not explicitly differentiate from the sibling tool 'get_v1_mantis_forecast_scorecard', which may have a similar purpose.
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 mentions the tool is strictly retrospective (24h maturity gate) and not current signals, implying when to use it. It does not explicitly state when not to use it or mention alternatives, but the context is clear enough for basic usage decisions.
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?
No annotations are provided, and the description does not disclose behavioral traits such as rate limits, authentication requirements, data freshness, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with four sentences, front-loading the core function. Minor fluff like price and category could be omitted but does not harm clarity.
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?
Given no parameters and no output schema, the description adequately explains what the tool returns, but lacks expectations about output format or pagination. Adequate for a simple 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?
Input schema has no parameters, so description does not need to add parameter details. Schema coverage is 100% by default, meeting the baseline for no-parameter tools.
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 it provides 'Bittensor NeuronRegistered count per hour' and explains utility for subnet growth analysis. It distinguishes itself from sibling tools by specifying a unique metric.
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 mentions 'AI agent API for subnet-health analysts' implying usage context, but does not specify when to use this tool versus alternatives or provide when-not 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?
Discloses 10-minute snapshot frequency, adding behavioral context beyond the empty schema. No annotations provided, so description carries burden; lacks details on rate limits or data freshness guarantees.
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?
Description is a single, well-structured sentence with a list and extra tags. The 'Price: $0.02' and category info are slightly tangential but not harmful; could be more concise.
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 parameterless, read-only tool, the description sufficiently covers output fields and update frequency. No output schema exists, so listing fields is helpful. Lacks explanation of data source or potential delays.
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 has no parameters, so coverage is 100%. Description adds value by listing returned fields (total issuance, stake, etc.), guiding the agent on what data to expect.
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 clearly states it returns 'Latest TAO network-wide fundamentals' and lists specific metrics. The name is explicit about network fundamentals, distinguishing it from sibling tools like subnets or registration.
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 on when to use this tool versus alternatives. Mentions snapshot frequency but doesn't explain trade-offs or when not to use it.
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 burden. It discloses the return format (verdict per item plus worst verdict), price, and category but does not mention side effects, authorization, rate limits, or whether it is read-only, leaving behavioral gaps.
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 reasonably concise, front-loading the tool name and purpose, then adding details on input types, cost benefit, and output. It could be slightly shorter but is well-organized.
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 batch tool with no output schema and a contradictory parameter schema, the description partially covers output but leaves input mechanics unclear, making it incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, but the description implies items are passed (URLs, wallets, etc.), creating a mismatch. Since the schema is empty, the description fails to clarify how to send the input, reducing usefulness.
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 performs a batch safety check on up to 10 items (URLs, wallets, messages, phone numbers), distinguishing it from single-check siblings by emphasizing batch processing and cost savings.
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?
It indicates the tool is for agents triaging many counterparties or links quickly, implying batch usage. However, it does not explicitly state when not to use it (e.g., for single items or deeper checks) despite having siblings like post_v1_safety_check_standard and deep.
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 mentions 'from months of continuous high-cadence snapshots', indicating historical data, but does not disclose data freshness, real-time vs static nature, or any side effects. The price and category are given but do not address behavioral concerns. Lacks clarity on potential issues like rate limits or output size.
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: one sentence conveying purpose, followed by a disclaimer and metadata. Every part is necessary and front-loaded. No fluff 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?
For a single-parameter tool with no output schema, the description explains the core metrics (accumulation/distribution, net flow, concentration trend) and temporal scope (months of snapshots). It lacks details on output format or interpretation, but given the straightforward input, it is fairly complete. The price and category add mild context.
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 only parameter (netuid), which is well-described in the schema as a path parameter with examples. The description reinforces 'per subnet' but adds no new semantic information beyond the schema. Thus 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?
The description clearly states what the tool does: 'dTAO stake-flow microstructure per subnet: per-neuron accumulation/distribution, net flow, concentration trend'. It specifies the resource (subnet identified by netuid) and the type of data (stake flows). This differentiates it from sibling tools like get_v1_bittensor_derivatives_subnet_netuid (general subnet info) and get_v1_bittensor_derivatives_alpha_prices (alpha 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 usage for stake-flow analysis but does not explicitly state when to use it versus alternatives. There is no mention of when not to use it or which other tools to consider. The disclaimer 'Informational research data — not investment advice' provides context but no comparison to 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?
No annotations are provided, so the description must fully disclose behavioral traits. The description states it returns a leaderboard but does not explain what 'Top-N' means, the number of results, update frequency, response format, or any constraints like rate limits. This lacks sufficient transparency for an agent to understand the tool's behavior.
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 concise at three sentences plus price and category, front-loading the main purpose. It is efficient but could be slightly more structured (e.g., bullet points for multiple facts).
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?
Given no parameters and no output schema, the description provides the essential purpose, price, and category. However, it lacks details like the definition of 'Top-N', update cadence, or how results are structured, leaving some context incomplete for an agent.
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, and the input schema is empty with 100% coverage. Per the rubric, baseline score is 4. The description does not need to add parameter semantics, and it accurately notes no parameters are required.
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 top-N validators per tracked Bittensor subnet, aggregated across 13 focus subnets, providing a cross-subnet leaderboard. It distinguishes itself from subnet-specific sibling tools by specifying cross-subnet aggregation and use case.
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 mentions the tool is for cross-subnet validator research and stake allocation decisions, providing a clear use case. However, it does not explicitly state when not to use it or direct to alternative tools for subnet-specific data, which would improve 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?
With no annotations provided, the description carries full burden for behavioral traits. It mentions a price of $0.02 but does not disclose details like rate limits, authentication requirements, data freshness, or side effects. The absence of parameters simplifies behavior but transparency is still limited.
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 one sentence with additional metadata (price, category, caution). It is concise and front-loaded with key details. Minor extra information like 'not investment advice' is acceptable for clarity.
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?
Given no output schema and no annotations, the description provides the core purpose and audience but lacks details on data format, update frequency, or pagination. For a parameterless research data endpoint, it is adequate but not fully comprehensive.
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?
There are no parameters, and the schema coverage is 100% (no params to describe). The description adds context about the returned data (diversity distribution and privacy share), which compensates for the lack of an output schema. Score is baseline 4 for zero 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 specifies the tool returns Bitcoin own-node peer-network diversity data including IPv4/IPv6/Tor/I2P/CJDNS distribution and privacy share. The target users and category are mentioned, distinguishing it from sibling tools like the Kaspa diversity tool.
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 identifies target audiences (privacy researchers, node operators, network-health analytics) and states it's informational research data, not investment advice. However, it does not explicitly state when to use this tool versus alternatives or when not to use it.
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?
With no annotations, the description carries full burden for behavioral disclosure. It mentions the metric and price, but lacks details on update frequency, response format, or any side effects. The description does not contradict annotations, but omits important behavioral traits.
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 four sentences, each adding distinct value: metric definition, uniqueness, application signal, and pricing. No filler. Front-loaded with the core purpose.
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 parameters and no output schema, the description adequately explains what the tool measures and its uniqueness. It could optionally describe the output format (e.g., time series), but the core context is sufficient for an agent to decide applicability.
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 has no parameters, and schema_description_coverage is 100% (empty schema). The description adds no parameter info because none exist, so baseline 4 is appropriate. No additional value 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 clearly states the tool measures 'chain-blocks vs total DAG blocks per hour', specifying the resource (Kaspa chain blocks) and the metric (ratio). It distinguishes from siblings by highlighting it's a 'unique signal not available from generic block-explorer APIs' and measures 'BlockDAG branching activity'.
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 through phrases like 'measures BlockDAG branching activity' and 'Chain ratio drift signals DAG-mode shifts', but does not explicitly state when to use this tool versus alternatives among the many Kaspa sibling tools. No when-not or direct comparisons are provided.
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 full burden. It adds context that the data is informational, not investment advice, costs $0.03, and captures the halving schedule. However, it lacks details on return format, pagination, or any side effects. The transparency is moderate.
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 concise, with a few sentences covering data, use case, disclaimer, and cost. It is front-loaded but could be more structured. Every sentence adds value, though the disclaimer and pricing could be placed after the core description.
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?
Given no output schema and no parameters, the description should fully describe what the tool returns. It lists three data points (supply, emission rate, percent-mined) and mentions halving schedule. However, it lacks information on time range or granularity (e.g., daily, hourly), leaving some ambiguity.
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?
There are no parameters, so the description cannot add parameter information. Schema coverage is trivially 100%. Per guidelines, baseline 4 applies for zero-parameter tools.
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 'Kaspa circulating supply over time + emission rate + percent-mined' and references the geometric halving schedule. It distinguishes from sibling tools by focusing on Kaspa supply/emission, with many siblings for other cryptocurrencies or different Kaspa 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 for 'tokenomics tracking and supply-emission models' but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or when-not-to-use guidance. Given no direct alternative among siblings, the guidance is adequate but not explicit.
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?
No annotations provided, so description must disclose behavioral traits. It mentions AI-powered analysis, higher-confidence verdicts, and reasoning trace, but fails to explain how the tool is invoked (no parameters, no request body guidance), whether it is destructive, rate limits, or what happens on fraud detection. The lack of input schema explanation is a significant gap.
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?
Extremely concise: two sentences, price, and category. Every word adds value. Front-loaded with tool name and core capability. No fluff.
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?
Despite no parameters and no output schema, the description leaves critical gaps: it does not explain how to supply the item to check (e.g., request body requirements), and it references 'Quick' without defining it. An agent cannot reliably invoke this tool without additional context about the request structure.
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?
Input schema has zero parameters, so baseline is 4. Description does not need to explain parameters. However, it could clarify that the tool uses the request body for input, but since schema is empty, it's acceptable. No contradictions.
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 performs a safety check with AI-powered fraud analysis, positioning it as the 'Standard' tier above 'Quick'. It lists specific use cases (onboarding counterparty, approving transfer, vetting suspicious message), effectively distinguishing from siblings like post_v1_safety_check (likely Quick) and post_v1_safety_check_deep.
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 indicates when to use: 'Best when a decision actually matters' with concrete examples. Implies Quick is for less critical decisions, but does not address other siblings like Deep, Batch, or Token, leaving some ambiguity. Still, the guidance is clear enough for high-stakes scenarios.
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 adds behavioral context: 'Informational research data — not investment advice' and 'Price: $0.50', disclosing cost and advisory nature. It also mentions the data source is an independent event archive. Missing details on auth or destruction, but adequate given the informational nature.
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 three sentences, front-loaded with purpose and key details. Including 'Price: $0.50' and 'Category: bittensor-mantis' adds minor but useful context; could be trimmed slightly but remains efficient.
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 (1 param, no output schema, no annotations), the description covers purpose, usage, behavioral caveats, and cost. It is sufficiently complete for an agent to decide to use it.
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%, so baseline 3. The description does not add significant meaning beyond the schema's 'Path parameter netuid (e.g. BTC, ETH, SOL, or other supported identifier)'. It reuses similar examples but no new 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 retrieves a 'subnet-owner reputation verdict' detailing track-record, stake behavior, longevity, and multi-subnet footprint. It distinguishes from sibling tools by focusing specifically on owner reputation for a given subnet netuid.
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 provides a use case: 'Due-diligence before you stake, mine, or invest in a subnet.' However, it does not explicitly mention when not to use it or compare it to alternatives like wallet_ss58_reputation or other subnet-specific 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?
With no annotations, the description carries full burden. It describes the data as 'copy-cluster detection', 'active committers', 'independence score (formula disclosed)', and notes it is 'informational research data'. It mentions the cost ($0.50) and that it is from the 'timelock weight-commit stream'. No destructive behavior is implied. Some details like rate limits or response format are missing, but transparency is generally good.
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 concise and well-structured: it states what the tool does, its purpose, and a caveat. It includes necessary details like price and category. However, the inclusion of 'Price: $0.50' and 'Category: bittensor-mantis' is somewhat extraneous but not harmful.
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?
Given no output schema, the description should clarify the return. It mentions three outputs (copy-cluster detection, active committers, independence score) but does not specify their format or structure. The single parameter is adequately described, but the lack of output details makes it incomplete for an agent to fully understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. However, the description does not add clarity to the 'netuid' parameter; it gives examples (BTC, ETH, SOL) that likely do not match Bittensor's numeric subnet IDs, potentially confusing the agent. The description fails to specify what values are valid, reducing its helpfulness.
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: copy-cluster detection, active committers, and independence score from the weight-commit stream. It explicitly mentions the purpose: to vet a subnet's validation honesty before staking or delegating. This distinguishes it from sibling tools.
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 advises when to use ('before you stake or delegate') and includes a disclaimer ('informational research data — not investment advice'). However, it does not mention when not to use the tool or compare directly with sibling tools, but the clear purpose provides implicit 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?
With no annotations, the description must disclose behavioral traits. It mentions it's a 'snapshot' (implies point-in-time data) and lists the price and category. However, it lacks details on data freshness, response format, or any limitations, which is only partially 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 three clear, front-loaded sentences with no wasted words. It conveys purpose, usage, and pricing efficiently.
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?
While it lists the data fields, it lacks an output schema and doesn't fully describe the return structure (e.g., format, pagination, ordering). For a snapshot of all subnets, more detail on response organization would improve completeness.
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?
There are no parameters, and schema coverage is 100% by default. The description adds no parameter info because none exist. Baseline 3 is appropriate; no extra value or deficit.
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 it returns a 'Snapshot of all 129 Bittensor mainnet subnets' and lists the specific data fields (burn, neurons, owner, modality, alpha-price). This distinguishes it from sibling tools that target individual subnets or specific metrics like alpha prices.
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?
It explicitly says 'For cross-subnet research and market-overview dashboards,' providing clear usage context. While it doesn't mention when not to use or alternatives, the context is sufficient for an agent to understand its broad-scope application.
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 that messages are curated and printable ASCII, and provides a time window, which adds context. However, it does not mention read-only nature, authentication, rate limits, or what happens when the window yields no results.
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 very concise: three sentences with no filler. It front-loads the main purpose and includes key constraints (printable ASCII, 7-day window, price, category). Every sentence serves a purpose.
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?
Given no output schema, the description should compensate by explaining the return format. It describes content (messages, pool tags) and constraints but does not specify whether the output is a list, includes timestamps, or how to interpret results. The simplicity of the tool (no params) partially offsets this, but the gap remains.
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?
There are zero parameters and schema coverage is 100% (trivially). The description adds no parameter details, but none are needed. Per rules, baseline score is 4 for zero 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 it provides curated Bitcoin coinbase scriptSig messages (printable ASCII only), mentioning pool tags, BIP-comment campaigns, and political statements. This is a specific and distinct resource, easily differentiated from sibling tools like 'get_v1_btc_derivatives_fee_curve' or 'get_v1_btc_derivatives_reorg_stream'.
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 mentions a 'Window up to 7d', implying recent messages, but does not explicitly state when to use this tool over alternatives. No exclusions or when-not guidance is provided, so the agent must infer usage context.
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?
No annotations are provided, so the description carries full burden. It does not disclose behavior such as read-only nature, authorization needs, or side effects. It only mentions the data source and that it's research data.
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, front-loading the core purpose and listing specific data points in a clear enumeration, with minimal waste.
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?
Given no parameters and no output schema, the description comprehensively lists the returned metrics (hashprice, revenue, hashrate, etc.) and includes pricing and category, fully specifying the tool's output.
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?
There are no parameters, so schema coverage is 100%. The description adds value by enumerating the output fields, going beyond the empty 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 it returns Bitcoin mining economics data from their own full node, listing specific metrics like hashprice, subsidy + fee revenue, hashrate, etc. It distinguishes itself from siblings by specializing in mining economics.
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 mining economics data but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites.
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 discloses a key limitation (output_btc includes change-outputs) but lacks details on whether the feed is real-time, historical, requires authentication, or has rate limits. Some behavioral context is present but incomplete.
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 three concise sentences, front-loaded with the main purpose and a notable warning. Every sentence adds value without redundancy.
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?
Given no parameters and no output schema, the description explains the nature of the feed and a critical caveat, but it omits details about the return format, update frequency, or how to interpret the enrichments. Adequate but not 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?
With zero parameters, the input schema provides no information. The description does not need to add param details, and the baseline is 4. No contradictions.
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 it is a 'Bitcoin whale transaction feed' with a default threshold of >10 BTC, listing enrichments (fee-rate, RBF flag, ancestor-count) and a warning about output_btc including change-outputs. This is specific and distinguishes it from sibling tools like coin_days_destroyed or mempool_pressure.
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 monitoring large Bitcoin transactions but does not explicitly state when to use this tool versus alternatives (e.g., for net transfers or other feed types). No exclusions or prerequisites are mentioned.
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 full burden. It clearly discloses that data is realized yield based on snapshots (not theoretical), includes 30d daily series and per-validator APR, and is informational research data. No destructive behavior or side effects, but pricing and category are transparently stated.
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 plus pricing and category. No superfluous text. Core information is front-loaded, making it efficient for AI agents to parse.
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 data retrieval tool with one parameter and no output schema, the description adequately covers data nature, time range, and what it is not. It lacks mention of output format or pagination, but given the tool's simplicity, this is acceptable.
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 one parameter 'netuid'. The schema already describes it as path parameter with examples. The description adds context about subnet focus, but does not significantly enhance understanding beyond the schema's explanation. 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?
The description clearly states it provides 'Realized Bittensor validator yield per subnet' and specifies measurement method ('emission/stake from continuous snapshots') and temporal scope ('30d daily series + per-validator APR'). It distinguishes from theoretical APY and sibling tools like mining viability by focusing on yield history.
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 does not explicitly state when to use this tool vs alternatives like stake flows or alpha risk. It only notes that data is informational, not investment advice. Usage context is implied by the tool's purpose but no direct comparisons or exclusions are provided.
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 full burden. It mentions the data source ('independent full event archive') and the informational nature, but does not disclose whether the operation is read-only, potential side effects, or the response format beyond listing components. An output schema or more explicit behavior description would improve this.
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, front-loaded with the core purpose, and includes necessary disclaimers and metadata (price, category) without superfluous information. Every sentence adds value.
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 description covers the tool's purpose, components, use case, and nature of data. However, given the lack of an output schema, more detail on the response structure would be helpful for complete understanding. The inclusion of 'formula disclosed' adds transparency.
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% coverage with a description for the `ss58` parameter. The description adds little beyond calling it a 'Bittensor address', which aligns with the schema. The schema's example mentions BTC, ETH, SOL, which may be inconsistent, but the description does not clarify further. 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?
The description clearly states the tool provides a reputation verdict for a Bittensor address, detailing components like registration track-record, stake-behavior, longevity, and stability score. This distinguishes it from sibling tools that focus on subnet-specific metrics, prices, or other blockchain derivatives.
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 states the use case: 'Counterparty due-diligence for OTC, delegation, and subnet operators.' This gives clear context on when to use the tool. However, it does not mention when not to use it or explicitly compare with alternatives, which would have earned 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?
The description discloses that data is derived from coinbase scriptSig parsing, includes explicit time windows and an Unknown bucket, and provides pricing ($0.03) and category (bitcoin-onchain). Given no annotations, it carries the full burden and does so well for a read-only data tool. It doesn't mention side effects, but reads are inherently safe.
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 plus a pricing and category line. Every sentence adds value, and the key information (data source, metrics, windows, explicit unknown handling) is front-loaded. No wasted words.
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 parameterless tool with no output schema, the description adequately covers what it returns (block-count, share %, windows, Unknown bucket) and how it derives data. It provides pricing and category. It could be considered complete for a simple retrieval endpoint, though it doesn't specify response format or example 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?
The input schema has zero parameters, so baseline is 4. The description does not need to add parameter details, but it does provide context about the output (block-count, share %, windows) which helps the agent understand what the tool returns. No additional parameter information is required.
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 it returns Bitcoin mining-pool hashrate shares derived from coinbase scriptSig parsing, with specific metrics (block-count, share %) and time windows (1h/24h/7d/30d). The inclusion of an 'Unknown bucket' further clarifies scope. This distinguishes it from sibling tools like coin_days_destroyed or ordinals_flow, which are about different Bitcoin on-chain metrics.
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?
There is no explicit guidance on when to use this tool vs alternatives. While the description implies it is for miner pool attribution, it does not state prerequisites, typical use cases, or situations where another tool would be more appropriate. This leaves the agent to infer usage from the name 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?
No annotations are provided, so the description carries the full burden. It discloses that data is informational research, not investment advice, and includes price and category. However, it does not mention behavioral traits like rate limits, auth requirements, or what happens if data is unavailable.
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 core purpose, followed by necessary disclaimers and metadata. Every sentence earns its place; no wasted words.
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 0 parameters, no output schema, and no annotations, the description is fairly complete. It explains the data and its purpose. Could be improved by mentioning output format, but overall adequate for a simple read-only endpoint.
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?
There are 0 parameters with 100% schema coverage (no parameters), so baseline is 4. The description adds meaning beyond the schema by explaining what the data represents (blue/red block density, DAG-stress proxy), which is valuable.
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 it provides Kaspa blue/red block density (GHOSTDAG), specifically merged vs selected-chain block share, as a DAG-stress/orphan-rate proxy. This is a specific verb+resource combination that distinguishes it from sibling tools like get_v1_kaspa_derivatives_chain_density or get_v1_kaspa_derivatives_dag_state.
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 through the mention of 'DAG-stress / orphan-rate proxy', but does not explicitly state when to use this tool vs alternatives or provide exclusions. No guidance on parameter usage since there are none.
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 burden of disclosing behavior. It accurately indicates the tool returns count and volume per hour, and adds the cost ('Price: $0.05'), which is a key behavioral trait. It also includes a disclaimer about investment advice. However, it does not mention data freshness or any limits, but given the simplicity, this is adequate.
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: three short sentences that front-load the core functionality. Every word adds value, including the price and category. No superfluous text.
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 parameterless tool with no output schema, the description sufficiently explains what the tool returns (count and volume per hour) and its use case. It does not specify the time range or default behavior, but 'per hour' implies a fixed granularity, which is acceptable completeness.
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 no parameters and schema coverage is 100% (empty schema). The description does not need to add parameter meaning. The baseline of 4 is appropriate as there is nothing to improve.
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 it returns 'Bittensor BalancesTransfer count + total TAO volume per hour', which is a specific verb+resource. It also contextualizes the use case ('TAO whale-watch and treasury-movement monitoring'), distinguishing it from sibling tools like registration or block metrics.
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 does not provide when to use this tool versus alternatives. Although it mentions a use case, it lacks explicit guidance on when not to use it or how it differs from similar sibling tools like get_v1_subtensor_derivatives_registration_pulse or get_v1_subtensor_derivatives_block_metrics.
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 bear the burden of transparency. It describes the output data but does not disclose whether the operation is read-only, any limitations, or data freshness. The lack of such details is a gap.
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 three sentences long, front-loading the core functionality and use case. Every sentence contributes meaningfully, with no waste.
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?
Given the absence of an output schema, the description provides a general idea of the output but lacks specifics like format (e.g., list of objects, time series). The completeness is adequate but not thorough.
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?
With no parameters, the schema has 100% coverage (empty). The description adds value by explaining what the tool returns, which is more than the schema alone can convey. Baseline for 0 params is 4.
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 provides hourly Bittensor subnet registration activity and current burn-cost per subnet, which distinguishes it from sibling tools like get_v1_bittensor_derivatives_subnets_all.
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 mentions the use case 'Useful for predicting cheap-registration windows,' providing helpful context. However, it does not compare to alternatives or specify when not to use.
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. It discloses that the score is 'transparent', the formula is disclosed, and based on 'months of continuous high-cadence network observation'. It also mentions price ($0.50) and category. It does not detail authorization or error behavior, but for a data retrieval tool, the key behavioral traits are covered.
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 three concise sentences, front-loading the core purpose and including essential context (when to use, price, category). Every sentence adds value without unnecessary verbosity.
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 has one simple string parameter and no output schema, the description adequately covers the purpose, usage context, and behavioral caveats. It does not detail the return format, but for a data query tool, this is acceptable. The description is nearly complete for its 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 schema coverage is 100% with one parameter 'netuid' described as 'Path parameter netuid (e.g. BTC, ETH, SOL, or other supported identifier)'. The description adds no additional meaning about the parameter beyond the schema, so it meets the baseline for high coverage.
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 'Bittensor subnet mining due-diligence verdict' with specific metrics (displacement rate, emission per earning miner, registration pressure, concentration, competitiveness score). It directly describes the purpose: assessing mining viability for a given subnet. While there are many sibling tools related to Bittensor, this one's focus on mining viability is distinct.
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 advises to 'Check before you burn registration fees', indicating when to use the tool (before subnet registration). It also notes the data is 'informational research data — not investment advice', setting expectations. However, it does not explicitly mention when not to use it or suggest alternative sibling 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?
Despite no annotations, the description openly labels the data as a 'PROXY methodology' with a warning emoji, revealing its limitations and indirect nature. This provides meaningful behavioral context beyond the empty 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 extremely concise: two sentences plus two additional lines for pricing and category. Every sentence adds value with no redundancy.
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?
For a simple tool with no parameters and no output schema, the description fully covers the methodology, limitations, pricing, and categorization. No further details are needed.
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 no parameters, and the schema coverage is 100%. The description does not need to add parameter details; a baseline score of 4 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 returns an hourly Bitcoin Coin Days Destroyed proxy, using specific components (consolidation_ratio, fee_weight, volume, whale-tx). It effectively communicates the tool's function, though it does not explicitly differentiate from sibling tools.
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 includes a clear usage caveat: 'suitable for trend signals, not absolute reserve-coin-age accounting.' This guides when to use the tool, though it does not mention alternative 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?
With no annotations, the description adequately discloses the data provided: fee curve targets and trend classification based on a 2h moving average, plus price and category. It is transparent about what the tool returns, though it does not outline rate limits or authentication needs.
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, efficient sentence that conveys all necessary information without waste. It is front-loaded with the core purpose and adds relevant details concisely.
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 tool with no output schema, the description sufficiently explains the return values. It covers the fee curve targets, trend classification, and metadata (price, category). However, it does not specify the exact structure or units, which might be needed for full clarity.
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 (0 parameters), so baseline is 4. The description adds meaning by explaining the output, but no parameter details are 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 clearly states the tool returns a Bitcoin smart-fee curve for multiple confirmation targets (1/3/6/12/24/144 blocks) along with trend classification, which is specific and distinguishes it from sibling tools like get_v1_btc_derivatives_mempool_pressure.
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?
No explicit when-to-use or when-not-to-use guidance is given. The description implies usage for obtaining Bitcoin fee curve data, but does not mention alternatives or context compared to other BTC derivatives 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 full burden. It discloses update frequency (every 5 min), pricing ($0.02), and category (bitcoin-onchain). It does not explicitly state read-only behavior, but this is implied by the GET method and no destructive hints. The description adds valuable temporal and cost 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the key outputs (pressure classification, fee buckets, counts), followed by three concise facts (update interval, price, category). Every piece of information 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?
Given no output schema, the description covers the main returned components: pressure classification, fee buckets (with specific ranges), RBF count, and CPFP count. It could be improved by describing the structure or format of these fields, but it is sufficiently complete for a parameterless 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 tool has zero parameters and schema coverage is 100%. According to guidelines, baseline is 4 for 0 parameters. The description does not need to add parameter semantics as there are none.
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 returns Bitcoin mempool pressure classification (low/medium/high/extreme), fee buckets with explicit sat/vB ranges, RBF count, and CPFP count. It distinguishes itself from siblings like get_v1_btc_derivatives_fee_curve which focuses on fee estimates, and other BTC derivative tools that cover different 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 mempool pressure and fee data but provides no explicit guidance on when to use this tool versus alternatives such as fee_curve or blocks_range. No when-not-to-use or prerequisites are 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?
No annotations exist, so the description carries full burden. It discloses cadence (10min), data type (orphans/forks), and a risk indicator. However, it lacks details on connection method (polling vs. push), data format, or whether it requires authentication. The term 'stream' with a cadence is somewhat ambiguous.
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?
Three sentences plus price/category, no fluff, front-loaded with main action. Every sentence adds value.
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 parameters or output schema, the description covers purpose, cadence, use cases, and a condition. It lacks output format details and clarification on 'stream' vs. polling, but overall sufficient for an agent to understand what it returns.
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?
No parameters exist, so baseline is 4 per rules. The description adds no param info, which is fine since there are none.
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 clearly states it's a stream of Bitcoin chain-tip orphans and valid forks with a 10-min cadence. It also lists specific use cases (exchange confirmation policy, cross-chain bridge safety, finality auditors) and a risk threshold (branch_length >= 2). This distinguishes it from sibling tools like get_v1_btc_derivatives_blocks_range or get_v1_btc_derivatives_coinbase_messages.
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?
Explicit use cases are provided, but the description does not include when-not-to-use or direct comparisons to sibling tools. The agent can infer usage from the purpose, but explicit guidance is missing.
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 provided, so description carries full burden. It adds cost ($0.05) and category (kaspa) info, plus a disclaimer (not investment advice). However, it lacks details on data update frequency, rate limits, or behavior if the fork is inactive, leaving some behavioral 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—three sentences that front-load the purpose, followed by value proposition and necessary metadata. Every sentence serves a clear purpose 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?
Given the tool's simplicity (no parameters, no output schema), the description adequately covers what the tool provides (activation distance, ETA, parameter reference) and includes cost and category. It could be enhanced by hinting at the response structure or data freshness, but it is largely 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?
There are zero parameters, and schema coverage is 100%. The description does not need to explain parameters, and it adds no parameter details beyond what is already structured. Baseline score of 4 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 it's a 'Kaspa Toccata hardfork tracker' and lists specific outputs (live activation distance, network-measured ETA, post-fork parameter reference), making the tool's purpose unambiguous and distinct from sibling tools.
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 implicitly indicates use for Toccata hardfork tracking by naming the hardfork and the data provided. No explicit when-not-to-use or alternative tools are mentioned, but the context is clear enough for selection.
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?
Discloses data type (hourly), detection method (magic bytes), window limit (7 days), and pricing. No annotations provided, so description carries full burden. Lacks info on rate limits or authentication, but for a read-only data tool this is adequate.
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?
Single sentence with all key details front-loaded: 'Hourly Bitcoin Ordinals inscriptions + OP_RETURN byte volume.' No extraneous words.
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 parameters and no output schema, description covers data, frequency, detection, window, and pricing. Could mention return format, but sufficient for agent to understand tool's output.
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?
No parameters in schema, schema coverage is 100%. Description adds no param info because none are needed. Baseline 4 applies, and no improvement needed, so score 5.
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 clearly states it provides 'Hourly Bitcoin Ordinals inscriptions + OP_RETURN byte volume' and specifies detection method. This distinguishes it from sibling tools which cover other Bitcoin derivatives like coin days destroyed or blocks.
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?
No explicit guidance on when to use this tool versus alternatives. However, the description implies use for Ordinals flow data, and among siblings there is no other Ordinals-specific tool, so context is somewhat implied.
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 transparency burden. It discloses that data is 'Informational research data — not investment advice' and notes the tool cost ('Price: $0.02'). It does not detail update frequency or authentication, but the simple read operation is adequately explained.
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 (four sentences) and front-loaded with the key purpose. Every sentence adds value: purpose, scope, use cases, and disclaimer/metadata. No redundant or trivial text.
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 zero parameters and no output schema, the description is fairly complete. It covers what data is returned (prices for all subnets), use cases, and a disclaimer. It lacks an example or detail on data format, but for a simple read endpoint it is sufficient.
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 has zero parameters, so the description's role is to explain what the tool returns. It states 'Latest alpha-token price per Bittensor subnet (TAO + USD). All 129 subnets in one call,' which adds meaning beyond the empty schema. However, it does not specify the output format or fields.
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 it provides the latest alpha-token price per Bittensor subnet (TAO+USD) for all 129 subnets in a single call. It distinguishes from siblings like get_v1_bittensor_derivatives_alpha_price_history_netuid (history for a specific netuid) and get_v1_bittensor_derivatives_subnets_all (subnet list, not prices).
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 for cross-subnet price arbitrage and dTAO portfolio rebalancing, but does not explicitly state when not to use or compare to alternatives. The phrase 'All 129 subnets in one call' suggests it is a bulk endpoint, providing clear context for selection.
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 provided, but description discloses output contents (height, time, miner pool, etc.), limits, and pricing. It implies a read operation but lacks explicit safety or side-effect 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three sentences, front-loaded with main purpose, then output details, then metadata. No unnecessary words; highly efficient.
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 no input parameters and no output schema, the description adequately covers purpose, constraints, and return format. Missing explicit mention of authentication or rate limits, but not critical.
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?
Input schema has zero properties, so no parameters to describe. Baseline is 4; description adds no additional parameter info, but it implicitly conveys the range is determined by the endpoint path.
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 clearly states 'Bulk Bitcoin block extract' with a specific scope (max 144 blocks) and lists output fields. Distinguishes from sibling tools like 'get_v1_btc_derivatives_blocks_height' by indicating it extracts a range.
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 specifies max blocks and price cap, implying usage for batch retrieval. However, it does not explicitly state when to use versus alternative tools (e.g., single block extraction) or provide when-not-to-use 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 discloses important traits: rolling nature, verifiability, use of validator-identical metrics, disclosure of random baselines, and disclaimer about not being investment advice. It does not mention update frequency or limitations.
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 (4 sentences), front-loaded with key purpose, and each sentence adds value: function, metrics, use case, disclaimer, and metadata (price, category).
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?
Despite no output schema, the description adequately covers the output (balanced accuracy, AUC, random baselines) and context (informational, not advice). It does not describe the exact response structure but is sufficient for understanding the tool's purpose.
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 has no parameters, so the description adds meaning by explaining what the tool returns (metrics and purpose). This is sufficient for a parameterless tool.
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 rolling verifiable AI-model quality scorecard with specific metrics (balanced accuracy, AUC) and purpose (audit AI track record). It is distinct from sibling tools which focus on cryptocurrency derivatives data.
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 phrase 'Audit an AI track record instead of trusting claims' implies when to use, but no explicit exclusions or alternatives are given. However, the differentiation from siblings 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?
With no annotations, the description carries full burden. It discloses key behavioral traits: full forensic workup, cross-chain, multi-language, detailed reasoning trace, and price. However, it does not mention response format, side effects, or rate limits, but given the tool's nature as a one-shot investigation, this is acceptable.
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 very concise: two sentences plus price and category. It front-loads the key purpose ('Carbon-Guard Deep Investigation'), then lists features, use cases, and cost. No redundant information, 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?
Given no parameters and no output schema, the description does a good job explaining the tool's role and when to use it compared to siblings. It mentions the key features (cross-chain, multi-language, reasoning trace) and use cases. However, it could briefly hint at the output nature (e.g., risk score report) but is still fairly 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?
There are 0 parameters, and schema coverage is trivially 100%. The description adds no parameter-level details, but baseline for 0 params is 4. The description compensates by explaining the tool's purpose and what it does, which is sufficient for parameterless tools.
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 'full forensic workup for high-stakes decisions' with 'broad cross-chain checks, multi-language coverage, and a detailed reasoning trace'. It distinguishes itself from sibling tools like 'post_v1_safety_check_standard' by explicitly being a 'deep investigation' for more critical use cases.
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 specifies when to use: 'For large transfers, serious counterparty due-diligence, and fraud investigations where being wrong is expensive.' It implies that for less critical situations, the standard check would be more appropriate, providing clear context.
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 describes the tool as a 'snapshot', implying current state, and lists what it returns. This is adequate for a read-only, parameterless tool. No contradiction with annotations (none provided).
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) and front-loaded with the main purpose. It includes pricing and category without unnecessary words.
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?
The tool has no parameters and no output schema, but the description explains the content (tips, sink, etc.) and use cases. It is complete enough for an agent to understand when to invoke 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?
There are no parameters, so schema coverage is 100% trivially. The description does not need to add parameter info, and none is missing. Baseline for 0 parameters is 4.
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 it provides a 'Kaspa BlockDAG topology snapshot' and lists specific elements (tips, sink, virtual chain, pruning point, blue scores). This is specific and distinguishable from sibling tools like 'get_v1_kaspa_derivatives_supply_trend' or 'get_v1_kaspa_derivatives_recent_blocks'.
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?
It explicitly says 'For DAG-state monitoring, side-branch detection, sync verification', giving clear use cases. While it does not explicitly exclude other uses or compare to alternatives, the purpose is well-defined and the context is sufficient.
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:

[![x402-mcp MCP server](https://glama.ai/mcp/servers/CarbonCashmere/x402-mcp/badges/card.svg)](https://glama.ai/mcp/servers/CarbonCashmere/x402-mcp)

Score Badge

Copy to your README.md:

[![x402-mcp MCP server](https://glama.ai/mcp/servers/CarbonCashmere/x402-mcp/badges/score.svg)](https://glama.ai/mcp/servers/CarbonCashmere/x402-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/CarbonCashmere/x402-mcp'

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