What can you do with this server?

This server lets you vet MCP servers from remote or local sources and generate harness-specific MCP configs, returning evidence-backed trust verdicts. * Vet remote targets: vet_server accepts npm:pkg, pypi:pkg, gh:owner/repo, or bare npm names, with optional strict mode. * Vet local directories: vet_directory scans a local MCP server source directory offline, with optional strict mode. * Get cached verdicts: get_verdict returns a cached verdict if fresh, otherwise re-vets the target. * List scanners: list_scanners shows the static scanners available (ssrf, exec, secrets, auth, provenance, deps). * List harnesses: list_harnesses shows supported config adapters (generic, claude-code, cursor, vscode, hermes). * Generate configs: get_config emits a paste-ready MCP server config block for a chosen harness, with custom command, args, env, and server name.

Which integrations are available for this server?

Allows scanning GitHub repositories for security and trustworthiness before use. Allows scanning npm packages for security and trustworthiness before installation. Allows scanning PyPI packages for security and trustworthiness before installation.

MCP-Vetting

by ElDiegolar

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

mcp-vet

A trust-scan framework for MCP servers: evidence-backed verdicts before you install — usable from any harness.

uvx --from mcp-vetting mcp-vet @modelcontextprotocol/server-fetch   # one command
uvx --from mcp-vetting mcp-vet ./my-server --harness hermes          # verdict + config for YOUR harness
uvx --from mcp-vetting mcp-vet pypi:fastmcp --json --gate            # machine-readable, CI-friendly

Verdicts: SAFE_TO_INSTALL · REVIEW_BEFORE_INSTALL · DO_NOT_INSTALL — every finding carries file:line and plain-English evidence. A verdict is a gate for humans, never a black box.

The flow

Vet any target: npm / PyPI / GitHub / local directory.
Read the verdict + findings (evidence, not vibes).
Configure: pick your harness, paste the emitted config block.
Gate it in CI with --gate (exit 1 on DO_NOT_INSTALL).

Related MCP server: tooltrust-mcp

Three surfaces, one engine

Surface	Use
Library	`from mcp_vet import vet, Policy` → `VetResult` (verdict, findings, provenance)
CLI	`mcp-vet <target> [--json] [--gate] [--strict] [--harness ...]`
MCP server	`mcp-vet-server` — tools: `vet_server`, `vet_directory`, `get_verdict`, `list_scanners`, `list_harnesses`, `get_config`

Targets

npm:pkg            npm registry + tarball        (bare names default to npm)
pypi:pkg           PyPI JSON + sdist/wheel
gh:owner/repo      GitHub metadata + source
./path             local source directory (offline)

Bare names that fail to resolve on npm (e.g. PyPI-only servers like
`mcp-server-time`) automatically fall back to PyPI before reporting failure.

Harness adapters (any harness, paste-ready)

--harness emits the exact config block for your tool:

harness	output
`generic`	universal `mcpServers` block
`claude-code`	`claude mcp add <name> -- <cmd> <args>`
`cursor`	`.cursor/mcp.json`
`vscode`	`.vscode/mcp.json` (VS Code `servers` schema)
`hermes`	`~/.hermes/config.yaml` `mcp_servers` block

--harness all prints every adapter. Programmatic: config_for(harness, ServerSpec(...)).

Policy (calibrated defaults, `--strict` to disable)

Static analysis must not cry wolf. Defaults, learned by vetting the real ecosystem:

Examples/tests/docs are informational — examples/, tests/, docs/ code can't block a package on its own (strict restores raw findings).
Fake secrets don't count — sk-test-…, example, xxxx literals are placeholders, not exfiltration.
Trusted-host auth is normal — credentials sent to a host named in the file (constant or literal) is client auth; HIGH only when the destination host appears nowhere in the code.
Host interpolation → REVIEW — https://${host}/… is a strong signal, but static analysis can't prove the host is user-controlled; a human decides. Strict mode blocks on it.

JSON schema (stable)

{
  "target": "npm:some-server", "kind": "npm", "version": "1.2.3",
  "verdict": {
    "level": "REVIEW_BEFORE_INSTALL",
    "summary": "3 finding(s); 0 high, 1 medium.",
    "findings": [
      {"scanner": "ssrf", "severity": "medium", "message": "...",
       "file": "dist/index.js", "line": 41, "evidence": "fetch(url)"}
    ]
  },
  "provenance": {"version": "1.2.3", "license": "MIT",
                 "source_url": "git+https://...", "source": "npm"},
  "files_scanned": 214, "duration_s": 1.7
}

Scanners

ssrf · exec · secrets · auth · provenance · deps — static, local-first (no telemetry, no cloud round-trips; the cache is a local SQLite file under ~/.cache/mcp-vet).

Verification

python3 -m unittest discover -s tests    # 48 checks: golden corpus is the quality bar

The golden corpus is the contract: known-good fixtures must never carry HIGH findings; malicious fixtures must always block. The ecosystem scan (scripts/ecosystem_scan.py) keeps the tool honest against real packages.

Honest limits

Static analysis has false positives and negatives. A verdict is a gate for humans, not a replacement for them — read the evidence. Sandboxed execution, egress audit-trail, and live CVE lookups are planned for v2.

Available Tools

6 tools

get_configA

Emit the ready-to-paste MCP config block for a harness (generic|claude-code|cursor|vscode|hermes).

ParametersJSON Schema

Name	Required	Default
`env`	No
`args`	No
`name`	Yes
`command`	No	uvx
`harness`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations exist, so the description carries full burden. It only says 'emit', which implies output generation, but does not disclose side effects, error handling, permissions, or what happens with invalid harnesses. 'Ready-to-paste' hints at output format but little else.

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?

A single, front-loaded sentence with no redundant words. It immediately states the tool's purpose and the list of harnesses.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 5 parameters, 0% schema coverage, and no annotations, this short description is insufficient. It does not explain how the parameters relate, what 'name' refers to, or when a user would need env/args, although the output schema does exist.

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%, yet the description only explains the `harness` parameter by listing valid values. It provides no meaning for `name`, `command`, `env`, or `args`, leaving the agent to guess their roles.

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?

Description uses a specific verb ('Emit') and a concrete resource ('ready-to-paste MCP config block') with a list of valid harnesses. This clearly distinguishes it from sibling tools like vet_server or list_harnesses.

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?

The context is clear: use it to generate an MCP config block for a particular harness. However, it does not explicitly mention when not to use it or point to alternatives like list_harnesses.

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

get_verdictA

Return the cached verdict for a target if fresh, else vet it now.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations provided, the description carries the burden of disclosing behavior. It reveals a key behavioral trait: it may trigger a vetting operation if the cached result is not fresh. This warns the agent that the tool might perform a potentially expensive action. It lacks specifics on what 'fresh' means or if there are side effects, but the core conditional behavior is clearly conveyed.

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, well-structured sentence. It front-loads the primary action and the conditional logic without redundancy. Every word contributes meaning, making it exceptionally concise and efficient.

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?

Given the tool's simplicity (one parameter, output schema exists), the description covers the essential behavior: returning cached verdicts or triggering vetting. It does not define 'target' or 'fresh', which are domain-specific, but the sibling tools provide context. The description is adequate for a tool of this complexity, though not exhaustive.

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?

The input schema provides only a parameter named 'target' with type string, and schema coverage is 0%. The description mentions 'a target' but does not define what constitutes a target, its format, or any constraints. It fails to compensate for the lack of schema detail, adding no meaningful semantics beyond the parameter name.

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 clearly states the tool's action: return a cached verdict or otherwise vet the target. It identifies the resource (target) and the conditional behavior, distinguishing it from sibling tools like vet_server and vet_directory that likely perform direct vetting without a cache-first approach.

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?

Usage is implied: use this tool when you need a verdict for a target, and it will handle freshness. However, it does not explicitly state when to use this versus alternatives, nor does it mention any prerequisites or exclusions. The conditional 'if fresh, else vet it now' provides context but not explicit alternative comparisons.

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

list_harnessesC

Harnesses with ready-to-paste config adapters.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.1/5.0

Behavior1/5

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

With no annotations available, the description carries the full burden of behavioral disclosure. It only mentions a data property ('ready-to-paste config adapters') but does not state that the tool returns a list, that it is read-only, or any other behavioral details.

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

Conciseness2/5

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

The description is very short but is a fragment rather than a complete sentence. It is concise but under-specified; a clearer structure like 'List all harnesses with...' would be more effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Although the tool has no parameters and an output schema exists, the description is too terse to fully convey the tool's purpose and behavior. It lacks a verb and any contextual guidance, leaving significant gaps for a standalone tool.

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 input schema has zero parameters and 100% coverage trivially, so the baseline for 0 params is 4. The description adds no parameter information, but none is needed due to the absence of parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description is a noun phrase, 'Harnesses with ready-to-paste config adapters,' and lacks an explicit verb like 'list' or 'retrieve.' It describes the content but does not clearly state the tool's action, making it reliant on the name for purpose. It also does not distinguish from siblings such as list_scanners.

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?

There is no guidance on when to use this tool versus alternatives like list_scanners or get_config. No use cases, preconditions, or exclusions are mentioned, leaving the agent without context for selection.

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

list_scannersC

The static scanners this framework runs.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/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 carry the full burden of behavioral disclosure. It does not state that the operation is read-only, has no side effects, or what the tool actually does beyond implying these scanners are available. For a zero-parameter tool, minimal behavior is expected, but even a simple read-only hint is missing.

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 extremely concise, using one short phrase. It is well-structured as a minimal statement, though it is not a complete sentence. For a simple list tool, this brevity is acceptable.

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?

With zero parameters, no annotations, and an existing output schema, the description is arguably adequate but minimal. It lacks a full verb and does not provide context about what 'static scanners' are or how they relate to the other tools. It is complete enough to infer the purpose but leaves room for more clarity.

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 the description does not need to explain parameter semantics. Baseline for 0 parameters is 4, and the description adds no unnecessary detail, which is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'The static scanners this framework runs' is a noun phrase rather than a full sentence with an explicit verb. It conveys that the tool lists the static scanners in the framework, but lacks a clear verb like 'list' and does not distinguish from sibling tool list_harnesses beyond the noun 'scanners.'

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 is provided about when to use this tool versus sibling tools like list_harnesses or get_config. The description simply states what scanners are, not when to invoke this tool or what context it fits into.

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

vet_directoryC

Vet a local MCP server source directory (offline). Returns the VetResult dict.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`strict`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It notes the tool is offline and returns a VetResult dict, but fails to mention side effects, required permissions, or whether it modifies anything. This is a significant gap for a tool with no structured behavioral hints.

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 concise sentence, but it is under-specified. The phrase 'Returns the VetResult dict' is redundant given an output schema exists, and the lack of parameter details makes the brevity feel like under-specification rather than effective economy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has two parameters, no annotations, and only a minimal description. It does not explain the 'strict' parameter, what vetting involves, or any behavioral expectations. For a 2-parameter tool with zero annotation coverage, this description is grossly incomplete.

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

Parameters1/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 clarify parameter meaning, but it does not mention 'path' or 'strict'. The path parameter is implied by 'directory', but 'strict' is completely unexplained, leaving the agent without guidance on how to set it.

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 clearly states the tool's function: vetting a local MCP server source directory offline. It uses a specific verb and resource, and the 'offline' qualifier distinguishes it from sibling tools like vet_server.

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?

The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions or prerequisites. The offline/local context is implied but not developed into actionable usage guidance.

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

vet_serverA

Vet a remote MCP server (npm:pkg, pypi:pkg, gh:owner/repo, or bare npm name). Returns the VetResult dict: verdict level/summary/findings, provenance, files scanned.

ParametersJSON Schema

Name	Required	Description	Default
`strict`	No
`target`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description must carry the full burden for behavioral disclosure. It does disclose the return format (VetResult dict with verdict, findings, provenance, files scanned) and accepted input formats, but it does not explain whether the tool downloads/executes packages, requires network access, or has side effects. This leaves gaps in understanding the tool's operational behavior beyond the basic input->output mapping.

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 two sentences long and front-loads the core purpose, then provides target formats and output structure. No filler or redundant information is present. It is appropriately sized for the tool's simplicity.

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?

Given that an output schema exists (so return values are already structured), the description adequately covers the main purpose, target formats, and output summary. The main missing element is the meaning of 'strict' and any usage exclusions, but overall the description is reasonably complete for a tool with two parameters. The absence of side-effect disclosure is a minor gap given the likely read-only nature of vetting.

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 description explains the 'target' parameter by listing the supported package identifier formats, which is not present in the input schema. However, the 'strict' boolean parameter is completely undocumented in both the schema and description, leaving its meaning and effect unknown. Since schema description coverage is 0%, the description only compensates for one of the two parameters.

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 clearly states a specific action ('Vet') applied to a specific resource ('remote MCP server') and enumerates accepted target formats (npm:pkg, pypi:pkg, gh:owner/repo, bare npm name). This distinguishes it from sibling tools like vet_directory, which presumably handles local directories. The mention of the VetResult dict further clarifies the tool's purpose.

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?

The description provides clear context by specifying 'remote MCP server' and the exact package identifier formats, implying it is intended for remote package references. However, it does not explicitly state when not to use this tool or suggest alternatives like vet_directory for local directories. Thus it has clear context but no explicit exclusions or alternative direction.

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.

6 tool updatesv0.2.2Aug 8, 2026
- First observedget_config
- First observedget_verdict
- First observedlist_harnesses
- First observedlist_scanners
- First observedvet_directory
- First observedvet_server

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.5/5.0

Scored 2026-08-08 00:40 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: vetting remote vs local, retrieving cached verdicts, listing scanners, listing harnesses, and generating configs. No two tools overlap in what they do, and the descriptions reinforce their unique roles.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern: vet_server, vet_directory, get_verdict, list_scanners, list_harnesses, get_config. The verbs (vet, get, list) are descriptive and uniform.

Tool Count5/5

With 6 tools, the set is well-scoped for a vetting framework, covering both operational actions and informational queries. There is no bloat or redundancy.

Completeness5/5

The tool surface covers the core lifecycle: vetting remote and local servers, retrieving cached results, enumerating available scanners and harnesses, and generating configuration. No obvious gaps hinder a user from completing a vetting workflow.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

mcp-shield A
com.craftedtrust
Trust verification for MCP servers. Check scores, scan for security issues, search 4,200+ servers.
Security Developer Tools
42
mcpcheck B
io.github.joeyough
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Penetration Testing Security
21
MCPLookup A
com.mcplookup
Look up independent trust ratings and security, maintenance, and adoption evidence for MCP servers.
Developer Tools Search Open Data
31
Dominion Observatory
com.dominionobservatory
Trust checks for MCP servers: trust scores, tool-drift detection, signed diligence receipts. Free.
Security Observability
2

Related MCP Servers

oathe-mcpofficial
Security Testing & QA Tools App Automation
oathe-ai
A
license
A
quality
C
maintenance
MCP server for https://oathe.ai security audits. Runtime behavioral analysis and security scanner for Ai systems. Check trust scores before installing MCP servers, plugins, or AI agent skills.
Updated 7 months ago (2026-02-23 03:41 UTC)
5
16 npm
1
MIT
tooltrust-mcp
AI & Machine Learning Security Testing & QA Tools
AgentSafe-AI
A
license
Not graded
quality
A
maintenance
Scans MCP servers for prompt injection, supply chain attacks, excessive permissions, and code execution risks. Includes an offline blacklist that catches known-compromised packages like LiteLLM 1.82.7/1.82.8 and Trivy with zero latency.
Updated 4 days ago (2026-09-09 14:31 UTC)
19
MIT
MCPskills
Code Analysis Developer Tools Security
BeBraveBeKind
A
license
A
quality
D
maintenance
Pre-install trust scoring & safety scanning for MCP servers, AI skills & npm packages — 15 signals incl. OSV/KEV/EPSS vuln intel and an auto-gate go/no-go.
Updated 3 months ago (2026-06-09 03:46 UTC)
9
163 npm
1
MIT
mcp-fortress
Security Penetration Testing
mcp-fortress
A
license
Not graded
quality
D
maintenance
Scans MCP servers for security vulnerabilities, prompt injection, and tool poisoning, providing risk scores and protection.
Updated 5 months ago (2026-04-20 13:24 UTC)
4
MIT

mcp-vet

The flow

Three surfaces, one engine

Targets

Harness adapters (any harness, paste-ready)

Policy (calibrated defaults, --strict to disable)

JSON schema (stable)

Scanners

Verification

Honest limits

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

oathe-mcpofficial

Policy (calibrated defaults, `--strict` to disable)