mcp-name: io.github.nzdsf2-gif/relayshield-mcp
RelayShield 安全情报以 MCP 服务器形式提供——将泄露检测、SIM 卡更换检测、域名仿冒监控、OAuth 供应链监控列表以及 URL/文件扫描直接接入 Claude 和任何兼容 MCP 的 AI 智能体。
工具 | 功能说明 | 按量付费价格 |
| 邮箱泄露查询——通过 HIBP 覆盖 130 亿+条记录 | $0.10 USDC |
| 通过实时运营商数据进行 SIM 卡更换/eSIM 检测 | $0.25 USDC |
| 利用证书透明度进行域名仿冒/近似域名检测 | $0.50 USDC |
| 通过 HIBP + 窃密日志语料库检测 OAuth 应用泄露和被盗令牌暴露 | $0.30 USDC |
| 通过 Hudson Rock Cavalier 查询信息窃取恶意软件日志 | $0.15 USDC |
| 通过 GoPlus Security 进行 EVM 钱包链上风险检查 | $0.10 USDC |
| 跨 70+ 引擎的 URL 恶意软件/钓鱼扫描（异步） | $0.05 USDC |
| 跨 70+ 杀毒引擎的二进制恶意软件扫描（异步） | $0.10 USDC |
| 在 | 免费 |
| 针对 MCP 服务器的域名仿冒/IOC/注册时长检查 | $0.35 USDC |
| 源自 AI 智能体提示注入攻击的泄露暴露 | $0.35 USDC |
| 最多检查 10 个供应商域名的泄露/信息窃取暴露 | $0.10 USDC |
| 活跃/可重用的被盗会话（cookie/令牌）暴露检查 | $0.30 USDC |
| 非人类身份凭据暴露——API 密钥、服务令牌、PAT | $0.40 USDC |
| 公开 GitHub 仓库中暴露的机密信息 | $0.35 USDC |
check_oauth_watchlist、check_supply_chain、check_session_risk、check_nhi_exposure 和 check_secret_scan 覆盖了相关领域——连接应用、会话和机器凭据在某个身份或其供应链中的暴露情况——是在审查智能体当前权限（而不仅仅是登录状态）时自然适合一起使用的一组工具。
Related MCP server: Nullcone MCP Server
订阅模式 — 从 api.relayshield.net/developers 获取 API 密钥。全部 15 个工具可用。免费层：每月 100 次调用。付费层每月 $29 起。
按量付费模式 — 无需 API 密钥。通过 Base 上的 USDC（x402 协议）按次付费。使用你的支付证明设置 RELAYSHIELD_X_PAYMENT。全部 15 个工具可用（每次检查 $0.05–$0.50，check_scan_result 免费）。在未设置支付方式的情况下调用工具，将收到定价和支付说明。
发现模式 — 既不设置密钥也不设置支付。工具调用将返回支付要求和订阅链接。
pip install relayshield-mcp或者不安装直接运行：
uvx relayshield-mcp编辑 ~/Library/Application Support/Claude/claude_desktop_config.json（macOS）或 %APPDATA%\Claude\claude_desktop_config.json（Windows）：
订阅模式（RelayShield API 密钥）：
{
"mcpServers": {
"relayshield": {
"command": "relayshield-mcp",
"env": {
"RELAYSHIELD_API_URL": "https://api.relayshield.net",
"RELAYSHIELD_API_KEY": "your-relayshield-api-key-here"
}
}
}
}按量付费模式（Base 上的 x402 USDC）：
{
"mcpServers": {
"relayshield": {
"command": "relayshield-mcp",
"env": {
"RELAYSHIELD_API_URL": "https://api.relayshield.net",
"RELAYSHIELD_X_PAYMENT": "your-x402-payment-proof-here"
}
}
}
}编辑后退出并重新启动 Claude Desktop。
claude mcp add relayshield \
--command relayshield-mcp \
--env RELAYSHIELD_API_URL=https://api.relayshield.net \
--env RELAYSHIELD_API_KEY=your-relayshield-api-key-here配置完成后，让 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.com对于 URL 和文件扫描，Claude 会自动每 5 秒轮询一次 check_scan_result，直到判定结果就绪。
变量 | 说明 |
| API 网关基础 URL（必填） |
| RelayShield 订阅密钥（订阅模式）——在 api.relayshield.net/developers 获取 |
| x402 支付证明——Base 上的 USDC（按量付费模式） |
设置 RELAYSHIELD_API_KEY 或 RELAYSHIELD_X_PAYMENT——不要同时设置两者。如果两者都设置了，API 密钥优先。
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.
OT/ICS threat intel for AI agents: 40 tools, pay per call in USDC on Base via x402.
Pay-per-call safety checks for AI agents: screen a crypto address or URL before you transact.
