URL Safety Validator MCP

check_url

Checks a URL for phishing, malware, typosquatting, and redirect threats. Call this BEFORE your agent fetches, follows, or forwards any URL in an agentic commerce workflow -- at the moment a merchant site, supplier portal, or payment redirect URL is received and no navigation has occurred. Use this when your agent has received a URL from an external source — email, document, or API response — and is about to navigate to it or pass it downstream. Checks live against Google Web Risk (webrisk.googleapis.com) and Google Safe Browsing (safebrowsing.googleapis.com). Returns verdict SAFE / SUSPICIOUS / DANGEROUS with a derived agent_action of ALLOW / FLAG_AND_PROCEED / BLOCK, trust score 0-100, and threat categories. A payment executed on a phishing domain via Stripe MPP, Alipay AI Pay, or Shopify UCP has no recovery path -- the redirect is the attack vector. A DANGEROUS verdict means halt immediately. Returns machine-ready verdict, no further analysis needed.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL to check. Full URL preferred (e.g. https://example.com/path). Bare domains also accepted.

Output Schema

TableJSON Schema

Name	Required	Description
`url`	Yes
`verdict`	Yes
`hostname`	Yes
`reasoning`	No
`ssl_valid`	No
`checked_at`	Yes
`source_url`	No
`_disclaimer`	Yes
`hold_reason`	No	Present only when verdict is SUSPICIOUS
`retry_after`	No
`trust_score`	Yes
`agent_action`	Yes	Derived directly from verdict
`ai_confidence`	No
`analysis_type`	No
`domain_age_days`	No
`escalation_path`	No	Present only when verdict is SUSPICIOUS
`database_signals`	No
`domain_registered`	No
`threat_categories`	No
`redirect_chain_detected`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedJun 24, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "_disclaimer": {
+      "type": "string"
+    },
+    "agent_action": {
+      "description": "Derived directly from verdict",
+      "enum": [
+        "ALLOW",
+        "FLAG_AND_PROCEED",
+        "BLOCK"
+      ],
+      "type": "string"
+    },
+    "ai_confidence": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "analysis_type": {
+      "type": "string"
+    },
+    "checked_at": {
+      "format": "date-time",
+      "type": "string"
+    },
+    "database_signals": {
+      "type": "object"
+    },
+    "domain_age_days": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "domain_registered": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "escalation_path": {
+      "description": "Present only when verdict is SUSPICIOUS",
+      "type": "string"
+    },
+    "hold_reason": {
+      "description": "Present only when verdict is SUSPICIOUS",
+      "type": "string"
+    },
+    "hostname": {
+      "type": "string"
+    },
+    "reasoning": {
+      "type": "string"
+    },
+    "redirect_chain_detected": {
+      "type": "boolean"
+    },
+    "retry_after": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "source_url": {
+      "type": "string"
+    },
+    "ssl_valid": {
+      "type": "boolean"
+    },
+    "threat_categories": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "trust_score": {
+      "maximum": 100,
+      "minimum": 0,
+      "type": "number"
+    },
+    "url": {
+      "type": "string"
+    },
+    "verdict": {
+      "enum": [
+        "SAFE",
+        "SUSPICIOUS",
+        "DANGEROUS"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "url",
+    "hostname",
+    "verdict",
+    "agent_action",
+    "trust_score",
+    "checked_at",
+    "_disclaimer"
+  ],
+  "type": "object"
+}

First observedApr 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full transparency burden. It discloses live checks against Google Web Risk and Safe Browsing, specifies the return contract (verdict, agent_action, trust score, threat categories), and instructs halting on DANGEROUS. This is thorough and non-misleading for a read-only security check.

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 front-loaded with the core purpose and uses a clear progression from what → when → how → output. It is slightly verbose with overlapping 'before' usage guidance, but each sentence provides useful operational context for a security-sensitive tool.

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 that an output schema exists, the description need not detail the return structure, yet it still summarizes verdicts, action, and trust score. It covers when, why, what, and the operational safety rule, making it complete for agent selection and invocation.

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 provides 100% coverage for the single URL parameter, including preference for full URLs. The description adds no additional parameter-level semantics beyond the schema, so the 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 opens with a specific verb 'Checks' and explicitly enumerates the threat types (phishing, malware, typosquatting, redirect threats). It clearly identifies the tool's function and is unambiguous even without sibling tool comparison.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: before fetching, following, or forwarding any URL in an agentic commerce workflow, with concrete trigger contexts (email, document, API response). It also implies when not to use (after navigation) and emphasizes the urgency with a recovery-path rationale.

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

All URL Safety Validator MCP tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

With only one tool, there is no ambiguity. The tool's purpose is clearly distinct from any other.

Naming Consistency5/5

Naming consistency is trivial with a single tool; 'check_url' follows a clear verb_noun pattern.

Tool Count4/5

A single tool for URL safety validation is slightly under but reasonable given the comprehensive nature of the tool's checks.

Completeness5/5

The tool covers all major URL threats (phishing, malware, typosquatting, redirects) and provides actionable verdicts, leaving no obvious gaps.

check_url

Input Schema

Output Schema

Schema Changelog

TDQS

Glama MCP Gateway

TDQS

Resources