Skip to main content
Glama
bswa006

AI Agent Template MCP Server

by bswa006

check_security_compliance

Analyze code for security vulnerabilities and compliance issues including secrets, injection, XSS, authentication, cryptography, and validation checks.

Instructions

Check code for security vulnerabilities and compliance

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesCode to check for security issues
checkTypesNoTypes of security checks to perform

Implementation Reference

  • Main handler function that performs comprehensive security compliance checks on code, detecting secrets, injections, XSS, auth issues, data exposure, and more.
    export async function checkSecurityCompliance(
      code: string,
      sensitiveOperations?: string[]
    ): Promise<SecurityCheckResult> {
      const result: SecurityCheckResult = {
        secure: true,
        violations: [],
        recommendations: [],
      };
    
      // Check for hardcoded secrets
      checkHardcodedSecrets(code, result);
      
      // Check for injection vulnerabilities
      checkInjectionVulnerabilities(code, result);
      
      // Check for XSS vulnerabilities
      checkXSSVulnerabilities(code, result);
      
      // Check authentication/authorization
      checkAuthIssues(code, result);
      
      // Check for sensitive data exposure
      checkDataExposure(code, result);
      
      // Check specific sensitive operations if provided
      if (sensitiveOperations) {
        checkSensitiveOperations(code, sensitiveOperations, result);
      }
      
      // Additional security checks
      checkGeneralSecurity(code, result);
      
      // Determine if code is secure
      result.secure = result.violations.filter(v => 
        v.severity === 'critical' || v.severity === 'high'
      ).length === 0;
    
      return result;
    }
  • Registration and dispatching logic in the MCP tool handler switch statement, including Zod input validation and calling the security compliance function.
    case 'check_security_compliance': {
      const params = z.object({
        code: z.string(),
        sensitiveOperations: z.array(z.string()).optional(),
      }).parse(args);
      
      const result = await checkSecurityCompliance(
        params.code,
        params.sensitiveOperations
      );
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify(result, null, 2),
          },
        ],
      };
    }
  • Tool definition in the list of MCP tools, including the input schema specification.
    {
      name: 'check_security_compliance',
      description: 'Check code for security vulnerabilities and compliance',
      inputSchema: {
        type: 'object',
        properties: {
          code: {
            type: 'string',
            description: 'Code to check for security issues',
          },
          checkTypes: {
            type: 'array',
            items: {
              type: 'string',
              enum: ['secrets', 'injection', 'xss', 'auth', 'crypto', 'validation'],
            },
            description: 'Types of security checks to perform',
          },
        },
        required: ['code'],
      },
    },
  • TypeScript interface defining the output structure of the security check result.
    interface SecurityCheckResult {
      secure: boolean;
      violations: {
        severity: 'critical' | 'high' | 'medium' | 'low';
        type: string;
        message: string;
        line?: number;
        suggestion: string;
      }[];
      recommendations: string[];
    }
    
    export async function checkSecurityCompliance(
      code: string,
      sensitiveOperations?: string[]
    ): Promise<SecurityCheckResult> {
      const result: SecurityCheckResult = {
        secure: true,
        violations: [],
        recommendations: [],
      };
    
      // Check for hardcoded secrets
      checkHardcodedSecrets(code, result);
      
      // Check for injection vulnerabilities
      checkInjectionVulnerabilities(code, result);
      
      // Check for XSS vulnerabilities
      checkXSSVulnerabilities(code, result);
      
      // Check authentication/authorization
      checkAuthIssues(code, result);
      
      // Check for sensitive data exposure
      checkDataExposure(code, result);
      
      // Check specific sensitive operations if provided
      if (sensitiveOperations) {
        checkSensitiveOperations(code, sensitiveOperations, result);
      }
      
      // Additional security checks
      checkGeneralSecurity(code, result);
      
      // Determine if code is secure
      result.secure = result.violations.filter(v => 
        v.severity === 'critical' || v.severity === 'high'
      ).length === 0;
    
      return result;
    }
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but doesn't describe how it behaves: no information about output format, whether it's read-only or has side effects, performance characteristics, error handling, or security context needed. For a security tool with zero annotation coverage, this leaves significant gaps in understanding its 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 extremely concise with just 8 words: 'Check code for security vulnerabilities and compliance.' Every word earns its place by specifying the action, target, and purpose. There's no redundancy or unnecessary elaboration, making it front-loaded and efficient.

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?

For a security analysis tool with no annotations and no output schema, the description is insufficient. It doesn't explain what constitutes a 'vulnerability' or 'compliance', what standards are referenced, what the output looks like, or how results should be interpreted. The agent must guess at critical behavioral aspects despite the tool's potential complexity.

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 fully documents both parameters ('code' and 'checkTypes'). The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate but minimal value addition when the schema does all the work.

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: 'Check code for security vulnerabilities and compliance' with a specific verb ('check') and resource ('code'). It distinguishes from most siblings that focus on code generation, analysis, or workflow tasks rather than security compliance. However, it doesn't explicitly differentiate from 'validate_generated_code' which might have overlapping security aspects.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this security check should be performed (e.g., before deployment, during development), what makes it different from 'validate_generated_code', or any prerequisites. The agent must infer usage from the tool name and description alone.

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

Install Server

Other Tools

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/bswa006/mcp-context-manager'

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