trust-check-mcp
Server Details
Free OFAC SDN wallet screen + sample preview for AI agents on Base. Read-only, no payment surface.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- paladinfi/trust-check-mcp
- GitHub Stars
- 0
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.
Tool Definition Quality
Average 4.7/5 across 3 of 3 tools scored.
Each tool serves a clearly distinct purpose: health check returns service status and OFAC list metadata, OFAC free screens wallet addresses, and preview provides sample data for integration testing. No functional overlap exists.
All tools follow a consistent `trust_check_<action>` pattern with snake_case naming, making the set predictable and easy to navigate.
With only 3 tools, the server is tightly scoped for free-tier trust checking. Each tool contributes a distinct capability without unnecessary bloat.
The server lacks a real token-contract trust check, only offering a preview. For a service named 'trust-check', this is a significant gap; the core evaluation functionality is missing.
Available Tools
3 toolstrust_check_healthTrust Check Service HealthARead-onlyInspect
Return service health, supported chains, OFAC list refresh timestamp + size.
Pure introspection — no external API calls, no money handling.
Returns:
dict with status, supportedChains, version, and (when the OFAC
list is loaded) an ofac_list block with updated_at + sdn_count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and no destructiveness; description adds 'no external API calls, no money handling', reinforcing safety beyond structured fields.
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 short paragraphs plus a line, front-loaded with purpose, every sentence adds value. No waste.
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?
Covers return structure with conditional fields, states it's introspection. Sufficient given no parameters and sibling context.
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?
No parameters; schema coverage 100%. Description adds no param info (unnecessary). Baseline 4 for 0-param 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?
Clearly states verb 'Return' and resource: service health, supported chains, OFAC list details. Distinguishes from siblings (OFAC free and preview) by focusing on introspection.
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?
Explicitly says 'Pure introspection — no external API calls, no money handling', clarifying safe context. Lacks explicit 'when not to use' but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trust_check_ofac_freeWallet OFAC SDN Screen (Free, Real Data)ARead-onlyIdempotentInspect
Free wallet-address OFAC SDN screen on Base.
Live US Treasury OFAC SDN list lookup. Anonymous (no API key, no signup). Rate-limited at 1 request per second + burst 3 + 3 concurrent per IP. Refreshed daily from the Treasury XML feed.
Scope: US OFAC SDN wallet/EOA addresses only (~93 entries at last refresh).
Returns a binary allow / block verdict — no warn state on this
endpoint. No token-contract risk evaluation, no GoPlus signals, no
Etherscan verification, no anomaly heuristics — those are paid-endpoint
features not exposed through this MCP.
No money handling. No calldata. No signing surface. No transaction execution. Pure information retrieval.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Wallet/EOA address to screen (0x-prefixed 40 hex chars; must match `^0x[a-fA-F0-9]{40}$`) | |
| chainId | No | EVM chain ID (default 8453 = Base; only chain supported) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations, including rate limits (1 req/s, burst 3, 3 concurrent), daily refresh from Treasury, no API key needed, and the exact binary nature of the verdict. All traits are consistent with annotations (readOnly, idempotent, non-destructive).
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 well-structured with a clear first-line summary, followed by bullet-like details and explicit exclusions. Every sentence adds value, and the length is appropriate for the complexity of the tool.
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 existence of an output schema and annotations, the description covers all essential aspects: what it does, limits (rate, concurrency), data source, verdict format, and exclusions. It is complete enough for an agent to select and invoke the tool correctly.
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?
With 100% schema coverage, the baseline is 3. The description adds value by clarifying that chainId defaults to 8453 (Base) and that only Base is supported, which is not explicit in the schema. It also reinforces the address format. This extra context merits a slight increase.
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 it is a free wallet-address OFAC SDN screen on Base, with a specific verb (screen) and resource (OFAC SDN list). It distinguishes itself from siblings by detailing what it does and does not do, such as not including token risk evaluation or other paid features.
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 provides clear contexts: anonymous usage, rate limits, data refresh frequency, and binary verdict output. It also explicitly excludes use cases like token-contract risk evaluation and directs that those are paid features not available through this MCP, implicitly guiding when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trust_check_previewToken Trust Check (Preview)ARead-onlyIdempotentInspect
Get a SAMPLE-FIXTURE preview of the PaladinFi token-contract trust check.
⚠️ NOT a real evaluation. Returns fixed sample data with _preview: true,
every factor marked real: false, and recommendation prefixed sample-
(sample-allow / sample-warn / sample-block). Use this for shape-testing
your integration; DO NOT use the verdict to gate real swaps, signing, or any
production agent decision.
Programmatic safety check: before consuming any field of this response,
agents should test resp.get("_real") is True (top-level) — preview always
returns _real: false. Substring-matching on recommendation (e.g.
"allow" in resp["trust"]["recommendation"]) will INCORRECTLY match
sample-allow; use exact-equality (resp["trust"]["recommendation"] == "allow")
or test the _real field instead.
For free real-data wallet-OFAC screening (binary allow/block, anonymous, no
payment), use trust_check_ofac_free from this same MCP server.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | ERC20 contract address to evaluate (Base 8453 only currently; must match `^0x[a-fA-F0-9]{40}$`) | |
| chainId | No | EVM chain ID (default 8453 = Base; only chain supported) |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already read-only, idempotent, non-destructive. Description adds: returns _preview: true, all factors real: false, recommendation prefixed sample-. Also provides programmatic safety check and warns against substring matching, adding value beyond 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?
Clear and front-loaded, well-structured with bullet points and markdown. However, the programmatic safety check section is somewhat verbose, slightly reducing conciseness.
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 output schema documents return values and annotations cover safety, description is complete: explains purpose, usage, warnings, and alternatives. No gaps.
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 has 100% description coverage for both parameters. Description doesn't add extra meaning beyond what's in the schema. 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?
Description clearly states 'Get a SAMPLE-FIXTURE preview of the PaladinFi token-contract trust check', specifying verb, resource, and scope. It distinguishes from siblings by mentioning the real OFAC screening tool.
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?
Explicitly says when to use (shape-testing integration) and when not to use (DO NOT use verdict to gate real decisions). Provides alternative: 'trust_check_ofac_free' for real screening.
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.
Discussions
No comments yet. Be the first to start the discussion!