relayshield-mcp

Official

by relayshield

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.6
Disambiguation5/5
Each tool has a distinct, non-overlapping purpose: breach checking, domain lookalikes, OAuth watchlist, SIM swap, file/URL scanning, and polling for results. No two tools could be confused for the same action.
Naming Consistency4/5
Most tools follow a 'check_' prefix pattern, while 'scan_file' and 'scan_url' use 'scan_' for submission actions. 'check_scan_result' mixes both but remains clear. The pattern is mostly consistent with verb_noun, though two verbs are used.
Tool Count5/5
Seven tools is ideal for a security-focused server: it covers email breaches, domain impersonation, OAuth monitoring, SIM swap detection, and malware scanning without being bloated or too sparse.
Completeness5/5
The tool set covers the full lifecycle of common security checks: detection (breach, lookalikes, OAuth, SIM), submission (scan_file, scan_url), and result retrieval (check_scan_result). No obvious gaps for the stated domain.
Average 4.2/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on August 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![relayshield-mcp MCP server](https://glama.ai/mcp/servers/relayshield/relayshield-mcp/badges/card.svg)](https://glama.ai/mcp/servers/relayshield/relayshield-mcp)

Score Badge

Copy to your README.md:

[![relayshield-mcp MCP server](https://glama.ai/mcp/servers/relayshield/relayshield-mcp/badges/score.svg)](https://glama.ai/mcp/servers/relayshield/relayshield-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/relayshield/relayshield-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server