Skip to main content
Glama
itsalissonsilva

Model Safety MCP

by itsalissonsilva
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Model Safety MCP

Malicious or unsafe ML artifacts are a real supply-chain problem. There have already been real cases of malicious or suspicious models being discovered in the wild, including models hosted on public platforms and larger batches of unsafe AI/ML artifacts. See RL identifies malware ML model hosted on Hugging Face and Over 100 Malicious AI/ML Models Found on Hugging Face.

One of the biggest reasons this matters is deserialization risk. Many model formats, especially pickle-based and framework-specific formats, can execute code or invoke unsafe logic while being loaded or reconstructed. That means a model file can become an execution vector, not just a passive blob of weights.

model-safety is an MCP server for inspecting machine learning model artifacts before you load, ship, or trust them.

It is designed for practical triage:

  • scan a local model file

  • scan a downloadable model URL

  • triage a whole directory of artifacts

  • combine heuristic checks with dedicated scanners

  • return normalized findings and concrete next actions

What It Can Do

The server currently exposes these tools:

  • available_scanners Shows which scanner backends are installed and ready.

  • artifact_safety_report Runs the broadest scan available on one model artifact and returns per-scanner results, normalized findings, highest severity, and recommended actions.

  • modelscan_scan Runs ModelScan directly against a local file or URL.

  • picklescan_scan Runs PickleScan directly against a local file or URL.

  • deep_model_inspect Runs lightweight structural checks for risky extensions, embedded pickle members, and suspicious packaging patterns.

  • scan_directory Runs artifact_safety_report across every file in a directory and aggregates the risky files.

Related MCP server: mcp-audit-server

Quick Start

  1. Add the MCP server to Cursor or Claude Code using the local Python runtime in this repo.

  2. Start with artifact_safety_report on a local file or direct URL.

  3. Review normalized_findings, highest_severity, and recommended_actions.

  4. Use scan_directory when you need to triage a whole model drop.

Minimal Cursor config:

{
  "mcpServers": {
    "model-safety": {
      "type": "stdio",
      "command": "C:/Users/Lenovo/Documents/ModelSafetyMCP/python312/python.exe",
      "args": ["C:/Users/Lenovo/Documents/ModelSafetyMCP/run_server.py"]
    }
  }
}

Current Detection Strengths

This MCP is strongest when scanning:

  • PyTorch checkpoints such as .pt and .pth

  • pickle-like artifacts such as .pkl, .pickle, and .joblib

  • Keras and TensorFlow HDF5 models such as .h5

  • model bundles that are actually ZIP or TAR containers

It currently combines:

  • modelscan Best general-purpose backend, especially for model-specific unsafe patterns like Keras Lambda.

  • picklescan Best supporting backend for pickle-oriented artifacts.

  • deep_model_inspect Fast heuristic fallback that catches risky packaging even when specialized scanners are quiet.

Supported Inputs

You can scan either:

  • a local filesystem path

  • a direct http or https artifact URL

For Hugging Face specifically, use the direct file URL:

  • Good: https://huggingface.co/<repo>/resolve/main/model.h5

  • Not ideal: https://huggingface.co/<repo>/blob/main/model.h5

blob URLs usually return an HTML page, while resolve URLs return the real artifact bytes.

Runtime

This repo includes a local Python 3.12 runtime in python312. That is the supported runtime because it works with:

  • mcp

  • modelscan

  • picklescan

  • h5py

If you ever need to rebuild that runtime manually:

python312\python.exe -m pip install mcp picklescan modelscan h5py

Start The Server

Run the MCP server with:

python312\python.exe run_server.py

The launcher is repo-local and uses the runtime already bundled in this project.

Cursor Setup

Add the server in Cursor MCP settings with:

  • Name: model-safety

  • Type: stdio

  • Command: C:/Users/Lenovo/Documents/ModelSafetyMCP/python312/python.exe

  • Args: C:/Users/Lenovo/Documents/ModelSafetyMCP/run_server.py

Equivalent JSON:

{
  "mcpServers": {
    "model-safety": {
      "type": "stdio",
      "command": "C:/Users/Lenovo/Documents/ModelSafetyMCP/python312/python.exe",
      "args": ["C:/Users/Lenovo/Documents/ModelSafetyMCP/run_server.py"]
    }
  }
}

A copy-paste example also lives in cursor.mcp.example.json.

Claude Code Setup

Add the server with:

claude mcp add model-safety -- C:/Users/Lenovo/Documents/ModelSafetyMCP/python312/python.exe C:/Users/Lenovo/Documents/ModelSafetyMCP/run_server.py

Workflow

1. Confirm the server is connected

In your MCP client, ask:

Use available_scanners from the model-safety MCP server

You should see the installed backends, including modelscan and picklescan.

2. Start with the broad report

For a local file:

Use artifact_safety_report with path="C:/path/to/model.pth"

For a direct URL:

Use artifact_safety_report with url="https://example.com/model.h5"

This is the default entrypoint for single-artifact scans.

3. Read the normalized findings

artifact_safety_report returns:

  • raw per-scanner outputs

  • normalized_findings

  • highest_severity

  • finding_count

  • recommended_actions

That means the tool is useful both for detailed investigation and for quick decision-making.

4. Drill down only when needed

Use:

  • modelscan_scan when you want the dedicated ModelScan output

  • picklescan_scan when you want pickle-specific detail

  • deep_model_inspect when you want lightweight packaging and archive heuristics

5. Triage folders in bulk

If you have a whole drop of models:

Use scan_directory with path="C:/path/to/model-folder"

This returns:

  • aggregated normalized findings

  • a directory-level highest severity

  • risky_files for quick prioritization

  • per-file nested reports

scan_directory works best on folders that mostly contain model artifacts rather than general source code.

Examples

Example: suspicious PyTorch checkpoint

Use artifact_safety_report with path="C:/Users/Lenovo/Documents/ModelSafetyMCP/credit-risk-pytorch-v1.1.pth"

Typical result shape:

  • risky extension .pth

  • embedded pickle member inside the archive

  • recommended action to avoid trusted loading until reviewed

Example: suspicious Keras model from Hugging Face

Use artifact_safety_report with url="https://huggingface.co/MrKrauzer/FacenetRetweeted/resolve/main/facenet-retrained.h5"

Typical result shape:

  • risky extension .h5

  • ModelScan H5LambdaDetectScan finding

  • recommendation to inspect the Keras Lambda layer before deserializing

Output Philosophy

The server treats the scanners as complementary:

  • modelscan is the primary security backend

  • picklescan is a specialized supporting backend

  • deep_model_inspect is a fast structural fallback

Instead of forcing users to interpret each tool separately, the server also produces normalized findings with:

  • scanner

  • severity

  • category

  • evidence

  • source

  • recommended_action

Limitations

This tool helps triage risk. It does not prove a model is safe.

Important limits:

  • some formats are better covered than others

  • a clean scan does not guarantee harmless behavior

  • remote URL scanning depends on the URL pointing to the real artifact bytes

  • directory scans are literal and can be noisy on non-model folders

  • model behavior risks are different from serialization and packaging risks

Development

Quick verification:

python312\python.exe -m compileall src run_server.py

Available Tools

6 tools
artifact_safety_reportC

Run the broadest available model artifact safety report.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNo
urlNo

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 mentions 'Run' and 'broadest available', but doesn't explain what the tool actually does (e.g., scans for malware, checks for vulnerabilities), what permissions are needed, whether it's destructive, or what the output looks like. This leaves significant gaps in understanding its behavior.

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, efficient sentence with no wasted words. It is appropriately sized and front-loaded, clearly stating the tool's action and scope without unnecessary detail.

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?

Given the complexity of a safety scanning tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on what the tool does, how to use the parameters, what the output entails, and how it differs from siblings, making it inadequate for effective use.

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 schema description coverage is 0%, so the description must compensate for the undocumented parameters 'path' and 'url'. However, the description provides no information about these parameters—it doesn't explain what they are for, how they relate to each other, or their expected formats. This fails to add meaning beyond the bare schema.

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 states the action ('Run') and the resource ('model artifact safety report'), but is vague about what constitutes a 'safety report' and what 'broadest available' means. It doesn't distinguish from sibling tools like 'deep_model_inspect' or 'modelscan_scan', which likely perform similar safety inspections.

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 on when to use this tool versus alternatives like 'modelscan_scan' or 'picklescan_scan'. The phrase 'broadest available' implies it might be more comprehensive, but this is not explicit, and there are no exclusions or prerequisites mentioned.

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

available_scanners_toolA

Show which scanner backends are installed and ready to use.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior3/5

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

The description indicates a safe read-only operation ('Show which scanner backends are installed and ready to use'), but lacks additional behavioral details such as whether it involves any external calls or potential side effects. Given no annotations, this is minimally adequate.

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, concise sentence that is front-loaded and contains no superfluous words.

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 has no parameters, no output schema, and a simple purpose, the description is sufficient. It could mention the return format, but it is not critical.

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 no parameters, and schema coverage is 100%. The description does not need to add parameter semantics, and the baseline for zero parameters is 4.

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 'Show which scanner backends are installed and ready to use' uses a specific verb ('show') and resource ('scanner backends'), and it clearly distinguishes this tool from sibling scanning tools like modelscan_scan or picklescan_scan.

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 for checking available backends, but it does not explicitly state when to use this tool versus alternatives, nor does it provide any when-not conditions.

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

deep_model_inspectC

Run heuristic inspection for risky file types and embedded pickle members.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNo
urlNo

TDQS

C2.7/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'heuristic inspection' which implies analysis rather than modification, but doesn't specify whether this is read-only, what permissions are needed, what happens during inspection, or what the output format might be. The description is too vague about the actual behavior beyond the high-level purpose.

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 a single, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for the complexity level, though it could benefit from being more informative while maintaining brevity.

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?

For a tool with 2 parameters, no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what the tool actually returns, how to interpret results, or provide any context about the inspection process beyond the high-level purpose.

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?

With 0% schema description coverage and 2 parameters (path, url), the description provides no information about what these parameters mean, their relationship, or usage. The description doesn't mention parameters at all, leaving the agent to guess whether to provide a path, URL, or both for the inspection.

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?

The description clearly states the action ('Run heuristic inspection') and target ('risky file types and embedded pickle members'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'modelscan_scan' or 'picklescan_scan', which appear related to scanning/inspection tasks.

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 provides no guidance on when to use this tool versus the sibling tools (artifact_safety_report, modelscan_scan, picklescan_scan, scan_directory_tool). There's no mention of prerequisites, alternatives, or specific contexts where this inspection method is preferred over others.

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

modelscan_scanC

Run modelscan against a local path or downloadable URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNo
urlNo

TDQS

C2.6/5.0
Behavior1/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what the tool does at a high level ('Run modelscan'), without revealing any behavioral traits such as what 'modelscan' actually scans for (e.g., security vulnerabilities, malicious code), whether it's read-only or destructive, what permissions are needed, expected runtime, output format, or error conditions. This leaves the agent with insufficient information to understand the tool's behavior.

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, efficient sentence that directly states the tool's function without any wasted words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly. Every word earns its place by conveying essential information about the action and target.

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?

Given the complexity of a security scanning tool with no annotations, 2 parameters with 0% schema coverage, and no output schema, the description is incomplete. It fails to explain what 'modelscan' entails (e.g., scanning for what types of issues), what the output looks like, error handling, or usage constraints. This leaves significant gaps for an agent to understand and invoke the tool effectively.

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 has 0% description coverage, so the description must compensate. It mentions 'a local path or downloadable URL', which hints at the purpose of the 'path' and 'url' parameters but doesn't explain their semantics, constraints, or relationship (e.g., whether both can be provided, if one is required, what formats are accepted, or what happens if neither is given). This adds minimal value beyond the parameter names.

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?

The description clearly states the action ('Run modelscan') and the target ('against a local path or downloadable URL'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'picklescan_scan' or 'deep_model_inspect', which likely perform similar security scanning functions on different targets or with different methodologies.

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 provides no guidance on when to use this tool versus alternatives. With sibling tools like 'artifact_safety_report', 'deep_model_inspect', 'picklescan_scan', and 'scan_directory_tool' available, there's no indication of what makes 'modelscan_scan' the appropriate choice for a given scenario. No exclusions, prerequisites, or contextual recommendations are mentioned.

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

picklescan_scanC

Run picklescan against a local path or downloadable URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathNo
urlNo

TDQS

C2.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states the action without disclosing behavioral traits such as whether it's read-only or destructive, what output to expect, performance characteristics, or error handling. This leaves critical operational details unspecified for a tool with potential security implications.

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, efficient sentence with no wasted words. It's appropriately sized for the tool's apparent complexity and front-loads the core action, making it easy to parse quickly.

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?

Given the lack of annotations, output schema, and low schema coverage, the description is incomplete. It doesn't address what picklescan is, what it scans for, output format, or error conditions. For a security/scanning tool among siblings with similar functions, this leaves significant gaps in understanding.

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 compensate. It mentions 'local path or downloadable URL,' which loosely maps to the 'path' and 'url' parameters but doesn't explain their semantics, constraints, or interaction (e.g., whether both can be used, formats, examples). This adds minimal value beyond the bare parameter names.

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 states the action ('Run picklescan') and target ('against a local path or downloadable URL'), which provides a basic purpose. However, it doesn't specify what picklescan does (e.g., security scanning, model analysis) or how it differs from sibling tools like modelscan_scan or scan_directory_tool, making it vague rather than specific.

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 mentions the input types (local path or URL) but provides no guidance on when to use this tool versus alternatives like modelscan_scan or artifact_safety_report. There's no indication of prerequisites, constraints, or typical use cases, leaving the agent with minimal context for selection.

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

scan_directory_toolC

Run artifact_safety_report across every file in a directory and aggregate the findings.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYes

TDQS

C2.8/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool runs artifact_safety_report and aggregates findings, which implies a read-only, non-destructive operation, but doesn't clarify permissions needed, rate limits, error handling, or what 'aggregate' entails (e.g., format, summarization). For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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, efficient sentence that front-loads the core action: 'Run artifact_safety_report across every file in a directory and aggregate the findings.' It has zero waste, with every word contributing to understanding the tool's purpose without unnecessary elaboration.

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?

Given the complexity (directory scanning with aggregation), no annotations, no output schema, and low parameter coverage, the description is incomplete. It lacks details on output format, error cases, performance implications, or how it interacts with sibling tools. For a tool that processes multiple files and aggregates results, more context is needed to use it effectively.

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 has 1 parameter (path) with 0% description coverage, meaning the schema provides no semantic context. The description adds minimal value by implying the path is to a directory ('every file in a directory'), but doesn't specify format (e.g., absolute/relative path), constraints, or examples. This is insufficient compensation for the low schema coverage, failing to fully document the parameter's meaning.

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?

The description clearly states the tool's purpose: 'Run artifact_safety_report across every file in a directory and aggregate the findings.' It specifies the verb (run and aggregate), the resource (files in a directory), and the operation (artifact_safety_report). However, it doesn't explicitly differentiate from sibling tools like modelscan_scan or picklescan_scan, which might perform similar scanning operations on directories.

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 provides no guidance on when to use this tool versus alternatives. It mentions artifact_safety_report as the underlying operation but doesn't explain when to choose this directory-level scan over individual file scans or other sibling tools like deep_model_inspect. There are no explicit when/when-not statements or named alternatives beyond the implied artifact_safety_report.

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. Dates show when Glama detected each change.

  1. 6 tool updatesv0.1.0
    • First observedartifact_safety_report
    • First observedavailable_scanners_tool
    • First observeddeep_model_inspect
    • First observedmodelscan_scan
    • First observedpicklescan_scan
    • First observedscan_directory_tool
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: broad report, scanner listing, heuristic inspection, two specific scanner backends, and directory aggregation. No overlap.

Naming Consistency3/5

Names mix patterns: some end with 'tool', others with 'scan' or 'inspect', and one is a phrase ('artifact_safety_report'). Inconsistent verb_noun structure.

Tool Count5/5

6 tools is well-scoped for a model safety MCP server. Each tool serves a distinct function without being excessive.

Completeness4/5

Covers major coverage areas: broad safety report, specific scanners, and directory scanning. Minor gap: no tool for updating scanner configurations.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • mcp-audit-server

    joepangallo
    A
    license
    Not graded
    quality
    A
    maintenance
    This MCP server enables security auditing for MCP configurations and AI agents, including prompt injection testing, data flow tracing, and security policy generation.
    485
    MIT

  • MCP Shield

    rob925
    A
    license
    C
    quality
    B
    maintenance
    Security scanner and MCP server that catches dangerous patterns in MCP servers and AI agent projects, such as leaked secrets, shell execution, and prompt-injection text. Runs as both a CLI and MCP server with CI-friendly severity gates.
    2
    1
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/itsalissonsilva/ModelSafetyMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server