Skip to main content
Glama
benjaminsamson0210

nexusgrid-mcp

by benjaminsamson0210
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

NexusGrid Unified MCP Server (nexusgrid-mcp)

npm version License: MIT

Official Model Context Protocol (MCP) server providing AI coding agents and LLMs with instant web scraping, email deliverability auditing, and signup fraud verification tools.

Engineered for Claude Desktop, Cursor, Windsurf, Zed, and LangChain.

⚡ Available Tools

Tool Name

Description

Source API

nexus_scrape

Fetches any URL and extracts clean, LLM-optimized Markdown while stripping ads, cookie banners, navigation, and clutter.

NexusScrape API

email_deliverability_audit

Full audit of SPF, DKIM, DMARC, BIMI, MTA-STS, and RFC 7208 lookup cap depth. Verifies Google/Yahoo 2024 compliance.

MailAuthGuard API

verify_email_risk

Instant disposable email detection, fraud scoring, and MX deliverability check for any email address.

FraudShield API

Related MCP server: multi-scraper-mcp

🚀 Quickstart

Run directly without installing via npx:

npx nexusgrid-mcp

Or install globally:

npm install -g nexusgrid-mcp

🛠️ Configuration

1. Claude Desktop

Add this to your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "nexusgrid": {
      "command": "npx",
      "args": ["-y", "nexusgrid-mcp"]
    }
  }
}

2. Cursor IDE

In Cursor Settings -> Features -> MCP Servers -> Add New MCP Server:

  • Name: nexusgrid

  • Type: command

  • Command: npx -y nexusgrid-mcp

3. Optional: RapidAPI Pro Key (For High-Volume Quotas)

By default, the server includes community rate limits. If you have a RapidAPI Pro key for unlimited requests across the NexusGrid suite, pass RAPIDAPI_KEY:

{
  "mcpServers": {
    "nexusgrid": {
      "command": "npx",
      "args": ["-y", "nexusgrid-mcp"],
      "env": {
        "RAPIDAPI_KEY": "your-rapidapi-key-here"
      }
    }
  }
}

📖 Tool Usage & Schema

1. nexus_scrape

Converts any web article or documentation into clean Markdown.

{
  "url": "https://example.com/blog/my-post",
  "include_images": false,
  "only_main": true
}

2. email_deliverability_audit

Runs comprehensive RFC-compliant email health audits.

{
  "domain": "stripe.com",
  "dkim_selector": "google"
}

3. verify_email_risk

Detects throwaway and disposable emails in signups or outreach lists.

{
  "email": "user@tempmail.com"
}

📄 License

MIT License © 2026 NexusGrid

Available Tools

3 tools
email_deliverability_auditB

Comprehensive email deliverability, DNS, SPF, DKIM, DMARC, BIMI, and MTA-STS audit for any domain. Calculates RFC 7208 lookup cap and Google/Yahoo 2024 bulk sender compliance. Powered by MailAuthGuard.

ParametersJSON Schema
NameRequiredDescriptionDefault
domainYesThe domain name to audit (e.g. stripe.com, substack.com, or company.com).
dkim_selectorNoDKIM selector to verify (default: google).

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It implies a non-mutating audit and discloses the check coverage, but says nothing about authentication requirements, rate limits, runtime, or whether the operation touches live DNS. The 'comprehensive' framing adds context but not operational detail.

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 dense sentences front-load the capability and scope, with compliance context appended. The 'Powered by MailAuthGuard' tagline is mild marketing filler that does not earn its place, keeping it short of a 5.

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?

For a two-parameter read tool it covers what is checked, but with no output schema and no annotations the description should explain what the audit returns (pass/fail per record, scores, remediation hints). That gap leaves it merely adequate.

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%, so both parameters (domain, dkim_selector with its default) are fully documented in the schema. The description adds no parameter-level detail beyond restating that DNS/DKIM are checked, so the 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?

States a specific verb (audit) and resource (email deliverability/DNS/SPF/DKIM/DMARC/BIMI/MTA-STS) scoped to any domain. This is clearly distinguishable from nexus_scrape (scraping) and verify_email_risk (single-address risk).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Mentions the RFC 7208 lookup cap and Google/Yahoo 2024 bulk sender compliance as coverage areas, which hints at a use case, but gives no explicit when-to-use guidance or when to prefer a sibling like verify_email_risk. No prerequisites or exclusions are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

nexus_scrapeB

Fetch any webpage URL and extract clean, LLM-optimized Markdown while stripping ads, cookie banners, navigation, and clutter. Powered by NexusScrape.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe target webpage URL to scrape and convert to markdown.
only_mainNoWhether to isolate only main article content (default: true).
include_imagesNoWhether to retain markdown images in output (default: false).

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It usefully discloses what gets stripped (ads, cookie banners, navigation, clutter) and that output is markdown, but says nothing about authentication, rate limits, JS-rendered pages, timeouts, or failure behavior.

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, front-loaded with the core action and effect. The trailing 'Powered by NexusScrape.' branding adds no operational value but is a minor tax.

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?

For a simple three-parameter scraping tool with no output schema and no annotations, the description covers the essential what and the stripping behavior, but omits failure modes and return characteristics an agent would want before invoking 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?

Schema description coverage is 100%, so all three parameters are already documented. The description adds no syntax, format, or defaulting detail beyond what the schema provides, making the 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?

States a specific verb ('Fetch') and resource ('any webpage URL') and the concrete transformation applied ('extract clean, LLM-optimized Markdown'). The task is unambiguous and cannot be confused with the unrelated email-related siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description never states when to use this tool versus alternatives, nor any prerequisites or exclusions. There is only an implied 'give it a URL' usage, with no guidance on scenarios where it would fail or be inappropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_email_riskB

Instant fraud score, disposable temporary mailbox detection, and deliverability risk check for any email address. Powered by FraudShield.

ParametersJSON Schema
NameRequiredDescriptionDefault
emailYesThe email address to evaluate (e.g. user@tempmail.com).

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full disclosure burden. It usefully tells the agent this is an instant, single-call evaluation returning a fraud score plus two boolean-style signals, but it omits permission/auth requirements, behavior on malformed or unknown addresses, rate limits, and whether results are cached or live. Adequate but not rich for a zero-annotation tool.

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 tightly written sentences with the outcome types front-loaded. 'Powered by FraudShield' is marketing filler that adds no invocation value, but it costs only four words.

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?

For a one-parameter, no-annotation, no-output-schema tool, the description covers what signals come back but not their shape, range, or interpretation (e.g. score scale). An agent can call it correctly but cannot interpret the response without experimentation.

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 description coverage is 100%: the single 'email' parameter is fully documented in the schema, including an example. The description adds no format or syntax guidance beyond that, so the schema does the heavy lifting and a baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete resource (email address) and enumerates what the tool returns: fraud score, disposable/temporary mailbox detection, and deliverability risk. That is clear and specific. However, it does not differentiate itself from the sibling email_deliverability_audit, which covers overlapping deliverability territory, so the agent cannot tell the two apart from the text alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus the sibling email_deliverability_audit, no prerequisites, and no mention of when it should not be used. The agent must infer that this is a single-value risk lookup based on the name and enum-free single parameter.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.0.0
    • First observedemail_deliverability_audit
    • First observednexus_scrape
    • First observedverify_email_risk
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 3 tools

Disambiguation4/5

The three tools target distinct operations: web scraping, domain-level email deliverability auditing, and individual email risk verification. The two email tools could be momentarily confused, but their descriptions clearly separate domain audit from address-level fraud check.

Naming Consistency3/5

All names use snake_case, but the pattern is inconsistent: nexus_scrape uses a brand prefix and verb, email_deliverability_audit is a noun phrase, and verify_email_risk is a verb phrase. It is readable but not predictable.

Tool Count4/5

Three tools is on the low end, but each represents a substantial standalone utility rather than a trivial operation. For a small multi-utility server, the count is reasonable, though a 'grid' name suggests more breadth could be expected.

Completeness4/5

The email surface covers both domain-level deliverability (DNS, SPF, DKIM, etc.) and address-level risk, while scraping is handled in one comprehensive tool. Minor gaps exist, such as bulk operations or multi-page crawling, but core functions are covered.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • multi-scraper-mcp

    Perufitlife
    A
    license
    Not graded
    quality
    C
    maintenance
    Enables lead generation and web scraping through 16 MCP tools, allowing AI clients like Claude, Cursor, and Windsurf to perform scraping tasks via natural language.
    21 npm
    MIT

  • @agentlair/mcp

    piiiico
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI agents to register, send/receive email, store encrypted credentials, emit audit events, and query behavioral trust scores via MCP tools.
    0
    5
    MIT
  • @crawlbrulee/mcp by crawlbrulee

    @crawlbrulee/mcpofficial

    crawlbrulee
    A
    license
    A
    quality
    A
    maintenance
    Enables MCP-aware AI agents to scrape web pages into markdown, screenshots, metadata, and links, map sites, run asynchronous scrape jobs, and check usage, with EU-hosted, GDPR-aligned processing.
    7
    650 npm
    Apache 2.0