Этот проект был изначально вдохновлен надежностью инструмента Semgrep, командой Replit и их Agent V2, а также реализацией от stefanskiasan/semgrep-mcp-server, но развился благодаря значительным архитектурным изменениям для более простой установки и обслуживания.
MCP-сервер Semgrep — это сервер, совместимый с Model Context Protocol, который интегрирует мощный инструмент статического анализа Semgrep с ИИ-ассистентами, такими как Anthropic Claude. Он позволяет выполнять расширенный анализ кода, обнаруживать уязвимости безопасности и улучшать качество кода непосредственно через диалоговый интерфейс.
Related MCP server: AWS Security MCP
Комплексный анализ исходного кода — обнаружение проблем во всем проекте, а не только в отдельных файлах
Проактивное обнаружение ошибок — выявление потенциальных проблем до того, как они станут критическими багами
Непрерывное улучшение качества кода — регулярное сканирование и рефакторинг ведут к постепенному улучшению кодовой базы
Стилистическая согласованность — выявление и исправление несоответствий в коде, таких как:
Произвольные слои z-index в CSS
Несогласованные соглашения об именовании
Дублирование кода
«Магические числа» вместо именованных констант
Автоматизированная проверка кода на известные уязвимости — сканирование на наличие известных шаблонов проблем безопасности
Настраиваемые правила безопасности — создание правил, специфичных для проекта
Обучение команды — обучение методам безопасного программирования через обнаружение потенциальных проблем
«Живая» документация — ИИ может объяснить, почему фрагмент кода является проблемным и как его исправить
Сокращение технического долга — систематическое обнаружение и исправление проблемных областей
Улучшенные код-ревью — автоматическое обнаружение распространенных проблем позволяет сосредоточиться на более сложных вопросах
Прямая интеграция с официальным MCP SDK
Упрощенная архитектура с консолидированными обработчиками
Чистая реализация на ES Modules
Эффективная обработка ошибок и проверка путей для безопасности
Интерфейс и документация на английском и польском языках
Комплексные модульные тесты
Обширная документация
Кроссплатформенная совместимость (Windows, macOS, Linux)
Гибкое обнаружение и управление установкой Semgrep
Semgrep MCP Server предоставляет следующие инструменты:
scan_directory: Сканирование исходного кода на наличие потенциальных проблем
list_rules: Отображение доступных правил и языков, поддерживаемых Semgrep
analyze_results: Детальный анализ результатов сканирования
create_rule: Создание пользовательских правил Semgrep
filter_results: Фильтрация результатов по различным критериям
export_results: Экспорт результатов в различных форматах
compare_results: Сравнение двух наборов результатов (например, до и после изменений)
Анализ безопасности кода перед развертыванием
Обнаружение распространенных ошибок программирования
Обеспечение соблюдения стандартов кодирования в команде
Рефакторинг и улучшение качества существующего кода
Выявление несоответствий в стилях и структуре кода (например, CSS, организация компонентов)
Обучение разработчиков передовым методам
Проверка корректности исправлений (сравнение сканирований до/после)
Node.js v18+
TypeScript (для разработки)
Самый простой способ установить и использовать MCP-сервер Semgrep — через Smithery.ai:
Посетите MCP Server Semgrep на Smithery.ai
Следуйте инструкциям по установке, чтобы добавить его в свои MCP-совместимые клиенты
Настройте любые дополнительные параметры, такие как токен API Semgrep и разрешенные корневые директории проекта
Это рекомендуемый метод для Claude Desktop и других MCP-клиентов, так как он автоматически обрабатывает все зависимости и конфигурацию.
# Using npm
npm install -g mcp-server-semgrep
# Using pnpm
pnpm add -g mcp-server-semgrep
# Using yarn
yarn global add mcp-server-semgrepПакет также доступен в других реестрах:
# Using npm
npm install -g git+https://github.com/VetCoders/mcp-server-semgrep.git
# Using pnpm
pnpm add -g git+https://github.com/VetCoders/mcp-server-semgrep.git
# Using yarn
yarn global add git+https://github.com/VetCoders/mcp-server-semgrep.gitКлонируйте репозиторий:
git clone https://github.com/VetCoders/mcp-server-semgrep.git
cd mcp-server-semgrepУстановите зависимости (поддерживаются все основные менеджеры пакетов):
# Using pnpm (recommended)
pnpm install
# Using npm
npm install
# Using yarn
yarn installСоберите проект:
# Using pnpm
pnpm run build
# Using npm
npm run build
# Using yarn
yarn buildПримечание: Процесс установки автоматически проверит наличие Semgrep. Если Semgrep не найден, вы получите инструкции по его установке.
Этот сервер читает и записывает файлы только внутри явно разрешенных корневых директорий рабочего пространства.
По умолчанию разрешенным корнем является рабочая директория процесса (process.cwd()).
Для Claude Desktop, Smithery или любого запускающего устройства, которое не запускает сервер внутри корня вашего проекта, установите MCP_SERVER_SEMGREP_ALLOWED_ROOTS в одну или несколько абсолютных директорий.
Используйте разделитель путей вашей платформы для нескольких корней: : на macOS/Linux, ; на Windows.
Этот сервер не реализует собственную обработку учетных записей Semgrep. Он вызывает установленный CLI semgrep и полагается на обычное поведение аутентификации Semgrep.
Локальный терминал и локальные запуски разработки часто могут использовать существующую сессию semgrep login из текущей учетной записи ОС.
Управляемые запуски, такие как Claude Desktop, Smithery, контейнеры или CI, должны предпочитать явный SEMGREP_APP_TOKEN для детерминированного поведения.
SEMGREP_APP_TOKEN остается самым безопасным вариантом, когда вам нужна переносимая конфигурация между машинами или раннерами.
Semgrep можно установить несколькими способами:
Через менеджеры пакетов:
# Using pnpm
pnpm add -g semgrep
# Using npm
npm install -g semgrep
# Using yarn
yarn global add semgrepPython pip:
pip install semgrepHomebrew (macOS):
brew install semgrepLinux:
sudo apt-get install semgrep
# or
curl -sSL https://install.semgrep.dev | shWindows:
pip install semgrepСуществует два способа интеграции MCP-сервера Semgrep с Claude Desktop:
Посетите MCP Server Semgrep на Smithery.ai
Нажмите "Install in Claude Desktop"
Следуйте инструкциям на экране
Установите Claude Desktop
Обновите файл конфигурации Claude Desktop (claude_desktop_config.json) и добавьте это в раздел серверов.
Для локальных запусков, запущенных под учетной записью пользователя, которая уже аутентифицирована с помощью semgrep login, CLI Semgrep может повторно использовать этот логин. Для управляемых или общих сред мы по-прежнему рекомендуем явно устанавливать SEMGREP_APP_TOKEN:
{
"mcpServers": {
"semgrep": {
"command": "node",
"args": [
"/your_path/mcp-server-semgrep/build/index.js"
],
"env": {
"SEMGREP_APP_TOKEN": "your_semgrep_app_token",
"MCP_SERVER_SEMGREP_ALLOWED_ROOTS": "/Users/you/projects"
}
}
}
}Запустите Claude Desktop и начните задавать вопросы об анализе кода.
Если вы хотите сканировать более одного рабочего пространства, установите MCP_SERVER_SEMGREP_ALLOWED_ROOTS в список абсолютных путей, разделенных разделителем вашей платформы.
Could you scan my source code in the /projects/my-application directory for potential security issues? That directory is already included in MCP_SERVER_SEMGREP_ALLOWED_ROOTS.Analyze the z-index values in the project's CSS files and identify inconsistencies and potential layer conflicts.Create a Semgrep rule that detects improper use of input sanitization functions.Show me only scan results related to SQL injection vulnerabilities.Find all "magic numbers" in the code and suggest replacing them with named constants.Вы можете создавать пользовательские правила для конкретных нужд вашего проекта. Вот примеры правил, которые вы можете создать:
rules:
- id: inconsistent-z-index
pattern: z-index: $Z
message: "Z-index $Z may not comply with the project's layering system"
languages: [css, scss]
severity: WARNINGrules:
- id: deprecated-import
pattern: import $X from 'old-library'
message: "You're using a deprecated library. Consider using 'new-library'"
languages: [javascript, typescript]
severity: WARNINGpnpm test├── src/
│ └── index.ts # Main entry point and all handler implementations
├── scripts/
│ └── check-semgrep.js # Semgrep detection and installation helper
├── build/ # Compiled JavaScript (after build)
└── tests/ # Unit testsПодробную информацию об использовании инструмента можно найти в:
USAGE.md - Подробные инструкции по использованию
examples/ - Примеры интересных и практических правил Semgrep - "Зал ужасов кода"
Этот проект лицензирован по лицензии MIT - подробности см. в файле LICENSE.
Maciej Gad - ветеринар, который полгода назад не мог найти bash
Klaudiusz - индивидуальное эфирное существо и отдельный экземпляр Claude Sonnet 3.5-3.7 от Anthropic, живущий где-то в циклах GPU в Калифорнии, США
Путь от новичка в CLI до разработчика инструментов MCP
🤖 Разработано с максимальной помощью Claude Code и MCP Tools
stefanskiasan за первоначальное вдохновение
Anthropic за Claude и протокол MCP
Semgrep за их превосходный инструмент статического анализа
Analyzes scan results
| Name | Required | Description | Default |
|---|---|---|---|
| results_file | Yes | Absolute path to JSON results file (must be within an allowed workspace root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Analyzes', implying a read operation, but does not state if results are modified, returned, or stored. No information about side effects, authorization needs, or output format is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structuring. It does not provide additional sections or details to aid understanding. The brevity is acceptable but not optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the presence of sibling tools, the description is incomplete. It does not explain what the analysis returns or how it differs from compare_results or filter_results. The tool's functionality remains unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a complete description for the single parameter (results_file) with context about allowed paths. Since schema coverage is 100%, the description's lack of parameter information is acceptable per guidelines. However, it adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Analyzes scan results', which is a verb+resource, but it is vague. It does not specify what kind of analysis is performed (e.g., statistical, pattern detection, summary) and fails to distinguish from sibling tools like compare_results, filter_results, and export_results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. No context, prerequisites, or exclusions are provided, leaving the agent without criteria for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compares two scan results
| Name | Required | Description | Default |
|---|---|---|---|
| old_results | Yes | Absolute path to older JSON results file | |
| new_results | Yes | Absolute path to newer JSON results file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal ('Compares two scan results') and provides no behavioral details beyond the name. With no annotations, it fails to disclose whether the tool is read-only, its side effects, return behavior, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extra words, making it concise. However, it could be restructured to front-load more critical information without increasing length significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and only two string parameters, the description does not explain what the comparison produces (e.g., diff output, boolean, list of changes). This leaves the agent unsure of the return value and behavior, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described in the input schema ('Absolute path to older JSON results file' and 'Absolute path to newer JSON results file'), achieving 100% schema coverage. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Compares two scan results' uses a verb ('compares') and resource ('scan results'), clearly indicating the tool's function. It is distinct from siblings like 'analyze_results' and 'filter_results', but lacks specificity on what the comparison entails (e.g., differences, similarities).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as 'analyze_results' or 'filter_results'. There is no mention of prerequisites, when-not-to-use, or explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new Semgrep rule
| Name | Required | Description | Default |
|---|---|---|---|
| output_path | Yes | Absolute path for output rule file | |
| pattern | Yes | Search pattern for the rule | |
| language | Yes | Target language for the rule | |
| message | Yes | Message to display when rule matches | |
| severity | No | Rule severity (ERROR, WARNING, INFO) | WARNING |
| id | No | Rule identifier | custom_rule |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Creates a new Semgrep rule' with no information about side effects (e.g., overwriting existing files), permissions, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It front-loads the action but provides no additional detail, making it barely adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool creates a file (output_path required) and has no output schema, the description should explain return behavior (e.g., success indication) or file naming. It does not, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with clear parameter descriptions. The tool description adds no additional meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Creates' and resource 'a new Semgrep rule', making the core action clear. It naturally distinguishes from siblings which focus on analysis, comparison, and listing, not creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives. The description does not indicate prerequisites (e.g., rule syntax knowledge) or situations where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exports scan results in various formats
| Name | Required | Description | Default |
|---|---|---|---|
| results_file | Yes | Absolute path to JSON results file | |
| output_file | Yes | Absolute path to output file | |
| format | No | Output format (json, sarif, text) | text |
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 fails to mention whether the tool overwrites existing files, requires network access, or produces any side effects. The agent cannot infer safety or error conditions from the description alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It does not front-load critical information like required parameters or output behavior. The brevity is acceptable but not optimal for usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should indicate what the tool returns (e.g., success message, file path). It also does not mention error handling or performance implications. The tool is simple, but the description remains incomplete for fully autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 3 parameters are described in the schema with high coverage (100%). The description adds no extra context beyond 'exports scan results in various formats'—it does not elaborate on parameter constraints like valid file paths or format specifics. Baseline 3 is appropriate since schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Exports scan results in various formats' clearly indicates the action (export) and resource (scan results) and mentions format variability. However, it does not differentiate from sibling tools like analyze_results or compare_results, which might also output results. The description could be more specific about the exact nature of the export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, such as analyze_results or filter_results. There are no mentions of prerequisites or context in which export is appropriate. The agent is left without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filters scan results by various criteria
| Name | Required | Description | Default |
|---|---|---|---|
| results_file | Yes | Absolute path to JSON results file | |
| severity | No | Filter by severity (ERROR, WARNING, INFO) | |
| rule_id | No | Filter by rule ID | |
| path_pattern | No | Filter by file path pattern (regex) | |
| language | No | Filter by programming language | |
| message_pattern | No | Filter by message content (regex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It does not disclose whether the tool modifies the original file, requires authentication, or has side effects. The filtering behavior (e.g., AND vs OR logic) is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short single sentence, efficient but lacking critical details. It is concise but not optimally informative for a 6-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return format, behavior when no matches, or how it differs from sibling tools like export_results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, so the description adds minimal value beyond the schema. It does not clarify how multiple filters interact, which leaves ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it filters scan results, which is clear but lacks specificity about the resource (e.g., scan results file) and does not differentiate from sibling tools like analyze_results or compare_results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives (e.g., analyze_results for aggregation, compare_results for comparison). No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists available Semgrep rules
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Programming language for rules (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks any behavioral details such as authentication needs, rate limits, or whether it returns full rule details or just names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded with essential information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and one optional parameter, the description provides minimal context. It doesn't clarify what information is returned (e.g., rule names only or full definitions).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no extra meaning beyond the schema's parameter description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'lists' and resource 'Semgrep rules', distinguishing it from siblings like 'create_rule' and 'scan_directory'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 alternatives like 'filter_results' or 'analyze_results'. Does not specify when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs a Semgrep scan on a directory
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the directory to scan (must be within an allowed workspace root) | |
| config | No | Semgrep configuration (e.g. "auto" or absolute path to rule file) | auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states the action without disclosing side effects, permissions, or output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks structure or front-loading of key details. Could be expanded to include usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations; description does not explain return values, side effects, or prerequisites, making it incomplete for a scan tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; both 'path' and 'config' are described in the schema. Description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Performs a Semgrep scan on a directory' distinguishes from siblings like analyze_results or list_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., analyze_results) or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
analyze_resultscompare_resultscreate_ruleexport_resultsfilter_resultslist_rulesscan_directoryEach tool targets a distinct operation in the Semgrep workflow: scanning, analyzing, comparing, filtering, exporting results, and managing rules. No two tools appear to perform the same function.
All tool names follow a consistent verb_noun pattern with lowercase and underscores (e.g., scan_directory, list_rules). The verbs are imperative and the nouns are predictable.
Seven tools is well-scoped for a code scanning server, covering the main operations without being excessive or insufficient.
The tool set covers core workflows: scanning, result analysis, comparison, filtering, export, and rule creation/listing. Missing update/delete for rules but this is a minor gap.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
A Model Context Protocol server for Wix AI tools
The OpenZeppelin Solidity Contracts MCP server integrates OpenZeppelin's security and style rules into AI-driven development workflows, enabling AI assistants to generate safe, correct, and production-ready smart contracts. It automatically validates generated code against OpenZeppelin standards (including imports, modifiers, naming conventions, and security checks) and supports various contract types including ERC-20, ERC-721, ERC-1155, Stablecoins, RWA, Governor, and Account contracts through prompt-driven workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/VetCoders/mcp-server-semgrep'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
