Skip to main content
Glama
ralf9090

Agent Kiosk

compliance_check

Read-onlyIdempotent

Screen 0x EVM addresses for AML, OFAC sanctions, phishing, mixer, and malicious counterparty risk before agents execute transfers.

Instructions

Institutional AML, Sanctions (OFAC), Phishing, Mixer, and Malicious Counterparty Compliance Screening ($0.05 USDC). Screens any 0x EVM address against GoPlus Security (Base + Ethereum) and 4-chain RPC footprint before autonomous agents execute transfers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressYes0x... 40-hex EVM wallet or contract address to screen for AML/sanctions

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.5.0

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, open-world and non-destructive, so safety is covered. The description adds genuinely new behavioral context beyond them: a $0.05 USDC cost (a payment requirement the agent must account for) and the data sources backing the verdict (GoPlus Security on Base + Ethereum plus a 4-chain RPC footprint).

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 tight sentences, with the screening scope front-loaded and cost stated inline. Dense with value and free of filler, though the first sentence reads as a keyword list rather than flowing prose.

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 single-parameter read tool with full annotations, the description covers purpose, trigger context, cost, and data provenance. The one gap is that no output schema exists and the description does not hint at what a screening result looks like (e.g., risk verdict format), which an agent would need to interpret the response.

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 address parameter, so the schema already carries the documentation load. The description only adds the scope constraint that the input must be a 0x EVM address, which is already implied by the schema description — 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?

Names a specific verb ('Screens') and resource ('any 0x EVM address') and enumerates the exact check categories (AML, OFAC sanctions, phishing, mixer, malicious counterparty). No sibling tool in the list performs compliance screening, so the agent can place it immediately.

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 states the usage context — screening 'before autonomous agents execute transfers' — which tells the agent when this tool fits in a workflow. It stops short of naming alternatives or when-not-to-use conditions, so it is 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.