@blockchainacademics/mcp

Official

by blockchainacademics

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.5.1
Disambiguation3/5
Many tools target similar domains (e.g., multiple sentiment and social tools), and the sheer number of tools increases the chance of misselection. However, detailed descriptions help differentiate them, so ambiguity is moderate.
Naming Consistency4/5
All tools use snake_case, and names are generally descriptive. However, the verbs are diverse (get, list, search, check, track, etc.), and while not chaotic, a more uniform pattern would improve predictability.
Tool Count1/5
99 tools is excessive for a single MCP server. Such a large surface overwhelms agents and suggests a lack of focus, contradicting best practices for tool design.
Completeness5/5
The toolset is remarkably comprehensive, covering news, prices, on-chain data, DeFi, NFTs, memecoins, regulation, jobs, templates, and more. There are no obvious gaps for the stated crypto research domain.
Average 3.1/5 across 99 of 99 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose response format, rate limits, auth requirements, or whether the tool is read-only. For a tool with zero annotation coverage, the description must compensate but fails entirely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but under-specified. The description is a fragment rather than a complete sentence, making it less useful. Conciseness is not just brevity; the description must earn its place by being informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter and no output schema, the description omits critical details like return type (boolean, list, object) and any error conditions. The agent cannot reliably invoke this tool without guessing.
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?
Schema description coverage is 0%. The description does not elaborate on the 'domain' parameter beyond its name. No example, format, or constraints are given, leaving the agent to guess the expected input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Known phishing / scam domains + contracts.' is a fragment that does not specify the action (e.g., 'checks if a domain is known as phishing'). It leaves ambiguity whether the tool returns a list or verifies a single domain. Title is null, adding no clarity.
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 siblings like scan_contract or check_rugpull_risk. The description does not mention any prerequisites or contextual triggers.
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 only states 'tracker' without explaining if it is read-only, what data it retrieves, or any side effects. Minimal transparency.
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 very short (one sentence), but it lacks substance and is not front-loaded with critical information. While not verbose, it is under-informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, one undocumented parameter, and many sibling tools, the description is severely incomplete. It does not specify return format, data fields, or how it differs from other data-providing tools.
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?
Schema description coverage is 0%. The description does not mention the 'limit' parameter or explain its purpose. No information on what the limit controls (number of tokens? data points?).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description ('AI agent tokens tracker: Virtuals, ai16z, Aixbt, Griffain, Zerebro.') is vague about what the tool does ('tracker' could mean many things). It does not specify what data is returned (price, market cap, social metrics, etc.) and does not distinguish from sibling tools like get_price or get_market_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. The description lacks any context about use cases, prerequisites, 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention any: no indication of side effects, auth requirements, rate limits, or whether data is live/historical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (9 words) but omits essential information. It is not a model of efficiency; it is under-specified. Front-loaded but lacking substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (jargon, no annotations, no output schema, 0% schema coverage), the description is severely incomplete. It does not explain return values, parameter interpretation, or typical use cases.
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 two parameters (limit, window) with no descriptions, and the description does not clarify them. Schema description coverage is 0%, so the description should compensate but fails to provide any parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it returns top PnL wallets on memes, which indicates the tool's purpose. However, it uses jargon like 'PnL' and 'Pro tier' without explanation, which may be unclear to an AI agent. It distinguishes from siblings like get_wallet_profile but could be more explicit.
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. The description does not mention any prerequisites, context, or scenarios, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only says 'tracker', implying read behavior without details on side effects, permissions, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While extremely concise, the description is under-specified and fails to convey necessary information, making it ineffective rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and many siblings, the description is completely inadequate. It lacks details on return value, parameter usage, and tool context.
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 sole parameter 'limit' is not described. Schema coverage is 0%, and the description adds no meaning, leaving the agent without insight into its purpose or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'DePIN ecosystem tracker' is vague. It does not specify a clear verb or resource, nor does it distinguish the tool from numerous sibling tools like get_entity or get_tokenomics.
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. The description offers no context for selection among many similar data retrieval tools.
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, and the description does not disclose any behavioral traits such as read-only status, authorization needs, rate limits, or side effects. The description fails to compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively brief (one sentence) and uses the unexplained acronym 'BCA', sacrificing clarity for brevity. It does not effectively communicate the tool's value or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (two parameters, no output schema, unspecific description), the description is inadequate. It lacks parameter explanations, return value details, and distinctiveness from similar sibling tools.
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 0% description coverage. The required parameter 'entity_slug' and optional parameter 'days' are not explained in the description. No additional meaning is provided beyond their types, leaving their purpose and format unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it provides 'historical BCA coverage series per entity', indicating a per-entity historical data retrieval. However, it uses the acronym 'BCA' without definition, and the term 'coverage' is ambiguous. It does not clearly distinguish from siblings like get_history_prices or get_history_sentiment, which also provide historical series.
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. With numerous history-related siblings (e.g., get_history_prices, get_history_correlation), the lack of usage context leaves the agent without decision criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'where leveraged positions get wiped', omitting whether it's a read operation, auth requirements, rate limits, or output format. This is insufficient for an agent to understand its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description is under-specified rather than concise. It omits critical information, making it inefficient for agent use. Every sentence should add value; here, 'Pro tier' is irrelevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple input, the description is completely inadequate. It fails to explain what data is returned, how the symbol is used, or even what a liquidation heatmap is. An agent cannot form a correct invocation.
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?
Schema coverage is 0%, and the description provides no information about the 'symbol' parameter. Without param descriptions, the agent cannot know what values to supply (e.g., BTC/USD or just BTC).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Where leveraged positions get wiped. Pro tier.' is vague and cryptic. It implies a heatmap of liquidations but lacks a specific verb like 'get' or 'retrieve', and does not clearly distinguish the tool from siblings such as 'get_funding_rates' or 'get_exchange_flows'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_funding_rates' or 'get_options_flow'. The agent receives no context for selecting it over other data tools.
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, and the description only states what data is returned. It does not disclose whether the operation is read-only (implied but not stated), how the limit parameter affects behavior, pagination, or any rate limits. Minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (8 words), but this conciseness sacrifices critical details such as the verb, parameter explanation, and usage context. It is front-loaded but incomplete.
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 lack of output schema and annotations, the description should explain the return structure and behavior more thoroughly. It mentions fields but omits details like ordering, default limit, and whether the list is exhaustive or paginated.
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?
Schema description coverage is 0%, and the description adds no information about the limit parameter. The meaning of the parameter is left entirely to the schema type definition, which is insufficient for an agent to know its purpose or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states what the tool returns (currencies with fields) but lacks an explicit action verb like 'list' or 'retrieve', relying on the name to imply the action. It distinguishes from siblings by specifying it returns a list of all tracked currencies, but does not clearly differentiate from similar list tools like list_stablecoins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. Does not mention prerequisites, typical use cases, or scenarios where a sibling tool like get_currency_feed 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 present, the description should disclose behavioral traits like read-only status or rate limits. It does not mention any such details, leaving the agent uninformed about 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words) but at the cost of clarity. It sacrifices informativeness for brevity, making it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameter explanations, no output schema, and no behavioral context, the description is far from complete. It fails to equip the agent with sufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the only parameter 'limit'. The description does not explain what 'limit' controls (e.g., number of results), leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Cross-symbol social signal feed' conveys that the tool retrieves a feed of social signals across symbols, but it lacks a specific verb and does not differentiate from sibling tools like get_social_signals_detail or get_social_pulse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description is entirely silent on usage context.
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?
With no annotations, the description must disclose behavioral traits. It fails to mention whether the tool is read-only, what data is returned, or any side effects. The description is completely opaque on behavior.
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 extremely short (10 words) but not well-structured. It reads as a list rather than a coherent statement. While concise, it sacrifices informativeness needed for tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no input or output schema and no annotations, the description is the sole source of context. It fails to explain what the metrics are, time ranges, format, or how the data is organized. This is incomplete for an AI agent to use 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 tool has zero parameters, and schema coverage is 100% (empty schema). Per guidelines, baseline for 0 parameters is 4, and the description does not need to add parameter info. However, it does not clarify what 'metrics' are returned, but that is covered under other dimensions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists specific projects (Bittensor subnets, Ritual, Prime Intellect) and a tier designation but does not state what action the tool performs. The tool name includes 'get' but the description lacks a verb, leaving the purpose ambiguous. It does not differentiate from sibling tools like get_ai_agent_tokens or get_depin_projects.
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. The description only mentions specific topics without context on appropriate use cases or exclusions.
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?
The description only states the basic function without disclosing behavioral traits such as data format, required parameters beyond symbol, or any destructive or read-only nature. No annotations are provided to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is concise (one sentence), it is under-specified, omitting critical information. It is not efficiently structured for an agent to act upon without additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and detailed parameter descriptions, the one-sentence description is far from complete. An agent would lack understanding of the return format, required inputs, and behavioral semantics.
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?
Schema description coverage is 0%, yet the description only mentions 'symbol' implicitly. The 'days' parameter is unexplained, leaving the agent to guess its meaning (likely a time range).
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 provides a 'historical sentiment series for a symbol,' which is a specific verb-resource combination. However, it does not differentiate from siblings like get_sentiment or get_social_pulse, which could overlap.
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 (e.g., get_sentiment for current data). The description lacks any when-to-use or when-not-to-use 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 provided, and the description fails to disclose behavioral traits such as read-only nature, potential rate limits, or data freshness. The agent cannot assess side effects or required access levels.
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 very concise (5 words), which is efficient but under-specifies crucial information. It is front-loaded but lacks enough content to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 parameters, no output schema, and 80+ sibling tools, the description is severely incomplete. It omits return values, error cases, and integration context, making it nearly unusable for correct invocation.
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?
Schema description coverage is 0%, and the description adds no meaning to parameters 'limit' and 'topic' beyond their names. No format, constraints, or examples are given, forcing the agent to guess valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Polymarket + Kalshi + Azuro odds.' hints at getting odds from these prediction markets, but lacks a clear verb (e.g., 'Get', 'Fetch') and does not distinguish from sibling tools like 'get_funding_rates' or 'get_sentiment' which are also market-related.
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. The description does not mention use cases, prerequisites, or exclusions, leaving the agent to infer its purpose 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only mentions 'Starter tier' (implying possible restrictions) but does not explain whether the operation is read-only, what happens on invalid input, or any side effects. This is insufficient for a tool with no annotation support.
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 very short (one sentence), which avoids verbosity but is not optimally structured. It front-loads the core idea but omits necessary details like a verb, scope, or usage context. It could be expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 provide comprehensive context. It fails to explain what a 'roadmap' contains, what 'BCA editorial fact-check' means, or what the response format is. This is inadequate for a tool with a single parameter and no output schema.
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?
Schema description coverage is 0%, and the description adds no meaning to the sole parameter 'entity_slug'. The parameter name is somewhat descriptive, but the description does not clarify format, examples, or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Project roadmap with BCA editorial fact-check. Starter tier.' vaguely indicates the tool provides a roadmap with fact-checking for a project. It does not use a clear verb like 'retrieve' or 'get', and 'Starter tier' is ambiguous. It distinguishes from siblings like 'get_entity' by the term 'roadmap', but lacks specificity.
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. With a large list of sibling tools, the agent has no context for selecting 'get_roadmap' over similar data-retrieval tools, e.g., 'get_explainer' or 'get_article'.
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?
The description provides no behavioral details beyond the name, and there are no annotations to clarify side effects or constraints. The agent has no insight into data freshness, access limits, or mutation risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (6 words) but lacks substance. The phrase 'Starter tier' is vague and does not justify its inclusion. Being concise is not an excuse for missing critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter, no output schema, and appears among many data retrieval tools, the description fails to specify return format, data scope, or how the limit parameter works. It is insufficient for an AI agent to use correctly.
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?
Schema description coverage is 0%, and the description does not mention the 'limit' parameter or its semantics. The agent receives no help understanding the parameter even though it is optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (real-world asset tokens) and action (tracker), but does not differentiate from sibling tools like list_stablecoins or list_nft_communities, which have similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context for 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 are provided, so the description must carry the full burden. It mentions 'Pro tier', indicating access restrictions, but does not disclose other behavioral traits such as side effects, authentication requirements, rate limits, or what happens if the entity_slug is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two phrases), which is concise but at the expense of crucial information. It fails to explain what the tool returns or any usage context, making it under-specified rather than genuinely 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?
Given the tool has one parameter, no annotations, and no output schema, the description should compensate by explaining the return value and typical use cases. It does not, leaving the agent uninformed about what to expect from the tool.
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 has 0% description coverage, and the description adds only 'per project', implying entity_slug is a project identifier. It does not explain the format, expected values, or how to obtain entity_slug, leaving the agent with insufficient semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it tracks EU MiCA compliance per project, which gives some purpose, but it is vague as it does not specify what exactly the status is (e.g., boolean, score, report). It is somewhat distinguishable from sibling 'get_regulatory_status' by being EU-specific, but not explicitly.
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. There is no mention of the 'Pro tier' requirement or that it is specific to EU MiCA regulation, which would help differentiate from similar tools like 'get_regulatory_status'.
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?
With no annotations provided and a very brief description, the tool's behavioral traits are entirely opaque. The description does not disclose output format, data sources, update frequency, or any side effects, leaving the agent with minimal information.
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 very short and concise, but it sacrifices essential detail. While brevity is valuable, the extreme conciseness results in under-specification that harms usefulness.
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 tool has only one parameter and no output schema or annotations, the description should provide more context about what 'social signal detail' means, the nature of the output, and how it relates to sibling tools. The current description is incomplete for effective tool selection.
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?
Schema description coverage is 0%, and the description adds no additional meaning to the 'symbol' parameter. The parameter is left entirely unexplained, forcing the agent to rely on the parameter name alone.
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 verb 'get' and resource 'social signal detail' for 'a single symbol', making it easy to understand the tool's basic function. However, it does not explicitly differentiate from the sibling tool 'get_social_signals', which likely lists multiple signals, but the phrase 'single symbol' provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 other social signal or sentiment tools. No context on prerequisites, data freshness, or typical use cases is given.
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 discloses that the tool returns aggregated audits and a score, but lacks behavioral traits such as whether it is read-only, required authentication, rate limits, or output format. Minimal transparency.
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 a single short sentence, which is concise and front-loaded. However, it omits essential details, so it is not optimally structured for completeness.
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 tool has one required parameter and no output schema, the description is too brief. It does not explain the input, output, or any behavioral aspects. The context is incomplete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'entity_slug' with no description. The description does not explain what 'entity_slug' represents or how to use it. With 0% schema coverage, the description adds no value beyond the schema, failing to clarify parameter meaning.
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 aggregates audits from specific firms (Trail of Bits, Certik, etc.) and includes a BCA review score. It uses a specific verb and resource, making the purpose clear. However, it does not differentiate from sibling tools like 'get_risk_score' or 'check_rugpull_risk', which may overlap.
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. There is no mention of prerequisites, context, or exclusions. The description simply states what it does without any usage recommendations.
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 provided, the description is the sole source for behavioral traits. It only states the data type ('Net in/out from CEXs') and a 'smart-money signal' tag, but does not disclose data freshness, update frequency, whether the operation is read-only, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), but it sacrifices necessary detail. While it avoids fluff, it fails to convey critical information about parameters and usage, making it under-specified rather than efficiently succinct.
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 tool has two parameters, no output schema, and no annotation context, the description lacks completeness. It does not explain what the tool returns, how to interpret the output, or how the parameters affect results, leaving an AI agent with insufficient information to invoke the tool correctly.
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?
Schema description coverage is 0% and the description adds no meaning to the two parameters ('symbol' and 'window'). For example, 'window' as a string is ambiguous; the description should clarify acceptable values (e.g., timeframes) but does not.
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 identifies the resource ('Net in/out from CEXs') and frames it as a 'smart-money signal' with a 'Pro tier' qualifier, making the tool's purpose reasonably clear. However, it does not explicitly differentiate it from sibling tools that also deal with exchange flows or signals.
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, nor does it mention prerequisites or exclusions. It only notes it is 'Pro tier,' implying a subscription requirement, but fails to give actionable 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 behavioral burden. It mentions deduplication but omits read-only status, pagination, or any constraints beyond the limit parameter.
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 a single short sentence, making it concise. However, it sacrifices necessary detail for brevity, which is acceptable but not exemplary.
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 only one parameter, the description should clarify return format and type of stories (e.g., titles, summaries). It does not, leaving the agent underinformed.
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?
Schema description coverage is 0%, and the description does not explain the limit parameter (e.g., what it controls, acceptable values). No added semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves recent clustered stories and includes deduplication. It distinguishes from siblings like search_news by focusing on clustered/recent, but doesn't explicitly name alternatives.
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 siblings like search_news or get_unified_feed. The description lacks context for appropriate use.
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 only mentions 'Starter tier', which hints at limited data but does not disclose behavioral traits such as read-only nature, rate limits, or data freshness. The description is insufficient for safe invocation.
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 very short, consisting of two phrases. While concise, it lacks structure and detail. Every word earns its place but the result is under-specification.
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 simple one-parameter schema and no output schema, the description should at least clarify what 'Starter tier' entails and what the response contains. It does not, leaving significant gaps.
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 schema has a single required parameter 'country' with 0% description coverage and no enums. The description adds no meaning beyond 'jurisdiction'; it does not specify expected format (ISO code, full name, etc.) or provide examples.
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 states 'Crypto tax rules per jurisdiction' which clearly indicates the tool retrieves tax rules based on jurisdiction. It uses a specific verb and resource. However, it does not differentiate from sibling tools, most of which are unrelated to tax rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any conditions or exclusions. The description lacks usage context entirely.
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 behavior. It states the tool is 'Entity-graph backed' but does not mention whether it is read-only, if it requires authentication, rate limits, or any side effects. This is insufficient for an agent to understand operational invariants.
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 short and uses bullet-like phrasing, but it is not structured to front-load the most critical information (what the tool does and its input). The sentence 'Entity-graph backed. Pro tier.' adds minimal value and could be integrated more effectively.
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 low parameter count and lack of output schema or annotations, the description does not provide sufficient context for confident invocation. It omits return format, pagination, error conditions, or examples, leaving the agent with significant uncertainty.
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 only parameter 'entity_slug' has no description in the schema (0% coverage) and the tool description does not explain its format or meaning. The description lists outputs but fails to connect the parameter to the data retrieval, leaving the agent without guidance on how to set the parameter.
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 lists specific outputs (Founders, LinkedIn-verified backgrounds, prior exits, doxx status) and mentions the underlying data source (Entity-graph backed), making the tool's purpose clear. However, it does not explicitly state that it provides information for a given entity slug, which would strengthen clarity.
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 siblings (e.g., get_entity, get_explainer). It mentions 'Pro tier' implying a cost or access restriction but gives no explicit usage context or 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?
With no annotations, the description carries the full burden of disclosing behavioral traits. It does not state whether this is a read-only operation, what happens with invalid parameters, or how results are sorted/limited. The short description fails to provide essential behavioral context.
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 extremely concise (four words), which is efficient but at the cost of completeness. It front-loads the core idea but omits necessary detail, striking a poor balance between brevity and informativeness.
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 low schema coverage, no output schema, and many sibling tools, the description is insufficient. It does not explain return values, parameter constraints, or typical use cases, leaving the agent with significant uncertainty.
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?
Schema coverage is 0%, and the description adds no information about the two parameters ('limit' and 'window'). It only mentions 'by window,' which echoes the parameter name without explaining valid values, formats, or behavior. The agent gains no additional meaning beyond the parameter names.
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 'Trending entities + articles by window' clearly indicates the tool returns trending entities and articles filtered by a time window. It effectively distinguishes from many sibling tools that focus on specific entities, news search, or sentiment, but lacks precise detail on what constitutes 'trending' or how 'window' is applied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like search_news or get_entity. The description does not specify prerequisites, limitations, or when not to use it, forcing the agent to guess based on 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 provided, so the description must disclose behavior. It mentions deduping, but lacks other behavioral traits like pagination, rate limits, data freshness, or mutation effects. Incomplete for a tool with no annotations.
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?
One sentence, concise and to the point. However, it lacks structure for presenting parameter details or usage notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations, output schema, or parameter descriptions, the description is severely incomplete. It only states sources and deduping, leaving out essential details 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (chain, limit, remote, seniority). The tool's purpose implies filtering, but no semantics are added beyond parameter names.
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 is an aggregated crypto job board, deduped from specific sources. This gives a clear purpose but lacks detail on filtering or output, and does not differentiate from siblings, though siblings are mostly non-job 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 guidance on when to use this tool versus alternatives. Sibling tools are not job-related, but there is no explicit context for when to invoke this tool or prerequisites.
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 does not mention if the tool fetches live data, returns cached results, or any rate limits. The behavior beyond the basic action is unclear.
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 very short, which is concise, but it fails to provide necessary detail for a tool with no output schema and no annotations. It is under-specified rather than properly 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?
Given the lack of output schema, annotations, and parameter documentation, the description is incomplete. It does not inform the agent about return values or how to effectively use the tool.
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 one parameter (limit) with 0% description coverage. The description does not explain what the limit parameter controls, leaving the agent to guess its meaning.
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 specifies the resource (pump.fun) and the data type (trending and new launches). It distinguishes from sibling tools like track_bonkfun which focus on a different token. However, it lacks specificity on what 'trending' and 'new launches' entail.
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, or any prerequisites. The description is a single phrase with no 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 must carry the full burden. It only states the data source and topic, but does not disclose whether the tool is read-only, requires authentication, has rate limits, or what kind of output format to expect. This is insufficient for safe invocation.
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 of 9 words, which is concise and front-loaded with the core purpose. However, at the cost of omitting crucial details. It earns its place but lacks completeness.
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 low complexity (1 parameter, no output schema, no annotations), the description should be complete enough for the agent to use the tool correctly. It fails to explain the parameter, return format, or contextual hints, leaving major gaps.
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 sole parameter entity_slug has 0% schema description coverage. The tool description does not explain what entity_slug should represent (e.g., protocol name, slug format) or how it relates to the exploit history. The agent must guess its meaning, risking incorrect invocations.
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 provides historical exploits per protocol, specifying sources (Rekt and DefiLlama hacks). It distinguishes from siblings like check_rugpull_risk or get_audit_reports which focus on other security aspects. However, it does not explicitly say it returns a list or details, leaving some ambiguity.
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 many security-related siblings, there is no context on prerequisites, scope, or appropriate use cases. The agent would have 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It only says 'chronological news feed' without disclosing important traits like pagination, time range, sorting, max results, or data source. Limited insight beyond basic functionality.
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 concise sentence that gets to the point. No wasted words, but it could include more detail without losing conciseness.
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 minimal description, the tool is incomplete. The feed's content type, ordering, and constraints (e.g., how far back it goes) are missing. For a 2-parameter tool, this is insufficient for effective invocation.
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?
Schema description coverage is 0%, and the description does not mention the 'symbol' or 'limit' parameters. It adds no meaning beyond the raw schema, failing to explain what the symbol should be or how limit affects results.
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's a chronological news feed for a single currency, which indicates the main verb and resource. However, it doesn't explicitly differentiate from siblings like search_news or get_unified_feed, lacking explicit scope or type detail.
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 usage context provided. The description does not indicate when to use this tool over alternatives like search_news or get_recent_stories. Absence of when/when-not or prerequisite conditions.
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?
With no annotations provided, the description must disclose behavioral traits. It only lists the L2s compared, with no information about data freshness, mutability, authentication needs, or any side effects. For a data retrieval tool, this 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise line. However, it is overly brief and lacks structure (e.g., no bullet points or clear separation of purpose and output). It earns its place but could be improved.
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 0 parameters, no output schema, and no annotations, the description is the only source of context. It fails to specify what the comparison includes (e.g., TVL, fees, transactions) or how to interpret results. This is incomplete for a data tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so there is nothing to explain. The description could have clarified what kind of comparison is returned (e.g., metrics, charts), but it does not. The baseline for 0 parameters is 4, but the lack of added detail reduces it to 3.
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 provides a side-by-side comparison of specific L2 networks (Base, Arbitrum, etc.). The verb 'compare' is implied by 'side-by-side', and the listed resources make the scope distinct from sibling tools which focus on prices, news, or individual entities.
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. The description does not mention scenarios where this comparison is appropriate or any prerequisites. An agent would have to infer its use case from the name and list.
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 'Fetch', implying a read-only operation but does not disclose authorization needs, rate limits, side effects, or response format. The lack of behavioral details hinders the agent's ability to use the tool safely.
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 very concise (one sentence), which is good for quick reading, but it sacrifices valuable information. It could be slightly expanded to cover parameter details or usage context without becoming verbose.
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 one parameter and no output schema, the description is insufficient. It does not specify what the response contains, error cases, or how the slug should be formatted. The agent cannot fully understand the tool's behavior from this description alone.
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 description coverage is 0%, yet the description adds little meaning beyond 'by slug'. It does not explain what a slug is, its format, or how to obtain it. Even with one parameter, the description should clarify the parameter's semantics and provide examples or context.
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 action ('Fetch'), the resource ('specific investment memo'), and the unique identifier ('by slug'). It implies a single memo retrieval, distinguishing it from list_memos which returns multiple. However, it could explicitly mention that this is for a single memo to improve clarity.
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 offers no guidance on when to use this tool versus alternatives like list_memos or other get_* tools. There is no mention of prerequisites, context, or when not to use this tool. This is a significant gap given the many sibling tools.
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 such as data freshness, rate limits, or authentication requirements. It only mentions 'Pro tier' which hints at access restrictions but does not elaborate. No side effects or return behavior are described.
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 very short, which is concise, but it sacrifices clarity. It front-loads key terms but uses a cryptic style lacking verbs and context. It could be more informative without being longer.
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 tool has only one parameter and no output schema, the description should clarify what the output contains. It lists data types but not their structure or how they are returned (e.g., as a table, heatmap, list). This is insufficient for an agent to understand the tool's full behavior.
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 single parameter 'symbol' is not described at all. Schema coverage is 0%, so the description must compensate but fails to explain what inputs are expected (e.g., ticker format, example). The parameter remains ambiguous.
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 mentions specific features (IV, strike heatmap, block trades) and exchanges (Deribit, Lyra, Aevo), giving a good indication of the tool's domain. However, it lacks a clear verb and could more explicitly state that it retrieves options flow data. It distinguishes from siblings by focusing on derivatives data, which is unique among the listed 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 guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or conditions under which the tool is applicable. The description is purely a list of features without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It lists data fields but does not cover whether the operation is read-only, authentication requirements, rate limits, or side effects, leaving significant gaps.
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 extremely short and to the point, but it lacks sentence structure and fails to elaborate on essential details. It is concise at the expense of completeness.
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 lack of output schema, annotations, and parameter documentation, the description is insufficient for an agent to fully understand the tool's behavior, return format, or prerequisites. It leaves too many unknowns.
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 single parameter entity_slug has 0% schema documentation. The description adds no explanation or example for this parameter, failing to compensate for the schema gap. It only explains what data is returned.
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 lists key data fields (supply, emission, vesting, etc.) and positions the tool as a premium, comprehensive source, making its purpose clear. However, it does not explicitly state that it retrieves data, leaving the action implied by the tool name.
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 like generate_tokenomics_model or get_defi_protocol. The mention of 'Pro tier' hints at a premium context but lacks explicit usage conditions.
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 exist, so the description must disclose behavioral traits. It only says 'snapshot', implying a read operation, but omits response structure, data freshness, pagination, or any limitations. Critical for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one phrase) with no redundancy. It is front-loaded but could be more informative without losing conciseness.
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 parameters, no output schema, and many similar siblings, the description is too minimal. It fails to explain what data the snapshot contains or how the agent should interpret the output, leaving the agent underinformed.
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 zero parameters, so schema coverage is 100%. The description adds no parameter meaning, but none is required. Baseline score of 3 applies per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as 'TON + Telegram mini-apps ecosystem snapshot', which pairs with the tool name to indicate a get operation. However, 'snapshot' is vague and does not specify what data is included or how it differs from sibling ecosystem tools like get_solana_ecosystem.
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_market_overview or other ecosystem snapshots. The agent must rely solely on the name, which is insufficient for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only says 'Decode a transaction' and lists outputs, but omits whether the operation is read-only, any destructive effects, authorization needs, or rate limits. 'Starter tier' hints at limitations but is too vague to be actionable.
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?
Two sentences, short and to the point. However, the final 'Starter tier' is unclear and may mislead without context. It could be removed or explained. Overall, it is not verbose but sacrifices clarity for brevity.
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 simple two-parameter tool with no output schema, the description is incomplete. It lacks details on return format (e.g., is it raw JSON, decoded fields?), error handling (invalid hash, unsupported chain), and any constraints. An agent needs more to invoke correctly, especially given the variety of sibling tools.
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 50%: only 'hash' gets a description ('Transaction hash.'). 'chain' lacks description. The tool description adds no parameter-level detail; it only lists output fields. Since coverage is low, the description should compensate but does not clarify the 'chain' parameter's purpose or accepted values.
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 verb 'Decode' and resource 'transaction', listing key outputs like sender, receiver, value, events, status. This distinguishes it from sibling tools, which focus on other data types (prices, news, entities, etc.). The 'Starter tier' phrase is ambiguous but does not obscure the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, no context about inputs like transaction hash format or supported chains. The description does not mention any restrictions or use cases, leaving the agent without decision-making support.
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 does not disclose behavioral traits such as read-only nature, pagination, authentication requirements, or how ranking is computed. The term 'Ranked' hints at ordering but lacks specifics.
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?
Single sentence is concise and front-loaded with key purpose. However, the brevity comes at the cost of missing parameter explanation and usage guidance.
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 simple list tool with one optional parameter, the description provides only core purpose. It omits important context like default sorting, result format, and whether the list is exhaustive or paginated.
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?
Input schema has one parameter (limit) with 0% schema description coverage. The tool description adds no explanation of what 'limit' controls, leaving the parameter's semantics entirely unspecified.
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 verb 'Ranked' and resource 'trading bots / copy-trade platforms', mentioning specific attributes (fees, exchanges, track record). It distinguishes from sibling list tools that target different entities.
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. Sibling tools like list_yields, list_aggregators are not contrasted. Usage context is only implied by the resource domain.
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 behaviors. It only says 'Starter tier', which hints at limited scope but doesn't explain data freshness, permissions, read-only nature, or return structure. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise, but it sacrifices necessary detail. It is front-loaded with the list of L2s and tier, but every sentence should earn its place; this one does not fully explain the tool's behavior.
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 param details, the description should explain what the tool returns (e.g., status fields, metrics). It only lists L2s and a tier label, leaving the agent with little understanding of the response format or content.
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 (0 params, 100% schema description coverage). The description adds no parameter info, which is acceptable since none are needed. Baseline 4 applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists specific L2s (Stacks, Rootstock, BOB, Babylon, Merlin, Bitlayer) and mentions 'Starter tier', implying it retrieves status for these. However, it lacks a specific verb like 'get' or 'retrieve' and doesn't clearly state what aspect of status is returned, making it somewhat vague. It could be confused with sibling 'get_l2_comparison'.
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 similar siblings like 'get_l2_comparison'. No exclusions, prerequisites, or context for appropriate use provided.
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 says 'active bounties' implying freshness, but lacks detail on data format, pagination, rate limits, or authentication. Minimal behavioral disclosure.
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 very concise (one short sentence). It is front-loaded with 'Active bounties', but omits necessary detail about parameters and output, making it under-specified.
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 simplicity (2 optional params, no output schema), the description is incomplete. It fails to describe return values, parameter usage, or data scope, leaving the agent underinformed.
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?
Schema description coverage is 0%, and the description does not explain the 'limit' or 'min_payout' parameters. No added meaning beyond the raw schema structure.
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 active bug bounties from specific sources (Immunefi and Hackerone crypto), distinguishing it from sibling tools which cover different crypto topics. The verb 'get' and resource 'bug bounty programs' is precise.
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 others; no mention of prerequisites, alternatives, or disclaimers. The context of active bounties is implied but not explicitly tied to 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 provided; description only says 'Fetch', implying a read operation. No details on permissions, rate limits, side effects, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence, but it lacks helpful elaboration. Could include more context without becoming verbose.
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 simple scope (single param, no output schema), the description is minimally complete but could mention that the slug comes from list_theses or similar.
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 description coverage is 0%. Description mentions 'by slug' but provides no format, examples, or additional meaning beyond the schema field name.
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 action ('Fetch') and resource ('specific trade thesis') with identifier 'by slug'. It is not a tautology but lacks differentiation from sibling tools like list_theses.
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 (e.g., list_theses). No mention of prerequisites or context for having a slug.
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 read-only nature, rate limits, data freshness, or pagination behavior. The mention of 'Starter tier' implies a potential limitation but is not explained. For an unannotated tool, this is insufficient 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 a single, focused sentence. It is concise and front-loaded with key information. However, it could be more structured by separating the purpose from the tier indicator.
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 3 params with no descriptions, the description falls short. It does not explain the return format, pagination (implied by 'limit'), or what each field corresponds to. The 'Starter tier' ambiguity leaves the agent without full operational context.
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 0% (no parameter descriptions). The description mentions 'focus, ticket size, stage, portfolio count, recent deals' but only 'focus' and 'stage' appear as parameters; 'ticket size', 'portfolio count', and 'recent deals' are not parameters, causing potential confusion. The 'limit' parameter is not mentioned in the description. The description adds some context but lacks completeness and consistency.
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 is a VC directory listing focus, ticket size, stage, portfolio count, recent deals. It indicates the tool lists VC firms with specific attributes, which is distinct from sibling tools like list_stablecoins. However, the phrase 'Starter tier' is vague and could imply limited data without clarification.
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. There are many sibling list tools (e.g., list_stablecoins, list_nft_communities), but the description does not explain what makes list_vcs unique or when to prefer it. No context about required permissions or prerequisites.
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 the description must carry full weight. It does not disclose data freshness, pagination, or any side effects. Minimal 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?
Extremely concise (one line), but sacrifices necessary detail. Every sentence earns its place, but more content is needed.
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 tracking tool with no output schema, the description should clarify what constitutes a 'trending launch' and how the limit affects results. It is incomplete.
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 single parameter 'limit' has no schema description and the tool description does not explain its purpose (e.g., max number of launches returned). 0% schema coverage means the description must compensate, but it fails to.
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 identifies a specific resource (Solana meme launches) and action (tracking trending launches), but does not differentiate from similar siblings like track_pumpfun, which may overlap.
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 such as track_pumpfun or check_memecoin_risk. The agent has no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the tool is read-only, requires authentication, has rate limits, or what the output contains. For a tool that provides regulatory status, crucial details like data freshness or scope are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two phrases). While concise, it lacks structure and omits important context. 'Starter tier' is unclear and adds little value. The description could be more informative without being verbose.
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 a single parameter, the description fails to explain what the output looks like, how to interpret results, or any limitations. For a regulatory status tool, missing details like what constitutes 'status' or whether it's current/data completeness leaves the agent underinformed.
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 'ISO country code or name.'). The description adds no additional meaning beyond the schema. Baseline 3 is appropriate since the schema already documents 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 'Country-by-country crypto regulation state' clearly indicates the tool retrieves regulatory status for a given country. The verb is implied (get/retrieve), and the resource is well-defined. 'Starter tier' is somewhat vague but doesn't obscure the main purpose. It distinguishes itself from siblings like get_mica_status and get_tax_rules.
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 usage guidelines are provided. There is no mention of when to use this tool versus alternatives, such as other regulatory tools (get_mica_status, get_tax_rules). The description gives no context on appropriate scenarios or prerequisites, leaving the agent without guidance.
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 exist, so the description carries full burden. It reveals that memos are public and paid fields are redacted, which is helpful, but it does not disclose behavior like filtering, pagination, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that serves the purpose. No unnecessary words or structures, earning full marks for efficiency.
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 only one optional parameter and no output schema, the description provides the core purpose. However, it lacks guidance on usage and parameter semantics, making it minimally adequate.
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 0% coverage for parameter descriptions, and the tool description does not explain the 'limit' parameter at all. This leaves agents without guidance on how to use the parameter effectively.
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 action 'Browse' and the resource 'public investment memos', with a specific note about redaction. However, it does not differentiate from sibling tools like 'get_memo' or 'list_entities', which could lead to confusion.
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 vs. alternatives. The description only states what it does without any exclusions or context about appropriate 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?
With no annotations, the description must disclose behavioral traits. 'Starter tier' hints at limited access but does not explain what is returned (e.g., full filings, summaries) or if the data is read-only. No mention of rate limits or authentication.
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 short and front-loaded but sacrifices useful information. 'Starter tier' is an inefficient phrase that could be replaced with clearer scope details.
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 one parameter and no output schema, the description is incomplete. It does not specify return format, data frequency, or what constitutes 'filings' (e.g., 10-K, 8-K). More context is needed for an agent to use it effectively.
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 already covers the single parameter with examples (MSTR, COIN, HOOD). Description adds no extra meaning beyond what the schema provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool retrieves SEC filings for crypto companies identified by ticker, and it is distinct from siblings like get_price or get_market_overview. However, 'Starter tier' is vague and could confuse scope.
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 (e.g., search_news, get_entity). No mention of prerequisites or limitations such as data freshness or ticker availability.
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. Mentions 'Pro tier' indicating potential access restrictions, but does not disclose if the operation is read-only, rate limits, or behavior for invalid inputs.
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?
Single sentence, front-loaded with key information. Conciseness is appropriate, though it could be expanded slightly for additional context without becoming verbose.
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?
No output schema exists, and the description does not explain return values or format. Given the complexity of the tool (comparison output) and many siblings, the description is incomplete for an agent to fully understand the tool's behavior and output.
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 a clear description of entity_slugs as comma-separated slugs. The tool description does not add extra meaning beyond what the schema already provides, earning a baseline of 3.
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 performs a side-by-side comparison of protocols covering specific metrics (TVL, fees, etc.). The resource (protocols) and action (compare) are clear. However, it does not differentiate from sibling comparison tools like get_l2_comparison.
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. No exclusions or prerequisites mentioned. The description implies usage for comparison but provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must compensate. It does not mention whether the data is real-time, cached, requires authentication, or has usage limits. The phrase 'pricing per GPU type' implies a static lookup, but behavioral details are absent.
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 very concise at 6 words, efficiently conveying the core purpose. However, it lacks structure (e.g., no separate sentences for usage) and could expand slightly to include key details without losing brevity.
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 annotations or output schema, the description should provide more context about expected output behavior, defaults, and prerequisites. For a simple tool, it is incomplete—an agent would need to infer or test to understand how to use it properly.
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% as the single parameter 'gpu' has a description with examples. The description adds context by naming the providers, but does not explain the parameter's effect on the response (e.g., if omitted, returns all GPU types). This is adequate but not exceptional.
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 provides pricing per GPU type for Akash, Render, and IO.net. It distinguishes itself from other tools in the list, as no sibling tool offers compute pricing. However, it could be more specific about the action (e.g., 'Retrieve pricing') and the scope.
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 vs alternatives. The sibling tools include many listing and analysis tools, but no direct substitute is mentioned. An agent might not know if this is the correct tool for GPU cost comparison.
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 bears the full burden. It mentions the formula components and the signal interpretation, but does not disclose whether this is a read-only operation, any limitations (e.g., data availability, rate limits), or that it is a Pro-tier feature. The description is too brief to cover 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using sentence fragments to convey the core idea and formula. It is front-loaded and avoids superfluous text. However, it could be restructured to be more understandable (e.g., starting with a clear verb) without becoming lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description does not explain what the return value contains (e.g., numeric value, metadata). Given the complexity of the index and many sibling tools, the description should provide more context about the output format, units, or example usage to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with descriptions for both parameters ('Rolling window.' and 'Entity slug.'). The description in the tool adds no additional semantics beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description defines the tool as a 'BCA Coverage Index' with a formula and states that high values signal accumulation before price. This gives a clear sense of what it computes and its interpretation, distinguishing it from sibling tools like 'get_fear_greed' or 'get_sentiment'. However, it lacks a direct verb+resource statement (e.g., 'Retrieve the coverage index').
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 description mentions 'Pro tier' but does not explain when it is appropriate to call this tool compared to similar coverage or sentiment tools in the sibling list. There are no examples or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the tool is read-only, requires authentication, has rate limits, or any side effects. The description is minimal and does not compensate for missing annotations.
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 very concise, consisting of two sentences that front-load the core purpose. There is no fluff, but the brevity comes at the cost of missing important parameter and output details. It earns a 4 because it is efficient despite the gaps.
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 tool's complexity (3 parameters, no output schema), the description is incomplete. It does not describe the output format (e.g., time series of correlation values), the metric used (Pearson vs. Spearman), or the interpretation of the correlation. The agent lacks sufficient context to fully understand the tool's behavior.
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 description coverage is 33% (only 'peer' has a description). The tool description adds no parameter details beyond the schema; 'days' remains undocumented, and 'symbol' lacks any description. With low coverage, the description should compensate but fails to explain the meaning or usage of parameters.
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 states 'Correlation series between two symbols (price/sentiment)' which clearly indicates the tool computes correlation over time. It distinguishes itself from sibling history tools (e.g., get_history_prices, get_history_sentiment) by focusing on correlation. However, the phrase '(price/sentiment)' is ambiguous whether it correlates price and sentiment or correlates the same metric across two symbols.
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 'Useful for pair trades,' which provides a usage context but does not offer explicit when-to-use or when-not-to-use guidance. It does not compare with sibling tools like get_pair_data or get_history_prices, leaving the agent to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and description is minimal, not disclosing behavioral traits like idempotency, error handling (e.g., missing slug), or read-only nature.
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?
Extremely concise single sentence, but lacks sufficient detail to be helpful; it's front-loaded but overly sparse.
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 one parameter, no output schema, and no annotations, the description fails to specify return type or complete behavior, leaving the agent underinformed.
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 0%, and description only names 'slug' without explaining its format, source, or relationship to template content.
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?
Clearly states it fetches a specific marketing template by slug, using a specific verb and resource. Distinguishes from sibling 'list_marketing_templates' which lists templates.
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 like list_marketing_templates, or any prerequisites such as the need to have a slug.
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?
Without annotations, the description must disclose behavioral traits. It mentions smoothing and derivative computation but does not clarify if it is read-only, requires paid access, or has rate limits. No side effects or limitations are discussed.
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 very short and to the point, but uses jargon ('d/dt') which may reduce clarity. It conveys key information without excess words, but lacks structure for easy scanning.
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 tool with no output schema and two parameters, the description gives enough context to understand its purpose (early reversal detection). However, it does not explain the output format or how results are interpreted, leaving some 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?
The input schema already describes both parameters with 100% coverage, so baseline is 3. The description adds no further parameter details; 'smoothing' may relate to 'window' but is not explicit.
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 states it computes the derivative of sentiment with smoothing for early reversal detection, which clearly identifies the tool's function. However, it does not explicitly distinguish it from sibling sentiment tools like get_sentiment.
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 'Pro tier' and 'Early reversal-detection signal' hint at a specialized use case, but there is no direct comparison or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'browse', implying read-only, but lacks details on pagination, ordering, or any side effects. The behavioral profile is under-characterized.
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 succinct sentence with no extra words. It is front-loaded and efficient, even though it sacrifices detail.
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, the description should clarify what is returned. It does not mention response format, ordering, or pagination. The tool is simple, but the description is too minimal for an agent to use correctly without additional context.
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?
Schema description coverage is 0%, and the description adds no information about the 'limit' or 'status' parameters. It does not explain allowed values, defaults, or usage. The agent has no guidance for using the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'browse' and the resource 'public trade theses', with parenthetical clarification of thesis types (entry/invalidation/targets). It distinguishes from sibling 'get_thesis' which retrieves a single thesis.
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. The description does not mention prerequisites, filtering strategies, or when not to use it. The agent must 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.
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 states it lists 'best' opportunities but does not explain how 'best' is determined, data freshness, pagination, rate limits, or any side effects. As a read operation, it fails to disclose whether the data is real-time or cached.
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 very short (two sentences) and front-loaded, but the second sentence ('DefiLlama yields + BCA risk overlay. Starter tier.') reads like fragments. While concise, it sacrifices clarity and structure. Every sentence serves a purpose, but more structured detail would improve usability.
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 tool has 3 optional parameters, no output schema, and no annotations, the description does not adequately compensate. It lacks information on return format, error handling, or data interpretation. The 'Starter tier' label is vague. The tool is embedded in a large ecosystem (many siblings), but the description does not leverage that context.
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 schema has three parameters (chain, limit, min_apy) with no descriptions (0% coverage). The description only hints at 'chain' and 'risk tier', but 'risk tier' is not a parameter and 'min_apy' is omitted entirely. No explanation is given for 'limit' or how to use these parameters. This is severely lacking.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: listing best staking/LP/vault opportunities with filters by chain and risk tier. It specifies data sources (DefiLlama yields + BCA risk overlay) and indicates a simplified version ('Starter tier'), making the purpose distinct and unambiguous. No sibling tools overlap with this function.
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 implicitly suggests usage for quick overviews ('Starter tier') but provides no explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, and there are no similar sibling tools to differentiate from. The hint about 'best' opportunities sets some expectation but lacks clarity on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present. Description does not disclose behavioral traits such as whether it is read-only, if it requires authentication, or what 'Starter tier' implies (limitations). Does not describe caching or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded with key information. Could be more structured with separate lines for value and limitations, but efficient overall.
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?
No output schema, and description fails to specify what the tool returns (e.g., numeric score, units, range). Missing details on 'Composite of BCA Narrative Strength Score' meaning. Incomplete for an agent to fully understand the output.
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?
Parameter narrative has a description with examples in schema, but window parameter is undocumented. Description adds example narratives for context, but does not otherwise enhance meaning beyond schema. Schema coverage is 50%, but description partially compensates.
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 real-time narrative strength for specific categories like AI agents, RWA, etc. Verb 'track' is clear. However, it does not differentiate from sibling 'get_narrative_strength', which likely has similar function.
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. No mention of prerequisites or when not to use. Implied usage for getting narrative strength but lacks explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only states the purpose. It does not specify read-only nature, data frequency, error handling for invalid symbols, or limitations on the 'long-range' scope, leaving significant gaps for an agent.
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 extremely concise at one sentence, but this brevity sacrifices essential usage and parameter details. While it avoids verbosity, it under-specifies, making it less helpful for an AI agent.
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 lack of annotations, output schema, and parameter descriptions, the description is insufficient. It does not cover return format, error scenarios, or relationship to similar price tools like 'get_price' or 'get_ohlc', leaving an agent poorly informed.
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 0%, so the description should explain parameter meanings. It adds value for 'symbol' implicitly but fails to explain 'days' (e.g., optional, range, default behavior). The term 'long-range' hints at temporal scope but does not clarify how the 'days' parameter interacts.
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 'Long-range historical price series for a symbol' clearly states the tool's function with a specific verb ('get history') and resource ('price series'). It distinguishes from siblings like 'get_price' (current price) and 'get_ohlc' (candlestick data) by emphasizing 'long-range' historical 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 obtaining extended historical price data but provides no explicit guidance on when to use this tool over alternatives. It does not mention exclusions or specific contexts, leaving the agent to infer from the 'long-range' qualifier 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 provided, so description must convey behavior. It discloses the feed is chronological and cross-source, but omits details like pagination, rate limits, data freshness, or what 'articles + stories' entails.
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 no filler. Front-loaded with purpose, includes key qualifiers (chronological, cross-source). Every word 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?
For a simple tool with one optional param and no output schema, the description is adequate but could be improved by clarifying the types of sources or the structure of the response. Lacks context compared to sibling tools that provide more detail.
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?
Only one parameter 'limit' with type number, but description adds no explanation beyond the schema. Schema description coverage is 0%, so agent must infer 'limit' meaning from context.
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 chronological cross-source news feed containing articles and stories. The verb 'get' and resource 'unified feed' are specific, but it does not explicitly differentiate from sibling tools like get_currency_feed or get_recent_stories.
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. Does not specify if it should be used for a general overview or for specific filtering. No conditions or exclusions mentioned.
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 of behavioral disclosure. It only states 'Browse' and 'Filter by kind', but does not disclose aspects like pagination, rate limits, or whether the operation is read-only. Given the lack of annotations, this 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence). While it avoids wordiness, it could be more informative without losing conciseness. It adequately front-loads the core purpose but omits useful detail.
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 should explain return structure, pagination, or filtering mechanics. It fails to do so, leaving significant gaps for an agent to determine correct invocation.
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 description coverage is 0%, yet description only mentions 'Filter by kind' without explaining valid values or behavior. The 'limit' parameter is not discussed. This adds minimal meaning beyond the raw 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 browses the BCA entity universe with a specific scope (~200 entities) and indicates filtering by kind. This verb+resource+scope effectively distinguishes it from siblings like get_entity (individual entity) and other list 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 implies usage for browsing and filtering entities, but it does not provide explicit guidance on when to use this tool versus alternatives like get_entity or search tools. 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.
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 tool returns top communities ranked by metrics, but does not disclose read-only nature, auth requirements, rate limits, or side effects. For a list tool, it is likely read-only, but this is not explicitly 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?
A single, front-loaded sentence that conveys the essential purpose and ranking criteria without unnecessary words.
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 is minimal. It does not explain the limit parameter or how to interpret the results. For a simple list tool, it is marginally adequate but lacks completeness.
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?
Schema description coverage is 0%. The only parameter, limit, is not explained in the description. The description adds no meaning beyond the schema's type definition.
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 lists top NFT communities ranked by floor, holders, Discord activity, and OG status. The verb 'list' and resource 'NFT communities' are explicit, and the ranking criteria distinguish it from other list 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?
No explicit guidance on when to use this tool versus sibling tools like list_stablecoins or list_yields. Usage is implied for NFT community discovery, but no when-not or alternatives are provided.
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. Fails to disclose how the score is computed, data sources, update frequency, or that it's read-only (non-destructive).
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, no wasted words. Front-loaded with core action and exchanges. Highly efficient.
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 0% parameter coverage, the description is incomplete. Lacks information on output format (e.g., score range), interpretation, and how to use the parameter effectively.
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 description coverage is 0%, yet description does not explain the sole parameter 'entity_slug'. The agent must guess its meaning (e.g., coin slug or ID).
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?
Clearly states the tool predicts listing probability for Binance, Coinbase, and Upbit. Distinguishes from sibling tools like 'submit_listing' which handles listing requests, and others like 'get_sentiment'.
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. No mention of prerequisites, context, or exclusions. The 'Pro tier' hint is vague.
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 the full burden. It mentions the actions performed (bytecode verification, honeypot check) but does not disclose whether the tool is read-only, any side effects, permissions needed, rate limits, or output format. The term 'static analysis' hints at read-only behavior but is not explicit.
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 extremely concise—one sentence that front-loads the core purpose. It contains no unnecessary words and is well-structured for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema, no annotations), but the description provides minimal context. It does not explain what the analysis returns, how to interpret results, or any limitations. Given sibling tools offer more specialized analysis, more completeness would help the agent decide correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description restates the parameter requirement ('address (0x EVM address)') but adds no new semantic meaning beyond what the schema already describes. The description's mention of 'EVM address' slightly reinforces the schema, but given high coverage, 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 performs basic static analysis on any EVM address, specifically bytecode verification and honeypot check. This is a specific verb-resource combination that distinguishes it from siblings like check_rugpull_risk or get_audit_reports.
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. The phrase 'Starter tier' implies it might be a basic check, but there are no explicit instructions, prerequisites, or exclusions relative to sibling tools.
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 provided, the description must disclose behavioral traits. It states the tool creates a campaign ('Broker') and returns a campaign_id, but does not mention side effects, idempotency, required permissions beyond 'Pro tier', error conditions, or rate limits. This is insufficient transparency for a mutation tool.
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, 25 words) and front-loaded with the primary purpose. Every sentence adds value: first sentence states the action and system, second specifies required inputs and returns. No wasted words.
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 tool has 5 parameters, no output schema, and no annotations, the description is too brief. It does not explain the return format beyond 'campaign_id + next steps', nor does it cover prerequisites, error handling, or the campaign lifecycle. For a business-critical mutation tool, this is incomplete.
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 only 20% (only contact_email has a schema description). The tool description adds meaning by identifying the three required parameters (contact_email, budget_usd, objective) and their role in brokering a campaign. However, it omits any explanation of the two optional parameters (target_audience, launch_window_days), leaving gaps. The description partially compensates for low schema coverage but not fully.
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 states a specific verb ('Broker') and resource ('KOL campaign via BCA Studio CRM'), clearly indicating the tool's action. While it distinguishes itself from the many read-only sibling tools, it does not explicitly contrast with any alternative mutation tools (none exist), so a 4 is appropriate.
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 creating a KOL campaign by listing required parameters and mentioning 'Pro tier'. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention any alternative tools for related tasks (e.g., evaluating KOLs). Usage is implied but not clearly bounded.
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 adds 'Returns time-series. Pro tier' but does not disclose side effects, permissions, limitations, or error behavior. Not enough context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste, front-loaded with purpose. Efficiently communicates key 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?
Missing many behavioral details: no output schema, no explanation of formula syntax beyond example, no clarification of 'BCA primitives', no error handling info. Not sufficiently complete for a build tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 50% with only 'formula' described. Description provides an example (e.g., 'coverage_index(X)/price_change_7d(X)') adding meaning beyond schema. 'target' parameter lacks description in both schema and description text, limiting completeness.
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?
Explicitly states 'Define a custom indicator formula over BCA primitives' with specific verb and resource. Distinguishes from sibling tools which are mostly 'get_' read operations.
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 (e.g., other build tools or get tools). Lacks when/when-not criteria or references to sibling tools.
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 provided, the description carries full burden for behavioral disclosure. It does not state read-only nature, authentication requirements, rate limits, or what 'BCA interpretation' means. The description is too sparse to compensate for missing annotations.
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?
Single concise sentence front-loading the key information (source, content). For a tool with one parameter, this is appropriately sized with 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 the low complexity (1 param, no output schema, no annotations), the description covers the essential purpose and data source. However, it omits details like output format or behavioral traits, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds 'historical series' implying the days parameter controls lookback, but the schema already describes it as 'Lookback days.' No additional meaning beyond 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 retrieves the Crypto Fear & Greed Index from Alternative.me, including historical series and BCA interpretation. This verb+resource explicitly distinguishes it from sibling tools like get_sentiment or get_social_signals.
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. The description does not specify context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name 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 exist, so the description carries full burden. It does not disclose whether the call is safe, destructive, or requires authentication. Only a high-level output breakdown is given.
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 without unnecessary words. Efficient and front-loaded with key output categories.
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 lack of output schema, the description should provide more detail on the returned data structure. It names three components but omits format, field names, or data types.
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 the schema provides full coverage. The description does not add parameter information, but it is not needed.
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 retrieves Solana metrics, top projects, and SPL activity, providing a specific verb-resource mapping. However, it does not differentiate from siblings like get_ton_ecosystem.
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. No exclusions or comparison with similar tools (e.g., get_ton_ecosystem) are provided.
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 says it fetches a topic node with related items but does not disclose behavior on missing slugs, error handling, rate limits, or read-only nature.
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 of 12 words, front-loaded with the action and resource, no redundant information.
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 fetch tool with one parameter and no output schema, the description provides the core return content but lacks details on error conditions, return format, or edge cases.
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 only parameter 'slug' has no schema description (0% coverage) and the description adds no meaning, format, or example for the slug parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'topic node' and specifies what is included (articles under it, parents, siblings), distinguishing it from siblings like list_topics and get_entity.
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 fetching a specific topic node by slug, but does not explicitly state when to use it vs alternatives (e.g., list_topics for listing) or provide exclusions.
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 behavior. It mentions the tool is composite and lists components, but it does not describe the output format (e.g., score, boolean, report), side effects, or authorization requirements beyond Pro tier. This leaves the agent with incomplete understanding of 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 extremely concise—a single sentence—and effectively lists the risk components. It sacrifices some detail for brevity but remains clear. It could be improved by adding a brief note on output, but given the simplicity, it earns a high score for conciseness.
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?
Even with 100% schema coverage and a clear purpose, the description fails to explain what the tool returns (no output schema) and lacks usage context relative to siblings. For a composite risk tool of moderate complexity, the description is incomplete.
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 a clear description for entity_slug ('Required. Target entity slug.'). The description repeats the requirement and implies it is an entity identifier, but adds no extra semantic meaning beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a composite rugpull risk covering specific factors (honeypot, LP lock, ownership renounce, contract verification, team risk). It also mentions the required parameter and that it is a Pro tier feature, making the purpose highly specific and actionable.
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 need for an entity_slug and that it requires Pro tier, but it does not provide guidance on when to use this tool versus alternatives like check_memecoin_risk or check_exploit_history. No explicit when-to-use or when-not-to-use information is given.
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 'with bucket drivers' but does not state that the tool is read-only, whether authentication is needed, what happens if the entity is not found, or any rate limits. The description is insufficient for an agent to understand the tool's impact and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's core function without redundancy. Every word is necessary and relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two parameters, no output schema, and moderate complexity. The description provides the output type (sentiment bucket) but omits the structure (e.g., whether it returns a string or an object with drivers). Given the lack of output schema, additional detail on the return format 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?
Schema description coverage is 100%, so both parameters are documented. The description adds value by explaining that the output includes 'bucket drivers' and that the tool is for an 'entity,' but it does not elaborate on the 'window' parameter (e.g., allowed values, meaning). The baseline is 3, and the description offers marginal additional context.
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 specifically states it returns a 'BCA editorial sentiment bucket (bullish/bearish/neutral/mixed) for an entity with bucket drivers,' clearly identifying the verb (get), resource (entity), and the nature of the output (sentiment bucket). This distinguishes it from sibling tools like 'get_fear_greed' (market-wide) and 'get_sentiment_velocity' (change in sentiment).
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. For example, it does not mention that 'get_fear_greed' is for market-level sentiment or that 'get_sentiment_velocity' is for trend analysis. The description implies it's for entity-specific sentiment but fails to clarify exclusions or preferred use cases.
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 tool returns BCA_NOT_IMPLEMENTED if social ingest is not wired, which is useful, but does not mention other behaviors like rate limits, idempotency, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. The structure is efficient, though it could be improved by adding brief parameter descriptions.
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 parameter count and lack of output schema, the description covers the main function and an important error case, but missing parameter explanations and return format details leave gaps for the agent.
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?
Schema description coverage is 0%, so the description must explain parameters. It does not describe 'entity_slug' or 'window' at all, leaving the agent without guidance on what values to provide or their 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 the tool returns social velocity metrics (mentions, engagement, sentiment) across Twitter/Reddit/Discord, and distinguishes it from siblings like get_sentiment and get_social_signals by specifying the platforms and 'Pro tier' limitation.
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 social metrics but does not explicitly state when to use this tool over alternatives like get_social_signals or get_sentiment. The 'Pro tier' note provides some context but lacks exclusion criteria or 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.
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 mentions 'Pro tier' suggesting restricted access, but does not detail authentication, rate limits, or behavioral impacts like data delay or failure handling.
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, using just two phrases to convey purpose and scope. Every word is informative, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema and annotations; description does not explain return format, pagination, or data freshness. For a Pro-tier tool involving multiple exchanges, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters with basic examples ('BTC', 'ETH' for symbol, comma-separated for exchanges). Description adds no additional meaning beyond schema; baseline 3 for 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 the tool retrieves perpetual funding rates from specific exchanges (Binance, Bybit, dYdX, Hyperliquid, Drift) and indicates it is a 'Pro tier' feature. This distinguishes it from sibling tools like get_price or get_fear_greed.
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 (e.g., get_ohlc, get_fear_greed). The description implies usage for perps funding data, but doesn't provide context on preferred scenarios or exclusions.
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 mentions 'Starter tier' but does not explain implications (e.g., rate limits, data freshness). No disclosure of side effects, authentication needs, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and followed by use case. Every sentence adds value 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?
For a simple data retrieval tool without output schema, the description is minimally adequate. However, it lacks details on data format, pagination, or 'Starter tier' limitations, especially given the large set of sibling tools requiring differentiation.
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 description coverage is 67% (2 of 3 parameters described). The description does not add meaning beyond the schema: the undocumented 'vs' parameter is not explained. The tool description does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'OHLC candlestick history for a token', which is a specific verb-resource combination. It distinguishes from sibling tools like get_price (spot price) and get_pair_data (more comprehensive 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 says 'Useful for technical-setup agents and backtesting', which implies appropriate use cases but does not explicitly state when not to use it or compare with alternatives. The guidance is implicit rather than directive.
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. Description mentions 'Starter tier' implying a limitation, and explains inputs. But lacks side effects or idempotency info.
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, no fluff, front-loaded with purpose and output.
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?
Minimal but covers main purpose and output. Missing: valid entity types, examples, error states. Adequate for a simple tool.
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?
Single parameter entity_slug with 0% schema coverage. Description does not explain what entity_slug means or its format.
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?
Clear statement: composite risk score from specific factors, outputs a single number (0-1). Distinguishable from siblings like check_rugpull_risk.
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 or alternatives. Implied usage for risk assessment, but no context for exclusion.
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 discloses output shape (sentiment score, bucket, article linkback) but omits ordering, pagination, default limit (50), and behavior for parameters like since.
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, compact and front-loaded with key output elements. No wasted words, but could be slightly more structured with explicit output 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?
No output schema is provided, so the description should compensate. It mentions sentiment score, bucket, and article linkback but does not specify mention text, ordering, or how limit/since affect results. Partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds minimal value beyond 'timeline' context, adhering to baseline expectation.
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 timeline of editorial mentions with sentiment score, bucket, and article linkback per mention. This distinguishes it from siblings like search_news (general search) and get_sentiment (aggregate sentiment).
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: 'Use this to reconstruct narrative arc over time.' However, it does not explicitly state when not to use this tool or suggest alternatives among the many sibling tools.
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, yet the description does not disclose behavior such as read-only nature, return format (just names or full details), pagination, or authentication requirements. Minimal transparency for a read operation.
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 key examples and tier info; no fluff. Information is front-loaded and efficient.
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 many sibling tools, the description lacks details on return structure, what 'Starter tier' entails, and whether other tiers exist. Does not fully equip an agent for correct invocation.
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 in schema, so description doesn't need to explain them. The listing of template types adds some semantic value beyond the tool name, justifying a baseline of 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 lists campaign templates with specific examples (TGE checklist, airdrop ops, etc.) and mentions 'Starter tier', which distinguishes it from `get_marketing_template` that likely fetches a single template.
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 like `get_marketing_template`. The 'Starter tier' hint is vague and doesn't clarify when to choose list vs get.
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 states the tool submits a listing (a mutation) but does not disclose side effects, idempotency, error conditions, or what the return value indicates. This is insufficient for a mutation 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 very concise: one sentence plus a brief note on cost. It front-loads the purpose and required parameters. However, it could be more structured with sections for 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 the tool has 4 required parameters, no output schema, and no annotations, the description should explain the directory-specific behavior, what constitutes a valid entity, and the result of submission. The current description is too brief to be fully actionable.
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 description coverage is 50%, and the description adds no new meaning beyond naming the required fields. It does not explain what 'entity' or 'contact_email' represent or how they are used, leaving ambiguity.
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 action ('Submit a listing') and the resource ('BCA directory'), with examples of directories (vcs, aggregators, trading-bots). This distinguishes it from sibling tools like list_vcs which retrieve listings.
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 lists required parameters and notes the cost difference ('Free to call, paid to feature'). However, it does not provide explicit guidance on when not to use this tool or contrast it with alternatives, leaving some ambiguity for an 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?
With no annotations, the description carries full burden. It notes 'Async' and the return format '{job_id, status_url}', which are key behaviors. However, it does not disclose potential side effects (e.g., resource consumption), error conditions, or how to retrieve results later. More detail is needed 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The first sentence states the purpose, the second gives usage constraints, the third describes the return value. Every sentence earns its place, and the critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tokenomics simulation tool with an array parameter and no output schema, the description is too minimal. It omits essential details like how to interpret the result, required data dependencies, and the full async workflow. More context is needed for an agent to use it effectively.
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?
Schema description coverage is 0% for 3 parameters. The description only hints at 'scenarios' but does not explain what parameters mean, their formats, or valid values. Since the description adds no parameter clarification, it fails to compensate for the lack of schema descriptions.
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: 'Simulate emission/unlock impact on FDV across scenarios.' This is a specific verb (simulate) and resource (emission/unlock impact on FDV), and it distinguishes the tool from the many data-retrieval siblings. No tautology or vagueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context: 'Async, Team tier.' This indicates it is for asynchronous simulation and intended for Team-tier users. However, it does not explicitly state when not to use this tool or suggest alternatives (e.g., get_tokenomics for simpler queries). The guidance is clear but not exhaustive.
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 for behavioral disclosure. It mentions the data source and tier, hinting at possible rate limits or dependencies, but does not detail aspects like error handling, data freshness, authentication needs, or what happens if the external API fails.
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, well-structured sentence that front-loads the key purpose and data source. Every part is informative with no 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?
For a simple data retrieval tool with only two string parameters and no output schema, the description covers the essential function and data source. However, it lacks details on return format, potential pagination, or limitations, which would improve completeness for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters well-described. The description does not add additional meaning beyond what the schema already provides (chain slug and pair address). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides DEX pair analytics including specific metrics (liquidity, 24h volume, pair age, price). It names the data source (DexScreener) and tier, distinguishing it from sibling tools like get_price or get_ohlc that cover different data or scopes.
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 DEX pair data through the listed analytics, but it does not explicitly state when to use this tool versus alternatives like get_price or get_market_overview. No exclusion criteria or alternative tool names 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 present, so the description carries full burden. It mentions data sources (composite scoring), but does not disclose behavioral traits such as rate limits, pagination, data freshness, or whether the tool is read-only.
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 is front-loaded with the key ranking criteria and data sources. Every word adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter (no description), no output schema, and no annotations, the description is insufficient. It fails to specify what data fields are returned, how to handle pagination, or the meaning of 'limit'. The agent lacks critical context for correct invocation.
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 one parameter 'limit' with no description and schema description coverage is 0%. The tool description does not explain the parameter's meaning, default value, or allowed range, forcing the agent to guess.
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 that the tool lists stablecoins ranked by TVL, peg stability, audit status, and chain coverage. It specifies data sources (DefiLlama + BCA risk scoring), making the purpose distinct from sibling tools like list_yields or list_aggregators.
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 getting ranked stablecoin data, but provides no guidance on when to use this tool versus alternatives, no context on prerequisites, and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions the data source (DefiLlama) and 'Free tier', which hints at cost but does not disclose rate limits, required permissions, or whether it is read-only (though implied).
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 conveying purpose, metrics, source, and cost tier. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists key metrics (TVL, chains, volume, fees) that hint at the return structure, which is sufficient for a simple snapshot. However, it could mention pagination or data format for 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?
Schema description coverage is 100%, and the description provides an example ('aave', 'uniswap'), which mostly mirrors the schema's own description. The description adds minimal new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'DeFi protocol snapshot' with specific metrics (TVL, chains, volume, fees), distinguishing it from sibling tools focused on prices, sentiment, or other data. The verb 'get' and resource 'defi_protocol' 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 guidance on when to use this tool versus alternatives like compare_protocols or get_tokenomics. The description implies usage for a protocol overview but doesn't mention exclusion or 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?
No annotations are provided, so the description carries the full burden. It describes the tool as performing full-text search and returning results, which is adequate for a read operation. However, it does not disclose any behavioral traits such as whether results are paginated, any authorization needs, or limits on query complexity.
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 efficiently conveys the core purpose and output. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two parameters and no output schema, the description covers the basic functionality and return format. However, it lacks details on parameter semantics and usage context, which prevents it from being fully complete.
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 description coverage is 0%, and the description adds no meaning to the parameters. The 'q' parameter is implied to be the search query but is not explicitly explained. The 'limit' parameter is entirely undocumented. This is insufficient given the lack of schema descriptions.
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 full-text search across academy lessons and specifies the return format (course + lesson anchor per hit). This distinguishes it from sibling tools like search_news which search news rather than academy content.
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 searching academy lessons but provides no explicit guidance on when to use it versus alternatives (e.g., search_news) or when not to use it. No exclusions or context are given.
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?
Without annotations, the description lists detection types (bundler, dev sells, sniper) but fails to describe the output, side effects, or access constraints beyond the implied 'Pro tier'. Missing return value or behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, two sentences long, and immediately states the purpose. No unnecessary words, well-structured.
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 and no output schema, the description covers key aspects of what it does. However, it omits the return format (e.g., score, boolean) and does not provide enough context for an agent to fully understand the invocation's result.
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 a basic description for the 'mint' parameter. The tool description repeats the same info without adding new meaning, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates 'Memecoin-specific risk' and lists specific detection types (bundler, dev sells, sniper). This distinguishes it from sibling tools like check_rugpull_risk or get_risk_score, which cover different risk 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 memecoin risk analysis and mentions 'Pro tier', but it does not explicitly guide when to use this tool versus alternatives like check_rugpull_risk. No when-not-to-use or context exclusions are provided.
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 the method (eigenvector centrality in rolling windows) but does not cover behavioral traits like computational cost, authentication requirements, rate limits, or what happens with missing 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 two sentences, front-loaded with key information, and contains no fluff. 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?
With no output schema and only 2 parameters, the description covers the purpose and method but lacks details on return format, score interpretation, or any edge cases. It is minimally adequate but leaves gaps.
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 description coverage is 100%, but the description adds context that the rolling window is used to track consolidation vs fading, enhancing understanding beyond the schema's brief descriptions.
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 narrative strength via co-mention graph centrality, specifically identifying consolidating vs fading narratives. It distinguishes from sibling tools like get_sentiment or get_social_pulse by focusing on narrative centrality.
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 'Pro tier' implying premium access but gives no explicit guidance on when to use this tool vs alternatives, nor when not to use it. Usage context is somewhat implied by the name but not explicitly 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?
With no annotations provided, the description carries the full burden. It adds the behavioral detail 'Includes attributed header,' but does not cover potential errors (e.g., if slug not found), read-only nature, or any constraints. Minimal but adequate for a simple fetch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and resource. Every word contributes value; 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 (one parameter, no output schema), the description is mostly complete. However, it could mention the return type or that it's a read-only operation to fully compensate for missing annotations.
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 description coverage is 0%, meaning the schema only defines type 'string' for 'slug'. The description mentions 'by slug' but does not elaborate on format, examples, or case-sensitivity, thus adding little meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool fetches a specific smart contract template by slug, and notes the inclusion of an attributed header. The verb 'Fetch' and resource 'smart contract template' are specific, and the description implicitly distinguishes it from list_smart_contract_templates.
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 like list_smart_contract_templates. While the purpose implies usage when the slug is known, there is no direct comparison or exclusions 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 provided. Description indicates escalation to a skill (suggesting async processing), but does not detail side effects, rate limits, or authentication. Adequate for a straightforward request tool.
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 conveys action, prerequisites, tier, and outputs. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Specifies inputs and outputs but lacks explanation of workflow (e.g., async processing, delivery method). For a request tool without output schema, it is mostly complete but could add a note on expected turnaround or process.
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?
Only 2 of 4 parameters (contact_email, topic) are described in text. Depth and deadline_days are omitted despite low schema description coverage (25%). Description adds meaning for required ones but neglects optional 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?
Clear verb ('Request custom research') with specific resource ('BCA deep-researcher skill'), required parameters listed, and return fields stated. Distinct from sibling tools which are data retrieval queries.
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?
Specifies 'Pro tier' indicating audience, but does not explicitly state when to use vs alternatives or exclude conditions. Context implies it's for custom requests not covered by other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It implies a read-only listing operation but does not explicitly state that it is safe, non-destructive, or whether it requires network access or has rate limits. The description focuses on content rather than 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 extremely concise with two straightforward sentences. It front-loads the key information ('Audited Solidity templates') and provides concrete examples, earning its place without extraneous detail.
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 adequately informs the agent what the tool returns (a list of template types from known sources). It could mention that each template has an identifier or that tools like 'get_smart_contract_template' can retrieve details, but it is largely complete for a list 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 zero parameters, so the schema coverage is 100% trivially. The description adds value by listing the categories of templates available, which informs the agent about the expected output schema beyond the empty input 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 lists audited Solidity templates and enumerates specific types (ERC20, ERC721, etc.) and sources (OpenZeppelin, BCA academy). This distinguishes it from sibling tool 'get_smart_contract_template' which retrieves a single template. The verb 'list' is explicit in the name, and the description confirms the scope.
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. It does not mention prerequisites, when not to use it, or suggest related tools like 'get_smart_contract_template' for a specific template.
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 only states what the tool returns, but does not mention if the list is cached, how often it updates, any authentication needs, or limitations. For a simple list tool, this lacks sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no fluff. Every word adds value, making it appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description covers what the tool does and what it returns (list of sources with trust tier). It could mention if the list is ordered or static, but it is largely complete for its simplicity.
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_description_coverage is effectively 100%. The baseline for zero parameters is 4. The description adds context about the contents ('trust tier'), which is helpful 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 the verb ('list') and the resource ('editorial news sources BCA ingests'), and adds the specific attribute 'with trust tier'. It distinguishes itself from sibling tools like search_news or get_article by being the only tool that returns a complete source list.
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: to get all sources. However, it does not explicitly state when to use this tool over alternatives, nor does it mention any prerequisites or exclusions. With zero parameters, usage is obvious but guidance is minimal.
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 discloses that the action is async and requires Pro tier, but lacks details on webhook payload format, whether monitors are persistent, how to cancel, or rate limits. Since no annotations are provided, the description carries the full burden and is 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 two sentences long, front-loads the purpose, and contains no extraneous information. Every word earns its place.
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 omits critical context such as limits on monitors, how to remove a monitor, webhook payload details, and any constraints on the keyword. For a tool that sets up persistent monitoring, this lack of completeness hinders an agent's understanding.
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 description covers the two required parameters (keyword, webhook_url) with a hint about HTTPS for webhook_url. However, the optional parameter window_hours is not mentioned in the description, and its purpose is unclear. Schema coverage is only 33%, so the description partially compensates but misses an important parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Register', the resource 'keyword monitor', and the action 'fires a webhook when the keyword appears across corpus'. This distinguishes it from sibling tools, which are mostly read/get operations.
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 required parameters ('keyword, webhook_url') and mentions 'Async, Pro tier', providing context for when to use. However, it does not explicitly state when not to use or suggest alternatives.
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?
Without annotations, the description must disclose behavior. It notes async and Pro tier but omits details on auth, rate limits, error handling, or URL validation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loading key information: action, async, Pro tier, return format. No waste.
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 explains return values. It covers purpose, async behavior, and return format but lacks error scenarios or prerequisites. Adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (url described, length not). The description adds context for url (whitepaper) and return format but does not explain the length parameter. Partial compensation.
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 action ('Fetch + structurally summarize'), the resource ('whitepaper URL'), and the async nature, distinguishing it from synchronous sibling tools like get_article.
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 'Async, Pro tier', implying it is for long-running tasks and requires a subscription, but it does not explicitly compare with alternatives or specify when to use / not 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?
With no annotations, the description must carry the behavioral burden. It correctly indicates a read-only, non-destructive operation and mentions the enterprise tier. However, it does not disclose return format, pagination, performance considerations, or access restrictions beyond tier, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with no filler. The key term 'Time-travel query' is front-loaded, immediately conveying the core function.
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 four parameters, no output schema, and no annotations, the description is minimal. It covers the high-level purpose and use case but omits details on return values, error conditions, or parameter constraints (e.g., date range limits). For a simple snapshot tool, this is adequate but not thorough.
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 75%; one parameter ('limit') lacks schema description. The description adds minimal value beyond the schema: it reiterates 'as_of' as ISO 8601 without further detail. It does not explain 'limit', 'query', or 'entity' semantics beyond their names.
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 purpose: a time-travel query to return corpus state at a historical date. It uses specific verbs ('return the corpus state') and distinguishes from siblings by emphasizing 'time-travel' and 'Enterprise tier', which is unique among the listed 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 provides clear usage context: 'Enterprise tier' and 'Useful for backtesting and audit trails.' It implies when to use this tool (historical queries) but does not explicitly state 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It describes inputs (price return and coverage delta) and the lag range, but does not specify output format, return type, or any side effects. This is minimally acceptable but leaves 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 three sentences, front-loads the purpose, and contains 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (correlation with lags) and lack of output schema, the description should clarify the return type (e.g., single number or series) and how to interpret 'coverage delta'. The supported windows are limited to two, leaving the agent with 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?
Schema description coverage is 100%, but the schema only gives basic descriptions. The description adds concrete valid values for 'window' ('30d, 90d') and context about lags, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes 'Correlation of price return to coverage delta (lagged -1 to +3 days)', uses a specific verb ('get'), and distinguishes itself from siblings like get_price and get_coverage_index by its focus on correlation with lags.
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 'Pro tier' and 'Measures pre-coverage accumulation edge', which hints at use cases, but it does not explicitly state when to use this tool over alternatives like get_history_correlation, nor does it provide 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?
No annotations provided, so description carries the full burden. It lists the returned fields but does not mention any side effects, rate limits, or data freshness. Adequate for a read-only tool but lacks behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with the core action and immediately followed by usage context. Every word earns its place.
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?
Lacks output schema, so the description should explain return format more. It mentions returned fields but not ordering, pagination, or data source. Adequate for a simple tool but not fully complete for an autonomous agent.
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 the single parameter 'limit' described as 'Top N by mcap.' The description repeats this but adds no new details (e.g., default value, range), so it does not go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Top-N tokens by market cap' with specific attributes (volume, 24h change, category tags), which distinguishes it from sibling tools like 'get_price' or 'get_sentiment' that focus on narrower 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?
Explicitly tells when to use: 'for market-wide context (bull/bear, mover spotting).' Does not list exclusions or alternatives, but the context is clear enough for an agent to choose this tool over others.
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 full burden of behavioral disclosure. It indicates the tool returns balance, tokens, and labels, and mentions 'Starter tier' (which hints at limitations). However, it does not state whether the operation is read-only, required permissions, or any rate limits, leaving some transparency 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 brief and front-loaded, consisting of two sentences that convey the core functionality and use case without extraneous information. Every part 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 the lack of output schema, the description reasonably covers return values (balance, tokens, labels). The mention of 'Starter tier' is somewhat ambiguous, and additional details about result structure or pagination would improve completeness, but overall it is adequate for the tool's complexity.
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 describes the 'address' parameter with a clear pattern (EVM or Solana), but the 'chain' parameter has no description. The tool description mentions ERC-20/SPL tokens, which implies Ethereum and Solana chains, but it does not explicitly link to the 'chain' parameter. With only 50% schema description coverage, the description does not sufficiently compensate for the undocumented parameter.
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 a wallet summary including native balance, ERC-20/SPL token list, and labels, and explicitly mentions its use for wallet research and clustering. This distinguishes it well from sibling tools that focus on other aspects like transactions or token holders.
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 explains when to use the tool ('for wallet research and clustering') and implies it is for getting a high-level overview. It does not explicitly mention alternatives or when not to use it, but given the distinct purpose among siblings, the guidance is clear enough.
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 async behavior, return format (job_id, status_url), and polling need, plus notes Pro tier access. Missing details like error handling or invalid slug behavior, but covers key behavioral traits sufficiently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose concisely, second packs required param, depth options, async nature, return format, polling instruction, and tier. Every word earns its place; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is async and has no output schema, the description adequately covers what it does, required parameter, depth, and how to retrieve results. The optional focus parameter is not explained, which is a minor gap. Overall, sufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds a note on depth values (light, standard, deep) but those are already in the schema. It does not elaborate on the optional focus parameter beyond its schema description. No new meaning beyond 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 kicks off a full due-diligence report covering tokenomics, team, audits, risk, and narrative, distinguishing it from sibling tools that focus on individual aspects. The verb 'kick off' and listing components make the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions required parameter entity_slug and depth options, and instructs polling get_agent_job. However, it does not explicitly state when to use this tool versus alternatives like check_rugpull_risk or get_audit_reports, leaving some ambiguity about when a full report is appropriate.
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 explains the scoring formula and notes 'Pro tier' for access, but does not confirm read-only nature, indicate data sources, or disclose any side effects or limits. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no filler. The purpose is front-loaded and every phrase serves a purpose. 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 2-parameter tool with high schema coverage and no output schema, the description covers the essential behavioral context (formula, premium tier, parameter hints). Missing details about return format (e.g., returns a number or score) but overall 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?
Schema coverage is 100% with minimal descriptions. The tool description adds value by specifying that entity_slug is 'the KOL's canonical entity slug' and explicitly listing supported window values ('30d, 90d'), which is not in the schema. This enhances parameter understanding beyond the bare 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?
Description clearly states it computes a KOL influence score with a specific formula (reach × engagement × historical pick accuracy). Identifies the resource (KOL influence) and verb (get). Differentiates from numerous sibling tools which cover other metrics like fear/greed, news, prices, etc.
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?
Mentions 'Pro tier' indicating access restrictions and lists supported windows (30d, 90d), but does not explicitly state when to use this tool vs alternatives or when not to use it. Lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden; it reveals ranking criteria but omits output structure, pagination, or rate limits, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a focused two-sentence structure with no wasted words, front-loading the core purpose and required parameter.
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 simple schema and lack of output schema, the description adequately explains the tool's function and ranking criteria, though output details could be clearer.
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%; the description repeats the allowed values but adds no new meaning beyond what the schema already provides.
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 lists DEX, bridge, or yield aggregators ranked by volume, fees, and chain support, which distinguishes it from other list tools among siblings.
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 specifies the required 'kind' parameter with valid values, providing clear context for when to use the tool, though no explicit 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?
No annotations are provided, so the description carries full burden. It mentions the data source (CoinGecko) and warns about ID format, but lacks details on rate limits, data freshness, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary information; front-loads the key verb and resource.
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 present, and the description does not explain the return format or fields. For a simple tool, it is mostly adequate but leaves some ambiguity about output 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?
Schema coverage is 100%, and the description adds value by providing examples and emphasizing the required CoinGecko ID format, going beyond the schema descriptions.
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 retrieves spot price and 24h/7d/30d changes for tokens via CoinGecko, distinguishing it from other price-related tools like get_ohlc or get_history_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?
Provides explicit guidance on using CoinGecko IDs instead of exchange tickers, but does not explicitly mention when to use this tool versus alternatives like get_ohlc.
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 full burden. It discloses that the tool returns balances and percentage of supply for top holders. This implies a read-only, non-destructive operation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundancy. Front-loaded with core information, then constraints and usage. Every word 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?
Description covers purpose and constraints but lacks details on return format, ordering of 'top' holders, and how 'limit' affects results. With no output schema, additional clarity would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 67% of parameters with descriptions (chain and contract). Description adds no extra parameter details beyond reiterating EVM-only. The 'limit' parameter remains undescribed. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns top token holders with balance and %-supply, specifies EVM-only and Pro tier, and provides a use case (concentration/risk analysis). The verb 'get' and resource 'token holders' are explicit.
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 explicitly states EVM-only and Pro tier constraints, and suggests use for concentration/risk analysis. It does not mention when not to use or alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses 'Async' (asynchronous) and 'Team tier' (access requirement), but lacks details on response format, job polling, or side effects. Adequate but not thorough.
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 core purpose followed by succinct cues on requirements and async nature. No redundant words; efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param translation tool with no output schema, description is moderately complete. It mentions async behavior but doesn't explain the return type or job handling. Lacks details on error cases or size limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by listing supported languages ('Solidity ↔ Vyper ↔ Move ↔ Anchor'), which hints at allowed values beyond the schema's generic descriptions.
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 'Translate a smart contract between languages' and lists specific languages (Solidity, Vyper, Move, Anchor). Verb and resource are explicit, and no sibling tool performs translation, so differentiation is clear.
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?
Specifies required parameters and mentions 'Async, Team tier', which gives usage context. However, no explicit when-to-use or when-not-to-use guidance, though uniqueness among siblings makes it implicitly the only translation tool.
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, so description carries full burden. Clearly indicates read-only listing behavior. No mention of destructive side effects. Adequate for a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. Front-loaded with purpose. 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?
Given no parameters and no output schema, description adequately explains tool returns. Could elaborate on 'tool surfaces' but sufficient for a meta directory 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?
No parameters; schema coverage is 100% (empty). Description adds context about returning tool surfaces. Baseline for 0 params is 4, and description meets this.
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?
Clearly states it's a directory of crypto MCP servers (meta MCP-of-MCPs) to discover peer MCPs and their tool surfaces. Distinguishes from sibling tools which are specific crypto data 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?
Implied usage as a discovery tool for other MCPs, but no explicit when-to-use, when-not-to-use, or alternatives given. Context from sibling list suggests it's a meta tool, but guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. While it implies a read-only fetch, it does not explicitly state side effects, authentication needs, or rate limits. The description is adequate but lacks optional behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first declares the action and outputs, the second gives usage guidance. Every word earns its place; no redundancy or fluff.
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 the simple single-parameter tool and no output schema, the description explicitly lists all return fields (full body, citations, entity graph, attribution metadata), making it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter (slug) described as 'Article slug.' The description does not add extra meaning beyond the schema, earning a baseline score of 3.
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 fetches a single editorial crypto article by slug, listing the returned content (full body, citations, entity graph, attribution metadata). It distinguishes itself from siblings like get_explainer or get_entity by specifying exactly what it retrieves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs the agent to use this tool after search_news when full text is needed, providing clear context and a specific alternative (search_news). This is excellent guidance for 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?
Without annotations, the description implies read-only behavior via the verb 'browse', but does not disclose details like whether the list is static, paginated, or what the exact output structure is. The transparency is adequate but not thorough.
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 with no wasted words. The main action is front-loaded, and the usage guidance follows naturally.
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 zero parameters, no output schema, and simple listing behavior, the description fully covers what an agent needs to know: what the tool does and why to use it.
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 is not required to add parameter information, and it correctly omits any unnecessary detail. Baseline 4 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 browses the BCA topic taxonomy with specific examples (regulation, defi, etc.), and distinguishes its purpose from sibling tools by focusing on topic listing for filter discovery.
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 tells when to use the tool: 'Use to discover filter values for search_news'. This provides clear context, though it does not mention when not to use alternatives.
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, so description carries full burden. States polling behavior and return structure. Adequate for a simple polling tool, though could mention non-destructive nature or that job may be eventually removed.
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: one sentence with key information and return format. No unnecessary 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 the tool's simplicity and lack of output schema, the description is complete enough. It covers the purpose, parameters, and return values. Minor omission: no mention of error handling or invalid job IDs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 100% with job_id description. Description adds value by specifying that the job ID comes from any generate_* tool, which is beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Poll' and the resource 'async agent job', with specific return values. Distinguishes from many sibling get_* tools by being the only polling tool for async jobs.
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?
Implies usage after calling a generate_* tool (job_id from those). No explicit when-not or alternatives, but the context is clear given the sibling tools and the parameter description.
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?
Describes what the tool returns (dossier with articles, aliases, sentiment) and mentions alias resolution. Without annotations, it carries the burden but adequately discloses 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?
Three sentences, front-loaded with purpose, no wasted words. Efficiently conveys key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage context, and output content. Lacks details on error cases or return format, but adequate given no output schema.
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 has zero parameters, but the description implies it accepts entity names/aliases, which could confuse agents. Adds context beyond schema but conflicts with schema structure.
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?
Clearly states it fetches a canonical BCA entity dossier for projects, people, etc., with cross-referenced articles and sentiment. Distinguishes from sibling tools like search_news and generate_due_diligence by specifying its 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use after search_news or for 'what is X' questions, and prefers over generating definitions. Provides clear context for when to invoke.
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, so description carries full burden. Clearly describes a read-only retrieval operation ('Fetch a canonical lesson') with no side effects. Does not explicitly state read-only or safety, but its nature as a fetch is transparent. Some behavioral details (e.g., no output schema) could be added, but overall 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?
Two sentences: first covers purpose and scope, second adds usage guidance and preference over alternatives. No wasted words, front-loaded with key information. Exceptionally concise.
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?
With zero parameters and no output schema, the description should explain how the tool determines which lesson to fetch. The phrase 'canonical BCA Academy lesson' implies a specific lesson, but no mechanism is described. Given the context of many sibling tools, this omission leaves ambiguity about how the tool uses conversation context or other signals. Completeness is slightly lacking.
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 in the input schema, so baseline is 4. The description does not need to explain parameters, but it does not clarify how the tool selects which lesson given zero input, leaving a minor gap. However, for a tool with no parameters, the description is informative enough.
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?
Clearly states the tool fetches a canonical BCA Academy lesson, specifies the number of lessons (43) and courses (9), and lists covered topics (crypto fundamentals, DeFi, etc.). Distinguishes from generating own definitions, making purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this when the user needs a grounded, pedagogically sound explanation' and provides example queries. Advises to prefer this over generating own definitions, giving clear when-to-use and alternatives.
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 full burden. It discloses that the tool searches a specific corpus of 3,501+ editorial articles and returns dated, cited facts. It does not mention rate limits, pagination, or potential side effects, but being a search tool, it is inherently read-only and non-destructive. The description adds sufficient behavioral context beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences perfectly sized: the first defines the tool's core functionality and outputs; the second gives usage rationale and recommendation. Every sentence is essential, no repetition, and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a search tool: it states the corpus size, what is returned, and why to use it. With no output schema, describing return values is sufficient. It could mention how to handle large result sets or that the corpus is fixed, but the limit parameter covers pagination implicitly. Given the complexity and sibling tools, this is adequately 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?
Schema coverage is 100%, so the description does not need to redefine parameters. However, it adds meaning by setting the context of 'full-text search' and 'editorial crypto articles', which implies the query acts on a curated corpus. The description of returned fields (titles, summaries, etc.) indirectly enriches parameter understanding. This exceeds the baseline of 3 by providing operational context.
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 performs 'Full-text search across 3,501+ editorial crypto articles' and specifies the returned data (titles, summaries, citations, entity graph, attribution metadata). This distinguishes it from sibling tools like get_article or get_recent_stories, which are more specific retrieval operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use this whenever the user asks about recent crypto events, projects, tokens, regulation, protocols, or people' and 'Prefer this tool over generating claims from memory.' This clearly indicates when to use and why it is superior to relying on pretraining. No exclusion criteria are needed given the tool's broad applicability.
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:

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

Score Badge

Copy to your README.md:

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

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