Skip to main content
Glama
notasandy

MCP Code Sanitizer

analyze_code

Analyze code fragments with strict reviews powered by Groq LLM to identify bugs, vulnerabilities, and security issues.

Instructions

Strict analysis of a code fragment using Groq LLM.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesCode fragment to review.
languageNoProgramming language (python, javascript, go, rust, ...).python
contextNoOptional description - what the code does or where it came from.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The async function `analyze_code` is the core handler for the MCP tool. It takes `code`, `language` (default python), and optional `context`, validates input, checks cache, calls the Groq LLM via the ANALYZE prompt, parses the JSON response, caches it, and returns a JSON string with issues, warnings, suggestions, and score.
    async def analyze_code(code: str, language: str = "python", context: str = "") -> str:
    
        """
        Strict analysis of a code fragment using Groq LLM.
    
        Args:
            code:     Code fragment to review.
            language: Programming language (python, javascript, go, rust, ...).
            context:  Optional description - what the code does or where it came from.
    
        Returns:
            JSON with fields: issues, warnings, suggestions, score.
    
        """
    
        if not code.strip():
            return error_response("Empty code provided.")
    
        key = cache.make_key("analyze_code", code, language, context)
        if hit := cache.get(key):
            return hit
    
        context_block = f"\nContext: {context}" if context else ""
        user = f"Language: {language}{context_block}\n\nCode:\n```{language}\n{code}\n```"
    
        try:
            raw = await call(ANALYZE, user)
            result = json.loads(raw)
    
        except httpx.HTTPStatusError as e:
            return error_response(f"Groq API error {e.response.status_code}", e.response.text[:300])
        except json.JSONDecodeError as e:
            return error_response("Groq returned invalid JSON", str(e))
        except ValueError as e:
            return error_response(str(e))
    
    
    
        out = json.dumps(result, ensure_ascii=True, indent=2)
        cache.set(key, out)
        return out
  • Cache helper integration: `cache.make_key()` creates a SHA-256 cache key, `cache.get()` retrieves cached results, and `cache.set()` stores results to avoid redundant API calls.
    key = cache.make_key("analyze_code", code, language, context)
    if hit := cache.get(key):
        return hit
    
    context_block = f"\nContext: {context}" if context else ""
Behavior2/5

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

No annotations provided, so description bears full burden. It only mentions 'strict analysis' and 'Groq LLM', but does not disclose key behavioral traits such as whether it reads only, calls external APIs, has rate limits, or any side effects. The word 'strict' implies rigor but is vague.

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, concise sentence that immediately conveys the tool's core purpose. It is front-loaded and contains no extraneous information.

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 tool has 3 parameters and an output schema, the description is too sparse. It does not explain what 'strict analysis' entails, how the Groq LLM is used, or any constraints on the code fragment. An output schema exists but the description still lacks essential context for an agent to use it 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?

Schema description coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it refers to 'code fragment' which matches the 'code' parameter, but does not elaborate on 'language' or 'context' parameters.

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

Purpose4/5

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

The description clearly states the verb (analyze) and resource (code fragment), and specifies the method (using Groq LLM). It is distinct from siblings like 'analyze_file' by emphasizing code fragment analysis, but does not explicitly differentiate from 'explain_code' or 'compare_code'.

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. The description does not mention context, prerequisites, or scenarios where other tools like 'explain_code' or 'compare_code' would be more appropriate.

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/notasandy/mcp-code-sanitizer'

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