Skip to main content
Glama
cbuntingde

leak-secure-mcp

by cbuntingde
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

Leak Secure MCP Server

Copyright 2025 Chris Bunting cbuntingde@gmail.com

npm version npm downloads

Enterprise-grade MCP (Model Context Protocol) server for detecting secrets and sensitive information in code repositories. This server provides AI agents with powerful tools to scan GitHub repositories and code snippets for over 35 types of secrets, including API keys, passwords, tokens, and credentials.

Features

  • 35+ Secret Types Detection: Comprehensive pattern matching for AWS keys, GitHub tokens, database credentials, API keys, private keys, and more

  • GitHub Integration: Scan entire repositories or specific paths with automatic file traversal

  • Security Analysis: Risk scoring, compliance status, and detailed remediation recommendations

  • Enterprise-Grade Architecture: Production-ready with enterprise-level reliability and security

  • MCP Protocol: Standardized interface for AI agents to interact with security scanning tools

Enterprise-Grade Features

  • Rate Limiting: Token bucket algorithm for GitHub API calls with configurable limits (default: 5000/hour, burst: 100)

  • Retry Logic: Exponential backoff with jitter for automatic retry of failed requests (configurable: 3 retries, 1s-30s delays)

  • Circuit Breaker: Prevents cascading failures with automatic recovery detection (CLOSED/OPEN/HALF_OPEN states)

  • Timeout Handling: Configurable timeouts for API requests (30s) and scan operations (5 minutes)

  • Input Validation: Zod-based schema validation for all tool inputs with sanitization

  • Structured Logging: Enterprise logging system with automatic secret sanitization and log levels

  • Error Handling: Custom error types with operational vs programming error distinction

  • Memory Efficiency: Batch processing, file size limits, and maximum file count protection

  • Graceful Shutdown: Handles SIGTERM/SIGINT with proper cleanup and operation completion

  • Enhanced Security: Advanced secret masking, input sanitization, and secure error messages

Supported Secret Types

The server detects secrets across multiple categories:

  • Cloud Provider: AWS, Google Cloud, Azure credentials

  • Version Control: GitHub tokens, OAuth tokens

  • Database: PostgreSQL, MySQL, MongoDB connection strings

  • Payment: Stripe, PayPal API keys

  • Communication: Twilio, SendGrid, Mailgun, Slack tokens

  • Social Media: Twitter, Facebook API keys

  • Cryptography: RSA, SSH, ECDSA private keys

  • Authentication: JWT tokens, OAuth tokens, access tokens

  • Generic: API keys, secrets, passwords

Installation

Prerequisites

  • Node.js 18.0.0 or higher

  • npm or yarn

  • GitHub Personal Access Token (optional, for private repositories)

Install from npm (Recommended)

Install the package globally or locally:

# Global installation
npm install -g leak-secure-mcp

# Or local installation
npm install leak-secure-mcp

The setup script will automatically run after installation and prompt you for your GitHub Personal Access Token. You can:

  • Enter your token when prompted (recommended)

  • Press Enter to skip and configure it later

  • Run npm run setup manually at any time to configure or update your token

Install from Source

  1. Clone the repository:

git clone <repository-url>
cd leak-secure-mcp

  1. Install dependencies:

npm install

The setup script will automatically run after installation and prompt you for your GitHub Personal Access Token.

  1. Build the project:

npm run build

Usage

Running the Server

The MCP server runs on stdio and communicates via the Model Context Protocol:

npm start

For development with auto-reload:

npm run dev

MCP Tools

The server provides the following tools:

1. scan_repository

Scan a GitHub repository for secrets with enterprise-grade reliability features including rate limiting, retry logic, and circuit breaker protection.

Parameters:

  • owner (required): GitHub repository owner (username or organization) - validated and sanitized

  • repo (required): Repository name - validated and sanitized

  • branch (optional): Branch to scan (default: "main") - validated format

  • path (optional): Specific path within repository to scan

Features:

  • Automatic rate limiting to respect GitHub API limits

  • Retry logic with exponential backoff for transient failures

  • Circuit breaker protection against cascading failures

  • Batch processing for memory efficiency (50 files per batch)

  • Timeout protection (5 minute default)

  • Maximum file limit protection (10,000 files default)

Example:

{
  "owner": "octocat",
  "repo": "Hello-World",
  "branch": "main"
}

2. scan_code

Scan a code snippet or file content for secrets with enhanced validation and false positive reduction.

Parameters:

  • code (required): Code content to scan (max 10MB) - validated size

  • filePath (optional): File path for context - helps with false positive reduction

Features:

  • Input size validation (10MB maximum)

  • Enhanced false positive detection

  • Adaptive secret masking based on length

  • Performance optimizations (skips empty lines and comments)

Example:

{
  "code": "const apiKey = 'sk_live_1234567890abcdef'",
  "filePath": "config.js"
}

3. analyze_security

Perform comprehensive security analysis on a repository with risk scoring, compliance status, and remediation steps.

Parameters:

  • owner (required): GitHub repository owner

  • repo (required): Repository name

  • branch (optional): Branch to analyze (default: "main")

Returns:

  • Risk score (0-100)

  • Compliance status (compliant/at_risk/non_compliant)

  • Severity breakdown (critical/high/medium/low)

  • Detailed remediation steps

  • Security recommendations

4. get_secret_types

Get list of all supported secret types (35+ types) with categories, descriptions, and severity levels.

5. validate_secret

Validate if a detected secret is still active with structured recommendations.

Parameters:

  • secretType (required): Type of secret (validated against supported types)

  • value (required): The secret value to validate (max 10KB, sanitized)

MCP Resources

The server provides the following resources:

  • leak-secure://secret-types: List of all supported secret types

  • leak-secure://patterns: Detection patterns and regular expressions

Configuration

Environment Variables

The server can be configured using environment variables in a .env file or system environment:

Required

  • GITHUB_TOKEN (optional): GitHub Personal Access Token for accessing repositories

Optional Configuration

Server Configuration:

  • NODE_ENV: Environment mode (development, production, test) - default: production

  • LOG_LEVEL: Logging level (DEBUG, INFO, WARN, ERROR) - default: INFO

Rate Limiting:

  • GITHUB_RATE_LIMIT_PER_HOUR: Maximum API calls per hour - default: 5000

  • GITHUB_RATE_LIMIT_BURST: Burst capacity for rate limiter - default: 100

Timeouts (milliseconds):

  • GITHUB_REQUEST_TIMEOUT: Timeout for individual GitHub API requests - default: 30000 (30s)

  • SCAN_TIMEOUT: Timeout for entire repository scans - default: 300000 (5 minutes)

Retry Configuration:

  • MAX_RETRIES: Maximum retry attempts for failed requests - default: 3

  • RETRY_DELAY_BASE: Base delay for exponential backoff (ms) - default: 1000 (1s)

  • RETRY_DELAY_MAX: Maximum delay between retries (ms) - default: 30000 (30s)

File Processing:

  • MAX_FILE_SIZE: Maximum file size to process (bytes) - default: 10485760 (10MB)

  • MAX_FILES_PER_SCAN: Maximum files to scan per repository - default: 10000

Circuit Breaker:

  • CIRCUIT_BREAKER_THRESHOLD: Failure threshold before opening circuit - default: 5

  • CIRCUIT_BREAKER_TIMEOUT: Time before attempting recovery (ms) - default: 60000 (1 minute)

GitHub Token

A GitHub Personal Access Token is optional but recommended for:

  • Accessing private repositories

  • Higher rate limits (5000/hour vs 60/hour unauthenticated)

  • Better reliability and reduced rate limit errors

To create a token:

  1. Go to https://github.com/settings/tokens

  2. Click "Generate new token (classic)"

  3. Select scopes: repo (for private repos) or public_repo (for public repos)

  4. Copy the token and add it to your .env file:

    GITHUB_TOKEN=your_token_here

Configuration Example

Create a .env file in the project root:

# GitHub Configuration
GITHUB_TOKEN=ghp_your_token_here

# Server Configuration
NODE_ENV=production
LOG_LEVEL=INFO

# Rate Limiting
GITHUB_RATE_LIMIT_PER_HOUR=5000
GITHUB_RATE_LIMIT_BURST=100

# Timeouts (milliseconds)
GITHUB_REQUEST_TIMEOUT=30000
SCAN_TIMEOUT=300000

# Retry Configuration
MAX_RETRIES=3
RETRY_DELAY_BASE=1000
RETRY_DELAY_MAX=30000

# File Processing
MAX_FILE_SIZE=10485760
MAX_FILES_PER_SCAN=10000

# Circuit Breaker
CIRCUIT_BREAKER_THRESHOLD=5
CIRCUIT_BREAKER_TIMEOUT=60000

Security Considerations

Secret Protection

  • Adaptive Secret Masking: Secrets are automatically masked with adaptive length (shows first 4-6 and last 4-6 characters based on secret length)

  • Log Sanitization: All secrets are automatically sanitized in logs - never logged in full

  • Secure Error Messages: Error messages never expose sensitive data or full secret values

  • Input Sanitization: All inputs are sanitized to prevent injection attacks

False Positive Reduction

  • Enhanced Validation: Multiple layers of validation to reduce false positives

  • Pattern-Specific Validators: Custom validators for specific secret types

  • Context-Aware Detection: File path context helps improve accuracy

  • Common False Positive Filtering: Filters out example, test, placeholder values

API Security

  • Rate Limiting: Automatic rate limiting respects GitHub API limits and prevents abuse

  • Retry Logic: Smart retry only for operational errors, prevents infinite loops

  • Circuit Breaker: Prevents cascading failures and protects against API outages

  • Timeout Protection: Prevents hanging requests and resource exhaustion

  • Access Control: Use GitHub tokens with minimal required permissions (principle of least privilege)

Operational Security

  • Structured Logging: All logs are structured and sanitized for security compliance

  • Error Classification: Distinguishes between operational and programming errors

  • Graceful Degradation: Server continues operating even when some operations fail

  • Memory Protection: Limits on file sizes and counts prevent memory exhaustion attacks

Development

Project Structure

leak-secure-mcp/
├── src/
│   ├── index.ts                 # Main MCP server entry point
│   ├── detectors/
│   │   ├── SecretDetector.ts    # Core detection engine with enhanced security
│   │   └── patterns/
│   │       └── SecretPatterns.ts # 35+ secret detection patterns
│   ├── github/
│   │   └── GitHubClient.ts      # GitHub API integration with rate limiting & retries
│   ├── analyzer/
│   │   └── SecurityAnalyzer.ts  # Security analysis and risk assessment
│   └── utils/                   # Enterprise-grade utilities
│       ├── validation.ts        # Zod-based input validation schemas
│       ├── logger.ts            # Structured logging with secret sanitization
│       ├── config.ts            # Centralized configuration management
│       ├── errors.ts            # Custom error types and error handling
│       ├── rateLimiter.ts       # Token bucket rate limiting
│       ├── retry.ts             # Exponential backoff retry logic
│       └── circuitBreaker.ts    # Circuit breaker pattern implementation
├── dist/                        # Compiled JavaScript
├── scripts/                     # Setup and utility scripts
├── package.json
├── tsconfig.json
└── README.md

Building

npm run build

Linting

npm run lint

Testing

npm test

API Response Format

Scan Results

{
  "repository": "owner/repo",
  "branch": "main",
  "path": "entire repository",
  "totalFilesScanned": 150,
  "filesWithSecrets": 5,
  "totalSecretsFound": 12,
  "results": [
    {
      "file": "config.js",
      "detections": [
        {
          "type": "aws_access_key_id",
          "category": "Cloud Provider",
          "severity": "critical",
          "value": "AKIA****1234",
          "line": 42,
          "column": 15,
          "context": "...",
          "pattern": "AKIA[0-9A-Z]{16}",
          "recommendation": "Rotate AWS access keys immediately"
        }
      ],
      "severity": "critical"
    }
  ],
  "summary": {
    "totalFiles": 5,
    "filesWithSecrets": 5,
    "totalSecrets": 12,
    "severityBreakdown": {
      "critical": 3,
      "high": 5,
      "medium": 4,
      "low": 0
    },
    "topSecretTypes": [
      { "type": "aws_access_key_id", "count": 3 },
      { "type": "github_token", "count": 2 }
    ]
  }
}

Security Analysis Results

{
  "repository": "owner/repo",
  "branch": "main",
  "totalFilesScanned": 150,
  "filesWithSecrets": 5,
  "totalSecretsFound": 12,
  "results": [...],
  "analysis": {
    "riskScore": 75,
    "complianceStatus": "non_compliant",
    "criticalIssues": 3,
    "highIssues": 5,
    "mediumIssues": 4,
    "lowIssues": 0,
    "remediationSteps": [
      "URGENT: Address critical security issues immediately",
      "Rotate all exposed critical secrets",
      "Implement secret management solution"
    ],
    "recommendations": [
      "Most common secret types found: aws_access_key_id, github_token",
      "Consider implementing a security review process",
      "Enable secret scanning in your development workflow"
    ]
  },
  "riskScore": 75,
  "complianceStatus": "non_compliant",
  "remediationSteps": [...]
}

Error Response Format

{
  "error": "ValidationError",
  "code": "VALIDATION_ERROR",
  "message": "Invalid input parameters",
  "context": {
    "field": "owner",
    "issue": "Invalid owner format"
  }
}

Performance & Reliability

Rate Limiting

  • Token Bucket Algorithm: Efficient rate limiting with automatic token refill

  • Configurable Limits: Adjustable per-hour and burst limits

  • Automatic Waiting: Server automatically waits for rate limit tokens when needed

Retry Logic

  • Exponential Backoff: Smart retry delays increase exponentially (1s → 2s → 4s → 8s...)

  • Jitter: Random jitter prevents thundering herd problems

  • Selective Retry: Only retries operational errors (network, timeouts, rate limits)

  • Maximum Retries: Configurable retry attempts (default: 3)

Circuit Breaker

  • Three States: CLOSED (normal), OPEN (failing), HALF_OPEN (testing recovery)

  • Automatic Recovery: Detects when service has recovered

  • Failure Threshold: Configurable failure count before opening circuit

  • Timeout Protection: Prevents hanging on unresponsive services

Memory Management

  • Batch Processing: Files processed in batches (50 per batch) to manage memory

  • File Size Limits: Configurable maximum file size (default: 10MB)

  • File Count Limits: Maximum files per scan (default: 10,000)

  • Efficient Scanning: Skips binary files, large files, and common directories

Timeout Protection

  • Request Timeouts: Individual API requests timeout after 30 seconds

  • Operation Timeouts: Full repository scans timeout after 5 minutes

  • Graceful Handling: Timeouts return proper error responses

Error Handling

The server implements comprehensive error handling with custom error types:

  • ValidationError: Input validation failures (400)

  • GitHubAPIError: GitHub API communication errors (502)

  • RateLimitError: Rate limit exceeded (429)

  • TimeoutError: Operation timeout (504)

  • RepositoryAccessError: Repository access denied (403)

  • CircuitBreakerError: Circuit breaker open (503)

All errors are:

  • Properly typed and classified

  • Sanitized (no sensitive data)

  • Structured for easy handling

  • Logged with appropriate levels

Contributing

This is an enterprise-grade, production-ready implementation. When contributing:

  1. Code Quality: Maintain high code quality and security standards

  2. Testing: Add comprehensive tests for new features

  3. Documentation: Update documentation for all changes

  4. TypeScript: Follow TypeScript best practices and strict typing

  5. Security: Ensure all secrets are properly masked in outputs and logs

  6. Error Handling: Use custom error types from utils/errors.ts

  7. Logging: Use structured logging from utils/logger.ts (never log secrets)

  8. Validation: Use Zod schemas from utils/validation.ts for all inputs

  9. Configuration: Add new config options to utils/config.ts with validation

  10. Performance: Consider memory and performance implications of changes

License

MIT License

Support

For issues, questions, or contributions, please contact: cbuntingde@gmail.com

Architecture Highlights

Enterprise Patterns Implemented

  1. Rate Limiting: Token bucket algorithm for API call management

  2. Retry Logic: Exponential backoff with jitter for resilience

  3. Circuit Breaker: Prevents cascading failures

  4. Input Validation: Zod schemas for type-safe validation

  5. Structured Logging: JSON logging with secret sanitization

  6. Error Handling: Custom error types with proper classification

  7. Configuration Management: Centralized, validated configuration

  8. Graceful Shutdown: Proper cleanup and operation completion

  9. Memory Management: Batch processing and resource limits

  10. Timeout Protection: Prevents resource exhaustion

Security Features

  • Zero-trust secret handling (never logged, always masked)

  • Input sanitization and validation

  • Secure error messages (no sensitive data)

  • Rate limiting to prevent abuse

  • Memory protection against DoS attacks

  • Timeout protection against hanging operations

Acknowledgments

Built with:

Available Tools

5 tools
analyze_securityC

Perform comprehensive security analysis on a repository, including secret detection, vulnerability assessment, risk scoring, and compliance status.

ParametersJSON Schema
NameRequiredDescriptionDefault
ownerYesGitHub repository owner
repoYesRepository name
branchNoBranch to analyze (default: main)main

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 analysis components but doesn't disclose behavioral traits such as execution time, resource intensity, permission requirements, whether it modifies data, or output format. For a security analysis tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.

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, efficient sentence that front-loads the main purpose and lists key analysis components. It avoids redundancy and wastes no words, though it could be slightly more structured for readability.

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 security analysis, no annotations, and no output schema, the description is incomplete. It lacks details on what the analysis entails operationally, how results are returned, error handling, or integration with sibling tools. This makes it inadequate for an agent to fully understand the tool's context and usage.

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 three parameters (owner, repo, branch) with clear descriptions. The description adds no additional meaning about parameters beyond implying repository context. Baseline 3 is appropriate when schema does the heavy lifting.

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 performs 'comprehensive security analysis on a repository' and lists specific components (secret detection, vulnerability assessment, risk scoring, compliance status). It distinguishes from siblings like 'get_secret_types' (focused only on secret types) and 'scan_code' (likely narrower scope), though not explicitly. However, it doesn't fully differentiate from 'scan_repository' which might overlap.

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?

No guidance on when to use this tool versus alternatives like 'scan_repository', 'scan_code', or 'validate_secret' is provided. The description implies a comprehensive analysis but doesn't specify prerequisites, timing, or exclusions (e.g., when a simpler scan might suffice).

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

get_secret_typesB

Get list of all supported secret types that can be detected (35+ types).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/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 states this is a read operation ('Get list'), implying it's non-destructive, but doesn't disclose other behavioral traits like rate limits, authentication needs, or response format. The mention of '35+ types' hints at a static list, but more context would help.

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, efficient sentence with no wasted words. It front-loads the key action and resource, and the additional context ('35+ types', 'that can be detected') earns its place by clarifying scope. This is appropriately sized for a simple tool.

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 simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool returns (a list of secret types) but lacks details on format, ordering, or how it integrates with siblings. For a read-only tool, this is passable but could be more complete with behavioral context.

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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is given as it compensates adequately for the lack of parameters by focusing on the tool's purpose.

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 action ('Get list') and resource ('all supported secret types'), specifying what the tool does. It adds useful context about quantity ('35+ types') and purpose ('that can be detected'). However, it doesn't explicitly differentiate from sibling tools like 'validate_secret' or 'scan_code', which might also involve secret types.

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 scanning or validation), or exclusions. With siblings like 'analyze_security' and 'scan_repository', users are left to infer usage based on the name alone.

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

scan_codeA

Scan a code snippet or file content for secrets and sensitive information. Supports up to 10MB of code content with enhanced validation.

ParametersJSON Schema
NameRequiredDescriptionDefault
codeYesCode content to scan (max 10MB)
filePathNoFile path (optional, helps with context)

TDQS

A3.7/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 discloses behavioral traits such as the 10MB size limit and 'enhanced validation,' but lacks details on rate limits, authentication needs, output format, or error handling. This is a moderate disclosure given the absence of annotations, but more context would improve transparency.

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 appropriately sized and front-loaded, consisting of two concise sentences that directly state the tool's purpose and key constraints. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to understand.

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 complexity (scanning for secrets with size limits), no annotations, and no output schema, the description is moderately complete. It covers the purpose and size limit but lacks details on output format, error cases, or integration with sibling tools. This is adequate for basic use but has clear gaps for full contextual understanding.

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 both parameters ('code' and 'filePath') with descriptions. The description adds minimal value beyond the schema by implying the 'code' parameter handles up to 10MB, but does not provide additional syntax or format details. Baseline 3 is appropriate as the schema does the heavy lifting.

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 a specific verb ('scan') and resource ('code snippet or file content'), specifying what it scans for ('secrets and sensitive information'). It distinguishes from sibling tools like 'scan_repository' by focusing on code content rather than repositories, and from 'validate_secret' by scanning for secrets rather than validating them.

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 usage by mentioning 'supports up to 10MB of code content with enhanced validation,' suggesting it's for scanning code up to that size. However, it does not explicitly state when to use this tool versus alternatives like 'scan_repository' for repositories or 'analyze_security' for broader analysis, nor does it provide exclusions or prerequisites.

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

scan_repositoryA

Scan a GitHub repository for secrets and sensitive information. Detects 35+ types of secrets including API keys, passwords, tokens, and credentials. Enterprise-grade with rate limiting, retry logic, and comprehensive error handling.

ParametersJSON Schema
NameRequiredDescriptionDefault
ownerYesGitHub repository owner (username or organization)
repoYesRepository name
branchNoBranch to scan (default: main)main
pathNoSpecific path within repository to scan (optional)

TDQS

A3.7/5.0
Behavior4/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 effectively adds context beyond basic functionality by mentioning 'Enterprise-grade with rate limiting, retry logic, and comprehensive error handling,' which informs the agent about performance traits and reliability. However, it doesn't specify authentication requirements or potential side effects, leaving some gaps in behavioral understanding.

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 efficiently structured in two sentences: the first states the core purpose with specific details, and the second adds behavioral context. Every sentence earns its place by providing essential information without redundancy, making it front-loaded and appropriately sized for quick comprehension.

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 complexity (security scanning with behavioral traits) and the absence of annotations and output schema, the description is moderately complete. It covers purpose and some behavioral aspects but lacks details on output format, error specifics, or integration with sibling tools. This is adequate for basic use but leaves room for improvement in guiding the agent fully.

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 four parameters (owner, repo, branch, path) with clear descriptions. The description adds no additional parameter semantics beyond what the schema provides, such as examples or constraints, but it doesn't need to compensate for gaps. This meets the baseline for high schema 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 the specific action ('Scan a GitHub repository') and resource ('for secrets and sensitive information'), distinguishing it from sibling tools like 'analyze_security' or 'scan_code' by focusing specifically on secret detection. It provides concrete details about what it detects ('35+ types of secrets including API keys, passwords, tokens, and credentials'), making the purpose highly specific and differentiated.

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 like 'analyze_security' or 'scan_code', nor does it mention any prerequisites or exclusions. While it implies usage for security scanning, it lacks explicit context for tool selection, leaving the agent to infer based on tool names alone without clear differentiation.

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

validate_secretB

Validate if a detected secret is still active or has been revoked.

ParametersJSON Schema
NameRequiredDescriptionDefault
secretTypeYesType of secret (e.g., aws_access_key, github_token)
valueYesThe secret value to validate

TDQS

B3.1/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 states the tool validates secret status but does not explain how it performs this validation (e.g., via API calls, internal checks), potential side effects (e.g., logging, rate limits), or error handling. For a tool that likely interacts with external systems, this lack of detail is a significant gap.

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, clear sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and efficient, making it easy to understand at a glance. Every part of the sentence earns its place by conveying essential information.

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 complexity (validating secrets, likely involving external checks), the lack of annotations and output schema means the description should provide more context. It adequately states what the tool does but fails to cover behavioral aspects like validation methods or result formats. For a tool with no structured safety or output information, this is a minimal but incomplete 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?

The input schema has 100% description coverage, clearly documenting both parameters ('secretType' and 'value') with examples. The description does not add any additional meaning beyond the schema, such as format details or validation rules. According to the rules, with high schema coverage, the baseline score is 3, as the schema adequately handles parameter documentation.

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: 'Validate if a detected secret is still active or has been revoked.' It specifies the verb 'validate' and the resource 'detected secret,' with the outcome being a status check. However, it does not explicitly differentiate this from sibling tools like 'analyze_security' or 'scan_code,' which might also involve secret-related operations, leaving some ambiguity about its unique role.

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 does not mention prerequisites, such as needing a previously detected secret, or compare it to sibling tools like 'get_secret_types' for listing types or 'scan_repository' for initial detection. Without such context, users must infer usage based on the tool name alone.

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
Disambiguation4/5

Most tools have distinct purposes, but there is some overlap between scan_code and scan_repository, as both involve scanning for secrets, which could cause confusion. However, the descriptions clarify that scan_code is for snippets/files while scan_repository is for entire GitHub repositories, helping to differentiate them.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., analyze_security, get_secret_types, scan_code, scan_repository, validate_secret), with clear and predictable naming conventions throughout the set.

Tool Count5/5

With 5 tools, the server is well-scoped for security analysis and secret detection, covering key operations like analysis, scanning, validation, and information retrieval without being overly sparse or bloated.

Completeness4/5

The tool set covers core security analysis workflows, including scanning, validation, and information retrieval, but lacks explicit tools for remediation actions (e.g., revoking or fixing secrets) or reporting, which could be minor gaps in a comprehensive security workflow.

Resources

Related MCP Connectors

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/cbuntingde/leak-secure-mcp'

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