Entity relationship intelligence: finds all watchlist hits, traverses entity relation graph, screens connected entities, produces risk network map with composite scoring per node. Replaces 10-20 API calls + manual graph analysis. Costs $0.015 USDC via x402.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Graph traversal depth: 1 (direct connections) or 2 (connections of connections). Default: 1 | |
| query | Yes | Entity name to scan (e.g. 'Global Capital Ltd') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses core behavior (traverses graph, screens entities, produces composite scoring) and adds the cost per use ($0.015 USDC via x402). However, it does not mention whether it is read-only, potential response size, or any side effects beyond cost. The basic operational behavior is described, but not deeply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. The first sentence immediately states the tool's purpose and outputs; the second adds value proposition and cost. No wasted words, and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (graph traversal, scoring), and the description covers its main output (risk network map with composite scoring) without an output schema. It does not explain depth nuances or data sources, but given the schema covers parameters and the description gives a clear overview, it is sufficiently complete for an agent to select and invoke correctly. Minor gap: no mention of alternatives or when to use simpler tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters (query and depth). The description adds no additional parameter explanation, but the schema already provides adequate descriptions and defaults. The description's mention of 'traverses entity relation graph' indirectly ties to depth, but this is not explicit. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 and resource: 'finds all watchlist hits, traverses entity relation graph, screens connected entities, produces risk network map.' This distinguishes it from sibling tools like compliance_watchlist (simple watchlist check) and compliance_wallet_entity (entity-wallet linkage) by specifying the graph traversal and network map output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining it 'replaces 10-20 API calls + manual graph analysis,' which suggests when to use it. However, it does not explicitly state when not to use it or name sibling alternatives for simpler checks. The use case is clear but not as directly contrasted as ideal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clear distinct purposes, but several compliance screening tools (compliance_wallet, compliance_wallet_entity, compliance_watchlist, due_diligence) overlap partially and could confuse an agent. Country_brief and country_snapshot also have similar scope.
Naming is inconsistent: some tools use a compliance_ or country_ prefix, others use verb_noun (govdata_search, transaction_screen), and some are bare nouns (weather, forex_rates). No single convention is followed.
22 tools is on the heavier side but justified by the broad scope (global sanctions screening, travel rule, monitoring, and Mauritius economic data). The tools cover distinct functional areas, though a few could be consolidated.
Core compliance workflows are covered: screening, risk scoring, monitoring, travel rule, and due diligence. However, the monitoring lifecycle is incomplete (no unsubscribe or list subscriptions), and economic data is only provided for Mauritius, leaving gaps for global country intelligence.