Pre-transaction risk screening for Ethereum addresses: signed score, sanctions, audit trail.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 7 of 7 tools scored.
Each tool has a distinct role: screen_address is the only credit-costing action, while get_credit_balance, histories, narrative, compare, and monitoring are clearly read/reporting tools. The only minor ambiguity is between get_screening_history and get_address_screening_history, but the descriptions clearly separate all-address history from single-address history.
The dominant pattern is get_<noun>_<detail>, and screen_address is a clear imperative action. compare_screening_runs breaks the get_* pattern but still uses a recognizable verb-first structure, so naming is mostly consistent and predictable.
Seven tools is well-scoped for a wallet reputation screening service: one core action, a balance check, two history views, a narrative fetcher, a comparison tool, and monitoring events. Each tool has a clear purpose and none feel redundant or peripheral.
The surface covers the core workflow: screen an address, retrieve narrative, review history, check credit, compare runs, and monitor events. A notable minor gap is the lack of a direct fetch for a single screening run by screeningId, though the history and compare tools partially work around this.
compare_screening_runsCompare screening runsACompare two completed screens by their screeningId and see what changed. Costs zero credits. Two runs of the same address show why the reputation score moved. Two different addresses show a side by side. Returns each run score, band, and confidence, a reason level diff, and the score change broken into its drivers. Small differences between runs of one address can be normal variation rather than a data change.
| Name | Required | Description | Default |
|---|---|---|---|
| runIdA | Yes | First screeningId (rsr_...). Must be a completed screen you own. | |
| runIdB | Yes | Second screeningId (rsr_...). Must be a completed screen you own. |
| Name | Required | Description |
|---|---|---|
| mode | Yes | temporal_delta when both runs are the same address, else side_by_side |
| runA | Yes | |
| runB | Yes | |
| reasonDiff | Yes | What changed between the two runs at the reason level |
| scoreDelta | Yes | runA score minus runB score |
| compositionDiff | Yes | Which score drivers differ between the runs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, so safety is covered. The description adds meaningful behavioral details: 'Costs zero credits,' what the response contains (score, band, confidence, reason level diff, drivers), and a caution about normal variation. The warning shows deeper behavioral understanding and helps set expectations. It does not contradict annotations.
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 front-loaded with the core purpose in the first sentence, follows with the credit cost, then the two scenarios, the return summary, and a caveat. All sentences add information and there is no filler. It is a bit longer than absolute minimum but justified by the need to explain the variable comparison semantics.
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 the output schema exists and parameters are well-documented, the description adds the missing decision-making context: what the comparison tells you, when to use it, and how to interpret results. It is sufficient for an agent to select and invoke the tool with confidence.
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 runIdA and runIdB, so parameter basics are already documented. The description enriches parameter meaning by explaining the relationship between the two runs: they can be for the same address or different addresses, and the output interpretation depends on that relationship. This is value beyond the schema.
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 opens with a specific verb+resource: 'Compare two completed screens by their screeningId and see what changed.' It clearly distinguishes from siblings like get_screening_history or get_screening_narrative by focusing on comparison between two runs. The two use cases (same address vs different addresses) further clarify its unique niche.
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?
It provides context for when to use: comparing two runs of the same address to explain a reputation score move, or two different addresses for a side-by-side. It also warns that small differences may be normal variation, which helps an agent interpret results and decide whether to trust a data change. However, it doesn't explicitly name alternative tools for exclusion, relying on the sibling list for contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_address_screening_historyGet address screening historyARetrieve the authenticated user's prior screening runs for a specific Ethereum address, each with the same detail as screen_address: reputation score, band, confidence, sanctioned flag, and the top evidence signals. Use it to recall context for an already-screened address. Costs zero credits, unlike screen_address which always runs a fresh screen. For runs across all your addresses, use get_screening_history.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of past runs to return (1-50, default 5, newest first) | |
| address | Yes | Ethereum address (0x...) or .eth ENS name to look up historic screenings for |
| Name | Required | Description |
|---|---|---|
| items | Yes | Recent screening runs, newest first, each with the same detail as screen_address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already indicating readOnlyHint=true and openWorldHint=false, the description adds meaningful behavioral context: the cost implication ('Costs zero credits'), the relationship to screen_address (fresh vs. historical), and the specific output fields ('reputation score, band, confidence, sanctioned flag, and top evidence signals'). This goes beyond the annotations without contradicting them.
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 three sentences, each packed with distinct value: purpose/scope, use case, and key differentiator with alternatives. It is front-loaded with the essential action and avoids redundancy.
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?
For a relatively simple read-only tool with full schema coverage and an output schema present, the description provides complete context: what it returns, how it compares to a sibling, and when to use it. Nothing essential is missing.
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 input schema already provides full coverage for both parameters (address and limit) with detailed descriptions, including format and constraints. The description does not add parameter-specific semantics beyond what the schema offers, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb-resource pair: 'Retrieve the authenticated user's prior screening runs for a specific Ethereum address.' It explicitly distinguishes from siblings by naming get_screening_history for all addresses and screen_address for fresh runs.
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?
Provides explicit when-to-use guidance: 'Use it to recall context for an already-screened address.' It also gives an exclusion criterion: 'Costs zero credits, unlike screen_address which always runs a fresh screen,' and points to the alternative get_screening_history for broader queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_credit_balanceGet credit balanceAReturns the authenticated user's current credit balance as a whole number of credits. One credit screens one address: screen_address costs 1 credit, while this call and the history, narrative, and compare tools cost zero. Check it before screen_address to confirm a screen can be afforded.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds valuable context by explaining the credit costing model and return format. It does not repeat annotation info, and no contradictions are present.
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?
Three focused sentences: the core purpose, cost context, and usage guidance. Every sentence earns its place with no redundancy.
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?
For a parameterless, read-only tool with strong annotations, the description fully covers what the tool does, when to use it, and how it relates to siblings. No gaps remain.
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, so the schema fully covers this aspect. The description correctly adds no parameter details, which is appropriate per the baseline for parameterless tools.
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 uses a specific verb ('Returns') and resource ('current credit balance'), clearly distinguishing it from sibling screening tools. It also specifies the return unit ('whole number of credits'), removing ambiguity.
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 explicitly states when to use this tool: 'Check it before screen_address to confirm a screen can be afforded.' It also explains the cost relationship between tools, naming the specific alternative that consumes credits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_monitoring_eventsGet monitoring eventsAReturns the authenticated user's monitoring events: material reputation changes detected on their monitored addresses, oldest first, each with the change type, a summary, and the band transition. Also returns a deterministic digest that rolls up the window into one sentence. Page forward by passing the returned nextCursor as cursor. Bound the window with since and until, or restrict to one address with address. Costs zero credits.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of events (1-100, default 20) | |
| since | No | ISO-8601 lower bound. Only events at or after this time are returned. | |
| until | No | ISO-8601 upper bound. Only events at or before this time are returned. | |
| cursor | No | Pass the nextCursor from a prior call to page forward. | |
| address | No | Restrict to one monitored address (0x...). Omit for the whole portfolio. |
| Name | Required | Description |
|---|---|---|
| digest | Yes | Deterministic rollup of the events in this window |
| events | Yes | Monitoring events in the window, oldest first |
| hasMore | Yes | True when more events remain past this page |
| nextCursor | Yes | Cursor for the next page, or null when none remain |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, so the description adds value beyond them by revealing ordering (oldest first), pagination behavior, presence of a deterministic digest, and zero-credit cost. No contradiction exists between the description and annotations.
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?
Every sentence earns its place: first the main behavior and result shape, then the digest feature, then pagination, filtering, and cost. The description is information-dense but not padded, and it front-loads the most important semantics.
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 an output schema exists and all five optional parameters are documented in the schema, the description provides exactly the contextual glue needed for correct invocation: pagination, cursor behavior, filtering windows, ordering, and credit cost. Nothing essential is missing.
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 description coverage is 100%, so the parameter names and meanings are already well documented. The description does add helpful relational context, such as 'nextCursor as cursor' and 'since and until bound the window,' but it does not need to compensate for missing schema information.
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 resource ('the authenticated user's monitoring events') and the action ('Returns'), and specifies what each event contains: change type, summary, and band transition. This differentiates it from related sibling tools like get_screening_history, since the focus is explicitly on monitored address events and a rolled-up digest.
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 instructions: page forward with cursor, bound the window with since and until, restrict with address, and notes zero credit cost. It does not explicitly mention when not to use this tool or name an alternative, so it earns 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_screening_historyGet screening historyAReturns the authenticated user's most recent screening runs across all addresses, newest first, each with the same detail as screen_address: score, band, confidence, sanctioned flag, and the top evidence signals. Returns up to limit runs (default 20), so raise limit to reach older runs. Costs zero credits. For the history of one specific address, use get_address_screening_history instead.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results (1-100, default 20) |
| Name | Required | Description |
|---|---|---|
| items | Yes | Recent screening runs, newest first, each with the same detail as screen_address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses meaningful behavior: the scope across all addresses, the default of 20 results, the limit parameter semantics, the zero-credit cost, and the exact output fields via 'same detail as screen_address.' No contradiction with annotations exists.
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?
Three sentences, each earning its place: first sentence states the core result and fields, second explains limit behavior, and third provides the alternative. The most important scope constraint is front-loaded with no filler.
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 has only one optional parameter and an output schema, so the description covers what an agent needs beyond them. It addresses scope, ordering, cost, defaults, field content, and when to chose a different tool, leaving no obvious selection or invocation gap.
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% and documents the limit range and default, so the baseline is 3. The description adds value by explaining that increasing the limit reaches older runs and that the default is 20, which clarifies how the agent should advise the user.
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 states a specific verb ('Returns'), a concrete resource ('the authenticated user's most recent screening runs across all addresses'), and ordering ('newest first'). It also distinguishes itself from get_address_screening_history by addressing scope differences.
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?
It clearly says when to use this tool: when you need a user-wide history across all addresses. It also names the sibling get_address_screening_history for the single-address case, and notes the zero-credit cost, giving an agent a concrete routing and cost decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_screening_narrativeGet screening narrativeARetrieve the enhanced Probity review for a completed screen by its screeningId. Costs zero credits. Returns the narrative and the key concerns it raises. It is generated in the background after screen_address returns, so it may briefly be pending. Retry shortly if so.
| Name | Required | Description | Default |
|---|---|---|---|
| screeningId | Yes | The rsr_... id returned by screen_address. Must reference a completed screen; the narrative can be pending for a few seconds right after the screen returns. |
| Name | Required | Description |
|---|---|---|
| address | Yes | The screened address |
| concerns | Yes | Key concerns raised by the review |
| narrative | Yes | The enhanced review text |
| reportUrl | Yes | Link to the full report on the Probity dashboard |
| screeningId | Yes | The screen this review belongs to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true), the description discloses zero-cost behavior, background generation, and eventual consistency with retry guidance. It also clarifies the return content. This adds meaningful behavioral context without contradicting annotations.
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?
Three short sentences, front-loaded with purpose, then cost, output, and timing. Every sentence conveys essential information with no redundancy.
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 the single simple parameter, a rich schema, and an output schema, the description covers purpose, cost, pending behavior, and retry guidance. It is sufficiently complete for a low-complexity read tool.
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 schema fully describes the single parameter (screeningId) including its format and the pending-state caveat. The description restates the origin but does not add new semantic information beyond the schema, so it earns the baseline.
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 uses a specific verb ('Retrieve'), a specific resource ('enhanced Probity review' / 'narrative'), and identifies the key identifier (screeningId). It clearly distinguishes from sibling list/history tools like get_screening_history and screen_address by focusing on a single screening's narrative.
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?
It states that the narrative is generated in the background after screen_address returns, thereby specifying a clear use case (after screening) and handling the pending state. It also notes the requirement for a completed screen. It does not explicitly name alternative tools, but the context is sufficient for a single-purpose tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
screen_addressScreen addressAInspectScreen an Ethereum address or .eth ENS name for on-chain reputation risk. Costs 1 credit. Returns a signed reputation score (-100 to +100), a risk band, a confidence level, a sanctioned flag, the top evidence factors, a screeningId, and a link to the full report. The enhanced review is generated in the background. Fetch it with get_screening_narrative(screeningId). Use the score, band, and sanctioned flag to gate pre-trade or payout flows.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Ethereum address (0x...) or `.eth` ENS name (e.g. vitalik.eth) to screen. ENS names resolve to their current mainnet address and must resolve or the call errors. Addresses are case-insensitive and need not be checksummed. |
| Name | Required | Description |
|---|---|---|
| band | Yes | Reputation band, e.g. Low Risk, Reputable |
| score | Yes | Signed reputation score from -100 to +100. Lower is worse. |
| address | Yes | The screened address |
| summary | Yes | One line verdict headline |
| bandCode | Yes | Band identifier, e.g. LOW_RISK, REPUTABLE |
| evidence | Yes | Up to 10 signals behind the verdict, most severe first |
| reportUrl | Yes | Link to the full report on the Probity dashboard |
| confidence | Yes | Engine confidence in the result |
| sanctioned | Yes | True if the address is a direct OFAC match |
| screenedAt | Yes | When the screen ran (ISO-8601) |
| screeningId | Yes | Immutable identifier for this screen (rsr_...) |
| transactionCount | Yes | Number of transactions analysed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states that screening costs 1 credit and that the enhanced review is generated in the background, which adds meaningful behavior beyond the annotations. It also makes the side-effectful nature of the call visible despite readOnlyHint being false.
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, front-loaded, and every sentence adds value: purpose, cost, outputs, background behavior, and usage guidance. No filler or redundant phrasing is present.
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 single parameter is fully documented by the schema, the output is described with key fields and a link to a full report, and the description even names the follow-up tool for the background narrative. An agent has enough context to decide whether and how to call this tool.
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 input schema already provides 100% coverage for the single 'address' parameter, including ENS resolution, case-insensitivity, and error behavior. The description adds little beyond restating that an Ethereum address or ENS name can be screened, so the schema carries the semantic weight.
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 opens with a clear verb and resource: 'Screen an Ethereum address or .eth ENS name for on-chain reputation risk.' This clearly distinguishes it from sibling tools like fetching screening history or narratives, and the scope is explicit.
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 concrete application guidance: use the score, band, and sanctioned flag to gate pre-trade or payout flows, and use get_screening_narrative(screeningId) to fetch the enhanced review. It does not explicitly list when not to use this tool versus every sibling, but the primary alternative path is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
