nexargio-mcp

Overview Schema Source Related Servers Discussions Admin

nexargio_scan

Scan URLs, bare domains, or QR code images for phishing, credential harvesting, brand impersonation, and weaponized infrastructure. Returns a threat score, verdict, and NIST-sealed evidence.

Instructions

Scans a web URL, bare domain, or QR code image for phishing, credential
harvesting, brand impersonation, and weaponized infrastructure.

Accepts:
  - Full URL (e.g. 'https://login.microsoftonline.portal-security-check.com/auth')
  - Bare Domain (e.g. 'portal-security-check.com')
  - Local QR Code Image Path (e.g. 'C:/downloads/invoice_qr.png')
  - Remote QR Code Image URL (e.g. 'https://example.com/assets/invoice_qr.png')
  - Base64-encoded QR Image String

Scan Modes (Both 100% AI-Powered):
  - 'fast' (Default): Nexargio Autonomous AI Brain (Deep Cognitive System-Two reasoning).
    Returns deep contextual reasoning, brand impersonation detection, and plain-language explanation.
  - 'ultra_fast': Nexargio Normal Engine (Fast Neural System-One LPU).
    Returns instantaneous wire-speed score (0-100), verdict, and action policy (wire-speed execution).

Returns:
  - Verdict (WEAPONIZED_ATTACK, BENIGN_AMBIENT, etc.)
  - Threat Score (0-100) and Action Policy (HARD_BLOCK, ALLOW)
  - Targeted Brand impersonation attribution
  - Plain-language forensic explanation
  - RFC 3161 NIST SHA-256 evidence seal

If a scan cannot be completed, the result's verdict is SCAN_INCOMPLETE with
action_policy ERROR_REVIEW_REQUIRED -- it must NOT be treated as safe.

Args:
    target: The URL, domain, or QR image file path / remote URL to scan.
    scan_mode: Execution mode ('fast' for Deep Cognitive AI analysis, 'ultra_fast' for Wire-Speed Neural LPU triage).

Input Schema

Name	Required	Description	Default
`target`	Yes
`scan_mode`	No		fast

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 22, 2026

TDQS

A4.2/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 well: it discloses both execution modes and their tradeoffs, enumerates return artifacts (verdict, score, action policy, evidence seal), and explicitly warns that SCAN_INCOMPLETE/ERROR_REVIEW_REQUIRED must not be read as safe. It omits auth/permission needs, rate limits, and whether scanning submits data externally.

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?

Well front-loaded and scannable with input/mode/return sections, and every section is relevant. It loses a point for marketing jargon ('Deep Cognitive System-Two reasoning', 'System-One LPU') and repeated 'wire-speed' phrasing that adds length without decision value.

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?

An output schema exists, yet the description still sketches verdicts, scores and the evidence seal, and it covers the failure state an agent most needs to know. Missing only operational context (permissions, quotas, latency expectations) and any relationship to the sibling tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate and does: it enumerates the five accepted forms of 'target' with examples and defines the two legal values of scan_mode with their behavioral meaning and the default. This is meaning the bare schema ('type: string') cannot supply.

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?

Specific verb (scans) plus the exact resource classes (URL, bare domain, QR image) and the threat categories targeted (phishing, credential harvesting, brand impersonation). It never names or contrasts the sibling tools nexargio_disarm_carrier or nexargio_audit_action, so it stops short of the sibling-differentiation bar for a 5.

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?

Gives concrete accepted-input examples for every target form and explains when to pick each scan mode ('fast' default for deep reasoning vs 'ultra_fast' for wire-speed triage). It also states the SCAN_INCOMPLETE handling rule, but offers no when-not-to-use guidance or routing to the sibling tools.

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

Deploy Server