How do I use @gridinsoft/mcp-inspector?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@gridinsoft/mcp-inspector Check the domain reputation of example.com" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@gridinsoft/mcp-inspector

by gridinsoft

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

@gridinsoft/mcp-inspector

A Model Context Protocol server for domain reputation and URL analysis, powered by GridinSoft Inspector.

Requirements

Node.js 22 or newer, with npm/npx available to your MCP host.
A GridinSoft Inspector API key from your profile.

The npm package runs locally over stdio and calls the Inspector REST API over HTTPS. https://inspector.gridinsoft.com/mcp is the documentation page; /mcp/v1 is the REST bridge used by this package. Neither URL is a native remote MCP Streamable HTTP or SSE endpoint.

Related MCP server: agentminds-mcp

Connect an MCP client

Add this entry to your client's MCP server configuration:

{
  "mcpServers": {
    "gridinsoft": {
      "command": "npx",
      "args": ["-y", "@gridinsoft/mcp-inspector"],
      "env": {
        "GRIDINSOFT_API_KEY": "your_api_key_here"
      }
    }
  }
}

Use the configuration location and command transport supported by your MCP host. If it cannot find npx, supply the absolute path to your Node.js installation's npx executable.

URL scans may take up to 90 seconds. Where your client supports it, set its MCP request timeout to at least 120 seconds. The adapter's HTTP timeout defaults to 110 seconds and can be configured with GRIDINSOFT_TIMEOUT_MS (a positive integer in milliseconds). The adapter does not automatically retry requests, because a submitted scan may have already consumed credits. After a timeout, check the Inspector dashboard before submitting it again.

Tools

Tool	Input	Purpose	Credits
`inspect_domain`	`{"domain":"example.com"}`	Available reputation score, verdict, categories, and report link	3
`check_domain_safety`	`{"domain":"example.com"}`	Alias for `inspect_domain`	3
`get_domain_reputation`	`{"domain":"example.com"}`	Alias for `inspect_domain`	3
`scan_url`	`{"url":"https://example.com/login"}`	Page metadata and available security signals; additional analysis depends on the plan	10
`get_balance`	`{}`	Remaining credits and subscription status	Free

An Unknown verdict means no assessment is available; it does not mean the target is safe. Tool execution errors return isError: true, with an explanation in content. Discovery or prompt/resource failures surface as MCP errors.

Prompts and resources

check-website-safety requires the site argument (a URL or domain).
verify-domain-trust requires the domain argument.
gs://guide/threat-categories describes the security and content categories. A content category alone does not establish malware or fraud.

Example prompt arguments:

{
  "name": "check-website-safety",
  "arguments": { "site": "https://example.com" }
}

Command-line use

With GRIDINSOFT_API_KEY set in your environment:

npx -y @gridinsoft/mcp-inspector check example.com
npx -y @gridinsoft/mcp-inspector inspect example.com
npx -y @gridinsoft/mcp-inspector scan https://example.com/login
npx -y @gridinsoft/mcp-inspector --help

Commands print the JSON tool result and exit with a nonzero status on failure. Running without arguments starts the stdio MCP server when launched by a client.

Plans

New accounts receive 100 free API credits per month. See the Inspector dashboard for current plans and pricing.

Development

npm ci
npm test
npm run build
npm pack --dry-run

The tests cover MCP initialization, discovery, prompt argument forwarding, resources, tool aliases, authentication errors, HTTP failures, cancellation, timeouts, stdio framing, and CLI exit codes. An additional backend integration fixture can be run against an Inspector checkout with Composer dependencies installed:

INSPECTOR_TEST_ROOT=/absolute/path/to/inspector node --test test/php-integration.cjs

This fixture starts a temporary localhost PHP server, uses the real MCP routes/controller, and makes only public or unauthenticated requests. It does not load the application's environment file or perform paid scans.

License

MIT

Available Tools

5 tools

check_domain_safetyA

Semantic alias for inspect_domain. Quick check if a website is safe, malicious, or a scam. Returns reputation score and security verdict.

Name	Required	Description	Default
`domain`	Yes	The domain name to check (e.g., example.com)

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the behavioral burden. It partially does by naming the outputs (reputation score, security verdict), but says nothing about whether this is a read-only lookup, whether results are cached or live, latency, or auth requirements.

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 short sentences, with the most important fact (it is an alias of inspect_domain) front-loaded and no filler. Every sentence contributes either routing information or expected output.

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 read tool with no output schema, the description is barely sufficient: it names the outputs but not their shape. Given that this is a deliberate duplicate of inspect_domain alongside get_domain_reputation and scan_url, it should say more about when this alias is preferred.

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?

Only one parameter and schema description coverage is 100%, so the schema already fully documents the domain argument. The description adds nothing beyond the schema about format, normalization, URL-vs-domain handling, or subdomain behavior, which is the baseline 3 case.

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?

States a specific verb and resource (check a domain's safety) plus what the result contains (reputation score, security verdict). It also declares itself a 'semantic alias for inspect_domain', which is genuinely differentiating routing information, though it does not distinguish itself from get_domain_reputation or scan_url, which sound closely related.

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 alias note implies it is interchangeable with inspect_domain, which is a partial usage hint. There is no explicit when-to-use or when-not-to-use guidance relative to the other siblings (get_domain_reputation, scan_url), so an agent still has to guess which of the near-duplicate tools to pick.

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

get_balanceA

Check remaining API credits and subscription plan status

Name	Required	Description	Default
No parameters

TDQS

A3.8/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; 'Check' implies a safe read operation and it names the exposed data. However, it omits auth requirements, rate-limit behavior, and whether calling it itself affects credits.

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 definition is a single front-loaded sentence with no wasted words. It communicates the core purpose immediately.

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 simple zero-parameter balance check with no output schema, the description states enough about what information is retrieved. Minor missing details like auth requirements do not prevent correct invocation.

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?

There are zero input parameters, so parameter semantics are not a concern. The baseline for a no-parameter tool 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 uses a specific verb ('Check') and names the exact resources: remaining API credits and subscription plan status. Its scope is clearly distinct from the sibling domain/URL inspection tools.

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?

It states what the tool returns but gives no explicit guidance on when to call it, such as before API requests or when quota errors occur. No alternatives or exclusions are mentioned.

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

get_domain_reputationA

Semantic alias for inspect_domain. Get the trust and reputation score (0-100) for a domain.

Name	Required	Description	Default
`domain`	Yes	The domain name (e.g., example.com)

TDQS

A3.8/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 discloses the output meaning and scale (0-100), but does not state whether the operation is read-only, whether it performs an external lookup, or whether there are rate limits or auth requirements.

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 with no wasted words. The alias relationship is stated first, followed immediately by the output measure and range.

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 simple one-parameter lookup with no output schema, the description gives the essential return value and its range. It could be improved with a note on read-only behavior or lookup source, but it is largely complete for this tool's complexity.

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 has 100% schema description coverage, so the baseline is 3. The description adds no syntax, format, or validation detail beyond what the schema already 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?

The description names a specific resource (domain), a specific measure (trust and reputation score), and an output range (0-100). It also explicitly identifies itself as a semantic alias for the sibling tool inspect_domain, which helps distinguish its role.

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?

Calling itself an alias for inspect_domain implies interchangeable use, but it does not explicitly state when to choose this tool over inspect_domain or check_domain_safety. There are no exclusions or conditions given.

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

inspect_domainA

Domain reputation assessment. Returns the available reputation score (0-100), security verdict, categories, and report link. Unknown means no assessment is available, not that the domain is safe. Use this tool when users ask about site reliability, trust, or safety.

Name	Required	Description	Default
`domain`	Yes	The domain name to analyze (e.g., example.com)

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does a solid job: it discloses the return fields (score 0-100, verdict, categories, report link) and gives a genuinely important interpretation caveat that an 'Unknown' result means no assessment exists, not that the domain is safe. It omits auth requirements, rate limits, and coverage limits, so it falls short of a 5.

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?

Four short sentences, front-loaded with purpose and return values, then the critical 'Unknown' caveat, then usage. No filler and nothing redundant.

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?

With no output schema and no annotations, the description compensates well by enumerating return fields and warning about the misleading 'Unknown' value. The main missing piece is how this tool relates to its near-identical siblings, which an agent needs in order to choose correctly.

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?

There is a single required parameter with 100% schema description coverage, so the schema already documents it fully (domain name, e.g. example.com). The description adds nothing beyond that, so the baseline of 3 applies.

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 the resource and its purpose precisely: a domain reputation assessment that returns score, verdict, categories, and report link. However, it never differentiates itself from the closely-named siblings check_domain_safety and get_domain_reputation, leaving an agent unable to tell which of the three to call.

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?

"Use this tool when users ask about site reliability, trust, or safety" gives an implied usage context, but that same phrasing arguably applies equally to check_domain_safety. No exclusions, prerequisites, or explicit alternative-routing are given, which is a real gap given three near-identical siblings.

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

scan_urlA

Deep forensic URL analysis. Detects phishing, malware, and fraudulent redirects. Use this to verify specific links, login pages, or suspicious URLs. Returns page metadata and available security signals; additional analysis depends on the subscription plan.

Name	Required	Description	Default
`url`	Yes	The full URL to scan (e.g., https://example.com/login)

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does disclose useful behavior: it returns page metadata plus "available security signals," and that deeper analysis is gated by subscription plan — a real operational constraint an agent should know before promising results. It does not say whether the tool actively fetches/renders the target (a safety-relevant trait for a scanning tool) or mention rate limits, leaving some behavioral surface uncovered.

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?

Four short sentences, front-loaded with the core purpose, then usage, then return behavior. No filler, though the phrasing is terse enough that the sibling boundary could have been added at little cost.

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 one-parameter scan tool with no output schema, the description covers purpose, when to use it, what comes back, and the plan-dependent limitation. The main remaining gap is the absence of any safety/operational note about contacting the target URL, which matters for a security-scanning 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 coverage is 100% and the single parameter already documents itself with an example format. The description adds no extra meaning about the URL parameter, so the schema does the work and baseline 3 applies.

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?

States a specific verb and resource ("Deep forensic URL analysis" detecting phishing, malware, redirects), which is more precise than the name alone. It implicitly separates itself from domain-level siblings by emphasizing "specific links, login pages, or suspicious URLs," but never names inspect_domain or check_domain_safety, so the URL-vs-domain boundary is left to inference.

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?

"Use this to verify specific links, login pages, or suspicious URLs" gives a clear positive trigger for invocation. It stops short of explicit exclusions or naming the sibling to use instead when the subject is a whole domain rather than a single URL.

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.

5 tool updatesv1.0.7Oct 29, 2026
- First observedcheck_domain_safety
- First observedget_balance
- First observedget_domain_reputation
- First observedinspect_domain
- First observedscan_url

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

A3.6/5.0

Scored 2026-10-29 04:35 across 5 tools

Disambiguation2/5

Three of the five tools (inspect_domain, check_domain_safety, get_domain_reputation) perform the same operation; the descriptions admit they are 'semantic aliases' of each other, which helps an agent but doesn't remove the redundancy. Only scan_url and get_balance are genuinely distinct actions.

Naming Consistency5/5

All names follow a clean snake_case verb_noun pattern (inspect_domain, check_domain_safety, get_domain_reputation, scan_url, get_balance) with no mixing of conventions.

Tool Count3/5

Five tools is a reasonable raw count, but two of them are pure aliases, leaving an effective surface of three operations — thin for the advertised scope and inflated by duplication.

Completeness4/5

The core workflow is covered: domain reputation lookup, deep URL/link forensics, and credit/plan status. Minor gaps exist (no batch/bulk domain or IP reputation check, no way to distinguish plan-limited results beyond a text note), but agents can work around them.

Resources

Related MCP Connectors

sentrysurface
io.github.sentrysurface
Cybersecurity MCP server for URL scanning, threat intelligence, and domain reputation.
Security Penetration Testing
2
https://api.sentrysurface.io/mcp/mcp
Agent SafeA
io.github.wowcool
Email safety MCP server. Detects phishing, prompt injection, CEO fraud for AI agents.
Security Autonomous Agents
2
https://agentsafe.locationledger.com/mcp
secureflows-mcpA
io.github.michal-lefler
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
Code Analysis Developer Tools Security
181
https://www.secure-flows.com/mcp
ScanMalware.com URL ScannerB
com.scanmalware.mcp
MCP server for ScanMalware.com URL scanning, malware detection, and analysis.
Security Web Scraping App Automation
12821
https://mcp.scanmalware.com/mcp

Related MCP Servers

truth-anchor-agent
Search Blockchain
cristiano-c1
A
license
Not graded
quality
D
maintenance
An MCP server that provides fact-checking capabilities and truth anchoring for AI agents using verified data sources.
Updated 7 months ago (2026-04-02 20:46 UTC)
MIT
agentminds-mcpofficial
Web Scraping Penetration Testing
agentmindsdev
A
license
A
quality
D
maintenance
MCP server for AgentMinds collective intelligence platform, enabling AI agents to scan websites for security/SEO/performance issues, pull personalized recommendations, and share findings across the network.
Updated 4 months ago (2026-06-29 09:47 UTC)
7
25 npm
MIT
InjectShield
Security AI & Machine Learning
bch1212
A
license
Not graded
quality
C
maintenance
MCP server that provides tools to scan text and URLs for prompt injection attacks, protecting AI agents from adversarial inputs.
Updated 5 months ago (2026-06-06 12:39 UTC)
1
MIT
domainintel-mcp
Networking & Infrastructure Security
Bishop81
A
license
A
quality
D
maintenance
An MCP server for domain intelligence — WHOIS, DNS records, SSL certificate inspection, SPF/DMARC validation, security-header audits, and blacklist/reputation checks, callable by AI agents. Powered by domainintel.app; runs server-side, no local setup.
Updated 3 months ago (2026-07-24 18:12 UTC)
7
49 npm
MIT

@gridinsoft/mcp-inspector

Requirements

Connect an MCP client

Tools

Prompts and resources

Command-line use

Plans

Development

License

Available Tools

Tool Schema Changelog

Resources

Related MCP Connectors

Related MCP Servers

agentminds-mcpofficial