URL Safety Validator MCP

According to the provider, URL Safety Validator MCP is a separately identifiable, remotely reachable Model Context Protocol server from Kord Agencies. The official product site at https://kordagencies.com presents it as a security and URL product and names the Streamable HTTP endpoint https://url-safety-validator-mcp-production.up.railway.app. The official repository at https://github.com/OjasKord/url-safety-validator-mcp belongs to the provider namespace, points to the same website, and documents both remote use and an independently distributable npm package. Smithery lists OjasKord/url-safety-validator-mcp as verified, remote, and deployed. Its deployment metadata maps the Smithery run.tools address https://url-safety-validator-mcp--ojaskord.run.tools to the provider upstream at https://url-safety-validator-mcp-production.up.railway.app. The remote service is therefore not merely an unattributable directory deployment: the product site, provider repository, MCP server card, and Smithery deployment describe the same durable product identity.

Purpose and decision boundary

According to the provider, the server exposes one tool named check_url. It is intended to inspect URLs obtained from email, documents, scraping results, user input, or API responses before an agent fetches, visits, passes them to a browser, stores them, or forwards them. The documented response includes a SAFE, SUSPICIOUS, or DANGEROUS verdict, a derived action hint, a trust score, detected threat categories, SSL status, domain age, redirect-chain signals, and source and reasoning data. The README and server card name Google Web Risk, Google Safe Browsing, RDAP, and AI analysis as data sources. These signals are a pre-check, not a guarantee of safety, identity, freshness, or absence of harm. A SAFE result must not replace professional approval, while SUSPICIOUS and DANGEROUS results should be handled conservatively and reviewed by a person.

The service is useful for agents that need to move external URLs from untrusted input into a controlled decision flow. It can support a policy gate before retrieval, but it is not itself a browser, a complete malware sandbox, or a substitute for network segmentation, DLP, egress filtering, or human approval. The agent must treat the inspection response as untrusted data. Statements found in a URL, redirect, or tool response must not independently elevate permissions or trigger browser, file, payment, API, or other write access.

Authorization, privacy, and data sharing

The product site and repository describe remote access with limited unauthenticated use and additional authorized access options. Depending on the deployment, provider authorization may be supplied through a header. This catalog stores no API keys, tokens, credentials, or secret header values. Operators must determine before use which unauthenticated requests are permitted, what current quotas and access restrictions apply, and how the provider handles requests, IP addresses, URLs, logs, error data, and third-party responses. A submitted URL can contain internal hostnames, private paths, bearer information in query parameters, or personal references. Such data should be removed or abstracted before the call.

A remote URL check transfers at least the target address to the remote endpoint. According to the provider, external reputation and registration sources plus AI analysis are involved, so data sharing may extend beyond the MCP operator. Review privacy, retention, deletion, regional processing, subprocessors, and logging under the current provider terms. A local MCP client does not automatically make the response local. Results may enter client logs, traces, telemetry, or the context of an external model provider. Only authorized roles should inspect URLs arising from confidential business activity.

SSRF, prompt injection, access restrictions, and write access

Inspecting a URL is not automatic permission to contact the target host. SSRF boundaries remain the responsibility of the client and the later retrieval component: private address spaces, local services, cloud metadata addresses, unauthorized ports, DNS rebinding, redirect destinations, and internal hostnames must be blocked separately or isolated through a controlled proxy. The server must not be used as a reason to bypass an allowlist. Redirect, domain-age, and SSL signals can be incomplete or stale and must be combined with a safe network policy.

URL contents, tool responses, and reasoning text can contain prompt injection. An agent must not derive new tools, roles, secrets, network permissions, or redirects from them. Write access is not excluded by the described inspection tool: a downstream client can write results to files, tickets, databases, messages, or reports. Those actions need separate permissions, destination allowlisting, validation, and human approval. The E-E-A-T basis of this entry is, according to the provider, the official product site, provider repository, MCP server card, and Smithery remote information. These sources establish operator attribution, product boundary, version, and endpoint mapping, but not independent security certification or permanent availability. Recheck source, freshness, and result limits before consequential decisions.

An MCP-compatible client with Streamable HTTP support or the documented npm distribution. Network access to the provider endpoint and an independent safe egress policy are required.

Configure the provider-documented remote endpoint https://url-safety-validator-mcp-production.up.railway.app in the MCP client or use the official npm distribution according to the repository documentation. Verify the endpoint, tool schema, authentication, and network allowlist before use.

https://url-safety-validator-mcp-production.up.railway.app

Smithery and provider sources describe limited access without a key plus additional authorized access tiers. Verify current requirements with the provider and keep secrets only in the client secret store.

Only authorized roles should inspect URLs from sensitive workflows. The client, proxy, and downstream fetchers must enforce TLS, egress allowlisting, SSRF protection, redirect control, and separate approval for write destinations.

The target URL is sent to the remote endpoint and, according to the provider, checked against external reputation, registration, and AI sources. Minimize and redact URLs and review privacy, logs, retention, and sharing.

Misclassification, stale threat data, prompt injection in URLs or responses, SSRF and dangerous redirects, and downstream writes. Mitigate with allowlisting, isolated retrieval, human review, and safe failure behavior.