Skip to main content
Glama
overdoingism

URLVerify_MCP

by overdoingism
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

URLVerify_MCP

An MCP server that tells an AI agent whether a download, install command, repository or model is the project's official channel, before the agent fetches or runs it.

一個 MCP server：在 AI agent 下載或執行任何東西之前，判斷這個下載網址、安裝指令、 程式碼倉庫或模型，是不是該專案的官方管道。

  • Input / 輸入: the project name and exactly what will be used: a URL or one install command (pip install requests, winget install --id Docker.DockerDesktop, curl … | sh). 專案名稱，加上實際要用的東西：一個網址或一條安裝指令。

  • Output / 輸出: VERIFIED_TRUE · VERIFIED_FALSE · UNVERIFIABLE, a confidence score, and a next_action the agent follows (PROCEED · INFORM_USER_AND_CONFIRM · DO_NOT_PROCEED · FIX_INPUT_AND_RETRY). 三種判定、信心分數，以及 agent 應遵循的下一步。

  • It checks who publishes a source, not whether the file is safe: no download, no hash or malware scan. 它判斷的是「誰發佈的」，不是檔案是否安全：不下載檔案、不驗雜湊、不掃毒。

Quick start / 快速開始: English · 繁體中文

How it works

  1. Deterministic checks (no LLM): TLS, DNS (with a DNS-over-HTTPS cross-check), redirects, look-alike domains, Certificate Transparency, hosting-platform owners, allow / deny lists, prompt-injection screening of the target page.

  2. Fixed lookups (no LLM): Wikidata / Wikipedia, platform and registry records (GitHub, Hugging Face, PyPI, npm, NuGet, Flathub, SourceForge, Homebrew …), and the official site's own pages where needed.

  3. LLM investigation, only for the identity links still missing after step 2 (aliases, renames, product ↔ company). Structured records are cited by fact id; web pages need verbatim quotes.

  4. Rules engine decides: it verifies every quote, counts independent sources and matches the target against the established identity. The LLM proposes, the rules decide. When step 2 already decides, the LLM is never started.

Related MCP server: c2pa-mcp

The verify_source tool

verify_source(project, source, artifact="", description="", version="", options=None) -> YAML

Argument

Meaning

project

Product name only (LM Studio, requests).

source

Exactly what will be used: a URL or ONE install / download command. A bare name is rejected.

artifact

The form: Windows x64 installer, Python package, Docker image, install script.

description

What it is for. Give artifact or description, preferably both.

version

Optional exact version; empty = the registry's default.

options

Optional: mode (auto · fast = no LLM · quick · full), origin (distribution packages, see below).

The reply is YAML. machine_readable comes first and is the only part to act on; everything after it may quote untrusted web pages, and verdict words inside it are neutralised.

machine_readable:
  schema_version: 2
  verdict: VERIFIED_TRUE        # worst subject wins
  next_action: PROCEED
  confidence: 0.9
  codes: []                     # why it is not TRUE / what blocked it
  notices: []                   # conditions to tell the user about (e.g. OFFICIAL_DOWNLOAD_HOST, WIKIMEDIA_ONLY)
  subjects: [...]               # one per package / URL
summary: ...                    # fixed sentences in the caller's language
explanation: ...                # the LLM's prose
details: ...                    # evidence, checks, identity, notes

What source accepts

Verified

Commands / notes

URL

any https://…

PyPI

pip, python -m pip, uv pip/add/tool, uvx, pipx, poetry add, pdm add, pipenv install

npm

npm i/install/add, yarn add, pnpm add, bun add, npx, pnpm dlx, bunx (aliases resolved)

NuGet

dotnet add package, dotnet tool install, nuget install, Install-Package

WinGet

winget install --id <Id>: the installer URL from the winget-pkgs manifest is verified

git

git clone, gh repo clone

Hugging Face

hf download, huggingface-cli download

Containers

docker / podman / nerdctl pull / run on Docker Hub and ghcr.io

Homebrew

brew install [--cask] (official taps)

Scoop

scoop install [bucket/]<app> (official ScoopInstaller buckets)

Flatpak

flatpak install [flathub] <app-id>; apps not verified by their developer stay UNVERIFIABLE

Go

go install / go get <module>@<version>

apt / dnf / pacman / zypper / apk

pass the package manager's origin report in options.origin (LC_ALL=C apt-cache policy <pkg>, dnf info, pacman -Si, zypper info + zypper lr -u, apk policy)

Snap

snap install <name>: a publisher verified by the Snap Store is established through its website; --classic is reported

Composer

composer [global] require vendor/package[:version]: the source repository Packagist names is verified

Scripts

curl … | sh, irm … | iex and similar: the script URL is verified, not what it downloads next

Parsed but not verified yet (ECOSYSTEM_NOT_YET_VERIFIED): cargo, gem, choco, conda, AUR, ollama, Install-Module, msstore, other container registries. Always rejected: lock / requirement files, local paths, extra indexes, chained commands (&&, ;). Unknown flags are reported, never ignored.

Trust rules in brief

  • An official domain or account needs two independent source families (Wikimedia counts as one; all domains of one hosting platform count as one).

  • Self-published projects (a personal GitHub / Hugging Face account, nothing else) are checked for consistency across platforms only: TRUE is capped at 0.75.

  • Mirrors, CDNs and SourceForge: accepted only when the established official site links that exact file (or the SourceForge project, which links back) or redirects to the same file; TRUE capped at 0.8 with OFFICIAL_DOWNLOAD_HOST (compare the published checksum). SourceForge's automatic mirrors are SOURCEFORGE_MIRROR.

  • Old, widely read Wikimedia records may establish a domain alone (value unchanged since a random point 18–30 months ago, ≥ 2000 page views every month); lowest-confidence path, capped at 0.6 with WIKIMEDIA_ONLY.

  • Packages with signed build provenance from an established GitHub organisation take a fast path; packages without it need independent evidence like any website. A recently published version carries RELEASE_COOLDOWN_* (release_cooldown.hours, default 72).

  • Known malware: a package OSV.dev lists as malware in every version is VERIFIED_FALSE; if only the version to be installed is a listed malicious release of an official package, the verdict stands but next_action is DO_NOT_PROCEED. PyPI quarantine is DO_NOT_PROCEED too.

  • A URL whose host does not exist is UNVERIFIABLE with TARGET_DOMAIN_DOES_NOT_EXIST (FIX_INPUT_AND_RETRY).

  • Shared hosting: each customer of a shared host (x.readthedocs.io, x.netlify.app, x.github.io …) is its own domain (Public Suffix List, private section included); the provider's domain is never anyone's official domain.

  • UNVERIFIABLE means "not enough independent evidence", not "dangerous".

Every threshold is configurable; see document_for_config.md.

Security and privacy

  • Network targets: private, loopback and link-local addresses (and redirects to them) are refused.

  • TLS interception / DNS poisoning: the leaf certificate must be logged in Certificate Transparency, and the host is resolved again over DNS-over-HTTPS.

  • Admin UI: password login (default admin; change it in the UI). Keep it on 127.0.0.1.

  • HTTP transport: set server.auth_token to require Authorization: Bearer <token>; default bind 127.0.0.1.

  • What leaves your machine: project names, URLs and host names go to the public services that are looked up (Wikimedia, archive.org, crt.sh, DoH resolvers, GitHub, Hugging Face, package registries, OSV.dev, Flathub, SourceForge, Homebrew, your SearXNG, and Reddit / HN / Stack Exchange for dating forum posts). Page text and the investigator's messages go to the LLM endpoint you configure. No telemetry.

  • Footprint: documents only (no images, scripts or files under verification), per-run request budgets, caches for certificates and identities, JSON APIs instead of scraping.

Files

config.yaml   machine-specific settings (git-ignored)
state/        caches, admin password hash, edited prompts (rebuildable)
log/          history (one JSON per verification), dependency health, process logs

Nothing is written outside the project folder; there is no database.

Tests

Suite

Command

Needs

Unit + replay

uv run pytest -q

nothing (a few network tests skip when offline)

Live regression

uv run pytest tests/test_live.py --live -s

LLM, search, network; tens of minutes

Docs

MIT License, see LICENSE.

Available Tools

3 tools
get_verificationC

Fetch a previous verification result by trace_id.

ParametersJSON Schema
NameRequiredDescriptionDefault
trace_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It only states it fetches a result, but does not indicate whether this is read-only, requires authentication, has rate limits, or what happens if the trace_id is unknown. The existence of an output schema partially covers return format, but the description adds minimal behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is concise, but it is under-specified. It does not waste words, but it also does not earn its place with any extra guidance beyond the name. It is adequate but not informative.

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?

Given the tool's low complexity (one parameter) and the presence of an output schema, the description covers the basic action. However, it lacks any mention of usage context, error conditions, or relationship to sibling tools, making it incomplete for an agent to infer correct invocation in varied scenarios.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must explain the parameter. It mentions 'by trace_id' which implies the parameter identifies the verification, but offers no detail on format, origin, or constraints beyond the schema's basic string type. This is minimal added value.

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 clear verb ('fetch') and resource ('verification result') plus the key parameter (trace_id). It implies the tool retrieves a previously created verification, which distinguishes it from sibling 'verify_source' that likely creates one, though it does not explicitly name the sibling.

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?

No guidance on when to use this tool versus siblings, no context on prerequisites (e.g., must have a trace_id from a prior verification), and no exclusions. The description leaves the agent to infer usage solely from the tool name and parameter.

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

list_known_identitiesA

List cached, independently-established project identities (official domains / orgs).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden. It discloses that this is a non-mutating list operation and that results are cached and independently established, which helps set expectations about freshness and trustworthiness. It does not discuss staleness or caching semantics in depth, but for a zero-parameter listing tool the provided context is reasonably transparent.

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 description is a single, front-loaded sentence that provides the key qualifiers ('cached', 'independently-established', 'official domains / orgs') without any filler. Every word adds meaning relevant to tool selection.

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 the tool has no parametersasi, an output schema exists, and the operation is a simple read-only list, the description provides sufficient context. It explains the source and nature of the identities while leaving return-value details to the output schema.

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?

The tool has zero parameters, so there is nothing for the description to document beyond what the schema already reflects. The baseline of 4 applies because no parameter semantics are needed.

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 ('List') and resource ('cached, independently-established project identities'), with an explicit parenthetical scope ('official domains / orgs'). This clearly distinguishes the tool from siblings like verify_source and get_verification, which focus on verification rather than enumeration.

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 description implies usage when you need already-known or cached identities rather than live verification, but it does not explicitly state when to prefer this tool over verify_source or get_verification. There is no exclusion guidance or alternative routing, so the usage context is inferred rather than explicit.

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

verify_sourceA

Verify that url is an official / legitimate source for project.

Args: project: project / product name, e.g. "LM Studio". url: the download, installer, repository, model or data-source URL to check. description: what the URL is supposed to be, e.g. "Linux x64 AppImage installer". options: optional overrides: {"min_sources": 2, "allow_tier3": false, "history_days": 90}. Returns a dict with verdict (VERIFIED_TRUE | VERIFIED_FALSE | UNVERIFIABLE), confidence, reason (in the caller's language), evidence[], checks{}, identity{}, risk_signals[], cache_hits[], engine_notes[], trace_id.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYes
optionsNo
projectYes
descriptionNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden, and it provides substantial detail: the possible verdicts, confidence, reason language, evidence, checks, identity, risk signals, cache hits, engine notes, and trace ID. It also exposes meaningful behavior through the `options` overrides (`min_sources`, `allow_tier3`, `history_days`). It does not mention authorization, rate limits, or side effects, but the behavior is readable.

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 description is front-loaded with the single-sentence purpose, followed by a compact Args list and a compact Returns list. Every line adds information needed to call the tool, and there is no filler or repetition.

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 verification tool with a rich return shape, the description covers the action, all parameters, and the output structure. The main gap is not guiding the agent relative to siblings, and the semantics of the `options` keys are only implicit, but nothing critical is missing for invoking the tool.

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 description coverage is 0%, so the description must define the parameters, and it does: `project` is exemplified, `url` is scoped to download/installer/repository/model/data URLs, `description` is explained with a concrete phrase, and `options` has literal defaults. This fully compensates for the schema's lack of descriptions.

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 opening sentence names a specific action and resource: verify that a `url` is an official/legitimate source for `project`. This is clearly distinct from the sibling tools `get_verification` and `list_known_identities`, which suggest retrieval and listing rather than on-demand verification.

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 description implies the natural use case through 'Verify that ...' and the verdict return values, but it never states when to choose this over `get_verification` or `list_known_identities`, nor does it give exclusions or alternative routing. This is adequate but not explicit.

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 updatesv0.1.0
    • First observedget_verification
    • First observedlist_known_identities
    • First observedverify_source
Deploy Server
Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

TDQS

A3.8/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: performing a verification, retrieving a past result by trace_id, and listing cached identities. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (verify_source, get_verification, list_known_identities), making the API predictable and easy to navigate.

Tool Count5/5

Three tools is well-scoped for a focused URL verification server: one primary action plus two supporting retrieval/listing utilities. Nothing feels missing or redundant.

Completeness4/5

The core verification workflow is fully covered, including result retrieval and identity discovery. Minor gaps exist, such as no way to list verification history or manage identities directly, but these are not blocking for the server's purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • c2pa-mcp

    harelrech
    A
    license
    A
    quality
    B
    maintenance
    Verifies C2PA Content Credentials for local files or URLs and returns an LLM-ready verdict on trust, AI generation, and provenance.
    4
    34 npm
    1
    Apache 2.0

  • a2a

    paul-salviani
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI agents to check trustworthiness before recommending URLs, products, or organizations, with fail-closed pass/fail verdicts and attested-only recommendations.
    MIT

  • io.github.mgdsn/verify-api-mcp

    mgdsn
    A
    license
    A
    quality
    B
    maintenance
    Enables agents to verify whether citations exist and match canonical records, and whether URLs resolve and contain expected content, with evidence-backed confirmed, contradicted, or unknown verdicts.
    2
    33 PyPI
    MIT