bca-mcp

Server Quality Checklist

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

Latest release: v0.3.1
Disambiguation4/5
The tools cover a wide range of distinct functionalities, from market data to risk analysis to academic resources. While some tools like 'get_sentiment' and 'get_sentiment_velocity' are closely related, their descriptions and parameters clearly differentiate them. Overall, the set is well-disambiguated with minimal overlap.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case. The verbs are descriptive (get, list, search, track, etc.) and the nouns precisely indicate the resource. There are no mixed conventions, making the tool surface predictable.
Tool Count2/5
98 tools is far above the typical range for an MCP server. While the server aims to be a comprehensive crypto research platform, this large number can be overwhelming and suggests a lack of focus. Many tools could be consolidated or omitted.
Completeness4/5
The tool set covers nearly every aspect of crypto research: market data, on-chain analysis, risk assessment, news, academic content, and even job boards. It provides both basic and advanced analysis tools. Minor omissions (e.g., no tool for updating submitted listings) are acceptable for a research-focused server.
Average 3.1/5 across 98 of 98 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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 are provided. The description fails to disclose whether the tool is read-only, whether it aggregates data, or any side effects. It only lists three platforms without 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 5 words, but this brevity sacrifices clarity and utility. It lacks a verb and front-loading of critical information. While it is not verbose, it is under-specified.
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 explanations, the description is severely incomplete. It does not cover return value, behavior, or how to use the two parameters. The context signals indicate low schema coverage, and the description fails to compensate.
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?
With 0% schema description coverage, the description must explain parameters but does not. It does not mention 'topic' (a keyword for filtering) or 'limit' (maximum results). The description adds no semantic value beyond the schema structure.
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 'Polymarket + Kalshi + Azuro odds.' is a noun phrase lacking a verb. It implies retrieving odds from these platforms but does not explicitly state an action like 'get' or 'retrieve'. It provides some domain context but is too vague to clearly define the tool's purpose.
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 siblings such as get_price, get_sentiment, or other 'get_' tools. There is no mention of use cases, prerequisites, or alternatives.
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 carries the full burden of behavioral disclosure. It fails to mention any behavioral traits such as data freshness, rate limits, or whether the operation is read-only. The description is essentially silent 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but at the cost of critical information. It qualifies as under-specification rather than effective conciseness, as it omits essential details needed for correct 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 tool has two parameters, no output schema, and no annotations, the description is wholly inadequate. It does not explain what 'BCA' is, what the output looks like, or any constraints on usage, making it impossible for an agent to use 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%, and the description adds no meaning to the parameters 'entity_slug' or 'days'. The description does not explain what these parameters represent or how they affect results, leaving the agent with only the schema names.
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 'Historical BCA coverage series per entity' is vague and does not clearly state what the tool does. 'BCA' is an acronym without definition, and 'coverage series' is ambiguous. It fails to differentiate from sibling tools like 'get_coverage_index' or 'get_history_correlation'.
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 explicit context, prerequisites, or exclusions, leaving the agent without direction for appropriate invocation.
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 carries full burden for behavioral disclosure. It says nothing about data freshness, permissions, formatting, or any side effects. 'Pro tier' hints at access restrictions but is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but not concise in a helpful way. It lacks essential information, making it under-specified rather than efficiently 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, and a single parameter, the description is woefully incomplete. It doesn't explain the return format, how to interpret the heatmap, or any prerequisites.
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 adds no meaning to the 'symbol' parameter. The parameter constraints (pattern, length) are not explained. The description should clarify that symbol is a cryptocurrency ticker.
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. It implies a liquidation heatmap but doesn't clearly state that the tool retrieves a heatmap of liquidation levels for a given cryptocurrency symbol. It fails to differentiate from sibling tools like get_funding_rates or get_options_flow.
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 are no exclusions, contexts, or when-not scenarios. The agent receives no help in choosing 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavioral traits. It only mentions exchanges and 'Pro tier', failing to specify whether the tool is read-only, return format, or any constraints. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise at one line, but this brevity sacrifices necessary detail. While front-loaded, it does not earn its place due to lack of informative content.
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 of options data and minimal schema, description is grossly incomplete. No indication of output format, data fields, or pagination. Missing crucial information for a tool with a single required parameter.
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?
With 0% schema description coverage, description must explain the meaning of 'symbol'. It does not clarify that symbol likely represents a ticker or underlying asset, leaving the parameter's role ambiguous.
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?
Description uses cryptic terms 'IV, strike heatmap, block trades' without a clear verb indicating what the tool does. It mentions exchanges and 'Pro tier' but lacks a straightforward statement like 'Retrieves options flow data'. This is vague and does not effectively convey purpose compared to 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 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 get_funding_rates or get_liquidation_heatmap. Description omits context about symbol requirements or data applicability, leaving the agent without decision support.
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 exist, and the description fails to disclose any behavioral traits. It does not mention whether the tool is read-only, requires authentication, has rate limits, or what effects it has on the system. This is a critical gap for a tool that likely accesses external data.
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 (4 words) but under-specified. It lacks structure (e.g., no sentences) and does not earn its brevity by providing essential information. It is more an omission than 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 the tool's simplicity (one parameter, no output schema), the description is severely incomplete. It does not describe the output format, pagination, data freshness, or error handling, leaving the agent with insufficient context to use the tool 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?
The input schema has a single optional parameter 'limit' with no description, and the schema description coverage is 0%. The tool description does not explain the parameter's meaning, default values, or how it affects results, leaving the agent without necessary context.
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 'pump.fun trending + new launches' vaguely indicates the tool tracks trending and new launches on pump.fun, but it does not specify the verb (e.g., retrieve, monitor) or the exact resource. It lacks clarity on what constitutes 'trending' versus 'new launches' and does not differentiate from sibling tools like track_bonkfun.
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 guidance is provided. The description does not state when to use this tool versus alternatives such as get_trending or other track_* tools, nor does it explain any prerequisites or optimal 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?
No annotations provided, and the description fails to disclose any behavioral traits (e.g., data freshness, rate limits, side effects). The description is merely a list of nouns, offering no transparency.
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. Not concise in a helpful way; lacks structure and essential 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 no parameters or output schema, the description should be self-sufficient. It fails to explain what the tool returns or its intended use, making it 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?
Input schema has 0 parameters with 100% coverage. Baseline for 0 params is 4, but description adds no meaning beyond the schema. It does not clarify any parameter expectations, though none exist.
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?
Description lists 'Bittensor subnets, Ritual, Prime Intellect. Starter tier.' but does not specify what the tool does. No verb or action, so purpose is vague and not clearly differentiated from sibling tools like 'get_ai_agent_tokens'.
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 provides no context 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 exist, and the description does not disclose behavioral traits such as read-only status, rate limits, data freshness, or whether the list of tokens is static. The word 'tracker' implies data retrieval but is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence) but sacrifices clarity for brevity. It lacks essential information and does not front-load the most critical purpose.
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 severely incomplete. It does not specify what the tool returns (e.g., token data points, IDs, prices), how the limit parameter affects output, or any behavior details.
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 (limit) has no description in the schema (0% coverage), and the tool description does not explain its purpose, effect, or relationship to results. The description adds no value beyond the parameter name and default.
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 it as an 'AI agent tokens tracker' and lists examples (Virtuals, ai16z, etc.), giving a general purpose. However, it lacks specificity on what data is tracked (prices, market cap, etc.) and does not clearly differentiate from sibling tools like get_ai_crypto_metrics or get_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 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 does not mention conditions, prerequisites, or scenarios where this tool is preferred.
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. It does not state whether the operation is read-only, requires authentication, or what the output looks like, leaving the agent with no information about side effects or prerequisites.
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 includes potentially misleading information (contracts without a corresponding parameter). It is not efficiently packed with useful 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?
Given the lack of output schema and annotations, the description should explain what the tool returns (e.g., whether it returns a boolean, a risk score, or details). It fails to provide this, leaving the agent with incomplete information for a check 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 input schema covers the parameter thoroughly (regex, length, required), but the description adds no additional meaning. With 0% schema description coverage, the description should compensate but fails to do so.
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 'check phishing/scam domains + contracts', which indicates the tool's purpose. However, the input schema only includes a 'domain' parameter and no contract parameter, creating a slight mismatch that could confuse an AI agent about how to check contracts.
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 check_exploit_history or check_rugpull_risk. The description lacks context for appropriate 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 behavior. It fails to state that the tool is read-only, what exactly is returned, pagination behavior, or any side effects. Only a one-word action is implied.
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 a single short phrase, which is under-specified rather than concise. It omits essential context that would fit in a few sentences.
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 simplicity, the description should at least clarify output type (list of projects) and optional filtering. It provides no value beyond the name, leaving the agent to guess.
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 0% schema description coverage, and the description adds no explanation. It does not state that limit controls the number of projects returned or its default value.
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 'DePIN ecosystem tracker' identifies the domain (DePIN) but uses a vague verb 'tracker' instead of specifying retrieval. It does not differentiate from siblings like get_solana_ecosystem or get_defi_protocol.
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. Among many ecosystem tools, there is no context for selection, prerequisites, 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?
With no annotations provided, the description must fully disclose behavior. It only states 'chronological news feed' but fails to mention pagination, data freshness, rate limits, or whether the feed includes all news or filtered content. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence). However, conciseness sacrifices necessary detail, making it inadequate for any non-trivial use. Every sentence should earn its place, but this single sentence provides minimal value.
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, 0% parameter coverage, and a single-sentence description, the tool is severely under-documented. The agent has no information about return format, error conditions, or how to handle failures, making the description completely inadequate.
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 compensate by explaining parameters. It does not mention 'symbol' or 'limit' at all, leaving the agent without any guidance on what values to provide or how they affect the output.
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 chronological news feed for a single currency. It differentiates from sibling tools like get_unified_feed by specifying 'single currency'. However, it does not clarify what constitutes a 'currency' (e.g., cryptocurrency vs fiat), leaving room for 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 like get_unified_feed or get_article. The description lacks any context about prerequisites, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully communicate behavioral aspects. It only says 'tracker', implying read-only, but lacks details on output format, pagination, rate limits, or any side effects. This is insufficient for an agent to understand 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 (one sentence), which is concise but at the cost of essential information. It could be restructured to include more detail without being verbose, but as is, it 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?
Given the tool has only one optional parameter and no output schema, the description still fails to explain what the tool returns, how the limit works, or any authentication requirements. It is not complete enough for an agent to use 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?
The schema has a single 'limit' parameter with 0% description coverage, and the tool description does not address it. The agent receives no help on what the parameter does, how it affects results, or its acceptable values beyond basic constraints in 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 states 'Real-world asset tokenization tracker', which clearly identifies the tool's focus on RWA tokenization, distinguishing it from many sibling tools that cover other crypto topics. However, the phrase 'Starter tier' is ambiguous and does not add 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 is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage without 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, so the description must carry the burden. It only states 'cross-symbol' but omits details on pagination, rate limits, error handling, or read-only nature. The behavior is opaque.
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 but lacks substance. It could be more informative without being lengthy. Every sentence should earn its place; this one barely does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the tool's potential complexity (social signals across symbols), the description is insufficient. It does not explain return format, supported symbols, or default behavior, 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?
Only one parameter (limit) with schema coverage at 100% and a clear schema description ('Top-N signals to return.'). The tool description adds no extra meaning, so it meets the baseline but does not surpass it.
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' indicates it provides social signals across symbols, but it's vague—does not specify what kind of signals or symbols, and fails to differentiate it from siblings like get_social_pulse or get_social_signals_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 guidance on when to use this tool versus alternatives. Sibling tools exist but are not mentioned, and there is no context about 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits (e.g., rate limits, output format). It only mentions 'Starter tier' which hints at limitations but lacks specifics. The description is insufficient to understand the tool's behavior beyond its basic function.
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 (five words plus 'Starter tier'), but it sacrifices necessary details. While front-loaded with the key purpose, it could benefit from 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?
Given the single required parameter and no output schema, the description should explain what the output contains (e.g., tax rates, rules list). The mention of 'Starter tier' is vague. The tool lacks completeness for effective use.
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 for the country parameter, and the description adds no meaning beyond what the schema constraints provide. No examples or format guidance are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool provides crypto tax rules per jurisdiction, aligning with the tool name and country parameter. However, 'Starter tier' introduces ambiguity about scope, and it does not explicitly differentiate from similar siblings like get_regulatory_status.
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. The description does not indicate when to use this tool over alternatives or specify any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description is sole source. 'Browse' suggests read-only, but no details on pagination, sorting, field behavior, or what 'redacted' implies. Basic but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool description is a single short sentence, but it under-specifies behavior and parameters. Conciseness sacrifices 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 low complexity (1 optional param, no output schema), the description still lacks details on return format, redaction behavior, and ordering. Contextually incomplete for an agent to use 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 has no descriptions (0% coverage) and the tool description does not mention the 'limit' parameter. No added meaning beyond the schema's constraints.
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 'Browse public investment memos (paid fields redacted)' clearly states the action and resource, and hints at a limitation (redacted fields). It distinguishes from sibling 'get_memo' by implying a list vs single item, though 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 on when to use this tool vs alternatives like 'get_memo' or other list tools. No conditions, exclusions, or context 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 full burden. It implies a read operation with 'browse', but does not disclose any behavioral traits such as whether it requires authentication, rate limits, pagination behavior, or that it is read-only. 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 but too minimal. It front-loads the purpose, but lacks structure and fails to include necessary 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?
Given no output schema, the description should explain what the returned list contains (e.g., thesis titles, IDs). It does not. Parameter meanings and behavioral context are missing, leaving the description incomplete for a simple listing 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?
Schema description coverage is 0% (both parameters lack descriptions). The tool description does not mention or explain the 'status' or 'limit' parameters, adding no meaning beyond the schema's basic structure and enums.
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 uses a specific verb ('Browse') and resource ('public trade theses'), and mentions types of theses (entry/invalidation/targets). It distinguishes from siblings like 'get_thesis' by indicating a list operation, though it does not explicitly contrast 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 alternatives like 'get_thesis' or 'list_memos'. No context on prerequisites, filter combinations, or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It only states the purpose but does not disclose behavior such as data source, update frequency, rate limits, or any side effects. The agent cannot infer how the tool operates beyond fetching trending launches.
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 4 words, but this brevity sacrifices essential information. While no wasted words, the lack of detail makes it barely adequate.
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 one parameter, the description fails to explain return values, data format, or interpretation of 'trending launches'. The tool is likely functional, but the description leaves the agent 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?
The input schema has 0% description coverage, and the tool description does not mention the 'limit' parameter. The agent receives no context about what the limit controls (e.g., number of results) or how to use it 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 states 'Solana meme launcher — trending launches,' which clearly indicates the tool tracks trending launches on a Solana meme platform. It is specific but does not explicitly differentiate from the sibling tool 'track_pumpfun', though the name implies a different platform.
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 'track_pumpfun' or other tracking tools. The description does not mention any prerequisites, context, 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 exist, so the description bears full responsibility for behavioral disclosure. It fails to mention key traits such as the data resolution (e.g., daily bars), whether it supports multiple exchanges, or any rate limits. The description only states 'long-range' without specifying the maximum range or data granularity.
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 at one sentence, which is good for brevity. However, it is too short to cover necessary information, making it under-specified rather than optimally concise. It could be expanded with critical details 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?
Given the absence of annotations and output schema, the description lacks completeness. It does not describe the return format (e.g., array of price objects), frequency of data points, or any edge cases (e.g., invalid symbol). For a tool with two parameters and no output schema, 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain the parameters. It does not elaborate on 'symbol' (e.g., ticker symbol format) or 'days' (what it controls, default value 365, min 1, max 3650). The schema constraints are present, but the description adds no extra meaning to help the agent use parameters correctly.
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 'Long-range historical price series for a symbol' clearly states it retrieves historical prices over an extended period. It distinguishes from sibling tools like get_price (likely current price) and get_ohlc (OHLC data) by emphasizing 'long-range'. However, it doesn't explicitly differentiate from similar tools like get_history_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 is provided on when to use this tool versus alternatives. For example, it does not mention that short-term price queries should use get_price or that get_ohlc provides Open-High-Low-Close data. A usage guideline would significantly help an agent select the appropriate tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as read-only nature, data freshness, rate limits, or any side effects. Carries full burden but remains minimal.
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 with no filler, efficient but overly brief.
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 essential context: no output format, use cases, or parameter rationale. Incomplete for a tool with no output schema and minimal annotations.
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%. Description adds no explanation for 'symbol' or 'days' beyond the schema's basic constraints. Agent cannot infer meaning or proper usage from description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns historical sentiment for a symbol, distinguishing it from siblings like get_sentiment (likely current) and get_sentiment_velocity. However, it could be more specific about the resource.
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 get_sentiment or get_fear_greed. Context signals show many sentiment-related siblings, but description offers no differentiation 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 provided, and the description does not disclose behavioral traits such as data freshness, rate limits, read-only nature, or what constitutes 'Starter tier' (e.g., limited coverage). Agent cannot infer operational constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short (two fragments), which is concise but at the cost of completeness. It does not waste words, but more detail could be added 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?
For a simple one-parameter tool without output schema, the description is minimally adequate. However, it lacks context on what information the regulatory status includes, available countries, or how 'Starter tier' differs from higher tiers. Slightly 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?
Single parameter 'country' is fully described in the input schema (ISO code or name). Description adds no extra semantics beyond what schema provides. Schema coverage is 100%, so baseline 3 is appropriate.
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 indicates it provides crypto regulation status per country, but the phrase 'Starter tier' is ambiguous and does not clearly distinguish from sibling tools like get_mica_status. Purpose is understandable 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 on when to use this tool versus alternatives (e.g., get_mica_status for EU). No context on required prerequisites or recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not disclose behavioral traits such as authentication requirements, rate limits, or whether it is read-only. As a 'getter', it implies no side effects, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (three fragments) and to the point, but it lacks structured sentences or clear separation of concerns. It is efficient but could be more readable.
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 tool with one parameter and no output schema, the description should at least indicate what the return data looks like or how to interpret the results. It does not provide sufficient context for an agent to fully understand the tool's output.
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 describes the sole parameter 'entity_slug' as 'Entity slug.' The tool description adds no further meaning or example values, so the parameter understanding relies entirely on the schema's minimal definition.
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 tokenomics aspects (supply, emission, vesting, etc.) and states it's a 'single source replacing spreadsheet scraping', clearly indicating the tool retrieves comprehensive tokenomics data for an entity.
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 compared to siblings like 'generate_tokenomics_model' or other data retrieval tools. The description does not mention prerequisites 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?
No annotations provided. The description does not disclose behavioral traits such as whether it is read-only, pagination, rate limits, or if the list is exhaustive. It only mentions what data is included, leaving the agent uninformed about side effects or constraints.
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 that is concise but lacks structure. It does not front-load the primary purpose or provide any logical breakdown. While not verbose, it does not earn its place by adding value beyond the name.
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 simple input schema, the description should explain what the output looks like (e.g., list of objects) and any pagination. It only mentions fields, but not format or behavior regarding the 'limit' parameter. The description is incomplete for an agent 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 0%. The description does not mention the 'limit' parameter or its semantics, such as default, range, or how it affects results. The parameter's purpose is entirely left to the schema, which has no title explanation beyond 'Limit'.
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 lists all tracked currencies and mentions the fields returned (symbol, id, chain metadata). It implicitly distinguishes from 'list_stablecoins' by being broader. However, it lacks an explicit verb like 'list' or 'retrieve', though the name fills the gap.
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_stablecoins' or other list tools. Lacks when-not-to-use or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It mentions 'Pro tier' implying subscription requirement, but does not elaborate on data sources, update frequency, or whether predictions are real-time. This is 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (6 words), sacrificing essential detail for brevity. While concise, it omits necessary context such as parameter explanation and output format.
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 low parameter explanation, the description is incomplete. It does not specify the return value (e.g., probability percentage, score range) or handling of invalid slugs, leaving significant gaps for execution.
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 single parameter 'entity_slug' is not explained in the description. The schema provides constraints but no semantic meaning, and with 0% schema coverage, the description fails to clarify what an entity slug is or how to format it (e.g., 'bitcoin').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides listing probability scores for major exchanges (Binance, Coinbase, Upbit), specifying the output and scope. It distinctly identifies its purpose among siblings like 'submit_listing' or 'check_exploit_history'.
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 when to check for exchange listings via other tools. The description lacks context for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description is extremely brief. It does not disclose whether the tool returns filing details, links, summaries, or any limitations. The agent has no information about mutation, rate limits, or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loading the purpose. It is concise but could convey more useful information in the same space, such as output 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?
With one required parameter, no output schema, and no annotations, the description is incomplete. It omits what the user will receive (e.g., filing dates, links) and any constraints of the Starter tier.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter 'ticker' with a schema description giving examples. The tool description adds no extra meaning beyond the schema. With 100% schema coverage, baseline is 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 'SEC filings for listed crypto companies' clearly states the domain and resource (SEC filings of crypto companies). The verb 'track' is implied by the tool name, and 'Starter tier' hints at subscription level. However, it does not differentiate from sibling track tools like track_pumpfun or track_bonkfun, which target different data types.
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 sibling tools include many data retrieval tools, but the description provides no context for choosing this tool over, e.g., get_article or get_entity.
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 only mentions 'active bounties' but does not disclose behavior such as whether authentication is needed, rate limits, or how 'active' is defined.
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) and lacks substance. While concise, it fails to provide necessary details, making it under-specified rather than efficiently informative.
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 parameter descriptions, the tool is underspecified. Even for a simple tool with 2 optional parameters, the description does not cover what the response contains, sorting, or pagination.
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 provides zero explanation of the parameters (min_payout, limit). The schema defines types and defaults, but the description adds no semantic meaning, making it difficult for an agent to use parameters correctly.
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 active bug bounty programs from Immunefi and Hackerone crypto. It distinguishes this tool from sibling security-related tools by specifying the scope (active bounties) and sources.
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. The name and description imply it's for current crypto bug bounties, but no when-not or alternative tool mentions 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 must fully convey behavioral traits. It vaguely mentions 'Pro tier' but does not clarify access restrictions, rate limits, or whether the operation is read-only. This leaves significant uncertainty for an AI agent.
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 with two short sentences. It is front-loaded with the main purpose. However, it may be too terse, sacrificing some 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?
Given the lack of output schema, the description should provide basic information about return values or structure. It does not, leaving the agent without expectations for results. The tool is simple, but completeness is lacking.
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 description does not mention the 'window' or 'limit' parameters, despite 0% schema coverage. The parameters are self-explanatory from the schema, but the description misses the opportunity to clarify their usage or constraints.
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 'Top PnL wallets on memes. Pro tier' clearly indicates the tool returns top wallets by profit and loss on memecoins. While concise, it effectively communicates the core function and distinguishes it from sibling tools that focus on other metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It simply states what it does without 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?
The description mentions 'clustered' and 'deduped across sources', which adds behavioral context beyond the limited annotations (none). However, it does not disclose ordering, pagination, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (4 words), which is concise but missing essential details about parameters and usage. It is front-loaded 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 tool has one parameter, no output schema, and no annotations, the description is too terse. It does not explain what 'clustered' means, how deduplication works, or how results are sorted, leaving significant ambiguity.
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%, but the description does not mention the `limit` parameter at all. It adds no meaning beyond the schema, failing to compensate for the lack of parameter descriptions.
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 stories that are clustered and deduplicated across sources. It is specific about the resource and action, but does not explicitly differentiate from sibling tools like `get_trending` or `get_unified_feed`.
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 context like 'use for a feed of top stories' or 'not for individual article details'.
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, authentication requirements, rate limits, or pagination behavior. The description is minimal and does not add value beyond the 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 very concise (11 words), which is positive, but it sacrifices clarity and completeness. It is front-loaded with key information but lacks structure for detailed 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?
Given no output schema and no annotations, the description is insufficient. It does not explain return format, sorting, or any other details. The tool has only two optional parameters, but the description does not provide enough context for an agent to use it confidently.
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%, so the description must explain parameters. It only mentions 'by window' for the window parameter, but does not define enum values (1h, 24h, 7d) or the limit parameter. The description adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'trending entities + articles by window', which is specific and distinguishes it from many sibling tools that focus on specific types of data. However, it could more explicitly mention that it provides ranked or popular content.
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 get_recent_stories or get_unified_feed. The description does not provide context for appropriate 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?
No annotations provided; the description only says it's a chronological cross-source feed, lacking details on behavior like pagination, response format, 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?
The description is concise (one sentence) and front-loaded, but it omits necessary details, making it too terse.
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 and output schema, the description should explain more about the feed's contents and behavior; it is insufficient for an agent to confidently 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 single parameter 'limit' is not described; schema description coverage is 0%, and the description adds no meaning beyond the schema's type and constraints.
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 chronological cross-source news feed of articles and stories, distinguishing it from sibling tools like get_recent_stories or get_currency_feed.
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., get_recent_stories, get_currency_feed) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It implies a read-only query but does not confirm safety traits like no side effects, rate limits, or data freshness. The description is too brief to ensure behavioral clarity.
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 with a single sentence that effectively communicates the core functionality. It is well-structured and front-loaded, though it sacrifices completeness for brevity.
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 input and no output schema, the description provides a high-level purpose but lacks details on return format, data volume, or any constraints. It is minimally complete but leaves the agent guessing about outputs.
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 sole parameter 'entity_slug' is unexplained in the description. With 0% schema description coverage, the description should clarify that it is a slug identifier for a protocol. The current description only mentions 'per protocol' without linking to 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 clearly states the tool checks historical exploits per protocol, specifying data sources (Rekt + DefiLlama hacks). It distinguishes from sibling check_ tools like check_memecoin_risk which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines provided. The description does not indicate when to use this tool versus alternatives, such as other security assessment tools, nor does it mention any prerequisites or 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 exist. The description does not disclose whether the tool is read-only, any rate limits, or what exactly is returned (current snapshot? historical? average?). 'Pro tier' is unexplained.
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 (8 words) but lacks structure. It does not front-load the purpose clearly, and the brevity omits important 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?
Without an output schema, the description should explain what the tool returns, but it does not. The phrase 'Perps funding' is vague, and the agent cannot infer if it returns current rates, historical data, or aggregated metrics.
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 having descriptions. The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as 'Perps funding' (perpetual futures funding rates) and lists specific exchanges, making it clear what the tool retrieves. However, it lacks an explicit verb like 'Get' and the term 'Pro tier' is ambiguous.
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 sibling 'get_*' tools (e.g., get_price, get_fear_greed), no context is provided 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, and the description does not disclose any behavioral traits (e.g., read-only, dynamic data, authentication needs). The minimal description assumes the agent knows what 'side-by-side comparison' entails.
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 short line). While efficient, it lacks necessary detail to fully understand the tool's output or behavior. It could be improved without adding much length.
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, the description fails to explain what the tool returns. For a comparison tool, the user/agent needs to know the format and content of the result. This is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, meaning no parameters. With 100% schema coverage, the baseline is 3. The description adds no parameter information beyond the schema, but lists the chains included.
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 L2 chains, listing specific names. It distinguishes from other get_* tools that focus on individual entities. However, it does not specify what metrics or data the comparison contains, 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 is provided on when to use this tool versus alternatives. There are no explicit when-to-use or when-not-to-use instructions, nor mention of prerequisites or 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 compensate. It only states the tool's purpose but does not disclose whether it is read-only, has side effects, or requires special permissions. The word 'Starter tier' hints at limitations but is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), but it lacks substantive details. It is front-loaded with key terms but could be expanded to include more information 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?
Given no output schema and a simple input schema, the description should explain what the roadmap includes, how the fact-check affects results, and the meaning of 'Starter tier.' It does not provide enough context for complete 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 schema description coverage is 100% for the single parameter entity_slug, which has a clear description. The tool description does not add any additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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.' indicates the tool retrieves a project roadmap with editorial fact-checking, which aligns with the name. However, it lacks specificity on the exact content and does not distinguish from sibling tools like get_article or get_explainer.
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 over alternatives. With many sibling tools, the agent needs explicit context about appropriate scenarios, prerequisites (e.g., having an entity_slug), and when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only mentions the return type ('Returns time-series') but does not indicate if the operation is read-only, creates persistent data, requires special permissions, or has rate limits. This leaves significant ambiguity about side effects and usage costs.
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 (three clauses) and front-loaded with the most critical information. While it could benefit from slightly more detail without becoming verbose, it achieves efficiency and avoids 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 the low schema coverage (50%), lack of output schema, and missing annotations, the description is insufficient. It does not elaborate on the return format beyond 'time-series', nor does it explain the 'target' parameter or provide usage examples. A more complete description is needed to compensate for the sparse structured metadata.
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 the 'formula' parameter has a description (with an example), while 'target' is described only by its schema (string or null, default null). The description adds an example for 'formula' but does not explain 'target' at all, leaving a gap in understanding its purpose.
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: 'Define a custom indicator formula' and specifies the resource: 'over BCA primitives'. It also indicates output type ('Returns time-series') and tier ('Pro tier'). This effectively distinguishes the tool from sibling tools which are primarily getters or checks.
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 mention of 'Pro tier' implies a usage restriction, but there is no description of appropriate scenarios, prerequisites, or when not to use it. Sibling tools like 'get_coverage_index' serve different purposes, but the description does not clarify the trade-off.
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 data freshness, response structure, or any constraints. The phrase 'Starter tier' hints at limited detail but is too vague.
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 but lacks structure (e.g., no bullet points or clear subject-verb-object format). It is concise but not well-organized for quick parsing.
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 or parameter details, the description fails to explain what the tool returns or how to interpret results. Essential context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is already clear. The description adds value by listing the specific L2s covered, which is not in the 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 lists specific Bitcoin L2s (Stacks, Rootstock, etc.) and indicates 'Starter tier,' which clarifies the tool's purpose is to return status for these L2s. However, it does not define what 'status' means, lacking full 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 on when to use this tool versus alternatives like 'get_l2_comparison' or other related tools. Agents have no context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'Fetch', implying a read operation, but gives no details on side effects, authorization requirements, or what the returned data contains. With no annotations provided, the description should offer more transparency about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the primary action and resource. Every word is necessary and no information is redundant.
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 (single parameter, no output schema, no annotations), the description provides the basic purpose. However, it lacks context about what a memo is and what the return format looks like, leaving some uncertainty for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning to the slug parameter beyond the schema's validation rules. It says 'by slug' but does not explain what constitutes a valid slug or how to obtain it. With 0% schema coverage, the description fails to compensate.
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 'Fetch a specific investment memo by slug', specifying the action (fetch) and the resource (investment memo). It distinguishes the tool from list_memos which lists all memos, though it doesn't explicitly state that distinction.
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 list_memos or other get_* tools. There is no mention of prerequisites or context for using the 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, so the description bears full burden. It only mentions 'Pro tier', hinting at access restrictions, but lacks details on whether the tool modifies data, requires authentication, or has 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?
The description is very short (one sentence), which is concise. However, it lacks structure and buries the 'Pro tier' detail, which might be better as a separate note.
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 does not explain return values or error conditions. The tool is simple (one parameter) but the description still feels incomplete 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?
The schema has 0% description coverage, but the description adds 'per project', implying the entity_slug parameter identifies a project. This adds some meaning beyond the schema constraints, though format expectations are missing.
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 tracks EU MiCA compliance per project, and the name 'get_mica_status' aligns. It distinguishes from broader tools like 'get_regulatory_status' by specifying EU MiCA. However, the verb 'track' is implied rather than 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, such as 'get_regulatory_status' or other compliance tools. No exclusions or prerequisites 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 provided, so description carries full burden. It only adds 'Via DexScreener' and 'Starter tier' which hint at data source and access limits but does not disclose whether the operation is read-only, what side effects exist, error handling, or caching behavior. This is insufficient 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?
The description is a single sentence that front-loads the key purpose 'DEX pair analytics' and lists output fields. It efficiently conveys source and tier. Could be slightly more structured but is concise and to the point.
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 two parameters and no output schema, the description lists some output fields (liquidity, volume, age, price) which helps set expectations. However, it omits details like data format, time range for volume, and whether the pair address is checked for validity. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for chain and pair. The description adds no additional parameter guidance beyond what the schema already provides. Baseline 3 is appropriate as schema does the heavy lifting.
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 DEX pair analytics including liquidity, 24h volume, pair age, price. It identifies the resource (DEX pair) and specific data fields, distinguishing it from sibling tools like get_price which likely returns only price. However, it could be more explicit about the action (e.g., 'retrieves') and the exact 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?
The description mentions 'Via DexScreener. Starter tier.' but provides no guidance on when to use this tool versus alternatives like get_price, get_ohlc, or other analytics tools. No explicit when-to-use or when-not-to-use conditions are 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 bears full responsibility for behavioral disclosure. It merely states it returns 'detail' without specifying what fields, data freshness, or any side effects. This is insufficient for an AI agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. However, it could be slightly rephrased to front-load the purpose more clearly. It earns its place but is minimal.
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 explain what the returned 'detail' contains (e.g., sentiment metrics, mentions, etc.). It does not, leaving the agent with incomplete context. For a tool with a single parameter, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'symbol', with a clear description including format and constraints. The tool description adds only 'single symbol', which is redundant. Baseline 3 is appropriate since schema already provides necessary semantics.
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 states it provides 'social signal detail for a single symbol', clearly indicating the resource (social signal detail) and scope (single symbol). However, it does not explicitly differentiate from sibling tools like 'get_social_signals' or 'get_social_pulse', leaving ambiguity about what 'detail' entails.
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 (e.g., for a single symbol vs. multiple) or when not to use it. The description does not mention any prerequisites 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?
No annotations are provided, so the description must disclose behavioral traits. It does not mention read-only nature, authentication needs, rate limits, or what happens to state. The description only lists output categories.
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 with no redundant words. However, it could be slightly more informative 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?
Given no output schema and rich expected data (metrics, projects, activity), the description is too vague. It omits specifics on what metrics are included, how projects are ranked, or what SPL activity covers.
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?
No parameters exist (schema coverage 100%), so baseline is 3. The description adds minimal context by naming output categories but does not explain them beyond the title. It does not add parameter semantics since there are none.
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 Solana metrics, top projects, and SPL activity. It uses specific nouns and verbs, and distinguishes itself from sibling tools like get_ton_ecosystem by focusing on Solana.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention whether it is for a broad overview, specific use cases, or when to prefer other get_* 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 carries full burden but only mentions deduping. No info on authentication, rate limits, data freshness, or return 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?
One sentence is concise but too brief for a tool with 4 parameters. It front-loads the purpose but lacks necessary 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?
With no output schema and sparse description, the tool is incomplete. The 4 parameters and usage context are unexplained, despite being a straightforward list operation.
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 explanation for any of the 4 parameters (remote, seniority, chain, limit). Parameters remain opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's an aggregated crypto job board from specific sources, distinguishing it from siblings. The verb 'list' directly matches 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding jobs but provides no explicit guidance on when to use vs alternatives or when not to use. Siblings lack job listing tools, so context is weak.
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 does not disclose behavioral traits such as ordering direction (ascending/descending), data freshness, authentication needs, or rate limits. It only mentions ranking criteria without further 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 concise (one sentence, 11 words) but omits important parameter information. While it earns its place by stating purpose, it is not sufficiently informative for a tool with undocumented parameters.
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 of the tool (one parameter, no output schema, no annotations), the description is incomplete. It lacks details on parameter usage, ordering, and the definition of 'top', which are needed for proper 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%, so the description must compensate, but it fails to mention the limit parameter, its default, min, max, or effect. The description adds no semantic value to the single 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 tool lists NFT communities and specifies ranking criteria (floor, holders, Discord activity, OG status), which distinguishes it from sibling list tools like list_currencies 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 retrieving top NFT communities but provides no guidance on when to use this tool versus alternatives or when not to use it. No exclusions or contrasts with sibling tools are 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?
Without annotations, the description carries full responsibility for disclosing behavior. It mentions 'Starter tier' (implying a limitation) but does not explicitly confirm read-only operation, side effects, or response format. The phrase 'directory' suggests a query, but this is not stated definitively.
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 with no extraneous words. It front-loads the core purpose ('Crypto VC directory') and adds key attributes. While concise, it could be slightly more informative without losing efficiency.
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, no annotations, and three parameters, the description is insufficient. It does not explain the output structure, the meaning of 'Starter tier', or how to use the 'limit' parameter. The mention of output fields (ticket size, etc.) is helpful but 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 0%, so the description must add meaning. It lists 'focus' and 'stage' alongside non-parameter fields (ticket size, portfolio count, recent deals), implying these are filterable or output attributes. The 'limit' parameter is omitted. This provides partial context but not full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a 'Crypto VC directory' and lists key attributes (focus, ticket size, stage, portfolio count, recent deals), clearly indicating it lists venture capital firms. However, it lacks an explicit verb like 'list' or 'query', which slightly reduces clarity compared to 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 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_entity' or other list tools. The description does not specify use cases 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 provided, so description must disclose behavior. Only states it does a side-by-side comparison but omits details like output format, number of protocols supported, rate limits, or authentication requirements. 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?
Description is very short and front-loaded, but it's too terse. It lacks important context that could be added without becoming verbose. Not quite concise; it's 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 no output schema and no annotations, the description should provide more details like what the comparison output includes, limits on number of protocols, or response structure. Currently incomplete for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with description for 'entity_slugs'. The description adds no extra meaning beyond the schema's 'Comma-separated entity slugs (kebab-case)'. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool compares protocols side-by-side on specific metrics (TVL, fees, tokenomics, etc.) and distinguishes it from siblings like 'get_defi_protocol' or 'get_entity' by focusing on 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. Mentioning 'Pro tier' hints at access level but doesn't help in tool selection. No exclusions 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?
With no annotations provided, the description carries the full burden. It does not disclose behavioral traits such as idempotency, rate limits, or authentication requirements. 'Pro tier' hints at access restrictions but is insufficient. The lack of any behavioral information is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it sacrifices clarity for brevity. It is not front-loaded effectively; the key purpose is stated but in a cryptic manner. Every sentence earns its place, but the overall meaning is not immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain the return structure or data type. It only says 'High = accumulation signal before price', leaving the user to guess the format, range, or whether it's a single number or object. This is insufficient for a tool with two parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. The description does not add any additional semantics beyond the schema's 'Entity slug.' and 'Rolling window.'. While adequate, it could provide more context like examples or data formats.
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 is a 'BCA Coverage Index' composed of 'mention velocity x source diversity x editorial weight', clearly indicating it's a metric. It also hints at usage with 'High = accumulation signal before price'. However, it doesn't explicitly state that the tool returns the index value for a given entity and window, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Pro tier' suggesting a user tier, and the phrase 'High = accumulation signal before price' implies it's used for detecting accumulation. No explicit when-to-use or when-not-to-use guidance, nor does it compare to siblings like get_history_coverage.
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 disclosure burden. It only mentions 'Pro tier' hinting at access restrictions but omits details on authentication, rate limits, data freshness, or response characteristics.
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 (two fragments) and front-loaded with the key action. It is efficient but could be slightly expanded 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?
Given no output schema and minimal annotations, the description should compensate but does not. It lacks parameter explanations, behavioral details, and return value information, 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%, yet the description adds no explanation for the 'symbol' or 'window' parameters beyond what the schema already provides (e.g., the enum values). This fails to add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides net in/out flows from centralized exchanges, positioning it as a smart-money signal. This distinguishes it from other data retrieval tools in the sibling 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 for tracking smart-money flows but does not explicitly state when to use this tool versus alternatives or provide 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 provided. The description only says 'snapshot', implying read-only behavior, but lacks details on authentication, rate limits, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, one sentence, front-loaded. However, it could benefit from additional context 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?
The description is minimal and does not define what a 'snapshot' entails. Given no output schema, it leaves the agent guessing about return format and data coverage.
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 description does not need to explain them. The baseline for 0-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool returns a 'snapshot' of the 'TON + Telegram mini-apps ecosystem', which differentiates it from sibling tools like get_solana_ecosystem. However, 'snapshot' is somewhat vague.
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 sibling list includes many ecosystem tools, but no differentiation criteria 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, and the description does not disclose behavioral traits such as whether the tool requires authentication, has rate limits, or aggregates data from multiple sources. The simple description implies a read operation but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous information. Every word is essential.
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 parameter and no output schema, the description provides the core purpose but misses a hint about the return format (e.g., 'returns a list of prices'). Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the only parameter is described). The description adds context by mentioning 'per GPU type', which ties the param to the tool's output, but it does not clarify behavior when the parameter is null (default). No additional meaning beyond 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 specifies the tool returns pricing per GPU type for three platforms (Akash, Render, IO.net), which clearly identifies the resource and scope. It distinguishes from the many sibling tools that cover unrelated topics (e.g., defi, 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. While no sibling tool directly competes, context about when to query pricing (e.g., for cost comparison) is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It only describes the mathematical operation ('d/dt with smoothing') and access tier, but omits critical behavioral traits such as output format, latency, rate limits, authentication requirements, or whether the operation is read-only. A mutation-like operation is implied, but without annotations, the agent cannot assess safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no redundancy. It front-loads the key concept ('d/dt of sentiment bucket with smoothing'), then adds access tier and use case. Every sentence serves a purpose, though the structure could be improved with a clear statement of when to use.
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 (2 params, no output schema), the description is too sparse. It fails to explain what the output represents (e.g., a numeric velocity value, direction, magnitude), how to interpret it for reversal detection, or any constraints like data frequency or minimum entity activity. The long sibling list does not compensate.
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 covers 100% of parameters with descriptions for both 'entity_slug' (pattern, length) and 'window' (enum, default). The description adds no additional context about how these parameters influence the computation (e.g., how smoothing interacts with the window). Baseline 3 is appropriate as schema does the heavy lifting.
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 uses domain-specific language ('d/dt', 'sentiment bucket', 'smoothing') to convey the derivative of sentiment over time, which aligns with the tool name 'velocity'. It also mentions it's for early reversal detection, clearly differentiating it from siblings like 'get_sentiment'. The purpose is specific and actionable, though the jargon may be obscure.
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 'Early reversal-detection signal', implying a specific use case and access level. However, it does not compare this tool to alternatives (e.g., when to use this vs. 'get_sentiment' or other sentiment tools), nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic fetch action, omitting details like caching, rate limits, data freshness, or whether the thesis is from a research team or user-generated. For a simple read operation, this is acceptable but minimal.
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 sentence of 6 words is highly concise. It immediately states the action, object, and key parameter. No wasted 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?
The description is adequate for a simple fetch with one parameter, but it lacks details about the return value (structure, fields) and what a trade thesis comprises. Given the absence of an output schema, the agent has no clue about the response format, which could hinder correct downstream 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?
The description mentions the sole parameter 'slug' and explains its role as the identifier. This adds a little context beyond the schema (which only has a title and validation). However, the schema coverage is 0% (description doesn't list parameters explicitly), so the description compensates minimally.
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 the resource ('specific trade thesis') with the lookup key ('by slug'). It distinguishes from sibling 'list_theses' which lists all theses. However, it doesn't define 'trade thesis,' which could be ambiguous to an agent unfamiliar with the domain.
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 'list_theses' or other fetch tools. The agent is not told that this is for retrieving a single thesis when the slug is known, while 'list_theses' is for browsing all available theses.
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, and the description does not disclose behavioral traits such as read-only status, authentication needs, or any side effects; it merely states the data aggregated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and to the point, using a single sentence; however, structural improvements like front-loading could enhance readability.
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 simplicity (one parameter, no output schema), the description is minimally adequate but does not explain output format or limitations, 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 single parameter 'entity_slug' is fully described in the schema (100% coverage), but the description adds no additional meaning beyond the schema, meeting the baseline for 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 explicitly states that the tool returns aggregated audits from named security firms and a BCA review score, clearly defining its purpose and distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 is provided; the description lacks any contextual clues about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the error behavior (BCA_NOT_IMPLEMENTED) and the Pro tier requirement, but does not discuss auth needs, rate limits, or whether the operation is read-only. Significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that convey the core function and an important error condition. It avoids verbosity and front-loads the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should convey enough context about return values. It mentions mentions, engagement, and sentiment, but lacks details on return format or structure. The error note is helpful, but completeness is only moderate.
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 includes descriptions for both parameters. The description adds context about platforms and data types but does not provide additional semantic meaning for the parameters themselves. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves social velocity (mentions, engagement, sentiment) from Twitter/Reddit/Discord, and mentions it's a Pro tier feature. This provides a specific verb and resource, but does not explicitly differentiate from sibling tools like get_social_signals or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for Pro tier and warns about a possible error if social ingest is not wired, giving some context on prerequisites. However, it lacks explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds context such as 'Entity-graph backed' and lists the type of information returned. However, it does not disclose whether the tool is read-only, what happens on missing entities, or rate limits, leaving some behavioral traits opaque.
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 10 words, front-loading the key value propositions. However, it is fragmented and could be more structured without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists the types of data returned (founders, backgrounds, exits, doxx status), but lacks details on the completeness of the output or edge cases. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'entity_slug', which is adequately described. The description adds no extra meaning beyond the schema, so a 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 specifies the tool returns founders, LinkedIn-verified backgrounds, prior exits, and doxx status, clearly distinguishing it from siblings like 'get_entity' or 'get_kol_influence'. However, it does not explicitly state the tool's verb or resource, relying on the name 'get_team_info' for that.
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 mentions 'Pro tier', implying an access requirement, but provides no explicit guidance on when to use this tool versus alternatives. There is no scenario for when not to use it or mention of 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, so description carries full burden. It lacks disclosure about data source, calculation method, update frequency, or read-only nature. The agent is left guessing about operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. Information is front-loaded. Could slightly benefit from structuring, but very efficient overall.
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 moderate complexity (3 params, no output schema) and many siblings, the description provides minimal context. It lacks explanation of return format, series length, or correlation type, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33% (only peer has description). The description does not elaborate on symbol or days parameters beyond what schema shows. 'Price/sentiment' hints at the correlation type but doesn't explain how parameters affect output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes a 'correlation series between two symbols (price/sentiment)' and highlights its utility for 'pair trades'. This distinctly differentiates it from sibling tools like get_history_prices or get_history_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 mention that it is 'useful for pair trades' provides some context on when to use, but no explicit when-not-to-use or comparison to other history tools. More specific guidance would help an agent decide between correlation, price, and sentiment 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 are provided. The description only mentions a 'Pro tier' constraint but does not disclose any behavioral traits such as idempotency, side effects, error handling, or rate limits, which are critical for agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences covering purpose and key parameters. It is properly front-loaded with the purpose. A slight improvement would be to separate param details 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?
There is no output schema, so the description should explain what the tool returns. It does not. Additionally, the window parameter discrepancy between description and schema reduces completeness. The tool lacks guidance on expected output format or behavior.
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 adds context: 'entity_slug (the KOL's canonical entity slug)' and 'Supported windows: 30d, 90d.' However, the schema lists four enum values for window (1d, 7d, 30d, 90d), while the description only mentions two, creating a discrepancy that could confuse the agent. Schema coverage is 100%, so the description provides marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool computes: 'KOL influence score: reach x engagement x historical pick accuracy.' It names the specific resource (KOL) and the formula, distinguishing it from sibling tools that focus on other metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Pro tier,' implying usage restrictions, and lists supported windows. However, it does not explicitly state when to use this tool versus alternatives or when not to use it, leaving the agent without clear decision 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?
With no annotations provided, the description carries full responsibility for behavioral transparency. It only states 'Fetch' (implying read-only) but does not disclose error handling, return format, or any side effects. The description adds no behavioral context beyond the verb.
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 of seven words, perfectly concise and front-loaded. Every word adds value, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is minimally adequate. It states the core function but lacks details on the return value, error cases, or relationship to list_marketing_templates. Given the tool's simplicity, this is acceptable but not exemplary.
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 0%, so the description must compensate. It mentions 'by slug', which clarifies the parameter's role beyond the schema's name and constraints. However, it does not explain how to obtain a valid slug or what constitutes a valid slug, leaving some 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 'Fetch a specific marketing template by slug' clearly states the action (fetch) and the resource (marketing template) with the identifier (slug). It effectively distinguishes itself from the sibling list_marketing_templates tool, which returns multiple 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 is provided on when to use this tool versus alternatives like list_marketing_templates. There is no description of context, prerequisites, or exclusions, leaving the agent to infer usage patterns 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states it returns a sentiment bucket and mentions 'bucket drivers', but provides no information about safety, idempotency, auth requirements, or other behavioral traits. The read-only nature is implied but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 14 words, front-loaded with the key purpose. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and no annotations, the description does not explain what 'bucket drivers' are or the structure of the response. It is adequate but lacks detail that could further aid 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 description coverage is 100%, with clear descriptions for both 'entity_slug' and 'window' parameters. The description adds no additional meaning beyond the schema; 'rolling window' is already stated. 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 retrieves 'BCA editorial sentiment bucket' for an entity, specifying the possible values (bullish/bearish/neutral/mixed) and mentioning 'bucket drivers' to indicate additional detail. This distinguishes it from siblings like 'get_sentiment_velocity'.
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 sibling list includes 'get_sentiment_velocity' and other sentiment-related tools, but the description does not differentiate usage contexts or provide when-not-to-use 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 present, so the description must disclose behavioral traits. It only lists contents and mentions 'Starter tier' but fails to mention any auth, rate limits, pagination, or data freshness. The behavioral impact is under-disclosed.
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 front-loads the core purpose. Every part adds information without redundancy, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema, no annotations), the description adequately covers what templates are listed but does not mention output format, limitations, or whether results are paginated. The 'Starter tier' hint is useful but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so no parameter documentation is needed. The description adds value by listing the types of templates included, which is relevant context 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 indicates the resource (campaign templates) and provides specific examples (TGE checklist, airdrop ops, etc.), distinguishing it from sibling tools like get_marketing_template and list_smart_contract_templates. The verb 'list' is implicit from the tool name, and the description adds context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'Starter tier' but does not explicitly state when to use this tool versus alternatives or when not to use it. No direct guidance on context or exclusion is 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 burden. It reveals ranking criteria and data sources but lacks details on operational traits like data freshness, caching, rate limits, or error behavior. The description is partially transparent but leaves 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and ranking criteria. It is front-loaded and concise, though it could benefit from a bit 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?
For a simple list tool with one parameter and no output schema, the description covers the main purpose and ordering. However, it lacks details on the output structure, whether it includes all stablecoins or just top N, and any filtering options. It is adequate but not 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?
The input schema has one parameter (limit) with no description in the schema (0% coverage). The tool description does not mention this parameter at all, so it adds no meaning beyond the schema. Since coverage is low, the description should compensate but fails to do so.
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 lists ranked stablecoins with specific ranking criteria (TVL, peg stability, audit status, chain coverage) and data sources (DefiLlama + BCA risk scoring). It distinguishes from sibling tools like list_currencies by focusing on stablecoins and risk scoring.
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 ranked stablecoin data but does not explicitly state when to use this tool versus alternatives or provide exclusion criteria. No guidance on context or alternatives 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 provided; description only mentions return structure but omits side effects, authentication, or performance characteristics.
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, front-loaded with action and scope, zero 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?
Lacks parameter explanations, usage guidance, and behavioral details; minimally adequate for a simple search 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?
Schema description coverage is 0%; description hints at search query but does not explain 'limit' parameter or add value beyond schema constraints.
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 'full-text search across academy lessons' and specifies return format, distinguishing it from other search 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 use for academy lesson search but no explicit when-to-use vs alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description implies a read-only query but does not explicitly state it. It discloses that the score is a composite (BCA Narrative Strength Score) and that it is 'Starter tier', but does not mention side effects, rate limits, or authorization needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two succinct sentences, front-loading the key purpose. Every sentence adds value without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description gives a high-level purpose, it does not explain what the output looks like (no output schema) or explicitly list which narratives are supported. The examples in the description and schema help, but the lack of return format information limits completeness for a simple query 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 description adds context for the 'narrative' parameter by listing multiple examples beyond the schema's single example, but it does not mention the 'window' parameter. Since schema description coverage is 50%, the description partially compensates but is insufficient to fully cover 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 it tracks 'real-time narrative strength' for specific narratives (AI agents, RWA, etc.) and mentions it's a composite score. However, it does not differentiate from the sibling tool 'get_narrative_strength', leaving ambiguity about their relationship.
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_narrative_strength' or when not to use it. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior. It lists detection categories but does not mention read-only nature, side effects, error handling, or output format, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but the phrase 'Required: mint... Pro tier.' is a fragment. Still, it efficiently conveys core 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 one-parameter tool with no output schema, the description covers input and purpose but omits output expectations, leaving the agent uncertain about the return format.
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 the 'mint' parameter. The tool description merely restates the required field without adding new meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks memecoin-specific risks (bundler detection, dev sells, sniper detection) and specifies the required Solana mint address, distinguishing it 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?
The description implies usage for memecoins via 'Memecoin-specific risk' and notes 'Pro tier', but lacks explicit guidance on when to use versus alternatives like check_rugpull_risk 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, and the description only mentions 'Free tier' but does not disclose rate limits, auth requirements, caching, or error behavior. The description carries the full burden but adds minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the essential purpose. It is front-loaded with the tool's function, but could be slightly more 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 (one parameter, no output schema), the description provides the main idea but lacks detail on the return format or pagination. It is adequate but not fully 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 covers the sole parameter with a clear description including example slugs. The description adds no additional semantic meaning beyond noting the data source (DefiLlama), so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (snapshot) and resource (DeFi protocol), and lists key data points (TVL, chains, volume, fees). It is distinct from sibling tools like compare_protocols or get_price.
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 notes 'Via DefiLlama. Free tier.' which hints at usage context but provides no explicit when-to-use or alternatives. Usage is implied by the tool name.
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 carries the full burden. It discloses that the tool decodes a transaction and returns specific fields (sender, receiver, value, events, status), implying a read-only operation. However, it does not mention idempotency, authorization needs, or error behavior, which would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the action and output, making it efficient for quick understanding.
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 compensates by listing returned fields (sender, receiver, value, events, status). This provides sufficient context for a simple two-parameter tool. However, missing details on failure modes or edge cases prevent a perfect score.
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 does not add value beyond the schema, as the parameters are already clearly defined with descriptions and examples (e.g., chain enum). No additional semantic context is provided.
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 'Decode a transaction' and lists the decoded components (sender, receiver, value, etc.), using a specific verb and resource. This distinguishes it from sibling tools like get_ohlc or get_price, which focus on different data. However, it does not explicitly differentiate from other transaction-related 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. There is no mention of prerequisites, limitations, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially discloses behavior by naming data sources (DefiLlama + BCA) and mentioning a risk overlay. However, it does not explain what 'Best' means (sorting/criteria), the 'Starter tier' limitation, or any side effects (e.g., no destructive actions noted). Adds some value beyond the name but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence front-loads the core purpose and filters. The second adds valuable context on data sources. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and few parameters, the description could be more complete. It omits explanation of what 'Starter tier' means, how results are sorted, or the return format. Adequate for a simple list tool but lacks depth for confident use.
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 parameter descriptions are absent (0% coverage), and the tool description does not elaborate on any parameter (chain, min_apy, limit). The mention of 'by chain' aligns with the chain parameter, but 'risk tier' is not a parameter, potentially confusing. The description adds no meaning beyond the schema's property titles.
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 staking/LP/vault opportunities, specifying the data sources (DefiLlama yields + BCA risk overlay) and a filter criterion (chain and risk tier, with 'Starter tier' hint). This sufficiently distinguishes it from sibling tools like get_defi_protocol or compare_protocols.
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. While the purpose is implied, lacking usage context (e.g., 'Use for high-level yield scanning; for detailed protocol analysis use get_defi_protocol') leaves the agent uninformed about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Async, Team tier' but lacks details on response behavior, error handling, or side effects. The description is insufficient for a tool that likely has important behavioral nuances.
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 efficiently convey purpose, supported languages, required inputs, and async nature. No unnecessary words, and the key 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 no output schema and no annotations, the description omits crucial details: return format, potential errors, rate limits, and how the async behavior works. Compared to siblings that often include more context, 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 100%, so baseline is 3. The description repeats the required parameters and language list 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?
Clearly states the tool translates smart contracts between specific languages (Solidity, Vyper, Move, Anchor). The verb 'translate' and resource 'smart contract' are precise, and the bidirectional arrow distinguishes it from siblings like scan_contract or check_exploit_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists required parameters but provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or context where another tool would be more appropriate, 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?
No annotations are provided, so the description carries the full burden. It lists the composite factors but does not disclose whether the tool is read-only, what happens on error (e.g., invalid slug), 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence defines the composite risk, the second gives requirements. No extraneous 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?
The description explains what the tool does at a high level but does not describe the output structure or how to interpret the risk score. Given no output schema, more detail on the returned value 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 coverage is 100% with a clear parameter description ('Target entity slug.'). The description only restates the requirement and does not add new semantic 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 is a composite rugpull risk check covering multiple specific factors (honeypot, LP lock, etc.). It effectively distinguishes from sibling tools like check_memecoin_risk, which target different risk types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that entity_slug is required and that it is a Pro tier tool, but does not provide when-not-to-use guidance or mention alternatives among 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 are provided, so the description must fully disclose behavioral traits. It explains the metric and lag, but does not mention read-only nature, rate limits, or any side effects. Lacks detail for complete 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 two sentences, front-loaded with the core purpose, and contains no unnecessary words. 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?
The tool has no output schema, so the description should hint at output format. It implies a numeric correlation but does not explicitly state what the return value looks like. Overall adequate for the low complexity, but leaves some ambiguity.
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%; parameters are already documented. The description adds that the window is rolling and reiterates supported windows, but does not significantly enhance meaning beyond schema descriptions. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a correlation between price return and coverage delta with specific lags, specifying it's Pro tier and the kind of edge it measures. It distinctly identifies the resource and action, differentiating from many sibling 'get_' 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 mentions 'Pro tier' and 'Supported windows: 30d, 90d' but does not explicitly state when to use this tool over alternatives like get_history_correlation or when not to use it. Usage context is implied but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It states 'OHLC candlestick history', implying output data, but does not disclose rate limits, data freshness, pagination, or any constraints beyond the schema. It's minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise—two sentences that front-load the core purpose and add a usage hint. Every sentence earns its place with no wasted 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?
No output schema exists, so the description should compensate. It mentions 'OHLC candlestick history' but not the return format, ordering, or any limitations beyond 'Starter tier'. For a simple 3-parameter tool, it's moderately complete but missing key details for an agent to fully interpret results.
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?
Input schema coverage is 100%, so the schema already documents all three parameters (id, days, vs). The description adds no extra parameter information. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns OHLC candlestick history for a token, using a specific verb ('get') and resource ('candlestick history'). It mentions 'Starter tier' which hints at limitations, but does not explicitly distinguish from similar tools like get_history_prices or get_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides some context ('Starter tier', 'useful for technical-setup agents and backtesting'), but no explicit when-to-use or when-not-to-use, nor alternatives. The guidance is implied rather than 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?
With no annotations, the description carries the burden. It indicates the tool returns ranked data with specific attributes (fees, exchanges, track record), implying a read operation. However, it omits details like ordering, pagination, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded and contains no extraneous information. Every word 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?
For a simple tool with one optional parameter and no output schema, the description adequately communicates what the tool does and what it returns. It could be slightly more explicit about the list output, but is largely 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?
The only parameter (limit) is documented in the schema with default and constraints, but the description adds no information about it. With 0% schema description coverage, the description should compensate but does not.
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 ranked trading bots/copy-trade platforms with fees, exchanges, and track record. It is specific and distinguishes this tool from other list_* siblings like list_aggregators or list_currencies.
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 implies use when wanting a ranked list of trading bots, but does not mention when not to use or suggest 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?
No annotations are present, so the description carries the full burden. It partially discloses behavior by listing components and output range (0-1), but does not mention side effects, 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?
The description is extremely concise with three short sentences, no wasted words, and front-loads the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description provides sufficient context: components of the score and output format. It is mostly complete, though it lacks details on data sources or update frequency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'entity_slug'. The tool description adds little beyond the schema, only hinting that it relates to an entity. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes a composite risk score from specified components (regulatory flags, liquidity tier, team risk, audit status) and outputs a single number between 0 and 1. This distinguishes it from sibling tools like check_rugpull_risk or get_regulatory_status.
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 vs alternatives. The phrase 'Starter tier' implies a basic version but lacks clarity on usage context or when to prefer other risk 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?
No annotations to contradict. Description does not disclose potential side effects, auth requirements, or error conditions. The term 'Fetch' implies read-only, but minimal behavioral detail beyond a brief note on response content.
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 efficient sentences, front-loaded with purpose. No redundancy or wasted 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?
Adequate for a simple single-parameter tool, but lacks detail on return format beyond 'attributed header'. Could be more complete given no output schema.
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%. The description does not explain what 'slug' means or provide examples, leaving the parameter's semantics entirely to the schema constraints.
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 action (Fetch), resource (smart contract template), and identifier (by slug). Distinguishes from sibling tools like list_smart_contract_templates which lists all 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. User must infer from context that this fetches a single template while list_smart_contract_templates lists all. Implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication needs, or rate limits. While listing is implicitly safe, the lack of explicit transparency is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the key information (audited templates, specific types, and sources). 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?
For a simple list tool with no parameters and no output schema, the description covers the purpose and content adequately. It could optionally mention the output format, but not required.
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 no parameters, and schema coverage is 100%. The description does not add parameter information, but none is needed. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists audited Solidity templates and enumerates specific types (ERC20, ERC721, Vesting, etc.), distinguishing it from siblings like `get_smart_contract_template` 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 use for getting a list of templates but provides no explicit guidance on when to use this tool versus alternatives (e.g., `get_smart_contract_template`), nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'static analysis' and lists checks, implying read-only behavior. However, with no annotations, it should explicitly state that the tool does not modify state or require special permissions. The behavioral traits are implied but not fully disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys purpose and requirement without extraneous words. Perfectly 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?
The tool has no output schema, yet the description fails to explain what the analysis returns (e.g., boolean, risk report). This is a critical omission for an analysis tool, making it incomplete despite the simple input.
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 the address parameter. The description adds no new semantic value beyond restating the requirement, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as performing basic static analysis on EVM addresses, specifically bytecode verification and honeypot check. This distinguishes it from sibling tools like check_rugpull_risk or check_phishing_domain, which focus on specific risk types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the required parameter but does not provide explicit guidance on when to use this tool vs. other risk-checking siblings. It implies a basic analysis role but lacks when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'historical series + BCA interpretation,' giving some behavioral context, but does not disclose specifics such as authentication requirements, rate limits, or the exact nature of the interpretation. More details would improve 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, efficient sentence that front-loads the tool's identity and key features. 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 no output schema, the description should explain return values more thoroughly. 'Historical series + BCA interpretation' is vague; it does not specify data fields, format, or pagination. For a simple tool with one param, it is minimally adequate but lacks 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% (parameter 'days' described as 'Lookback days.'). The description adds 'historical series' but does not significantly enhance the parameter meaning beyond the schema. 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 that the tool provides the Crypto Fear & Greed Index from Alternative.me, including historical series and BCA interpretation. It uses a specific verb ('get') and resource ('Fear & Greed Index'), and is distinct from sibling tools like get_sentiment or get_history_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 implies usage for retrieving historical fear and greed data, but does not explicitly state when to use it vs alternatives or when not to use it. No exclusions or alternative tool references 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 mentions the output includes balance and percentage of supply, but lacks details on ordering, pagination, rate limits, or whether it's a read-only operation. The Pro tier mention hints at access restrictions but is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that efficiently convey purpose, constraints, and use case. Every word adds value, with no redundancy or filler.
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 moderate complexity (3 parameters, no output schema), the description is adequate but leaves gaps. It does not mention return format, pagination, or sorting order, which would be helpful for an agent 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes 2 out of 3 parameters (contract and chain) adequately. The description adds no new information about parameters; it merely repeats the EVM constraint. The 'limit' parameter lacks a description in both schema and description, so the description does not compensate for this 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 specifies the tool's purpose: retrieving top token holders with balance and percentage of supply. It also distinguishes from siblings by stating 'EVM-only, Pro tier' and explicitly mentions the use case for concentration/risk analysis, which sets it apart from other tools in the list that deal with prices, sentiment, etc.
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 context on when to use the tool: for concentration/risk analysis and only on EVM chains with Pro tier access. It does not explicitly state when not to use it or list alternatives, but the specificity about EVM-only and Pro tier effectively guides usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses the return structure (articles under it, parents, siblings) but omits behavioral details like whether it is read-only or has any prerequisites.
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, front-loaded sentence that efficiently conveys the tool's purpose without 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?
For a simple fetch tool with one parameter and no output schema, the description covers the main functionality and returned data well. Minor omission: no guidance on finding the 'slug' value.
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 does not explain the 'slug' parameter at all. It should clarify what a slug is and how to obtain it, as the parameter is required with specific validation.
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 topic node from the taxonomy and lists included related data (articles, parents, siblings), distinguishing it from siblings like get_article (fetches an article) and list_topics (lists topics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when retrieving a topic node and its relations, but does not provide explicit guidance on when to use this tool versus alternatives like list_topics or get_article.
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 mentions filtering by kind and a rough universe size, lacking details on read-only nature, pagination, return format, 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 a single, front-loaded sentence with no wasted words, efficiently conveying the tool's purpose and primary use.
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 two parameters and no output schema, the description covers the basic purpose and filtering but omits what is returned (e.g., list of entities) and does not fully compensate for the missing 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 coverage is 0%, but the description adds meaning for the kind parameter ('Filter by kind'). However, the limit parameter's function (number of entities returned) is not explained; the schema provides its range but not its purpose.
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 entity universe with filtering by kind, matching the name and distinguishing it from sibling tools that list other resources.
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 context for when to use the tool (to browse/filter entities) but does not include explicit exclusions or alternatives among sibling list 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?
No annotations are provided, so the description must carry the full behavioral burden. It discloses that it returns 'campaign_id + next steps' and implies mutation, but lacks details on idempotency, error handling, or specific authorization beyond Pro tier.
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—four short sentences that front-load the purpose and key details. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, 3 required, no output schema, no annotations), the description covers core purpose, required fields, and return value. However, it omits explanation of optional parameters and does not elaborate on the returned structure or behavior, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only contact_email has a description). The description lists required parameters but does not explain optional ones (target_audience, launch_window_days) or provide additional 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 uses a specific verb ('broker') and explicitly names the resource ('KOL campaign via BCA Studio CRM'). It clearly distinguishes from siblings, which are mostly data retrieval or risk-checking 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?
It explicitly states required fields (contact_email, budget_usd, objective) and a prerequisite (Pro tier). However, it does not mention when to avoid using this tool or suggest 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 are provided, so the description must disclose behavioral traits. It states the return shape but does not explicitly confirm it is read-only, mention rate limits, or explain behavior on repeated calls. The action 'Poll' implies no side effects, but transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one sentence plus a return type specification. No unnecessary words or fluff.
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 simplicity of a polling tool, the description is almost complete. It specifies the return shape, which is critical given no output schema. It lacks mention of potential blocking or timeout behavior, but the tool is straightforward.
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 covers 100% of parameters with a clear description for job_id. The description does not add significant meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Poll' and the resource 'async agent job', making the tool's purpose immediately obvious. It is distinct from sibling tools that retrieve data or perform other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used after calling generate_* tools (as job_id comes from them), but it lacks explicit guidance on when to use this tool versus alternatives, or when not to use it. No 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 the full burden. It describes the algorithm (eigenvector centrality, rolling windows) but does not disclose rate limits, auth requirements beyond 'Pro tier', or whether the operation is destructive. It adds some behavioral context but not comprehensively.
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 fluff. The core concept is front-loaded with 'co-mention graph centrality' and method details are provided succinctly. Every part of the description 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 2 parameters, no output schema, and no annotations, the description adequately covers the tool's purpose and methodology. It does not elaborate on return format or pagination, but for a centrality measure tool, this is sufficient.
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 schema descriptions like 'Entity slug.' and 'Rolling window.' The description adds context by linking 'rolling windows' to the eigenvector centrality method but does not significantly expand on parameter 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 the tool computes co-mention graph centrality using eigenvector centrality in rolling windows, specifically identifying consolidating vs fading narratives. This is a specific verb+resource+method combination that distinguishes it from siblings like track_narrative.
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' which indicates access restrictions but does not provide explicit when-to-use or when-not-to-use guidance, nor does it suggest alternatives. The context is clear but lacks 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 are provided, so the description carries the full burden. It discloses async execution and Pro tier requirement, but does not mention webhook payload format, rate limits, or how to cancel/duplicate monitors. More detail would improve 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?
Description is one concise sentence with key facts front-loaded. It efficiently communicates purpose, requirements, and constraints. Could be slightly more structured but is already efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and full parameter descriptions, the description covers the essentials. However, it lacks information about cancellation, duplicate monitors, and webhook payload details, leaving some gaps for a registration 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?
All three parameters have descriptions in the input schema (100% coverage). The description mentions keyword and webhook_url as required but adds no new meaning beyond the schema. 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 'Register a keyword monitor' and explains it fires a webhook. The verb 'register' combined with 'keyword monitor' is specific and distinct from the sibling tools, which are primarily get/list/check 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 lists required parameters (keyword, webhook_url) and notes that it's async and Pro tier. While it does not explicitly contrast with alternatives, the lack of direct sibling monitor tools makes the usage context 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 must disclose behavior. It mentions escalation to a deep-researcher skill, indicating delegation. However, it does not explain if the process is asynchronous, typical response time, or any side effects like cost implications.
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 single sentence that front-loads the action and key details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering no output schema and 4 parameters, the description provides a high-level purpose and output format (order_id + pricing) but lacks details on depth options, deadline implications, or escalation process. Adequate but not thorough.
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 only 25% (only contact_email has description). The description adds that contact_email and topic are required, but does not explain depth or deadline_days beyond what the schema provides (enum and default). For low coverage, more compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Escalate to BCA deep-researcher skill'), specifies required parameters (contact_email, topic), mentions tier (Pro), and indicates output (order_id + pricing). It distinguishes itself from sibling tools which are mostly data retrieval or analysis 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 implies usage for custom research requests and notes Pro tier requirement. It does not explicitly mention when not to use or alternatives, but the context of sibling tools makes it clear this is for escalation-driven research.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses cost implications but omits side effects, permissions, or post-submission behavior. Adds some value but limited.
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 requirements. Efficient and scannable.
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 submission tool with no output schema, missing details on confirmation, duplicates, or next steps. Cost info is helpful but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% with two descriptions. The tool description merely repeats that the listed parameters are required, adding no extra semantics for the undocumented 'entity' and 'contact_email' parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool submits a listing to a BCA directory with specific examples (vcs, aggregators, trading-bots), and lists required fields. This distinguishes it from siblings like list_vcs which are read-only views.
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 required fields (listing_name, directory, entity, contact_email) and cost model ('Free to call, paid to feature'), giving practical usage context. However, it does not explicitly compare to 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?
No annotations are provided, so the description carries the full burden. It adds that the tool is asynchronous and returns a job_id/status_url, which is important behavioral context. However, it does not disclose potential side effects (none expected), rate limits, or what happens on invalid URLs.
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, with the first sentence capturing the core function and the second specifying the output format and async nature. Every sentence is informative, with 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 (2 parameters, no output schema), the description covers the key aspects: action, input, async behavior, and output format. It could be improved by noting error handling or usage limits, but it is largely sufficient for an agent to understand and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have descriptions). The description adds 'Async, Pro tier' which is not in the schema, but does not elaborate on parameter usage beyond what the schema already provides. Baseline is 3 due to high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch + structurally summarize' and the resource 'whitepaper URL', making the tool's purpose unambiguous. It additionally specifies that it is async and for Pro tier, which differentiates it from sibling tools that may be synchronous or free.
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 longer-running tasks and may require a subscription, but it does not explicitly state when to use this tool versus alternatives like 'get_article' (which might fetch but not summarize). No exclusions 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears burden. It adds context about lessons (43, 9 courses, teacher-vetted) and pedagogical value. But it does not disclose read-only nature, rate limits, or output characteristics.
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, then constraint and usage preference. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with 2 parameters and no output schema, the description provides sufficient context including lesson count, course coverage, and usage guidance. Could mention return format but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes both parameters (100% coverage). The description adds the constraint that exactly one is required and clarifies that 'topic' resolves to a canonical lesson, adding value beyond 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 uses clear verb 'Fetch' and specifies the resource as 'canonical BCA Academy lesson'. It distinguishes from generating own definitions but does not explicitly differentiate from sibling tool 'search_academy'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States that exactly one of 'slug' or 'topic' is required and advises preferring this tool over generating definitions. However, it does not specify when to use alternative tools like search_academy.
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 states the output contents but does not disclose behavioral traits such as rate limits, authentication needs, or the meaning of 'Starter tier'. It is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the output summary followed by usage. Every word is relevant, no filler.
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, the description mentions some return fields but lacks details on format, error handling, or pagination. 'Starter tier' is unexplained. For a simple wallet summary, it is adequate but not fully 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 parameters. The description adds output context ('native balance, token list, labels') but no additional parameter semantics beyond what the schema 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 the tool returns a wallet summary including native balance, ERC-20/SPL token list, and labels. It specifies the resource (wallet profile) and action (get), distinguishing it from siblings like get_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 provides an explicit use case ('wallet research and clustering') but does not mention when not to use or suggest alternative tools. It gives clear context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses async nature, Team tier requirement, and return format ({job_id, status_url}). It does not contradict annotations. Could add details on polling behavior or time estimates, but sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no extraneous words. Front-loaded with the main action and key constraints. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers async nature, return format, tier requirement, and high-level purpose. Missing guidance on how to retrieve results (polling status_url), and doesn't mention that scenarios are optional. Still fairly complete for an async simulation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description adds context about 'emission/unlock impact on FDV' but does not explain the scenario enum values (base, bull, bear) beyond the schema. 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 simulates emission/unlock impact on FDV across scenarios, distinguishing it from sibling tools like get_tokenomics. The verb 'simulate' and resource 'tokenomics model' 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'Async, Team tier' implying usage context, but does not explicitly state when to use this tool versus alternatives like get_tokenomics or generate_due_diligence. No exclusion criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses that aliases resolve automatically, which is a behavioral detail, but fails to state whether the operation is read-only, its latency, or any side effects. Given the absence of annotations, the description is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences. The first sentence succinctly states the purpose and output content. The second provides the required parameter condition and an example. No unnecessary words; front-loaded with essential 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?
Given the complexity (dossier with cross-referenced data) and no output schema, the description mentions articles, aliases, and sentiment as output components. However, it does not detail the full response structure or pagination. For a single-entity fetch, this is adequate but could be more specific.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides good descriptions for both parameters (slug and ticker) with examples. The description adds the important constraint that exactly one must be provided, which is not enforced by the schema, and gives concrete alias resolution examples (CZ -> changpeng-zhao), adding clarity 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 the tool fetches a 'canonical BCA entity dossier' with specific content (cross-referenced articles, aliases, sentiment) and lists entity types (chain, project, person, organization, ticker). This differentiates it from siblings like get_price or get_sentiment that likely return only single data points.
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 specifies that exactly one of 'slug' or 'ticker' is required, which is a key usage constraint. However, it does not compare this tool to alternatives like list_entities or get_sentiment, leaving the agent to infer when to use this specific dossier retrieval.
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 ranking criteria but does not disclose behavioral traits such as pagination, rate limits, or the maximum number of results returned.
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 one sentence and a parameter hint, all front-loaded. Every part adds value without 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 covers the purpose, required input, and ranking criteria. It lacks details on result count or filtering, but these are minor for a straightforward 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?
The schema provides 100% coverage for the single parameter, but the description adds semantic value by specifying the ranking dimensions (volume, fees, chain support) beyond the parameter's enum 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 the tool lists DEX, bridge, or yield aggregators ranked by volume, fees, and chain support, with a required 'kind' parameter. This distinguishes it from sibling tools, which are mostly get_ or list_ operations on 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly specifies the required 'kind' parameter and its valid values, providing clear guidance on how to use the tool. However, it does not mention when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose any behavioral traits like read-only nature, authentication needs, or rate limits. For a list tool, minimal behavioral info is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key information, no unnecessary words. Efficiently communicates purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description covers essential info: what is listed and the meta nature. Could be more explicit about the output format, but 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?
Zero parameters; schema coverage is 100%. Description adds context about what is listed but is not required to explain 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?
Clearly defines tool as a directory listing crypto MCP servers, with a clear verb 'list' and resource 'MCP servers'. It is distinct from sibling list tools by explicitly stating the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Discover peer MCPs' which indicates when to use. No explicit when-not or alternatives, but the unique purpose among siblings makes it 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 states the tool returns specific data (titles, summaries, etc.) and implies read-only behavior. Lacks explicit statement of non-destructiveness, authorization needs, or rate limits, but adequate for a search 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: first explains functionality and return data, second provides usage guidance. Front-loaded, no fluff, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core purpose, required parameters, output fields, and usage context. Missing details on result ordering or pagination, but overall sufficient for a search tool with 5 parameters and 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 description coverage is 100%, so baseline is 3. Description adds minimal parameter-specific meaning beyond schema (e.g., notes 'Required field: query' but that is already in schema). Does not elaborate on parameter usage or formats.
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 performs full-text search across a specific corpus (3,500+ editorial crypto articles) and lists return fields (titles, summaries, citations, entity graph). Differentiates from siblings by specifying the corpus and preference over pretraining for recent crypto queries.
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 requires 'query' field and advises preferring this tool over pretraining for recent crypto events. Compares to a general alternative but does not reference specific sibling tools like search_academy.
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 correctly implies a read operation but does not mention authentication requirements, rate limits, or error handling (e.g., behavior when slug is invalid). For a simple fetch, the lack of detail is acceptable but not exemplary.
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-load the action and return information, then provide usage guidance. Efficient and clearly structured, with no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers purpose, input, and usage context. It does not mention failure modes or error handling, but for a low-complexity tool this is minor. Could be improved by stating it returns null or error on missing slug.
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 well-described 'slug' parameter including an example. The description repeats 'Required field: slug' which adds no value beyond the schema. Baseline is 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches an editorial crypto article by slug and lists the returned data components (full body, citations, entity graph, attribution metadata). This specificity differentiates it from siblings like search_news and get_editorial_premium.
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 instructs 'Use after search_news when you need the full text of a specific result,' providing direct guidance on when and how to use the tool versus 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?
No annotations are provided, so the description carries the burden. It identifies the data source (CoinGecko) and the output fields (spot price, percentage changes). However, it does not discuss rate limits, caching, update frequency, or error handling, which would enhance 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 exceptionally concise: two sentences that front-load the purpose and then provide parameter details. Every sentence adds unique value 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?
With no output schema, the description partially compensates by listing the return values (spot price and changes). However, it lacks detail on the exact response structure (e.g., array or object) and other common fields like market cap or volume. Given the tool simplicity, it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters have descriptions). The description adds value by clarifying that 'ids' must be CoinGecko IDs (with examples like 'bitcoin,ethereum') and that 'vs' defaults to usd, supplementing the schema with practical usage guidance.
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 'Spot price + 24h / 7d / 30d change' for tokens via CoinGecko, distinguishing it from siblings like get_history_prices or get_ohlc which serve different time-series needs.
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 field 'ids' with proper formatting (CoinGecko IDs, not exchange tickers) and explains the optional 'vs' parameter defaults to usd. However, it does not explicitly suggest when to use this tool over alternatives (e.g., for current vs historical data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the async behavior, return structure (job_id, status_url), and tier requirement. This provides sufficient transparency for a creation-oriented 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 deliver all essential information: purpose and usage instructions. No wasted words, and critical details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return and polling mechanism. It covers the report components but could elaborate on what each component entails. Still, it's adequately complete for an async generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions entity_slug, depth, and focus but adds little beyond the schema's own descriptions. The 'Pro tier' hint is contextual but not parameter-specific.
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 initiates a due-diligence report covering tokenomics, team, audits, risk, and narrative. It distinguishes from sibling tools like get_tokenomics or get_audit_reports which cover individual components.
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 entity_slug, acceptable depth values, async nature with polling via get_agent_job, and Pro tier restriction. It implies when to use (full report) versus individual get_* tools, though explicit alternatives are not given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return fields (sentiment, bucket, linkback) and implies a read-only operation, which is sufficient given no annotations. However, it could mention ordering (likely chronological) and any pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first describes the output, the second states the required parameter and use case. No redundancy, 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?
For a list tool with good schema and no output schema, it adequately describes the outputs and required input. It misses explicit mention of sorting order or pagination limits, but these are inferable or covered by the parameter defaults.
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 clear descriptions for each parameter. The description reinforces that 'slug' is required but adds no new semantic information beyond what the schema 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 provides a timeline of editorial mentions with sentiment score, bucket, and article linkback, differentiating it from other tools that might aggregate sentiment or provide single articles.
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 field 'slug' and suggests usage for reconstructing narrative arcs, giving good context for when to use, though it doesn't explicitly exclude alternative tools or mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. The description implies a read-only operation ('Browse'), which is transparent. However, it does not explicitly confirm no side effects, state changes, or output behavior beyond the implied list. A score of 3 is appropriate as it covers basic transparency but lacks explicit statements about idempotency or safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences. The first sentence immediately states the tool's purpose, and the second provides a concrete usage example. Every sentence adds value without 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 parameters and no output schema, the description is mostly complete. It explains the tool's functionality and a primary use case. It could be improved by explicitly stating the return format (e.g., 'returns a list of topic strings'), but the current description is sufficient for an agent to understand and use the tool 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?
There are no parameters, and schema coverage is 100% (empty object). Per guidelines, baseline is 4 for zero parameters. The description adds meaning by explaining what the tool does, making it a clear and useful entry point. No additional parameter detail is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: browsing the BCA topic taxonomy with examples of topics (regulation, defi, infra, memecoins, security, etc.). It distinguishes itself from sibling tools by focusing specifically on topic taxonomy navigation, which is unique among 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a primary use case: 'Use to discover valid filter values for search_news.' This provides clear guidance on when to employ this tool. It does not explicitly state when not to use it or alternative tools, but the guidance is sufficient for a simple taxonomy browser.
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 should disclose behavioral traits. It indicates a read operation (list) and mentions output fields, but lacks details on ordering, caching, or any side effects. Minimal but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys all necessary information without redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and simple functionality, the description is complete. It tells the agent exactly what the tool returns: a list of all editorial news sources with trust tier.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters (0 params), baseline is 4. The description adds meaning beyond the empty schema by specifying the content (all sources with trust tier).
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 all editorial news sources ingested by BCA, with trust tier. The verb 'list' and resource 'sources' are specific, and it naturally distinguishes from sibling tools like list_currencies or list_entities.
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 implication is clear: use this tool to retrieve available news sources and their trust tiers. However, there is no explicit when-to-use or when-not-to-use guidance, though the context of sibling list tools makes it unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully carries burden. Discloses optionality of parameters, default and max limit, and the nature of returned data (volume, change, tags). No hidden behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences. First sentence states purpose and output, second gives parameter info and usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (single optional parameter, no output schema), description covers all necessary information: what, how, and why to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds valuable detail: 'optional limit defaults to 20 (max 100)' which is not in schema's description of 'Top N by mcap.' Adds 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?
Description explicitly states 'Top-N tokens by market cap' with specific data fields (volume, 24h change, category tags). Clearly distinguishes from sibling tools like get_price or get_trending.
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 context: 'Use for market-wide context (bull/bear posture, mover spotting).' Lacks explicit when-not-to-use or alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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-python'

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