Oxyo (oxyo.si) — Cut Coding Agent Token & Quota Burn by up to 72%

oxyo_verify_python

Read-onlyIdempotent

Execute deterministic Python math, financial Decimal, or algorithmic checks inside an isolated zero-network sandbox (RESULT = ...), returning exact RESULT, stdout, and optional boundary-fuzz results. Use for procedural Python verification; use oxyo_prove_constraints for declarative constraint solving.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "code": "<code>"
    },
    "name": "oxyo_verify_python"
  }
}

Input Schema

Name	Required	Description
`code`	Yes	Self-contained standard-library Python code assigning final output to `RESULT = ...`.
`fuzz`	No	Run automated boundary/edge-case property fuzzing and determinism checks.
`timeout_s`	No	Maximum execution wall-time in seconds before termination (0.5..10.0).
`entrypoint`	No	Optional top-level function name in `code` to target during boundary fuzzing.
`invariants`	No	Optional Python boolean expressions (e.g. 'RESULT >= 0') asserted after execution.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 11, 2026

changedInput schema / properties / code / description

Previous value: -"Python snippet setting RESULT = ..."New value: +"Self-contained standard-library Python code assigning final output to `RESULT = ...`."

changedInput schema / properties / entrypoint / description

Previous value: -"Optional top-level function name to fuzz directly"New value: +"Optional top-level function name in `code` to target during boundary fuzzing."

changedInput schema / properties / fuzz / description

Previous value: -"Enable adversarial boundary/edge-case property fuzzing & determinism check"New value: +"Run automated boundary/edge-case property fuzzing and determinism checks."

changedInput schema / properties / invariants / description

Previous value: -"Optional boolean Python expressions (e.g. 'RESULT > 0') that must hold"New value: +"Optional Python boolean expressions (e.g. 'RESULT >= 0') asserted after execution."

addedInput schema / properties / timeout_s / description

Added value: +"Maximum execution wall-time in seconds before termination (0.5..10.0)."

First observedNov 11, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds real context beyond that: no network access, exact RESULT plus stdout capture, optional fuzz results, and a configurable wall-time limit. It stops short of stating failure behavior (timeouts, exceptions, non-zero exit) for a code-execution tool, which keeps it below a 5.

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?

Two sentences, both dense with operative information, with the core capability and environment front-loaded and the sibling routing at the end. No redundant restatement of the tool name or title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but the description compensates by naming the return payload (RESULT, stdout, fuzz results). For an isolated code-execution tool, the remaining gap is error/timeout semantics and any code-size or import restrictions, which are not addressed.

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?

Schema coverage is 100%, so the baseline is 3. The description nonetheless adds meaning the schema does not spell out: the `RESULT = ...` output convention used for grading, the fact that fuzz produces boundary-fuzz output appended to the result, and the procedural-vs-declarative framing for `invariants`.

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?

States a specific verb (execute) plus the resource/domain (deterministic Python math, financial Decimal, algorithmic checks) and the execution environment (isolated zero-network sandbox). It also names the `RESULT = ...` contract and explicitly distinguishes itself from `oxyo_prove_constraints`, so an agent can identify the right tool without opening the schema.

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?

Gives an explicit routing rule: use this for procedural Python verification, use `oxyo_prove_constraints` for declarative constraint solving. That is a clear when-to-use plus a named alternative with the condition that selects it.

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

All Oxyo (oxyo.si) — Cut Coding Agent Token & Quota Burn by up to 72% tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.