Return a representative sample of addresses on OceanAlt's reviewed risk list — OFAC-sanctioned, known mixers, and community-reported scam/phishing — each with its source category and reason. Takes no arguments. Free, no API key.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint; the description adds practical behavioral context beyond the annotation: it returns a 'representative sample' rather than an exhaustive list, includes source category and reason per address, and emphasizes the free/no-key nature. This is meaningful added transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states purpose and output contents, and subsequent short clauses cover constraints and access. No wasted words.
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?
Given that there are no input params, no output schema, and annotations already cover safety, the description provides enough context: what is returned, what categories are included, and that it is a sample. It also clarifies access requirements, making the tool self-contained for an agent.
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?
The tool has zero parameters and the schema already communicates this fully; the description reinforces it with 'Takes no arguments.' Since there are no parameter details to clarify, the baseline for a zero-parameter tool applies.
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?
Description clearly states a specific action ('Return') on a specific resource (OceanAlt's reviewed risk list), enumerating the categories of addresses and the per-item contents. It stands apart from the sibling screen_address tool because it provides a sample list rather than screening a single address.
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 gives clear usage context: no arguments are required and no API key is needed, making this an easy entry point. It does not explicitly name alternatives or say when not to use it, but for a zero-parameter read tool the guidance is sufficient.
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.
The three tools have distinct purposes: payment_decision is a payment gate, screen_address is a general risk assessment, and recent_flagged provides a sample list. While payment_decision and screen_address overlap in screening, their outputs and intended use cases are clearly differentiated by the descriptions.
All tool names use snake_case and are readable, but they follow different conventions: screen_address is verb_noun, payment_decision is a noun phrase, and recent_flagged is an adjective-participle. The lack of a uniform pattern (e.g., all verbs or all nouns) introduces mild inconsistency.
Three tools is on the lower end but appropriate for a focused AML compliance server. Each tool covers a distinct core function (payment gating, address screening, flagged list retrieval), so the count feels reasonable though not expansive.
The set covers the main workflows: screening an address, deciding on a payment, and seeing sample flagged addresses. However, there are gaps such as batch screening, attestation verification, and a way to fetch detailed information on specific flagged addresses, which agents might need for full compliance coverage.