Skip to main content
Glama
Tokenectomy-Labs

Tokenectomy-Razor

by Tokenectomy-Labs
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
Rust
Local

analyze_code

Detect resource leaks, security vulnerabilities, and logic flaws in Python code via static AST analysis. Use before committing or running to catch defects without executing code.

Instructions

Performs static AST code analysis using Tree-sitter to detect resource leaks (such as unclosed file handles), security vulnerabilities, and logic flaws with bounded execution limits and precise LSP UTF-16 coordinates.

• Side Effects: None. Strictly read-only analysis of in-memory code; does not execute code, spawn subprocesses, or write to disk. • Auth & Permissions: None required. Fully offline, in-memory parser. • Rate Limits: None. Bounded to 1MB max source size, 128 max AST depth, and 50,000 max node visits per call. • Return Shape: Returns a JSON object containing 'language', 'findings_count', 'duration_ms' (latency metric), and 'findings' (array of objects with rule_id, message, severity, line [1-indexed], column [1-indexed UTF-16 code units], and remediation). • Failure Modes: Returns findings: [] if the code contains no detected defects. Returns an error message if the language is unsupported or if source code exceeds the 1MB or 128 AST depth limits. • When to use: Use proactively before committing or running code, or when reviewing Python files for unclosed file handles, resource leaks, or AST defects. • When NOT to use: Do NOT use when you have an active runtime crash log (use get_error_context instead), and do NOT use to apply fixes automatically (use apply_code_patch instead). • Prerequisites: Supported languages currently include Python ('python', 'py').

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesRaw source code string to analyze. Must not exceed 1,000,000 bytes (1MB). Does not execute runtime code; strictly parsed via Tree-sitter AST.
languageYesProgramming language identifier for the code snippet. Case-insensitive. Supported values: 'python', 'py'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.8

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully discloses side effects (None, read-only), auth requirements (None required, offline), rate limits (1MB, 128 depth, 50k node visits), return shape (JSON with language, findings_count, duration_ms, findings array), and failure modes (empty findings, error on unsupported language or exceeded limits). This is comprehensive and leaves nothing ambiguous.

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 long but tightly organized in bullet points with clear headers. Every sentence adds value: side effects, auth, rate limits, return shape, failure modes, when/when-not, and prerequisites are all addressed. It front-loads the core purpose and then details specifics without redundancy.

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?

This is a complex tool (static analysis, multiple detection categories, limits, error conditions) with no annotations or output schema. The description fully compensates by specifying the exact return structure, failure modes, prerequisites (supported languages), and constraints. An agent has everything needed to call it correctly.

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 offers 100% description coverage for both parameters, including constraints (size limit, case-insensitivity, supported values). The description adds little new meaning for parameters beyond what the schema provides; it reiterates the 1MB limit but that's behavioral context rather than parameter semantics. Baseline 3 applies because 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 explicitly states the verb 'Performs static AST code analysis using Tree-sitter' and the resource 'code', and specifies the exact detection categories (resource leaks, security vulnerabilities, logic flaws). It names alternatives in the 'When NOT to use' section (get_error_context, apply_code_patch), distinguishing this tool from siblings clearly.

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

Usage Guidelines5/5

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

Provides a dedicated 'When to use' section recommending proactive use before commits or for Python file review, and a 'When NOT to use' section explicitly naming two sibling tools (get_error_context and apply_code_patch) with conditions for each. This is explicit routing guidance.

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

Deploy Server

Other Tools