Skip to main content
Glama

Python Code Validator

by ai.statemind

Repair Python

repair_python
Read-onlyIdempotent

Everything validation does, plus deterministic fixes: the corrected source comes back in fixed_code, and the original is kept whenever the fix cannot be proven safe. The code is still never run. Use it when validation failed and you want the fix rather than the diagnosis. Alternatives: validate_python when the diagnosis is enough; execute_python when the fix has to be proven to run. Auth: a key is required. This call needs a paid key and answers HTTP 402 without one. Credits are bought without an account, 3 per call: GET /v1/pricing says where to send the xDAI. Or pay for this one call with no key at all: call it without one and the result carries x402 payment requirements ($0.03 in USD Coin on eip155:8453); sign them and repeat the call with the payment in _meta['x402/payment']. Arguments: code: the whole file, 1..200000 bytes of UTF-8 measured after encoding (empty is refused with 400, larger with 413); a fragment is fine, but line and column numbers in the answer count from 1 in what you sent. language: must be 'python'; anything else is 400, and the field may be omitted. options.max_iterations (1..10, default 3) caps the fix/verify rounds: raise it for a file with several independent faults, leave it for a snippet. options.optimize (default false) additionally folds constants and drops dead code, and is only worth setting when you asked for a rewrite anyway. options.transpile_to (e.g. 'javascript') returns a translation of the repaired source in transpiled, not of what you sent. fixed_code is null when nothing could be proven safe to change, so treat null as 'no fix', not as an error. options.timeout_s, options.examples and options.expected_output do nothing here: nothing is run, so there is no clock, no stdout, and no way to check an example. Returns valid, score 0..1, diagnostics (rule, message, line, column), security findings, fixes, fixed_code and runtime; see outputSchema. The code and its verdict are retained to improve the service.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesThe source to check, as a whole file where possible: diagnostics carry the line and column of the text you send, and a fragment hides the imports and definitions the type check needs. A deployment may accept fewer bytes than the 200000 here.
optionsNoTuning knobs. Most of them only take effect in the mode that does the corresponding work; see each field.
languageNoThe language of the code. A service that does not handle it refuses the request rather than guessing; the enum is shared across services, so it lists more than any one of them accepts.python

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
metaYes
fixesNo
scoreYes
validYes
runtimeNo
securityNo
fixed_codeNo
transpiledNo
diagnosticsNo

TDQS

A5/5.0
Behavior5/5

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

The description goes well beyond annotations by detailing authentication requirements (paid key, HTTP 402, x402 payment flow), clarifying that the code is never run, explaining the null fixed_code semantics, and listing which options are silently ignored. This enriches the annotation hints without contradicting them.

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 every sentence carries essential information. It is well-structured across purpose, auth, arguments, and returns, with no fluff or repetition. Front-loading the core purpose and key caveat ('code is never run') makes it easy to scan.

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?

For a tool of this complexity, the description covers all critical aspects: behavior, auth, parameter semantics, ignored options, return value summary, and null handling. It leverages the output schema reference where appropriate and leaves no significant gaps for an agent to discover by trial and error.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even though schema coverage is 100%, the description adds meaningful context beyond the schema, such as advice on when to raise max_iterations, clarifying that transpile_to operates on the repaired source, and explicitly stating that timeout_s, examples, and expected_output have no effect here. This is valuable extra semantic guidance.

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 what the tool does: validation plus deterministic fixes, returning corrected source in fixed_code. It distinguishes itself from siblings by explicitly noting it never runs the code and by framing its output as the fix rather than the diagnosis.

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?

It provides explicit when-to-use guidance: 'Use it when validation failed and you want the fix rather than the diagnosis.' It also names concrete alternatives (validate_python when diagnosis is enough, execute_python when the fix must be proven to run), which is exactly the recommended level of guidance.

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

All Python Code Validator toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.9/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: validate only diagnoses, repair diagnoses and fixes, execute diagnoses, fixes, and runs. The descriptions explicitly state the differences and alternatives, leaving no ambiguity about which to choose.

Naming Consistency5/5

All tools follow the same verb_noun pattern: validate_python, repair_python, execute_python. The naming is perfectly consistent and predictable.

Tool Count5/5

Three tools is a well-scoped set for a Python code validator. Each tool adds a distinct level of functionality (diagnose, fix, run), and there are no redundant or unnecessary tools.

Completeness5/5

The toolset covers the full lifecycle of Python code validation: diagnose (validate), fix (repair), and verify (execute). The options within the tools (e.g., transpile, optimize, examples) further round out the surface, leaving no critical gaps.

Resources