Skip to main content
Glama
Sign In
LocalForge

LocalForge

by tanskong
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

run_python

Destructive

Execute Python code for local development automation or restricted analysis; choose dev or safe mode with timeout and root controls.

Instructions

Run Python automation in dev mode or restricted analysis in safe mode.

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": {
      "root": "<root>",
      "code": "<code>"
    },
    "name": "run_python"
  }
}

Input Schema

NameRequiredDescriptionDefault
codeYes
modeNodev
rootYes
purposeNo
timeout_secondsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.2

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, readOnlyHint=false and non-idempotency, so the safety profile is covered structurally. The description adds genuine value by introducing a restricted 'safe mode' versus an unrestricted 'dev' mode, but it never explains what safe mode actually restricts, whether dev mode runs unsandboxed, or what side effects persist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler, and the scope (what runs) precedes the mode distinction. It is efficient rather than bloated, though its brevity comes at the cost of the missing detail noted elsewhere.

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 an arbitrary-code-execution tool with destructive and open-world annotations, five undocumented parameters, and only implied mode semantics, the description is well short of complete. The existence of an output schema removes any obligation to describe return values, but the input contract and mode behavior remain undefined.

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

Parameters2/5

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

Schema description coverage is 0% for five parameters, so the description must carry the load and largely does not. It only hints at the 'mode' parameter's two values and says nothing about 'root', 'code', 'purpose', or 'timeout_seconds', leaving four parameters with no documented meaning anywhere.

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?

States a specific verb and resource ('Run Python') and names two operating modes, so an agent knows this executes Python code rather than merely reading or analyzing it. It fails to differentiate from the closely related sibling 'shell', which is also an arbitrary-code-execution tool, so it falls short of a 5.

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

Usage Guidelines3/5

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

The dev-vs-safe split implies a choice criterion ('automation' vs 'restricted analysis'), which is the main usage decision for this tool. However, it never states when to prefer run_python over sibling 'shell' or when validation via 'validate' should precede execution, and no prerequisites are given.

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