RelayShield-MCP is a security intelligence server that brings breach detection, threat scanning, and identity risk tools into Claude and other MCP-compatible AI agents. It offers the following capabilities:
Email Breach Lookup (check_breach): Check if an email appears in 13 billion+ compromised accounts via Have I Been Pwned, returning breach count and details.
SIM Swap Detection (check_sim_swap): Detect SIM swap or eSIM provisioning events on a phone number in the last 24 hours using live carrier data.
Domain Lookalike Monitoring (check_domain_lookalikes): Identify typosquat and lookalike domains impersonating a brand via DNS resolution and Certificate Transparency data.
OAuth Supply Chain Watchlist (check_oauth_watchlist): Check if high-risk OAuth-connected SaaS apps (Slack, GitHub, Notion, etc.) tied to an email have appeared in recent breaches.
Infostealer Log Lookup (check_infostealer): Check if an email appears in infostealer malware logs (RedLine, Raccoon, Vidar, etc.).
EVM Wallet Risk Scan (scan_wallet): Assess an Ethereum/EVM wallet for on-chain risk signals like blacklisting and phishing associations via GoPlus Security.
URL Malware/Phishing Scan (scan_url): Submit a URL for async analysis across 70+ security engines.
File Malware Scan (scan_file): Submit a publicly accessible file URL for async binary malware analysis across 70+ AV engines.
Scan Result Polling (check_scan_result): Retrieve the verdict (malicious, suspicious, clean, or timeout) for a previously submitted URL or file scan (free tool).
MCP Registry Risk Check (check_mcp_registry_risk): Check an MCP server URL or package name for known-malicious indicators, typosquats, and domain registration age before connecting.
Prompt Injection Breach Check (check_prompt_injection_breach): Detect email exposure in breach dumps linked to AI agent prompt-injection attacks.
Supply Chain Exposure (check_supply_chain): Analyze up to 10 vendor domains for breach or infostealer exposure.
Session Risk Check (check_session_risk): Detect active or reusable stolen session cookies/tokens tied to an identity.
Non-Human Identity (NHI) Exposure (check_nhi_exposure): Find exposed API keys, service tokens, and PATs associated with an identity.
Secret Scanning (check_secret_scan): Discover secrets exposed in public GitHub/GitLab repositories.
All tools are accessible via RELAYSHIELD_API_KEY (subscription) or RELAYSHIELD_X_PAYMENT (pay-as-you-go).
Check if GitHub OAuth apps connected to a user's email have been involved in known security breaches.
Check if Notion OAuth apps connected to a user's email have been involved in known security breaches.
Check if Slack OAuth apps connected to a user's email have been involved in known security breaches.
Check if Zapier OAuth apps connected to a user's email have been involved in known security breaches.
mcp-name: io.github.nzdsf2-gif/relayshield-mcp
RelayShield security intelligence as an MCP server — plug breach detection, SIM swap detection, domain lookalike monitoring, OAuth supply chain watchlist, and URL/file scanning directly into Claude and any MCP-compatible AI agent.
Tool | What it does | PAYG price |
| Email breach lookup — 13 billion+ records via HIBP | $0.10 USDC |
| SIM swap / eSIM detection via live carrier data | $0.25 USDC |
| Typosquat and lookalike domain detection with cert transparency | $0.50 USDC |
| OAuth-app breach + stolen-token exposure via HIBP + stealer-log corpus | $0.30 USDC |
| Infostealer malware log lookup via Hudson Rock Cavalier | $0.15 USDC |
| EVM wallet on-chain risk check via GoPlus Security | $0.10 USDC |
| URL malware/phishing scan across 70+ engines (async) | $0.05 USDC |
| Binary malware scan across 70+ AV engines (async) | $0.10 USDC |
| Poll for verdict after | free |
| Typosquat/IOC/registration-age check for MCP servers | $0.35 USDC |
| Breach exposure sourced from AI-agent prompt-injection attacks | $0.35 USDC |
| Up to 10 vendor domains checked for breach/infostealer exposure | $0.10 USDC |
| Active/reusable stolen session (cookie/token) exposure check | $0.30 USDC |
| Non-human-identity credential exposure — API keys, service tokens, PATs | $0.40 USDC |
| Secrets exposed in public GitHub repositories | $0.35 USDC |
check_oauth_watchlist, check_supply_chain, check_session_risk, check_nhi_exposure, and
check_secret_scan cover related ground — connected-app, session, and machine-credential exposure
for an identity or its supply chain — and are a natural set to use together when vetting an agent's
current authority, not just a login.
Related MCP server: unphurl-mcp
Subscription — API key from api.relayshield.net/developers. All 15 tools available. Free tier: 100 calls/month. Paid tiers from $29/month.
Pay-as-you-go — No API key needed. Pay per check in USDC on Base (x402 protocol). Set RELAYSHIELD_X_PAYMENT with your payment proof. All 15 tools available ($0.05–$0.50/check, check_scan_result free). Call a tool with no payment set to receive pricing and payment instructions.
Discovery — Set neither key nor payment. Tool calls return payment requirements and a subscription link.
pip install relayshield-mcpOr run without installing:
uvx relayshield-mcpEdit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
Subscription (RelayShield API key):
{
"mcpServers": {
"relayshield": {
"command": "relayshield-mcp",
"env": {
"RELAYSHIELD_API_URL": "https://api.relayshield.net",
"RELAYSHIELD_API_KEY": "your-relayshield-api-key-here"
}
}
}
}Pay-as-you-go (x402 USDC on Base):
{
"mcpServers": {
"relayshield": {
"command": "relayshield-mcp",
"env": {
"RELAYSHIELD_API_URL": "https://api.relayshield.net",
"RELAYSHIELD_X_PAYMENT": "your-x402-payment-proof-here"
}
}
}
}Quit and relaunch Claude Desktop after editing.
claude mcp add relayshield \
--command relayshield-mcp \
--env RELAYSHIELD_API_URL=https://api.relayshield.net \
--env RELAYSHIELD_API_KEY=your-relayshield-api-key-hereOnce configured, ask Claude:
Check whether user@example.com has been breached.Has there been a SIM swap on +14155551234?Check acme.com for lookalike domains.Are any OAuth apps connected to user@example.com in a recent breach?Scan this URL for malware: https://suspicious-link.example.comFor URL and file scans, Claude automatically polls check_scan_result every 5 seconds until the verdict is ready.
Variable | Description |
| API Gateway base URL (required) |
| RelayShield subscription key (subscription mode) — get one at api.relayshield.net/developers |
| x402 payment proof — USDC on Base (pay-as-you-go mode) |
Set RELAYSHIELD_API_KEY or RELAYSHIELD_X_PAYMENT — not both. API key takes priority if both are set.
Check whether an email address appears in known data breaches. Uses Have I Been Pwned (HIBP) — 13 billion+ compromised accounts. Returns breach count and details (breach name, date, exposed data classes). Use before allowing high-risk actions that depend on credential integrity. Pay-as-you-go: $0.10 USDC per check (x402 on Base). Subscription: rapidapi.com/relayshield
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses underlying data source (HIBP), scale (13B+ accounts), and pricing model (pay-as-you-go $0.10 USDC, subscription option). No annotations exist, so description compensates well, though rate limits or error handling are omitted.
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 sentences plus pricing note—no fluff. Could merge some details, but overall efficient. Front-loaded with core purpose and key contextual info.
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 no output schema, description explains return value (breach count and details including name, date, data classes). Also covers use case, source, and cost. Lacks info on invalid email handling, but still robust for a simple 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?
Schema covers the single 'email' parameter with format and description (100% coverage). Description adds no additional parameter-level semantics beyond context about the service; baseline of 3 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 action ('Check whether an email address appears in known data breaches'), the resource (email address against HIBP database), and differentiates from sibling tools like 'check_domain_lookalikes' which target different entities.
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 recommends use 'before allowing high-risk actions that depend on credential integrity', providing clear context. No explicit exclusion criteria or alternatives, but the sibling list implicitly defines other check contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect typosquat and lookalike domains impersonating a brand. Generates hundreds of permutations (TLD swaps, character typos, homoglyphs, phishing prefixes/suffixes), resolves them in parallel via DNS, and enriches live results with Certificate Transparency data (cert count, recent issuance). Returns all lookalike domains that are currently registered and resolving. Use to find domains impersonating your brand, or before an employee clicks a link that resembles a company domain. Pay-as-you-go: $0.50 USDC per scan (x402 on Base). Subscription: rapidapi.com/relayshield
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Root domain to scan (e.g. acme.com — no scheme or path needed) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Covers key behavioral traits (generates hundreds of permutations, parallel DNS, cert enrichment, pay-as-you-go cost) but omits details like rate limits or failure modes.
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 sentences plus pricing line, no filler. Every sentence adds value: purpose, method, output, and cost.
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 simple input schema and no output schema, description covers purpose, usage, behavior, and pricing fully. No missing context needed.
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% with a single parameter. Description adds no extra meaning beyond the schema's description; baseline 3 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 it detects typosquat/lookalike domains, generating permutations, resolving via DNS, and enriching with cert data. Distinguishes from sibling tools like check_breach or scan_url.
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 use cases: 'Use to find domains impersonating your brand, or before an employee clicks a link.' 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.
Check whether an email address appears in infostealer malware logs. Uses Hudson Rock Cavalier — a database of credentials harvested directly from infected computers by infostealer malware (RedLine, Raccoon, Vidar, etc.). Returns found (bool), stealer count, and per-infection details: date compromised, operating system, malware path, and number of corporate/personal credentials stolen. Unlike breach databases (HIBP), infostealer hits mean the device itself was compromised — all stored passwords, session cookies, and crypto keys are at risk. Pay-as-you-go: $0.15 USDC per check (x402 on Base). Subscription: rapidapi.com/relayshield
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to check for infostealer compromise |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the tool's behavior: it queries a specific database, returns found bool, stealer count, and per-infection details. It also clarifies the implications of an infection. No contradictory or missing behavioral traits.
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 a single coherent paragraph that front-loads the core purpose. It includes necessary details but could be slightly trimmed (e.g., pricing could be separate). Overall, it 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?
Given one parameter and no output schema, the description covers purpose, data source, return fields, and implications. It is complete enough for an agent to use correctly, though an explicit output structure would improve it.
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 has 100% coverage for the single parameter with a description. The description does not add new semantics beyond what the schema provides, so a baseline score 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 tool checks email addresses against infostealer malware logs. It specifies the data source (Hudson Rock Cavalier) and differentiates from breach databases like HIBP, establishing a distinct purpose among siblings.
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 context for when to use the tool (checking for infostealer compromise) and explicitly contrasts it with breach databases. It also mentions pricing, but lacks explicit instructions on when not to use it relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an MCP server URL or package name for red flags: known-malicious IOC match, typosquat/near-miss against well-known MCP ecosystem domains, and domain registration age. Part of RelayShield's Agentic Attack Surface bundle — early coverage for an ecosystem with minimal dedicated security tooling as of 2026. Use before an agent connects to or installs a new, unfamiliar MCP server. Absence of findings means 'unknown,' not 'verified safe.' Pay-as-you-go: $0.35 USDC per check (x402 on Base). Subscription: rapidapi.com/relayshield
| Name | Required | Description | Default |
|---|---|---|---|
| server_url | No | MCP server URL to check (e.g. https://example-mcp-server.com) | |
| package_name | No | Package name to check if no server_url is available (limited coverage — no dedicated MCP package registry yet) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the checks performed, the 'unknown' caveat, and pricing model. With no annotations provided, the description carries the full burden, and it does so adequately for safety and cost awareness.
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?
Five sentences, front-loaded with core function, then usage, caveat, and pricing. Pricing info could be considered extraneous but does not harm clarity.
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?
With no output schema, the description does not explain the response format (e.g., risk levels or indicators), which would help an agent parse results. Otherwise covers input, behavior, and usage.
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 covers 100% of parameters with descriptions. The description adds context for package_name ('limited coverage—no dedicated MCP package registry yet'), which is useful but not essential 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 clearly states the tool checks MCP server URLs or package names for three specific red flags: known-malicious IOC, typosquatting near well-known domains, and domain registration age. It distinguishes itself from sibling tools by focusing on the MCP ecosystem.
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 'Use before an agent connects to or installs a new, unfamiliar MCP server' and warns that absence of findings means 'unknown, not verified safe.' Does not provide when-not-to-use or alternatives among siblings, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether any high-risk OAuth-capable SaaS apps connected to an email account have appeared in recent data breaches. Monitors a curated watchlist of apps (Slack, Notion, GitHub, Zapier, Vercel, Loom, HubSpot, AI tools, and more). An attacker who breaches these services may obtain OAuth tokens granting access to your Google Workspace or Microsoft 365 without touching your password. Returns matched breached apps and recommended revocation steps. Pay-as-you-go: $0.15 USDC per check (x402 on Base). Subscription: rapidapi.com/relayshield
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address whose connected OAuth apps to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds substantial behavioral context: it monitors a curated watchlist (with examples), explains the risk scenario, and mentions output (matched apps and revocation steps). However, it lacks technical details like error handling, rate limits, or non-destructive nature.
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 multiple sentences but well-structured: purpose first, then risk context, then output, then pricing. Every sentence adds value, though the pricing details could be considered extraneous for an agent but are informative.
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 one parameter, no output schema, and no annotations, the description provides sufficient context: what the tool does, what it returns, and even cost information. It enables an agent to decide when to use it.
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% (only email parameter), and the description adds meaning by explaining how the email is used (checking its connected OAuth apps against the watchlist) and what the watchlist contains, going beyond the schema description.
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 (check), the resource (high-risk OAuth-capable SaaS apps connected to an email account), and the outcome (appeared in recent data breaches). It distinguishes from sibling tools like check_breach (general breach checking) by specifying the OAuth and watchlist focus.
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 the tool should be used when concerned about OAuth token compromise from breached SaaS apps, but does not explicitly state when to use it versus alternatives like check_breach. No exclusions or when-not-to-use guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether an email address has exposure in a criminal dump whose own announcement text suggests an AI agent — rather than a traditional phishing or malware campaign — was involved in obtaining it. Heuristic v1 classifier over Telegram dump-announcement text, not a confirmed-attribution guarantee. Use as an early signal that an AI agent workflow may have been the breach vector. Pay-as-you-go: $0.35 USDC per check (x402 on Base). Subscription: rapidapi.com/relayshield
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Email address to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's heuristic nature, data source (Telegram dump-announcements), and pricing structure, offering comprehensive behavioral insights.
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 efficiently convey purpose, limitations, and cost. While some details like pricing could be secondary, overall structure is clear and front-loaded.
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 no output schema and a niche, heuristic check, the description adequately explains purpose, source, limitations, and cost, enabling informed tool selection.
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 sole parameter 'email' is fully described in the schema (100% coverage), and the description adds no additional semantic details about the parameter itself, only contextualizing the check type.
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 checks whether an email address appears in a criminal dump linked to AI agent involvement, distinguishing it from sibling tools like check_breach and check_infostealer.
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 advises using the result as an early signal for AI agent breach vectors and notes it is a heuristic, not a guarantee. It implicitly differentiates from siblings but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Poll for the result of a previously submitted URL or file scan. Call every 5 seconds after scan_url or scan_file until status is 'completed'. Returns verdict (malicious/suspicious/clean) and engine vote counts, or {status: pending} if the scan is still running. Free with a paid scan (no additional charge).
| Name | Required | Description | Default |
|---|---|---|---|
| analysis_id | Yes | analysis_id returned by scan_url or scan_file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses polling behavior, pending status return, pricing (free with paid scan), and return structure (verdict, engine votes, pending). Lacks rate limit or timeout details but still good coverage.
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: purpose, usage, return value, and pricing. Front-loaded with key information, no fluff.
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?
With one simple parameter, no output schema, and rich description covering when to call, how often, what to expect in response, and pricing, the description is complete.
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 the one parameter. The description adds 'returned by scan_url or scan_file' which mirrors the schema description. No additional meaning beyond schema, meeting baseline for high coverage.
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 polls for scan results (verb 'poll') and specifies the resource 'result of a previously submitted URL or file scan'. It distinguishes from sibling tools like scan_url and scan_file which submit scans.
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 instruction to call every 5 seconds after scan_url or scan_file until status is 'completed'. Does not explicitly list alternatives but given the sibling tools, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect whether a SIM swap or eSIM provisioning event has occurred on a phone number in the last 24 hours. Uses Twilio Lookup v2 with live carrier data. Returns swapped (bool), swap timestamp, and current carrier. Use when a user reports losing mobile service, or before completing a high-risk action that depends on SMS-based authentication. Pay-as-you-go: $0.25 USDC per check (x402 on Base). Subscription: rapidapi.com/relayshield
| Name | Required | Description | Default |
|---|---|---|---|
| phone | Yes | Phone number in E.164 format (e.g. +14155551234) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight. It discloses the output (swapped bool, timestamp, carrier), live carrier data source, and pricing ($0.25 per check). It does not mention rate limits or authentication, but for a simple check tool this provides adequate behavioral context.
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 serving a clear purpose: core functionality, usage guidance, and pricing. No filler; front-loaded with the most critical information.
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 tool with one parameter and no output schema, the description covers all essential aspects: purpose, usage context, return values, time window, data source, and cost. It is self-contained and leaves no significant 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?
The single parameter 'phone' is fully described in the schema (E.164 format, pattern). The description adds no extra parameter-specific meaning beyond mentioning Twilio Lookup v2; thus baseline 3 is appropriate given 100% schema coverage.
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 detects SIM swap or eSIM provisioning events on a phone number within the last 24 hours. It uses a specific verb ('detect') and resource, and distinguishes itself from sibling tools like check_breach or check_domain_lookalikes by focusing on carrier events.
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?
Explicit guidance is given: use when a user reports losing mobile service or before high-risk actions depending on SMS authentication. While no exclusions are stated, the context is clear and siblings are sufficiently different, making ambiguity low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a file for binary malware analysis across 70+ AV engines. Provide a publicly accessible download URL — RelayShield handles the download. Returns an analysis_id immediately (async). Call check_scan_result with the analysis_id every 5 seconds until verdict is returned. Verdicts: malicious | suspicious | clean | timeout. Use when a user receives an email attachment and forwards the download link. Pay-as-you-go: $0.10 USDC per scan (x402 on Base). Subscription: rapidapi.com/relayshield
| Name | Required | Description | Default |
|---|---|---|---|
| file_url | Yes | Publicly accessible URL to download the file from | |
| filename | No | Optional filename hint (e.g. invoice_march.pdf) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses async nature (returns analysis_id immediately), cost ($0.10 USDC per scan), and verdicts. Lacks info on rate limits or error handling, but overall provides key behavioral traits given no 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?
Concise 5-6 sentences with front-loaded purpose. Every sentence adds value: purpose, URL requirement, async return, polling instruction, verdicts, use case, pricing. 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?
Explains return value (analysis_id), verdicts, and polling interval. Mentions cost and subscription. Lacks output schema but covers expected outcomes. Could mention file size limits or error scenarios, but overall complete for a scanning 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?
Schema coverage is 100%, so baseline is 3. Description adds value by noting that the file_url must be publicly accessible and that RelayShield handles the download, which is not in the schema description.
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 the verb 'Submit a file for binary malware analysis across 70+ AV engines.' Distinguishes from sibling tools like scan_url (URL scanning) and check_scan_result (polling for results).
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 use case: 'Use when a user receives an email attachment and forwards the download link.' Also explains the async workflow and polling with check_scan_result. Does not explicitly state when not to use, but implications are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a URL for malware and phishing analysis across 70+ security engines. Returns an analysis_id immediately (async). Call check_scan_result with the analysis_id every 5 seconds until verdict is returned. Verdicts: malicious | suspicious | clean | timeout. Use before navigating to an unfamiliar URL or when a user forwards a suspicious link. Pay-as-you-go: $0.05 USDC per scan (x402 on Base). Subscription: rapidapi.com/relayshield
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to scan (must start with http:// or https://) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses async behavior (returns analysis_id immediately), recommended polling interval (every 5 seconds), possible verdicts, and pricing. Without annotations, the description carries full burden and does so fairly well.
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?
Relatively concise, but includes pricing information that, while relevant, may not be essential for tool selection. Front-loaded with primary purpose.
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 tool with one parameter, no output schema, and no annotations, the description is complete: covers async polling, verdicts, use cases, and pricing. No missing critical information.
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% (single url param with description and format). Description adds that URL must start with http:// or https://, which is already implied by the format. No additional semantic value beyond what schema provides.
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 the tool submits a URL for malware and phishing analysis across 70+ engines, distinguishing it from siblings like scan_file (file analysis) and check_scan_result (polling for results).
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 use cases ('before navigating to an unfamiliar URL or when a user forwards a suspicious link') and directs to check_scan_result for polling, but lacks explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an EVM wallet address for on-chain risk signals using GoPlus Security. Detects blacklisted addresses, contract risk flags, malicious activity, phishing associations, and other on-chain threat indicators. Returns risk_level (LOW/MEDIUM/HIGH), risk_flags list, and raw GoPlus data. Supports Ethereum mainnet (default) and other EVM chains via chain_id. Use before sending funds to an unknown address or in DeFi due-diligence flows. Pay-as-you-go: $0.10 USDC per scan (x402 on Base). Subscription: rapidapi.com/relayshield
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | EVM wallet address to scan (0x + 40 hex chars) | |
| chain_id | No | EVM chain ID (default: 1 for Ethereum mainnet). Use 8453 for Base, 137 for Polygon. | 1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses return types (risk_level, risk_flags, raw GoPlus data), supported chains, and pricing model. It does not mention destructive actions, rate limits, or auth requirements, but for a read-only scanning tool, the disclosure is adequate.
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 a single paragraph of around 90 words, front-loading the main purpose and followed by details (output, chain support, pricing). It is concise with no fluff, though it could be slightly restructured for readability.
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 tool with 2 parameters and no output schema, the description covers the main output fields (risk_level, risk_flags, raw data) and provides pricing and chain information. It is fairly complete, though it could mention any pagination or error handling.
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% with both parameters described. The description adds context by confirming 'EVM wallet address' for address and 'default Ethereum mainnet, supports other chains via chain_id' for chain_id. This reinforces but does not significantly extend beyond the schema, meriting a baseline 3.
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 (check/scan) and resource (EVM wallet address) and specifies the output (risk_level, risk_flags, raw data). It distinguishes itself from sibling tools like check_breach, scan_file, etc., which target different entities (breaches, files, URLs).
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 explicit usage context: 'Use before sending funds to an unknown address or in DeFi due-diligence flows.' It also mentions pricing and chain support. It does not explicitly state when not to use or list alternative tools among siblings, but the given guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.6check_mcp_registry_riskcheck_prompt_injection_breachv0.2.2check_infostealerscan_walletv0.2.1check_breachcheck_domain_lookalikescheck_oauth_watchlistcheck_scan_resultcheck_sim_swapscan_filescan_urlScored across 11 tools
Each tool targets a distinct risk surface (phone, email, URL/file, wallet, MCP, domains), and the async scan tools have a clear poller companion. The only real ambiguity is among check_breach, check_infostealer, and check_prompt_injection_breach, which all take an email address but are differentiated by data source.
The set follows a consistent check_/scan_ + target convention, and check_scan_result clearly pairs with scan_url/scan_file. scan_wallet and check_domain_lookalikes deviate slightly from the expected direct-check naming, but the pattern remains predictable.
Eleven tools is a reasonable size for a security-checking server covering phone, email, URLs, files, wallets, MCP servers, and domains. Each tool represents a distinct check or required polling helper, with no obvious filler.
The surface covers the main security-check workflows end to end, including async URL/file scans paired with check_scan_result. Minor gaps exist (e.g., general domain reputation checking or historical result retrieval), but they do not create dead ends for the stated purpose.
Pay-per-call cybersecurity for AI agents: vuln scans, threat intel, compliance, code security.
Security intelligence for AI agents. 27 x402 endpoints: honeypot, forensics, CAPTCHA, preflight.
Pay-per-call safety checks for AI agents: screen a crypto address or URL before you transact.
Pay-per-call safety guards for AI agents: injection, tool-call, signing, secret, x402-trust.