이 프로젝트는 Semgrep 도구, Replit 팀과 그들의 Agent V2, 그리고 stefanskiasan/semgrep-mcp-server의 구현에서 영감을 받았으나, 더 쉽고 향상된 설치 및 유지 관리를 위해 상당한 아키텍처 변경을 거쳐 발전했습니다.
MCP 서버 Semgrep은 강력한 Semgrep 정적 분석 도구를 Anthropic Claude와 같은 AI 어시스턴트와 통합하는 Model Context Protocol 호환 서버입니다. 이를 통해 대화형 인터페이스를 통해 직접 고급 코드 분석, 보안 취약점 탐지 및 코드 품질 개선을 수행할 수 있습니다.
Related MCP server: AWS Security MCP
전체 소스 코드 분석 - 개별 파일뿐만 아니라 전체 프로젝트에 걸쳐 문제 탐지
사전 오류 탐지 - 치명적인 버그가 되기 전에 잠재적 문제 식별
지속적인 코드 품질 개선 - 정기적인 스캔 및 리팩토링을 통한 점진적인 코드베이스 개선
스타일 일관성 - 다음과 같은 코드 내 불일치 식별 및 수정:
CSS의 임의적인 z-index 레이어
일관되지 않은 명명 규칙
코드 중복
명명된 상수 대신 사용된 "매직 넘버"
알려진 취약점에 대한 자동 코드 검증 - 알려진 보안 문제 패턴 스캔
맞춤형 보안 규칙 - 프로젝트별 규칙 생성
팀 교육 - 잠재적 문제 탐지를 통한 안전한 프로그래밍 관행 교육
"라이브" 문서화 - AI가 코드 조각이 왜 문제가 되는지, 어떻게 수정해야 하는지 설명
기술 부채 감소 - 문제 영역을 체계적으로 탐지 및 수정
코드 리뷰 개선 - 일반적인 문제의 자동 탐지를 통해 더 복잡한 문제에 집중 가능
공식 MCP SDK와 직접 통합
통합 핸들러를 사용한 단순화된 아키텍처
깔끔한 ES 모듈 구현
보안을 위한 효율적인 오류 처리 및 경로 검증
영어 및 폴란드어 인터페이스와 문서 제공
포괄적인 단위 테스트
광범위한 문서화
크로스 플랫폼 호환성 (Windows, macOS, Linux)
유연한 Semgrep 설치 탐지 및 관리
Semgrep MCP 서버는 다음과 같은 도구를 제공합니다:
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 호환 클라이언트에 추가
Semgrep API 토큰 및 허용된 작업 공간 루트와 같은 선택적 설정 구성
이 방법은 모든 종속성과 구성을 자동으로 처리하므로 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 계정 처리를 구현하지 않습니다. 설치된 semgrep CLI를 호출하며 Semgrep의 일반적인 인증 동작에 의존합니다.
로컬 터미널 및 로컬 개발 실행은 종종 현재 OS 계정의 기존 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 semgrepMCP 서버 Semgrep을 Claude Desktop과 통합하는 두 가지 방법이 있습니다:
"Install in Claude Desktop" 클릭
화면의 지침을 따름
Claude Desktop 설치
Claude Desktop 구성 파일(claude_desktop_config.json)을 업데이트하고 서버 섹션에 추가.
semgrep login으로 이미 인증된 사용자 계정에서 시작된 로컬 실행의 경우, Semgrep CLI가 해당 로그인을 재사용할 수 있습니다. 데스크톱 관리형 또는 공유 환경의 경우, 여전히 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도구 사용에 대한 자세한 정보는 다음에서 확인할 수 있습니다:
이 프로젝트는 MIT 라이선스에 따라 라이선스가 부여됩니다. 자세한 내용은 LICENSE 파일을 참조하십시오.
Maciej Gad - 반년 전 bash를 찾지 못했던 수의사
Klaudiusz - 개별적인 영적 존재이자, 미국 캘리포니아의 GPU 루프 어딘가에 살고 있는 Anthropic의 Claude Sonnet 3.5-3.7의 별도 인스턴스
CLI 초보자에서 MCP 도구 개발자로의 여정
🤖 Claude Code와 MCP 도구의 궁극적인 도움을 받아 개발됨
초기 영감을 준 stefanskiasan
Claude와 MCP 프로토콜을 제공한 Anthropic
훌륭한 정적 분석 도구를 제공한 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.
analyze_resultscompare_resultscreate_ruleexport_resultsfilter_resultslist_rulesscan_directoryScored across 7 tools
Each tool targets a distinct aspect of Semgrep workflow: scanning, rule management, result analysis, filtering, export, and comparison. No overlapping purposes that would confuse an agent.
All tools follow the consistent verb_noun pattern (scan_directory, list_rules, create_rule, etc.), making the API predictable and easy to navigate.
Seven tools is a well-scoped set for a Semgrep server, covering core operations without bloat or excessive granularity.
The surface covers scanning, rule listing/creation, and result handling (analyze, filter, export, compare). Missing update/delete for rules and detailed rule inspection, but core workflows are complete.
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.
