anchain-data-mcp

Official

by AnChainAI

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct resources or actions, such as address labeling, risk scoring, transaction details, and sanctions database searches. However, certain tools like get_transaction_detail and get_contract_transaction may be confused, though descriptions provide some clarity.
Naming Consistency3/5
Naming patterns are mixed: most tools use get_ or search_ prefixes, but there are deviations like bulk_address_label, auto_trace_address, and fuzzy_search_ofac. The lack of a uniform verb_noun structure makes the set slightly inconsistent.
Tool Count3/5
With 20 tools, the server is somewhat heavy but not excessive for its dual focus on blockchain analytics and sanctions screening. Several tools are near-duplicates (exact vs. fuzzy search, bulk vs. single address), which could be consolidated.
Completeness4/5
The tool surface covers core workflows, including address analytics, risk scoring, transaction tracing, and sanctions screening. Gaps include batch sanctions screening and comprehensive address transaction history, but these are not critical for the server's apparent purpose.
Average 4/5 across 20 of 20 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under AGPL 3.0.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only mentions a cost of 50 credits. It does not describe read-only safety, failure modes, latency, or any other behavioral nuances. This is a significant gap for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-organized with a clear purpose line, an args section, and cost. Every line adds value without redundancy, though the format could be more polished.
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 an output schema present, return values are covered externally. The description explains parameters and cost, but it lacks any comparative usage context against 20 sibling tools and does not mention edge cases or prerequisites. It is adequate for a straightforward lookup but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides detailed meaning for both parameters, including the allowed protocol values (btc, eth, xrp, hash) and a concrete example hash. This significantly compensates for the schema's 0% description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed on-chain information for a specific blockchain transaction, using a specific verb and resource. It does not explicitly differentiate from sibling tools like get_transaction_graph, but the scope is distinct enough to avoid confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives, and no exclusions or comparable sibling tools are mentioned. The description focuses solely on what the tool does, not on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses cost (5 credits) and conditionality ('when available'), but fails to mention error handling, rate limits, or data freshness. With zero annotation coverage, this is insufficient for a fully transparent operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a one-sentence purpose, a structured Args block, and a cost note. Each element serves a purpose, though the protocol list is lengthy and could be moved to an enum in the schema to reduce verbosity.
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 output schema exists, so return values need no elaboration. However, the description lacks guidance on when to use this single-address tool versus bulk operations, and omits any behavioral caveats beyond cost. For a simple lookup with good parameter hints, it is barely adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Args section compensates by listing valid protocols (btc, eth, etc.) and providing an example address. This adds significant meaning beyond the bare schema types, though it could further explain address format per protocol.
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 a category label for a blockchain address and includes associated entity when available. This distinguishes it from siblings like get_address_risk_score or bulk_address_label, though it does not explicitly name them. The verb 'retrieve' and resource 'category label' 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?
Usage context is implied by the tool's purpose and sibling names, such as bulk_address_label for batch operations and get_address_risk_score for risk scoring. However, there is no explicit when-to-use or alternative mention, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for safety and behavior disclosure. It adds value by revealing a cost of 300 credits and mentioning what information is returned (input data, state changes, execution results). It does not disclose error handling, rate limits, or side effects, but for a read-only retrieval tool with an output schema, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a clear purpose statement followed by concise parameter details and cost. The example hash is useful and not excessive. The 'Args:'/'Cost:' formatting is slightly non-standard but requires minimal extra reading.
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 two simple parameters and an output schema, the description covers the essential invocation details. However, it does not clarify how this differs from closely related sibling tools like get_transaction_detail or get_transaction_graph, leaving the agent to infer the right selection. The behavior 'state changes' is mentioned but not elaborated, which may be a gap for complex contract analysis.
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 description coverage is 0%, so the description must compensate, and it does thoroughly. Both parameters are explained: proto has allowed values (eth, bnb) and transaction_hash includes a full example. This goes beyond the bare schema and gives the agent the needed context to construct valid arguments.
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 a specific action ('Retrieve detailed information for smart contract transactions') and identifies the resource scope ('smart contract transactions'). It implicitly distinguishes from siblings like get_transaction_detail by focusing on contract-related details, but does not explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for smart contract transaction analysis, and the parameters (proto, transaction_hash) provide context. However, it offers no explicit guidance on when to prefer this over get_transaction_detail or other sibling tools, nor any prerequisites or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does reveal the cost (300 credits), which is important for agents. However, it does not explicitly state that this is a read-only operation, nor does it mention any potential side effects, rate limits, or response behavior. The existence of an output schema helps, but the description itself is thin on operational 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 compact and well-structured: one main sentence for purpose, a concise Args block, and a cost line. There is no fluff, and the most important information is front-loaded. Every sentence earns its place, and the format is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple two-parameter tool with an output schema, the description is largely complete: it explains both parameters, notes the cost, and states the core purpose. It could be enhanced by mentioning expected outputs or error cases, but the output schema likely covers return values. The lack of usage guidance is a minor gap, but overall it is adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the input schema has zero description coverage, the Args section in the description is crucial. It explains 'proto' with example values (eth, bnb) and gives a concrete example for 'contract_address'. This adds meaning beyond the bare schema and helps the agent correctly populate both required 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 analyzes smart contract source code and related execution behavior, with a specific verb ('Analyze') and resource (smart contract). It distinguishes itself from siblings like get_contract_transaction, which focuses on transactions, and get_transaction_detail. The phrase 'related execution behavior' adds nuance but does not muddy the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites beyond the required parameters, or scenarios where a different tool might be preferred. Usage is only implied by the tool's purpose, but there is no actionable direction.
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 behavioral disclosure burden. It does disclose the 'Cost: 100 credits', which is useful context, but it omits other behavioral traits such as result limits, pagination, or error behavior. Since this is a read-only search tool, the missing details are less critical but still represent 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 compact and front-loaded, with a clear purpose statement, a single parameter explanation, and cost information. Every sentence earns its place, and there is no redundant or filler content.
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 one-parameter tool with an output schema, the description covers the core purpose, parameter semantics, and cost. However, it lacks usage context distinguishing it from the exact-search sibling and does not explain expected result behavior beyond the schema. It is adequate but leaves room for more context.
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 one parameter 'q' with 0% description coverage, but the description explains its meaning ('Fuzzy search query for broad text matching') and provides a concrete example ('e.g. bank corporation'). This adds significant practical value beyond the bare schema type definition, though it could include format or length 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 uses a specific verb 'Perform fuzzy text matching' and clearly identifies the resource ('OFAC sanctions database') and the fields searched (names, addresses, related fields). It also distinguishes itself from siblings by emphasizing 'fuzzy' matching and the OFAC scope, which differs from exact search tools like search_ofac and global sanctions 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 broad text matching via 'Fuzzy search query for broad text matching', but it does not explicitly state when to use this tool over exact search_ofac or fuzzy_search_global_sanctions. No exclusions or alternative tool recommendations are provided, leaving the usage decision partially ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It adds 'Cost: 10 credits' and enumerates dataset choices, but does not explicitly state that this is a read-only operation or clarify what a positive match means. For a simple screening tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with a clear one-sentence purpose, an Args block for parameters, and a single line for cost. Every sentence earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Purpose, parameters, and cost are all covered, and the presence of an output schema mitigates the need to describe return values. However, the description lacks explicit cross-references to alternative sanctions screeners, which would make it more fully self-contained.
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?
The input schema has zero descriptions (0% coverage), but the description fully compensates by documenting both parameters: 'address' with a concrete example and 'dataset' with all allowed values plus default. This is excellent parameter-level 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 opens with a specific verb ('Check whether') and a clear resource ('blockchain address appears on international sanctions lists'), and it explicitly mentions 'multiple countries and organizations', which distinguishes it from the OFAC-only sibling tool. This makes the tool's core function immediately apparent.
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 screen_ofac_address or search_global_sanctions. The dataset argument lists options, but there is no explicit statement about when a user should choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does add 'May take up to 5 minutes' and 'Cost: 200 credits,' which are useful behavioral traits. However, it does not mention side effects, rate limits, or error conditions. The output schema covers return format, but prerequisites or read-only status are not 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 well-structured with a clear action sentence followed by a compact Args list. Every line provides value: examples, formats, and cost/latency. It is appropriately sized given the schema's lack of parameter descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 required parameters with no schema-level descriptions, and no annotations. The description covers all parameters with syntax and value domains, includes a precise example, and warns about the 5-minute execution time. Since an output schema exists, return values are already documented, so the description is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 does so excellently by explaining all five parameters: proto lists possible values (btc, eth, trx, xrp), direct specifies 'in, out', address includes an example, and time_from/time_to are described as Unix timestamps with examples. This added meaning far exceeds the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Automatically trace the flow of transactions from a wallet address across multiple hops.' This uses a specific verb (trace) and resource (transaction flow from a wallet) and distinguishes it from sibling tools like get_transaction_graph by emphasizing automation and multi-hop 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 does not provide any guidance on when to use this tool versus the many sibling tools, such as get_transaction_graph or get_address_stats. It only states what it does and adds a latency warning, but no exclusions or alternative recommendations exist.
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 the cost (200 credits), the parameters, and the core behavior, but does not mention rate limits, authentication requirements, or any further behavioral details such as how attribution is computed or whether results are paginated. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the main purpose is stated in the first sentence, followed by parameter details and cost. Every sentence adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with an output schema present, the description covers the essential purpose, parameters, and cost. It is complete enough for basic usage, though it could add a note about expected output shape or typical use cases involving entity attribution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no property descriptions (0% coverage), so the description compensates by listing allowed protocol values (btc, eth, xlm) and providing a concrete address example. This adds meaningful context beyond the bare schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Analyze inflow and outflow activity of blockchain wallet addresses with entity-based attribution and percentage breakdowns.' This is a specific verb+resource combination that distinguishes it from sibling tools like get_address_stats or get_address_label, which focus on other aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for analyzing address activity flows, but it does not explicitly state when to use this tool versus alternatives or exclude cases. No alternative tools are mentioned, so guidance is implicit 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 transparency burden. It discloses the supported protocol (eth only) and the cost (100 credits), which is useful. However, it does not describe what happens with invalid hashes, whether it is read-only, or other behavioral aspects beyond the cost and protocol limitation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a purpose sentence, an Args section with clear labels, and a cost note. Every element earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The existence of an output schema means the description does not need to explain return values. It covers the essential inputs, protocol constraint, and cost. It lacks some usage guidance, but that is addressed in dimension 2; for the tool's operational context, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates well. It defines 'proto' as the blockchain protocol and notes only eth is supported, and it provides a concrete example for 'hash'. This adds meaning beyond the bare schema types, though it could be more explicit about possible proto values.
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 detailed transaction data with graph structures, specifying a concrete action and resource. The mention of 'graph structures' distinguishes it from sibling tools like get_transaction_detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for visualization and relationship analysis but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. It also notes 'currently only eth supported', which is a useful constraint but not a usage guideline.
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 for behavioral disclosure. It reveals the cost of 5 credits, which is useful, but does not mention any other behaviors like read-only guarantees, response format, or rate limits. This is adequate but not rich.
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 succinct, front-loaded with the primary purpose, and includes cost information. The Args and Cost lines are well-formatted and add 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?
For a simple one-parameter screening tool, the description covers the core purpose, parameter, and cost. An output schema exists to document return values, so the lack of return format detail is acceptable. It does not mention any caveats about the OFAC list or edge cases, but these are not essential for a basic screening tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description compensates by explaining the 'address' parameter and providing a concrete example. This adds meaningful context beyond the bare schema 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 uses a specific verb 'Check whether' with a precise resource ('blockchain address') and target ('OFAC sanctions list'). This clearly distinguishes from sibling tools like screen_ip_address or screen_global_sanctions_address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is evident from the description, but it does not explicitly state when to use this tool versus alternatives such as screen_global_sanctions_address. No exclusions or alternative recommendations are provided, leaving the choice somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does add useful context: the cost (50 credits), the fact it is a read-only retrieve operation, and the output categories (risk scores, levels, categories). However, it does not disclose potential rate limits, whether the query can fail for unknown addresses, or how the suspicious activity is determined beyond the categories. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It starts with one sentence on purpose, then a clear Args list with examples, and a single cost line. Every sentence adds value, with no redundant or vague filler. The front-loading of the main purpose is effective.
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 required parameters, output schema present), the description is nearly complete. It states the protocols, the address format, the cost, and what the response contains (risk scores, levels, categories). The only minor gap is the lack of explicit usage guidance relative to siblings, but this is partially covered by purpose clarity. The output schema covers the return structure, so the description doesn't need to detail it.
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 description coverage is 0%, so the description must compensate for the missing parameter details. The Args section provides explicit explanations: 'proto' lists all supported blockchain protocols (btc, eth, xlm, xmr, etc.), and 'address' provides a concrete example. This fully clarifies the meaning and acceptable values for both parameters, going well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve suspicious activity associated with a blockchain address, along with related risk scores, levels, and categories.' The verb 'retrieve' is specific, the resource is a blockchain address, and the additional outputs (risk scores, levels, categories) differentiate it from sibling tools like get_address_risk_score or get_address_label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for querying suspicious activities for a given address, but it does not explicitly state when to use this tool versus alternatives like get_address_risk_score or get_address_stats. No exclusions or alternative tools are mentioned; usage context must be inferred from the name and description.
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 discloses that matching is exact, covers multiple jurisdictions, and costs 20 credits. However, it does not explain behavior when no parameters are provided, response format, or potential pagination/limits. Some transparency is provided but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a clear one-sentence purpose, then efficiently lists parameters with single-line explanations, followed by cost. No redundant text; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers purpose, parameters, datasets, and cost. Since an output schema exists, return value details need not be explained. Minor missing context includes match behavior across multiple fields and any filter combinations, but overall it is sufficiently complete for selection and invocation.
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 0%, yet the description compensates fully by listing all 11 parameters with concise meanings, including allowed values for dataset and type, and the default for dataset. This provides clear semantic meaning that the schema itself lacks.
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 searches international sanctions databases with exact field matching across multiple jurisdictions. This distinguishes it from sibling tools like fuzzy_search_global_sanctions and screen_global_sanctions_address by emphasizing exact matching and broad coverage.
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 exact-match sanctions searching and lists available datasets, but does not explicitly state when to prefer this tool over fuzzy search or other screening tools. No exclusions or alternatives are mentioned, so guidance is only implicit.
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 of behavioral disclosure. It reveals the fuzzy matching nature and 'Cost: 200 credits,' but does not mention read-only status, permissions, or potential side effects. For a search tool, this is adequate but not rich.
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 purpose is stated clearly in the first sentence, followed by a well-structured Args section and a cost note. No redundant or unnecessary information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and an output schema exists so return values need not be explained. The description covers purpose, parameters, and cost, but lacks explicit alternative guidance. It is sufficient for a search tool with these structured inputs.
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 0%, so the description compensates fully. It explains q with an example ('Kesklinna') and dataset with the complete list of allowed values and default, adding significant meaning beyond the schema's bare types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'fuzzy text matching across international sanctions databases' with 'broader and more comprehensive coverage.' This specific verb+resource combination distinguishes it from sibling tools like search_global_sanctions (likely exact) and fuzzy_search_ofac (OFAC-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'broader and more comprehensive coverage' implies use when a broader fuzzy match is needed, but it does not explicitly name alternatives or state when not to use. It offers clear context without 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?
No annotations are provided, so the description carries the full burden. It discloses the cost (10 credits) and the exact output range and types, which are useful behavioral details. It doesn't explicitly state that the operation is read-only, but the 'retrieve' verb implies it. It also doesn't describe error handling 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 two structured paragraphs with no wasted words. The main sentence is front-loaded, and the Args section provides parameter details in a clean format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema and presence of an output schema, the description covers the core aspects: purpose, parameters, and cost. It does not go into edge cases or alternative use cases, but it is sufficiently complete for a straightforward query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates by listing all supported protocols for the proto parameter (btc, eth, xlm, xmr, etc.) and providing an example address for the address parameter. This adds significant meaning beyond the bare field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve an address risk score (0-100), risk level (1-4), category, and associated entity,' which specifies the verb, resource, and return values. This distinguishes it from siblings like bulk_address_risk_score and get_address_label.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for what the tool does and the cost, but it does not explicitly mention when to use it over alternatives like bulk_address_risk_score or get_address_label. The single-address parameter implies a single query, but no explicit when/when-not guidance is 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?
No annotations are provided, so the description carries the full burden. It discloses that the operation is a read ('retrieve'), specifies the output scope (transaction volume, frequency, behavioral patterns), and explicitly states the cost (100 credits). It does not mention rate limits or error behavior, but for a read tool this is reasonably 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 concise: two sentences for the purpose plus a compact arg list and cost. It is front-loaded and every sentence contributes, with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and both parameters, and the presence of an output schema covers return values. It is complete enough for basic invocation, but lacks explicit guidance on when to use this versus the many sibling address tools, and does not mention error behavior.
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 0%, so the description must compensate. It does so effectively: 'proto' lists valid values (btc, eth, xlm) and 'address' provides a concrete example. This adds critical meaning beyond the bare schema types.
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: 'Retrieve statistical insights for a blockchain address, including transaction volume, frequency, and behavioral patterns.' The verb 'retrieve' combined with the resource 'blockchain address' and the specific statistics distinguishes it from sibling tools like get_address_label or get_address_risk_score.
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 statistical analysis of addresses but does not explicitly provide when-to-use vs alternatives. It does not mention when not to use it or point to sibling tools, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it sources from multiple providers and mentions the credit cost, which is useful. However, it does not explicitly state that it's read-only, nor does it mention rate limits, input validation behavior, or what happens with empty queries. The 'retrieve' verb implies a non-destructive operation, but more transparency would be better.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The main purpose is stated in one sentence, followed by a compact args list and a cost note. Every line earns its place with no fluff. The format is scannable and 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?
For a simple, optional-parameter news retrieval tool with an output schema, the description covers the essential aspects: purpose, parameters with valid values, and cost. It doesn't describe return values, but the existence of an output schema mitigates that need. A minor gap is not mentioning whether the category filter is case-sensitive or how to combine query and category, but overall it is sufficiently complete.
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?
Despite the schema reporting 0% coverage, the description provides a detailed 'Args' section for both query and category. It explains the purpose of 'query' with an example and lists all valid category values (general, bitcoin, ethereum, defi, nft, regulation, exchange, mining). This adds significant meaning beyond the bare schema definition, which only says they are optional strings or nulls.
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 'Retrieve' and clearly identifies the resource: 'cryptocurrency and blockchain-related news and market information'. This distinguishes it from sibling tools, which are all about address/transaction/sanctions screening. No ambiguity about what this tool does.
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 clearly implies the tool is for retrieving crypto news, and no sibling tool overlaps with this function. It provides context (multiple sources) but doesn't explicitly state when to use it vs alternatives or mention exclusions. However, the lack of overlapping sibling 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 are provided, so the description carries the full burden. It states 'Analyze' implying a read-only operation and mentions a fixed cost of 5 credits, but does not disclose data sources, limitations, or any side effects. The output schema covers return values, but operational behavior is not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loads the purpose, with a clear parameter definition and cost note. Every sentence earns its place, 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?
For a simple tool with one parameter and an output schema, the description covers the key aspects: purpose, parameter format, and cost. It lacks explicit alternative guidance but is adequate for basic usage.
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?
The description adds format and example for ip_address ('IPv4 format, e.g. 1.2.3.4'), which is not present in the schema (0% coverage). This fully compensates for the missing schema descriptions and provides clear guidance on the expected 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 'Analyze IP geolocation data and sanctions status', identifying the specific resource (IP address) and purpose (regional compliance). It distinguishes from sibling tools that screen crypto addresses (e.g., screen_ofac_address) by focusing on IP addresses.
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 context ('to support regional compliance checks') but does not explicitly mention when to use this tool versus alternatives. It offers enough context for an agent to infer its use case, but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the exact-match behavior and cost (10 credits), which is useful. However, it does not clarify whether fields are combined with AND/OR, whether at least one parameter is required, or the behavior when no filters are provided. These are meaningful gaps for a search tool with all-optional parameters.
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 front-loaded with a clear purpose statement, followed by a compact parameter list and cost note. Every line serves a purpose; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameters, and cost, and the output schema exists to explain return values. However, it omits guidance on how to combine multiple filters and whether an empty search is valid. Given the tool's complexity (9 optional parameters), this leaves some ambiguity around invocation patterns.
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 description coverage is 0%, but the description compensates fully by explaining each parameter: type, name, first/last name, id, address, city, state, country. It even provides examples for type and id, adding real semantic value beyond the bare schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb ('Search'), the resource ('OFAC sanctions database'), and the method ('exact field matching'), which distinguishes it from fuzzy siblings like fuzzy_search_ofac. It is specific and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'exact field matching' gives clear context for when to use this tool over fuzzy alternatives, though it does not explicitly name alternatives or state when not to use it. The sibling 'fuzzy_search_ofac' is implied as the contrasting choice, so usage context is clear 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses important operational details: maximum batch size (10), supported protocols, and a 50-credit cost. It does not explicitly state read-only behavior or error handling, but 'retrieve' implies a safe read operation and the added constraints are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and efficient, delivering purpose, arguments, and cost in a few lines. The argument list is clearly formatted with no redundant phrases, earning a top score for conciseness.
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 two required parameters and an output schema present, the description covers purpose, parameter semantics, constraints, and cost. It does not explain return values, but the output schema likely covers that. The only gap is lack of explicit guidance on when to use this vs. sibling tools, though the batch nature is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining both parameters: 'proto' lists valid protocol values and 'addresses' specifies a list of 1-10 items. This adds meaning beyond the bare schema, though it does not describe address format or other property-level details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Retrieve') and resource ('address category labels and related entity information'). It explicitly notes 'multiple blockchain addresses (up to 10) in a single request', distinguishing it from the singular sibling get_address_label.
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 clear context for batch queries by specifying 'multiple' addresses, 'up to 10', and 'single request'. However, it does not explicitly name alternatives like get_address_label for single-address needs or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It discloses a key behavioral trait: the cost (100 credits) and the address count limits (1-10). These are useful operational details. However, it does not mention error handling, address validation, or potential rate limits, which would make it more 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 tightly structured: a headline sentence states the core function, followed by a labeled Args section and a one-line cost note. Every sentence adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered. The description adds essential context: batch size limits, allowed protocols, and cost. It stops short of being fully complete by not addressing edge cases (e.g., invalid addresses, partial failures), but for a straightforward batch retrieval tool, it is sufficiently complete.
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 description coverage is 0%, so the description must compensate. It provides meaningful semantics for both parameters: the 'proto' parameter is given an explicit list of allowed protocols, and 'addresses' is clarified as a list with a 1-10 count limit. This is exactly the missing meaning that the schema lacks.
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 ('Retrieve') and clearly identifies the resource ('address risk scores, risk levels, and categories') for 'multiple blockchain addresses'. It distinguishes itself from the sibling tool 'get_address_risk_score' by emphasizing 'multiple' and 'up to 10' in one request.
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 clearly conveys the intended use case: querying multiple addresses in a single batch. It implies that this tool is for multi-address queries, but it does not explicitly mention when not to use it or name the alternative (e.g., 'get_address_risk_score' for a single address).
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:

[![anchain-data-mcp MCP server](https://glama.ai/mcp/servers/AnChainAI/anchain-data-mcp/badges/card.svg)](https://glama.ai/mcp/servers/AnChainAI/anchain-data-mcp)

Score Badge

Copy to your README.md:

[![anchain-data-mcp MCP server](https://glama.ai/mcp/servers/AnChainAI/anchain-data-mcp/badges/score.svg)](https://glama.ai/mcp/servers/AnChainAI/anchain-data-mcp)

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AnChainAI/anchain-data-mcp'

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