Skip to main content
Glama
enesjakozh
semgrep

Semgrep MCP Server

Official
by semgrep
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

⚠️ The Semgrep MCP server has been moved from a standalone repo to the main semgrep repository! ⚠️

This repository has been deprecated, and further updates to the Semgrep MCP server will be made via the official semgrep binary.

Semgrep MCP Server

Add MCP Server semgrep to LM Studio Install in Cursor Install in VS Code UV Install in VS Code Docker Install in VS Code semgrep.ai PyPI Docker Install in VS Code Insiders Install in VS Code Insiders

A Model Context Protocol (MCP) server for using Semgrep to scan code for security vulnerabilities. Secure your vibe coding! 😅

Model Context Protocol (MCP) is a standardized API for LLMs, Agents, and IDEs like Cursor, VS Code, Windsurf, or anything that supports MCP, to get specialized help, get context, and harness the power of tools. Semgrep is a fast, deterministic static analysis tool that semantically understands many languages and comes with over 5,000 rules. 🛠️

NOTE

This beta project is under active development. We would love your feedback, bug reports, feature requests, and code. Join the#mcp community Slack channel!

Related MCP server: MCP Server Semgrep

Contents

Getting started

Run the Python package as a CLI command using uv:

uvx semgrep-mcp # see --help for more options

Or, run as a Docker container:

docker run -i --rm ghcr.io/semgrep/mcp -t stdio

Cursor

Example mcp.json

{
  "mcpServers": {
    "semgrep": {
      "command": "uvx",
      "args": ["semgrep-mcp"],
      "env": {
        "SEMGREP_APP_TOKEN": "<token>"
      }
    }
  }
}

Add an instruction to your .cursor/rules to use automatically:

Always scan code generated using Semgrep for security vulnerabilities

ChatGPT

  1. Go to the Connector Settings page (direct link)

  2. Name the connection Semgrep

  3. Set MCP Server URL to https://mcp.semgrep.ai/sse

  4. Set Authentication to No authentication

  5. Check the I trust this application checkbox

  6. Click Create

See more details at the official docs.

Hosted Server

WARNING

mcp.semgrep.ai is an experimental server that may break unexpectedly. It will rapidly gain new functionality.🚀

Cursor

  1. Cmd + Shift + J to open Cursor Settings

  2. Select MCP Tools

  3. Click New MCP Server.

{
  "mcpServers": {
    "semgrep": {
      "type": "streamable-http",
      "url": "https://mcp.semgrep.ai/mcp"
    }
  }
}

Demo

API

Tools

Enable LLMs to perform actions, make deterministic computations, and interact with external services.

Scan Code

  • security_check: Scan code for security vulnerabilities

  • semgrep_scan: Scan code files for security vulnerabilities with a given config string

  • semgrep_scan_with_custom_rule: Scan code files using a custom Semgrep rule

Understand Code

  • get_abstract_syntax_tree: Output the Abstract Syntax Tree (AST) of code

Cloud Platform (login and Semgrep token required)

  • semgrep_findings: Fetch Semgrep findings from the Semgrep AppSec Platform API

Meta

  • supported_languages: Return the list of languages Semgrep supports

  • semgrep_rule_schema: Fetches the latest semgrep rule JSON Schema

Prompts

Reusable prompts to standardize common LLM interactions.

  • write_custom_semgrep_rule: Return a prompt to help write a Semgrep rule

Resources

Expose data and content to LLMs

  • semgrep://rule/schema: Specification of the Semgrep rule YAML syntax using JSON schema

  • semgrep://rule/{rule_id}/yaml: Full Semgrep rule in YAML format from the Semgrep registry

Usage

This Python package is published to PyPI as semgrep-mcp and can be installed and run with pip, pipx, uv, poetry, or any Python package manager.

$ pipx install semgrep-mcp
$ semgrep-mcp --help

Usage: semgrep-mcp [OPTIONS]

  Entry point for the MCP server

  Supports both stdio and sse transports. For stdio, it will read from stdin
  and write to stdout. For sse, it will start an HTTP server on port 8000.

Options:
  -v, --version                Show version and exit.
  -t, --transport [stdio|sse]  Transport protocol to use (stdio or sse)
  -h, --help                   Show this message and exit.

Standard Input/Output (stdio)

The stdio transport enables communication through standard input and output streams. This is particularly useful for local integrations and command-line tools. See the spec for more details.

Python

semgrep-mcp

By default, the Python package will run in stdio mode. Because it's using the standard input and output streams, it will look like the tool is hanging without any output, but this is expected.

Docker

This server is published to Github's Container Registry (ghcr.io/semgrep/mcp)

docker run -i --rm ghcr.io/semgrep/mcp -t stdio

By default, the Docker container is in SSE mode, so you will have to include -t stdio after the image name and run with -i to run in interactive mode.

Streamable HTTP

Streamable HTTP enables streaming responses over JSON RPC via HTTP POST requests. See the spec for more details.

By default, the server listens on 127.0.0.1:8000/mcp for client connections. To change any of this, set FASTMCP_* environment variables. The server must be running for clients to connect to it.

Python

semgrep-mcp -t streamable-http

By default, the Python package will run in stdio mode, so you will have to include -t streamable-http.

Docker

docker run -p 8000:0000 ghcr.io/semgrep/mcp

Server-sent events (SSE)

WARNING

The MCP communiity considers this a legacy transport portcol and is really intended for backwards compatibility.Streamable HTTP is the recommended replacement.

SSE transport enables server-to-client streaming with Server-Send Events for client-to-server and server-to-client communication. See the spec for more details.

By default, the server listens on 127.0.0.1:8000/sse for client connections. To change any of this, set FASTMCP_* environment variables. The server must be running for clients to connect to it.

Python

semgrep-mcp -t sse

By default, the Python package will run in stdio mode, so you will have to include -t sse.

Docker

docker run -p 8000:0000 ghcr.io/semgrep/mcp -t sse

Semgrep AppSec Platform

Optionally, to connect to Semgrep AppSec Platform:

  1. Login or sign up

  2. Generate a token from Settings

  3. Add the token to your environment variables:

    • CLI (export SEMGREP_APP_TOKEN=<token>)

    • Docker (docker run -e SEMGREP_APP_TOKEN=<token>)

    • MCP config JSON

    "env": {
      "SEMGREP_APP_TOKEN": "<token>"
    }
TIP

Pleasereach out for support if needed. ☎️

Integrations

Cursor IDE

Add the following JSON block to your ~/.cursor/mcp.json global or .cursor/mcp.json project-specific configuration file:

{
  "mcpServers": {
    "semgrep": {
      "command": "uvx",
      "args": ["semgrep-mcp"]
    }
  }
}

cursor MCP settings

See cursor docs for more info.

VS Code / Copilot

Click the install buttons at the top of this README for the quickest installation.

Manual Configuration

Add the following JSON block to your User Settings (JSON) file in VS Code. You can do this by pressing Ctrl + Shift + P and typing Preferences: Open User Settings (JSON).

{
  "mcp": {
    "servers": {
      "semgrep": {
        "command": "uvx",
        "args": ["semgrep-mcp"]
      }
    }
  }
}

Optionally, you can add it to a file called .vscode/mcp.json in your workspace:

{
  "servers": {
    "semgrep": {
      "command": "uvx",
        "args": ["semgrep-mcp"]
    }
  }
}

Using Docker

{
  "mcp": {
    "servers": {
      "semgrep": {
        "command": "docker",
        "args": [
          "run",
          "-i",
          "--rm",
          "ghcr.io/semgrep/mcp",
          "-t",
          "stdio"
        ]
      }
    }
  }
}

See VS Code docs for more info.

Windsurf

Add the following JSON block to your ~/.codeium/windsurf/mcp_config.json file:

{
  "mcpServers": {
    "semgrep": {
      "command": "uvx",
      "args": ["semgrep-mcp"]
    }
  }
}

See Windsurf docs for more info.

Claude Desktop

Here is a short video showing Claude Desktop using this server to write a custom rule.

Add the following JSON block to your claude_desktop_config.json file:

{
  "mcpServers": {
    "semgrep": {
      "command": "uvx",
      "args": ["semgrep-mcp"]
    }
  }
}

See Anthropic docs for more info.

Claude Code

claude mcp add semgrep uvx semgrep-mcp

See Claude Code docs for more info.

OpenAI

See the offical docs:

Agents SDK

async with MCPServerStdio(
    params={
        "command": "uvx",
        "args": ["semgrep-mcp"],
    }
) as server:
    tools = await server.list_tools()

See OpenAI Agents SDK docs for more info.

Custom clients

Example Python SSE client

See a full example in examples/sse_client.py

from mcp.client.session import ClientSession
from mcp.client.sse import sse_client


async def main():
    async with sse_client("http://localhost:8000/sse") as (read_stream, write_stream):
        async with ClientSession(read_stream, write_stream) as session:
            await session.initialize()
            results = await session.call_tool(
                "semgrep_scan",
                {
                    "code_files": [
                        {
                            "path": "hello_world.py",
                            "content": "def hello(): print('Hello, World!')",
                        }
                    ]
                },
            )
            print(results)
TIP

Some client libraries want theURL: http://localhost:8000/sse and others only want the HOST: localhost:8000. Try out the URL in a web browser to confirm the server is running, and there are no network issues.

See official SDK docs for more info.

Contributing, community, and running from source

NOTE

We love your feedback, bug reports, feature requests, and code. Join the#mcp community Slack channel!

See CONTRIBUTING.md for more info and details on how to run from the MCP server from source code.

Similar tools 🔍

Community projects 🌟

MCP server registries

Made with ❤️ by the Semgrep Team

Available Tools

6 tools
get_scan_resultsC

Gets the results of a completed scan

Args: scan_id: Identifier for the scan

Returns: Dictionary with scan results

ParametersJSON Schema
NameRequiredDescriptionDefault
scan_idYes

TDQS

C2.9/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 states the tool retrieves results but doesn't specify what 'results' include (e.g., findings, logs, errors), whether it's idempotent, or any rate limits or authentication requirements. This leaves significant gaps for a tool that likely returns critical data.

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 appropriately sized and front-loaded, with the core purpose stated first. The Args and Returns sections are structured but could be more integrated; however, there's no wasted text, making it efficient for an agent to parse.

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 scan results (implied by sibling tools like 'semgrep_scan'), no annotations, and no output schema, the description is insufficient. It doesn't explain what 'results' entail (e.g., structured data, errors, completion status), leaving the agent unprepared for the tool's output or potential edge cases.

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 adds minimal semantics beyond the input schema: it names the parameter 'scan_id' and indicates it's an 'Identifier for the scan'. With 0% schema description coverage and only one parameter, this provides basic context but lacks details like format (e.g., UUID, numeric) or where to obtain it, resulting in an adequate baseline score.

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 as 'Gets the results of a completed scan', which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_scan_status', which might retrieve different metadata about scans.

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 doesn't mention prerequisites (e.g., that the scan must be completed), nor does it compare to siblings like 'get_scan_status' or 'start_scan', leaving the agent to infer usage context.

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

get_scan_statusC

Gets the current status of a scan

Args: scan_id: Identifier for the scan

Returns: Dictionary with scan status information

ParametersJSON Schema
NameRequiredDescriptionDefault
scan_idYes

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 carries full burden. It mentions returning a 'Dictionary with scan status information' but doesn't disclose behavioral traits like whether this is a read-only operation, if it requires specific permissions, potential rate limits, or what happens with invalid scan IDs. For a tool with zero annotation coverage, this leaves significant gaps.

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 appropriately sized and front-loaded, with the core purpose stated first. The Args and Returns sections are structured but could be more concise; for example, 'Identifier for the scan' is somewhat redundant. Overall, it's efficient with little waste.

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 (a status-checking tool with no annotations, no output schema, and 0% schema coverage), the description is incomplete. It doesn't explain what 'status information' includes, potential error conditions, or how it relates to sibling tools. For a tool that likely interacts with scanning processes, more context is needed for effective use.

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 adds minimal semantics beyond the input schema. It states 'scan_id: Identifier for the scan', which slightly clarifies the parameter's purpose, but with 0% schema description coverage and only one parameter, this doesn't fully compensate. The baseline for 0 parameters would be 4, but here there's one parameter with inadequate documentation, warranting an average score.

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 with a specific verb ('Gets') and resource ('current status of a scan'), making it immediately understandable. However, it doesn't explicitly differentiate this from sibling tools like 'get_scan_results' or 'start_scan', which would be needed for a perfect score.

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 siblings like 'get_scan_results' and 'start_scan', there's no indication whether this should be used during an active scan, after completion, or how it differs from getting results. The agent must infer usage from the name alone.

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

get_supported_languagesC

Returns a list of supported languages by Semgrep

Returns: List of supported languages

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

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 carries the full burden. It only states the return type ('List of supported languages') without disclosing behavioral traits such as whether this is a read-only operation, if it requires authentication, rate limits, or error conditions. For a tool with zero annotation coverage, this is insufficient transparency.

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 brief and front-loaded, stating the purpose in the first sentence. However, the second sentence ('Returns: List of supported languages') is redundant, repeating information from the first sentence without adding value. This minor inefficiency prevents a perfect score.

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

Completeness3/5

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

Given the tool's low complexity (0 parameters, no output schema), the description is minimally adequate. It covers the basic purpose but lacks context on usage, behavioral details, or integration with siblings. Without annotations or output schema, the description should do more to compensate, but it meets the minimum viable threshold for such a simple 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 tool has 0 parameters, and the schema description coverage is 100% (as there are no parameters to describe). The description doesn't need to add parameter semantics beyond what the schema provides. A baseline score of 4 is appropriate for zero-parameter tools, as there's no gap to compensate for.

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 tool 'Returns a list of supported languages by Semgrep', which clearly identifies the verb ('Returns') and resource ('list of supported languages'). However, it doesn't differentiate this from sibling tools like 'get_scan_results' or 'semgrep_scan', which might also involve language-related operations. The purpose is clear but lacks sibling differentiation.

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 doesn't mention prerequisites, context (e.g., before starting a scan), or exclusions. With sibling tools like 'semgrep_scan' that might depend on language support, this omission leaves the agent without usage direction.

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

semgrep_scanA

Runs a Semgrep scan on provided code content and returns the findings in JSON format

Args: code_files: List of dictionaries with 'filename' and 'content' keys config: Semgrep configuration (e.g. "auto" or absolute path to rule file)

Returns: Dictionary with scan results in Semgrep JSON format

ParametersJSON Schema
NameRequiredDescriptionDefault
code_filesYes
configNoauto

TDQS

A4.1/5.0
Behavior3/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 the tool runs a scan and returns JSON findings, which covers basic operation, but lacks details on performance (e.g., execution time, resource usage), error handling, or any constraints like rate limits or authentication needs. This leaves gaps in understanding the tool's behavior beyond the core function.

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

Conciseness5/5

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

The description is front-loaded with the core purpose in the first sentence, followed by structured sections for Args and Returns. Each sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse for an AI agent.

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?

For a tool with 2 parameters, no annotations, and no output schema, the description is adequate but has clear gaps. It explains the input parameters and return format, but lacks details on output structure (beyond 'JSON format'), error cases, or integration with sibling tools. This makes it minimally viable but incomplete for full contextual understanding.

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?

Given schema description coverage is 0%, the description compensates well by explaining both parameters: 'code_files' as a list of dictionaries with 'filename' and 'content' keys, and 'config' with examples ('auto' or path to rule file). This adds meaningful context beyond the bare schema, though it could elaborate on format specifics (e.g., JSON structure for code_files) to fully bridge the coverage gap.

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 purpose with specific verb ('Runs a Semgrep scan') and resource ('on provided code content'), and distinguishes it from siblings like 'get_scan_results' or 'start_scan' by specifying it operates on provided content rather than stored or initiated scans. It explicitly mentions the output format ('returns the findings in JSON format'), which helps differentiate its function.

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 implies usage context by specifying 'provided code content,' suggesting this tool is for immediate scanning of given data, unlike siblings that might retrieve stored results or start background scans. However, it does not explicitly state when to use this tool versus alternatives like 'start_scan_from_content' or provide exclusions, leaving some ambiguity in sibling differentiation.

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

start_scanC

Starts a Semgrep scan with progress updates via notifications

Args: ctx: MCP context for sending notifications target_path: Absolute path to the file or directory to scan config: Semgrep configuration (e.g. "auto" or absolute path to rule file)

Returns: Dictionary with scan information

ParametersJSON Schema
NameRequiredDescriptionDefault
configNoauto
target_pathYes

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 carries the full burden of behavioral disclosure. It mentions 'progress updates via notifications,' which adds some context beyond basic functionality. However, it omits critical details like error handling, performance impacts, or whether the scan runs asynchronously, leaving significant gaps for a tool that initiates a scan.

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 well-structured and front-loaded with the core purpose, followed by parameter explanations. It uses bullet-like formatting for Args and Returns, making it easy to parse. While efficient, the inclusion of 'ctx' (an MCP context parameter) adds minor verbosity without clear user value, slightly reducing conciseness.

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 starting a scan with no annotations or output schema, the description is incomplete. It lacks details on return value structure (beyond 'Dictionary with scan information'), error conditions, or how notifications work. For a tool with behavioral implications and multiple siblings, this leaves too many unknowns for effective agent use.

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?

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining 'config' as 'Semgrep configuration (e.g., "auto" or absolute path to rule file)' and 'target_path' as 'Absolute path to the file or directory to scan,' which clarifies usage beyond the schema. However, it doesn't cover all nuances, such as format constraints or default behaviors, keeping it at a baseline level.

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: 'Starts a Semgrep scan with progress updates via notifications.' It specifies the verb ('Starts'), resource ('Semgrep scan'), and a key behavioral trait ('progress updates via notifications'). However, it doesn't explicitly differentiate from sibling tools like 'semgrep_scan' or 'start_scan_from_content', which prevents a score of 5.

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 siblings like 'semgrep_scan' and 'start_scan_from_content', it fails to indicate scenarios where this tool is preferred, such as for real-time notifications or specific input types. This lack of comparative context leaves usage ambiguous.

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

start_scan_from_contentC

Starts a Semgrep scan with code content provided directly

Args: ctx: MCP context for sending notifications code_files: List of dictionaries with 'filename' and 'content' keys config: Semgrep configuration (e.g. "auto" or absolute path to rule file)

Returns: Dictionary with scan information

ParametersJSON Schema
NameRequiredDescriptionDefault
code_filesYes
configNoauto

TDQS

C2.9/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 'starts a scan' which implies an asynchronous operation, but doesn't describe what happens after starting (e.g., returns immediately, triggers background job), error handling, performance characteristics, or authentication requirements. The return value description is minimal ('Dictionary with scan information').

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 appropriately sized with 4 sentences. It front-loads the core purpose, then provides parameter details in a structured Args/Returns format. No wasted sentences, though the 'ctx' parameter explanation is minimal. The formatting with clear sections enhances readability.

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

Completeness3/5

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

Given 2 parameters with 0% schema coverage and no output schema, the description provides basic parameter semantics but lacks comprehensive behavioral context. For a tool that starts scans (potentially asynchronous/long-running operations), more detail about execution flow, error cases, and result structure would be helpful. The absence of annotations increases the burden on the description.

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?

Schema description coverage is 0%, so the description must compensate. It provides meaningful context for both parameters: 'code_files' is explained as 'List of dictionaries with 'filename' and 'content' keys' and 'config' as 'Semgrep configuration (e.g. "auto" or absolute path to rule file)'. However, it doesn't explain the 'ctx' parameter at all, and the examples for 'config' are limited without explaining what 'auto' means or rule file format.

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 verb ('starts') and resource ('a Semgrep scan') with the specific mechanism 'with code content provided directly'. It distinguishes from sibling 'semgrep_scan' and 'start_scan' by specifying content-based scanning rather than file-based or repository-based scanning. However, it doesn't explicitly contrast with all siblings like 'get_scan_results' or 'get_supported_languages'.

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 doesn't mention when to choose this over 'semgrep_scan' or 'start_scan', nor does it specify prerequisites, constraints, or typical use cases. The agent must infer usage from the name and description alone without explicit 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. Dates show when Glama detected each change.

  1. 6 tool updatesv1.0.0
    • First observedget_scan_results
    • First observedget_scan_status
    • First observedget_supported_languages
    • First observedsemgrep_scan
    • First observedstart_scan
    • First observedstart_scan_from_content
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation3/5

There is significant functional overlap between tools, particularly between semgrep_scan, start_scan, and start_scan_from_content, which all perform scanning operations with different interfaces. However, the descriptions clarify the distinctions between immediate vs. asynchronous scans and file-based vs. content-based inputs, helping agents differentiate them.

Naming Consistency4/5

Tool names follow a consistent snake_case pattern with clear verb_noun structure (e.g., get_scan_results, start_scan). The only minor deviation is semgrep_scan, which uses the product name as a prefix rather than a verb, but this maintains readability and domain context.

Tool Count5/5

With 6 tools, this server is well-scoped for code security scanning. It covers core operations like initiating scans, checking status, retrieving results, and getting language support, without being overly complex or sparse for the domain.

Completeness4/5

The toolset provides comprehensive coverage for scanning workflows, including both synchronous and asynchronous options, status tracking, and result retrieval. A minor gap is the lack of tools for managing scan configurations or rules beyond basic usage, but core operations are well-covered.

Maintenance

ActivityInactive
ResponsivenessNo issues

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 Server Semgrep

    VetCoders
    A
    license
    B
    quality
    A
    maintenance
    A Model Context Protocol compliant server that integrates Semgrep static analysis tool with AI assistants like Anthropic Claude, enabling advanced code analysis, security vulnerability detection, and code quality improvements through a conversational interface.
    7
    430
    28
    MIT

  • scanline

    mrzadexinho
    A
    license
    Not graded
    quality
    D
    maintenance
    Security scanning MCP server. Semgrep integration, SARIF parsing, baseline diffing, framework-aware ruleset selection, and automated finding triage.
    16
    1
    MIT

Appeared in Searches

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/semgrep/mcp'

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