How do I use Ghost Security MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Ghost Security MCP Server show my security findings for the main repository" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Ghost Security MCP Server

Official

by ghostsecurity

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Ghost Security MCP Server

A Model Context Protocol (MCP) server for the Ghost Security API, providing secure access to security findings and repository data through standardized tools.

Features

Security Findings Management: Query, retrieve, and update security findings
Repository Analysis: Access repository data and associated findings
Universal MCP Compatibility: Works with any MCP-compatible client or application
Bundled CLI Chatbot: Includes a simple chatbot for quick interaction
Comprehensive API Coverage: Full support for Ghost Security API (V2) endpoints
Type Safety: Complete TypeScript implementation with proper typing
Error Handling: Robust error handling and validation

Related MCP server: CyberMCP

Installation

Quick Install for Claude Code CLI

Option 1: Interactive Installer (Easiest)

# Clone and build
git clone https://github.com/ghostsecurity/ghost-mcp-server
cd ghost-mcp-server
npm install && npm run build

# Run interactive installer (prompts for API key)
npm run install:interactive

Option 2: Automated Setup Script

# Clone and build
git clone https://github.com/ghostsecurity/ghost-mcp-server
cd ghost-mcp-server
npm install && npm run build

# Run setup script with your API key
./setup-claude-code.sh YOUR_API_KEY

# Optional: Scope to a specific repository
./setup-claude-code.sh YOUR_API_KEY YOUR_REPO_ID

Option 3: Manual Setup

# Clone and build
git clone https://github.com/ghostsecurity/ghost-mcp-server
cd ghost-mcp-server
npm install && npm run build

# Add to Claude Code
claude mcp add --transport stdio --scope user ghost-security -- node $(pwd)/dist/index.js

# Then edit ~/.claude.json and add under mcpServers.ghost-security.env:
# {
#   "GHOST_SECURITY_API_KEY": "your-api-key",
#   "GHOST_SECURITY_BASE_URL": "https://api.ghostsecurity.ai/v2"
# }

Option 4: From npm (Coming Soon)

Once published to npm, installation will be even simpler:

claude mcp add --transport stdio --scope user ghost-security -- npx ghostsecurity-mcp

Then add your API key to ~/.claude.json:

{
  "mcpServers": {
    "ghost-security": {
      "env": {
        "GHOST_SECURITY_API_KEY": "your-api-key-here",
        "GHOST_SECURITY_BASE_URL": "https://api.ghostsecurity.ai/v2"
      }
    }
  }
}

Standard Installation (All MCP Clients)

Clone this repository:

git clone <repository-url>
cd ghost-mcp-server

Install dependencies:

npm install

Build the project:

npm run build

Usage

Configuration

The server requires a Ghost Security API key to be provided at startup. You can provide it in two ways:

Option 1: Environment Variable (Recommended)

export GHOST_SECURITY_API_KEY="your-ghost-security-api-key"
export GHOST_SECURITY_BASE_URL="https://api.ghostsecurity.ai/v2"  # optional, defaults to v2
export GHOST_SECURITY_REPO_ID="your-repository-id"  # optional - scope to specific repo

Option 2: Command Line Argument

node dist/index.js "your-ghost-security-api-key" "your-repository-id"

Note: Repository ID is optional. If provided, all operations will be scoped to that repository.

Running the Server

For development:

# Set environment variable first
export GHOST_SECURITY_API_KEY="your-api-key"
npm run dev

For production:

# Either with environment variable
export GHOST_SECURITY_API_KEY="your-api-key"
npm start

# Or with command line argument
npm run build
node dist/index.js "your-api-key"

CLI Chatbot

This project includes a simple CLI chatbot powered by Anthropic's Claude API that can interact with the MCP server.

export ANTHROPIC_API_KEY="your-anthropic-api-key"
export GHOST_SECURITY_API_KEY="your-ghost-api-key"
npm run chat

Adding to Any MCP Client

This server follows the standard MCP configuration format. Here are examples for different clients:

Standard MCP Configuration (Claude Desktop, ChatGPT, etc.)

{
  "mcpServers": {
    "ghostsecurity": {
      "command": "node",
      "args": ["/path/to/ghost-mcp-server/dist/index.js"],
      "env": {
        "GHOST_SECURITY_API_KEY": "your-ghost-security-api-key",
        "GHOST_SECURITY_REPO_ID": "your-repository-id"
      }
    }
  }
}

Environment Variable Setup (Universal)

For any MCP client that supports environment variables:

export GHOST_SECURITY_API_KEY="your-ghost-security-api-key"
export GHOST_SECURITY_BASE_URL="https://api.ghostsecurity.ai/v2"
export GHOST_SECURITY_REPO_ID="your-repository-id"

Repository Scoping

When a repository ID is configured via GHOST_SECURITY_REPO_ID environment variable or CLI argument:

ghostsecurity_get_findings returns findings only for that repository
ghostsecurity_get_repositories returns only the configured repository
ghostsecurity_get_repository_findings uses the configured repository as default (repoId parameter becomes optional)

Available Tools

Security Findings

`ghostsecurity_get_findings`

Get security findings with optional filtering and pagination.

Parameters:

cursor (string, optional): Pagination cursor
sort (string, optional): Sort field (created_at, updated_at)
order (string, optional): Sort order (asc, desc)
size (number, optional): Page size (1-1000)
status (string, optional): Filter by status
repo_id (string, optional): Filter by repository ID
project_id (string, optional): Filter by project ID

`ghostsecurity_get_finding`

Get a specific security finding by ID.

Parameters:

id (string, required): Finding ID
repoId (string, required): Repository ID associated with the finding
projectId (string, required): Project ID associated with the finding

`ghostsecurity_update_finding_status`

Update the status of a security finding.

Parameters:

id (string, required): Finding ID
repoId (string, required): Repository ID associated with the finding
projectId (string, required): Project ID associated with the finding
status (string, required): New status for the finding

Repositories

`ghostsecurity_get_repositories`

Get repositories with optional filtering and pagination.

Parameters:

cursor (string, optional): Pagination cursor
sort (string, optional): Sort field (created_at, updated_at, last_committed_at)
order (string, optional): Sort order (asc, desc)
size (number, optional): Page size (1-1000)

`ghostsecurity_get_repository`

Get a specific repository by ID.

Parameters:

id (string, required): Repository ID

`ghostsecurity_get_repository_findings`

Get security findings for a specific repository.

Parameters:

repoId (string, optional*): Repository ID (*required unless GHOST_SECURITY_REPO_ID is configured)
cursor (string, optional): Pagination cursor
sort (string, optional): Sort field (created_at, updated_at)
order (string, optional): Sort order (asc, desc)
size (number, optional): Page size (1-1000)

Publishing to MCP Registry

This server is configured for publishing to the MCP Registry.

Install Publisher CLI:
```
brew install mcp-publisher
```
Login:
```
mcp-publisher login github
```
Publish:
```
mcp-publisher publish
```

The server.json file contains the necessary metadata. Ensure you have published the package to NPM before publishing to the registry.

Development

Scripts

npm run dev: Run in development mode with hot reload
npm run build: Build TypeScript to JavaScript
npm start: Run the built server
npm run chat: Run the CLI chatbot

Project Structure

src/
├── index.ts          # Main MCP server implementation
├── ghost-client.ts   # Ghost Security API client (V2)
├── types.ts          # TypeScript type definitions
└── chatbot.ts        # CLI Chatbot implementation

API Reference

This MCP server provides a complete interface to the Ghost Security API V2. For detailed API documentation, visit: https://docs.ghostsecurity.ai/api-reference/introduction

License

MIT

Available Tools

7 tools

ghostsecurity_count_findingsB

Get count and statistics of security findings

ParametersJSON Schema

Name	Required	Description
`sort`	No	Sort field
`order`	No	Sort order
`status`	No	Filter by status
`repo_id`	No	Filter by repository ID
`project_id`	No	Filter by project ID

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states the basic function without mentioning any side effects, permissions, or limitations. The brevity leaves agents unaware of important context like whether this is a read-only operation.

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

Conciseness4/5

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

The description is a single sentence, which is concise and front-loaded. It wastes no words, but for a tool with 5 parameters, slightly more detail could be justified.

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 5 optional parameters, 2 enums, and no output schema, the description fails to explain what statistics are returned or how parameters influence results. The tool is under-documented for an agent to use effectively.

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 input schema has 100% description coverage, so the baseline is 3. The description adds no additional meaning beyond what the schema provides, such as explaining how parameters affect the count or statistics.

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 'count and statistics of security findings', using a specific verb and resource. It distinguishes from sibling tools like ghostsecurity_get_findings which return the findings list itself.

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 does not explicitly state when to use this tool versus alternatives. It is implied for aggregated data, but no direct guidance or exclusion criteria are provided.

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

ghostsecurity_get_findingA

Get a specific security finding by ID (requires repository and project context)

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Finding ID
`repoId`	Yes	Repository ID associated with the finding
`projectId`	Yes	Project ID associated with the finding

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose all behavioral traits. It only states it retrieves a finding, with no mention of side effects, permissions, rate limits, or response behavior. This is minimal transparency for a read operation.

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 sentence that immediately states the purpose and context. No unnecessary words or repetition.

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 simple read tool, the description is adequate but lacks details about the response format or return value. With no output schema, the agent may benefit from knowing what fields to expect.

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 input schema already describes each parameter with 100% coverage. The description adds no new meaning beyond what the schema provides, confirming the baseline score of 3.

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 uses specific verb ('Get') and resource ('specific security finding by ID') and clarifies the required context (repository and project). This clearly distinguishes from sibling tools like ghostsecurity_get_findings (plural) and ghostsecurity_count_findings.

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

Usage Guidelines3/5

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

The description implies when to use by stating requirements (repository and project context), but does not explicitly state when not to use or mention alternative tools. No guidance on prerequisites or exclusions is provided.

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

ghostsecurity_get_findingsB

Get security findings with optional filtering and pagination

ParametersJSON Schema

Name	Required	Description
`cursor`	No	Pagination cursor
`sort`	No	Sort field
`order`	No	Sort order
`size`	No	Page size (1-1000)
`mode`	No	Response mode: summary (lightweight), detailed (full), or count (statistics only)
`fields`	No	Specific fields to include in response (works with summary mode)
`status`	No	Filter by status
`repo_id`	No	Filter by repository ID
`project_id`	No	Filter by project ID

TDQS

B3/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. It only mentions filtering and pagination but does not disclose pagination mechanics (e.g., cursor-based), rate limits, or authentication requirements. Insufficient for safe agent invocation.

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

Conciseness3/5

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

Single sentence is concise but omits important context. Acceptable length given simplicity, but could be more informative without excess.

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 9 parameters, no output schema, and zero annotations, the description is too brief. Missing details on response format, typical use patterns, and interaction with pagination/filtering.

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 coverage is 100% with detailed parameter descriptions. The description adds no value beyond summarizing 'optional filtering and pagination'. Baseline 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?

Description clearly states the tool retrieves security findings with optional filtering and pagination. However, it does not explicitly differentiate from sibling tools like ghostsecurity_get_repository_findings or ghostsecurity_count_findings.

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?

Implied usage: use for fetching filtered lists of findings. No explicit guidance on when to use this versus alternatives like ghostsecurity_count_findings or ghostsecurity_get_finding.

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

ghostsecurity_get_repositoriesB

Get repositories with optional filtering and pagination

ParametersJSON Schema

Name	Required	Description
`cursor`	No	Pagination cursor
`sort`	No	Sort field
`order`	No	Sort order
`size`	No	Page size (1-1000)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It mentions pagination but does not disclose read-only nature, auth requirements, rate limits, or other behavioral traits. Requires more detail for safe usage.

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?

Single sentence is concise and front-loaded with purpose. No wasted words, but could be structured with more detail without losing brevity.

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

Completeness2/5

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

No output schema and description does not explain return format or behavior with empty results. For a paginated list tool, missing context on output structure reduces completeness.

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 baseline is 3. Description adds no additional meaning beyond summarizing parameters as 'optional filtering and pagination'. Does not compensate for low coverage (not applicable here).

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?

Description states 'Get repositories' with optional filtering and pagination, clearly identifying the verb and resource. It distinguishes from singular 'get_repository' sibling by implication, but does not explicitly differentiate.

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?

Implied usage for listing repositories, but no explicit guidance on when to use this vs alternatives like get_repository or get_repository_findings. 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.

ghostsecurity_get_repositoryA

Get a specific repository by ID

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Repository ID

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, and the description is minimal. It states the action without detailing side effects, authentication needs, or what happens if the ID is not found, which is acceptable for a simple read operation 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?

A single, front-loaded sentence that directly states the tool's purpose with no extraneous words.

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 simplicity of the tool (1 parameter, no output schema), the description is adequate but could mention return behavior (e.g., repository details or error handling) for full completeness.

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%, and the description adds no additional meaning beyond what the schema already provides for the single parameter 'id'.

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 uses a specific verb 'Get' with a clear object 'specific repository by ID', directly distinguishing it from the sibling tool 'ghostsecurity_get_repositories' which retrieves a list.

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 vs alternatives, but the context implies it is for a single repository by ID, contrasting with the plural sibling for lists.

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

ghostsecurity_get_repository_findingsC

Get security findings for a specific repository

ParametersJSON Schema

Name	Required	Description
`repoId`	Yes	Repository ID
`cursor`	No	Pagination cursor
`sort`	No	Sort field
`order`	No	Sort order
`size`	No	Page size (1-1000)
`mode`	No	Response mode: summary (lightweight), detailed (full), or count (statistics only)
`fields`	No	Specific fields to include in response (works with summary mode)
`status`	No	Filter by status

TDQS

C2.6/5.0

Behavior1/5

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

No annotations are provided, and the description is extremely brief ('Get'). It fails to disclose whether the operation is read-only, requires authentication, has rate limits, or any other behavioral traits. The description carries the full burden but adds no 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 a single short sentence, which is concise. However, it is almost too minimal, bordering on under-specification. It earns points for brevity but loses some for lack of structure.

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

Completeness1/5

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

The tool has 8 parameters with enums and pagination, yet the description provides no context about how they work, filter behavior, or output format. With no output schema, the description should compensate but fails completely.

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 documents all parameters. The description adds no additional meaning beyond what is in 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.

Purpose5/5

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

The description clearly states it gets security findings for a specific repository, using a specific verb and resource. It implicitly distinguishes from siblings like ghostsecurity_get_finding (single) and ghostsecurity_get_findings (likely all findings) through the inclusion of 'repository' in the name.

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

Usage Guidelines1/5

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 such as ghostsecurity_get_findings or ghostsecurity_count_findings. The description provides no context for selection.

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

ghostsecurity_update_findingA

Update a security finding (status and/or comments). At least one of status or comments must be provided.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Finding ID
`repoId`	Yes	Repository ID associated with the finding
`projectId`	Yes	Project ID associated with the finding
`status`	No	New user_status for the finding
`comments`	No	Comments on the finding (0-512 chars). Send empty string to clear.

TDQS

A3.7/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only discloses that the tool updates status and/or comments. Missing details on side effects, authorization needs, error handling, or what happens if the finding doesn't exist.

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?

Extremely concise: one sentence with a condition. No unnecessary words or repetition.

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 no output schema and no annotations, the description is somewhat adequate for a simple update tool. However, it lacks information about return values, error scenarios, and the effect of providing both parameters simultaneously.

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?

Schema coverage is 100%, baseline 3. The description adds the constraint that at least one of status or comments must be provided, which is not enforced by the schema alone. This helps the agent understand usage requirements.

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?

Clearly states the verb 'Update' and resource 'security finding', and specifies the aspects (status and/or comments). This distinguishes it from sibling tools like get_finding or get_findings.

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?

Implicitly indicates usage for updating status or comments, but lacks explicit guidance on when not to use or mention of alternatives. The condition 'at least one of status or comments' is stated, but no exclusion criteria.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool targets a distinct operation: counting, retrieving specific findings, filtering findings, retrieving repositories, retrieving a specific repository, repository-scoped findings, and updating findings. No overlapping purposes exist.

Naming Consistency5/5

All tools follow a consistent 'ghostsecurity_verb_noun' pattern (e.g., ghostsecurity_get_findings, ghostsecurity_update_finding). The naming is predictable and uniform.

Tool Count5/5

7 tools is well-scoped for a security findings server, covering essential read and limited write operations without being excessive or insufficient.

Completeness4/5

The tool surface covers core functionality (CRUD for findings, read for repositories) but lacks operations like creating or deleting findings, which may be intentional given typical security workflows.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

mcp-server
com.pentest-tools
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Penetration Testing Security
23
MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
Security Mcp A
io.github.varvararatta
MCP server for Security
Security Penetration Testing
2
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237

Related MCP Servers

OpenCTI MCP Server
Security Search Databases
zxzinn
A
license
A
quality
C
maintenance
A Model Context Protocol server that facilitates integration with OpenCTI, allowing users to query and retrieve cyber threat intelligence data via a standardized interface.
Updated a month ago (2026-08-03 01:14 UTC)
16
40
MIT
CyberMCP
API Testing Penetration Testing Security
ricauts
A
license
C
quality
D
maintenance
A Model Context Protocol server designed for testing backend APIs for security vulnerabilities like authentication bypass, injection attacks, and data leakage.
Updated a year ago (2025-05-28 05:19 UTC)
14
16
MIT
Socket MCP Server
Developer Tools Security Search
SocketDev
A
license
A
quality
A
maintenance
A Model Context Protocol (MCP) server for Socket integration, allowing AI assistants to efficiently check dependency vulnerability scores and security information.
Updated 7 days ago (2026-08-27 22:04 UTC)
1
1,665
132
MIT
MCPwner
Penetration Testing Code Analysis
nedlir
A
license
Not graded
quality
A
maintenance
Model Context Protocol server for security research automation, integrating multiple security testing tools into LLM-driven workflows for secret scanning, static analysis, and vulnerability discovery.
Updated 14 days ago (2026-08-20 21:42 UTC)
54
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/ghostsecurity/ghost-mcp-server'

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