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 |
| 인증서 투명성(CT)을 활용한 타이포스쿼팅 및 유사 도메인 탐지 | $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개 이상 백신(AV) 엔진 대상 바이너리 악성코드 스캔(비동기) | $0.10 USDC |
|
| 무료 |
| MCP 서버 대상 타이포스쿼팅/IOC/등록 경과 기간 검사 | $0.35 USDC |
| AI 에이전트 프롬프트 인젝션 공격에서 비롯된 유출 노출 | $0.35 USDC |
| 최대 10개 공급업체 도메인의 유출/인포스틸러 노출 검사 | $0.10 USDC |
| 활성/재사용 가능한 도난 세션(쿠키/토큰) 노출 검사 | $0.30 USDC |
| 비인간 정체성(NHI) 자격 증명 노출 — 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(x402 프로토콜)에서 USDC로 검사당 비용을 지불합니다. 결제 증명과 함께 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.comURL 및 파일 스캔의 경우 Claude는 판정이 준비될 때까지 5초마다 check_scan_result를 자동으로 폴링합니다.
변수 | 설명 |
| API Gateway 기본 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.
