Skip to main content
Glama
SymbioticSec

Symbiotic MCP Server

Official
by SymbioticSec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Symbiotic MCP Server

A Model Context Protocol (MCP) server for security analysis using Symbiotic CLI

Description

This server exposes security analysis tools via the MCP protocol for any MCP-compatible client. It allows scanning code and infrastructure files without affecting your workspace.

Available Tools

  • code_scan_files - Static code analysis

  • infra_scan_files - Infrastructure security scanning

  • security_scan_files - Comprehensive security scan (code + infrastructure)

  • get_supported_languages - List of supported programming languages

Related MCP server: agentguard

Cursor Integration

Setting up the Security Review Command

  1. Create a .cursor directory in your project root if it doesn't exist

  2. Create or update .cursor/commands/security-review.md with the contents of security-review.md

Using the Command

  1. Open the chat panel in Cursor (Cmd+L or Ctrl+L)

  2. Type /security-review followed by optional file paths or glob patterns

  3. The command will perform a comprehensive security analysis, including:

    • Scanning selected files or the entire workspace

    • Analyzing for security vulnerabilities

    • Triaging findings and filtering false positives

    • Providing a detailed report with severity levels and remediation suggestions

    • Offering to apply automatic fixes for identified issues

Installation

  1. Install symbiotic-cli

https://github.com/SymbioticSec/cli/releases

  1. Get API token

Create an account on Symbiotic Security and retrieve your API token.

  1. Build and start

Clone this repository and install dependencies:

npm install
npm run build

MCP Configuration

In VSCode, open MCP: Open User Configuration and add in servers:

{
 "servers": {
  "symbiotic-security": {
       "command": "node",
      "args": ["path/to/build/index.js"],
      "env": {
        "SYMBIOTIC_API_TOKEN": "your_token_here",
    }
  },
}

Configuration for other MCP clients may vary but generally follows the same structure.

{
  "mcpServers": {
    "symbiotic-security": {
      "command": "node",
      "args": ["path/to/build/index.js"],
      "env": {
        "SYMBIOTIC_API_TOKEN": "your_token_here"
      }
    }
  }
}

Important environment variables:

  • SYMBIOTIC_API_TOKEN (required) - Your Symbiotic API token

Note: Configuration file name and location may vary depending on your MCP client.

Transport Modes

  • STDIO (default) - Standard communication for MCP

  • SSE - Server-Sent Events over HTTP

  • Streamable HTTP - HTTP with /mcp endpoint

# STDIO (default)
node build/index.js

# HTTP server on port 9593
SERVER_PORT=9593 node build/index.js

Authentication

The server requires a valid Symbiotic Security API token. Configuration is done via MCP environment variables.

Minimal required configuration:

"env": {
  "SYMBIOTIC_API_TOKEN": "your_token_here"
}

How It Works

  1. Receives code files via MCP

  2. Creates temporary files

  3. Executes symbiotic-cli

  4. Automatic cleanup of temporary files

  5. Returns formatted results

Available Tools

4 tools
code_scan_filesB

Run Symbiotic CLI code analysis on provided code files - creates temporary files, scans them, and cleans up. Ideal for analyzing code snippets or specific files for security vulnerabilities without affecting the workspace.

ParametersJSON Schema
NameRequiredDescriptionDefault
code_filesNoArray of code files to process
codeFilesNoArray of code files to process (alias)
filesNoArray of code files to process (alias)

TDQS

B3.4/5.0
Behavior4/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 discloses key behaviors: creates temporary files, scans them, and cleans up, with no impact on the workspace. This is important for a tool that modifies temporary state. Missing details on authentication or rate limits, but the core behavioral profile is well communicated.

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

Conciseness5/5

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

The description is two sentences long, front-loaded with the core action and cleanup. Every word adds value with no redundancy. It efficiently conveys the tool's purpose and key behavioral note.

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

Completeness2/5

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

With no output schema and no annotations, the description should compensate by explaining return values or scan results. It does not mention what the tool returns (e.g., scan results, vulnerabilities). It also omits prerequisites, supported file types (though get_supported_languages exists), and error handling. The description is too brief for a tool with zero annotation coverage.

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

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for each parameter, but all three parameters (code_files, codeFiles, files) have identical descriptions indicating they are aliases. The description does not explain why there are three aliases or which one to use, causing potential confusion. This ambiguity reduces the value added beyond the schema.

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 that the tool runs Symbiotic CLI code analysis on provided code files, mentioning temporary file creation and cleanup. It differentiates from sibling tools by specifying 'code analysis' and 'without affecting workspace', but does not explicitly name alternatives like 'security_scan_files' or 'infra_scan_files' for comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'Ideal for analyzing code snippets or specific files for security vulnerabilities without affecting the workspace', which implies usage for ad-hoc scanning. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like get_supported_languages for language info.

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

get_supported_languagesA

Returns comprehensive list of programming languages supported by Symbiotic CLI security scanners for both code and infrastructure analysis

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.1/5.0
Behavior3/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 says 'returns comprehensive list', but does not elaborate on caching, authentication, or any side effects. For a simple parameterless retrieval, this is adequate but lacks depth.

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

Conciseness5/5

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

The description is a single, well-structured sentence that immediately conveys the tool's purpose. It is front-loaded with the key action and resource, with no unnecessary words.

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

Completeness5/5

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

Given the tool has no parameters, no output schema, and no annotations, the description sufficiently covers the tool's function. It tells what the list contains (programming languages for code and infrastructure), which is all an agent needs to decide to invoke it.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and the description adds no parameter-specific information. According to guidelines, baseline for 0 parameters is 4, which is appropriate here.

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 returns a comprehensive list of programming languages supported by Symbiotic CLI security scanners, specifying 'both code and infrastructure analysis'. This distinguishes it from sibling scan tools that perform actual scanning actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus the sibling scanning tools. The usage is implied as a prerequisite to scanning, but the description does not state that directly or provide any exclusion criteria.

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

infra_scan_filesA

Run Symbiotic CLI infrastructure security scanner on provided files - creates temporary files, scans them, and cleans up. Ideal for analyzing Dockerfiles, Kubernetes manifests, Terraform configs, and other infrastructure-as-code files without affecting the workspace.

ParametersJSON Schema
NameRequiredDescriptionDefault
code_filesNoArray of code files to process
codeFilesNoArray of code files to process (alias)
filesNoArray of code files to process (alias)

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses key behavioral traits: creates temporary files, scans, and cleans up, and states it operates without affecting the workspace. However, it does not cover permissions, error handling, or rate limits.

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 consists of two concise sentences. The first sentence immediately states the core action and side effects, and the second provides ideal use cases. Every sentence adds value with no filler.

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

Completeness4/5

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

Given the tool takes file arrays and has no output schema, the description sufficiently covers the purpose, file types, and cleanup. It could have mentioned the return format, but the core behavior is well covered.

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 100%, so the schema already describes the parameters. The description adds no additional meaning about the file format or that there are three alias parameters, which could cause confusion. The baseline of 3 is appropriate.

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 runs an infrastructure security scanner on provided files, specifying it is for Dockerfiles, Kubernetes manifests, and Terraform configs. It differentiates from siblings implicitly by focusing on infrastructure-as-code, but does not explicitly contrast with sibling tools like code_scan_files or security_scan_files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool (analyzing infrastructure-as-code files) and mentions it does not affect the workspace. However, it does not include explicit when-not-to-use guidance or mention alternatives among sibling tools.

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

security_scan_filesA

Comprehensive security scan using Symbiotic CLI on provided files - creates temporary files, runs both code and infrastructure security analysis, and cleans up. Perfect for complete security analysis of code snippets and infrastructure files.

ParametersJSON Schema
NameRequiredDescriptionDefault
code_filesNoArray of code files to process
codeFilesNoArray of code files to process (alias)
filesNoArray of code files to process (alias)

TDQS

A3.7/5.0
Behavior3/5

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

Discloses creation of temporary files, running both analyses, and cleanup, but lacks information about permissions, error handling, return values, or potential side effects. With no annotations, the description carries full burden and misses some behavioral context.

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?

Two sentences efficiently convey key functionalities: scan type, tool used, temporary files, dual analysis, and cleanup. No redundant statements.

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?

Lacks explanation of the three seemingly redundant array parameters (code_files, codeFiles, files) and their relationship. Does not fully explain how it combines code and infrastructure scans compared to sibling tools. Output schema missing.

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 100% with each parameter described minimally. The tool description does not add meaningful information about parameters beyond the schema, resulting in a baseline score.

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

Purpose5/5

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

Description clearly states it performs a comprehensive security scan using Symbiotic CLI, covering both code and infrastructure analysis, which distinguishes it from sibling tools code_scan_files and infra_scan_files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies use for complete security analysis of both code and infrastructure files, but does not explicitly specify when to use this tool versus the separate code or infrastructure scan tools, nor provide any exclusions or prerequisites.

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.

  1. 4 tool updatesv1.0.0
    • First observedcode_scan_files
    • First observedget_supported_languages
    • First observedinfra_scan_files
    • First observedsecurity_scan_files
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 4 tools

Disambiguation3/5

Tools have distinct purposes (code scan vs infra scan vs combined), but security_scan_files overlaps with both code_scan_files and infra_scan_files, potentially causing confusion about which to use for code-only or infra-only scans.

Naming Consistency3/5

Three tools follow the pattern '<domain>_scan_files', but 'get_supported_languages' uses a different verb and noun structure, breaking consistency. The convention is mostly snake_case but lacks uniformity.

Tool Count5/5

With 4 tools, the server is well-scoped for its purpose: code scanning, infrastructure scanning, combined scanning, and language support query. No unnecessary bloat or deficiency.

Completeness4/5

Covers core scanning operations (code, infra, combined) and a utility for supported languages. Minor gaps like directory scanning or output formatting are absent but not critical for typical use.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • 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.
    5 npm
    1
    MIT

  • agentguard

    dockfixlabs
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables scanning of AI agent code for security vulnerabilities such as prompt injection, tool abuse, and data exfiltration, directly from MCP-compatible clients like Claude Code.
    2
    LGPL 3.0

  • scopeguard-mcp

    mzatylny
    A
    license
    A
    quality
    B
    maintenance
    Enables policy-first defensive security operations for MCP, providing repository and web-security analysis with controlled authorization, scoped execution, and auditability.
    9
    1
    MIT