Skip to main content
Glama

Extract Function

extract_function

Extract a named function, including its imports and referenced helpers, into a standalone program and run it in a sandbox with your test inputs.

Instructions

Extract a named function (with its imports + referenced helpers) into a standalone program and run it in the sandbox.

python3 gets exact ast extraction; other languages best-effort block extraction (pass call to execute non-python). Returns the extracted program and per-input runs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
callNoCall expression to invoke the extracted function; required for non-python3 languages
codeYesSource containing the function to extract, plus its imports and helpers
languageYesLanguage `code` is written in; python3 gets exact ast extraction, others best-effort block extraction
test_inputsNoInputs to run the extracted program with, one run per input
function_nameYesName of the function within `code` to extract into a standalone program

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.12.0
    • addedInput schema / properties / call / description
      Added value: +"Call expression to invoke the extracted function; required for non-python3 languages"
    • addedInput schema / properties / code / description
      Added value: +"Source containing the function to extract, plus its imports and helpers"
    • addedInput schema / properties / function_name / description
      Added value: +"Name of the function within `code` to extract into a standalone program"
    • addedInput schema / properties / language / description
      Added value: +"Language `code` is written in; python3 gets exact ast extraction, others best-effort block extraction"
    • addedInput schema / properties / test_inputs / description
      Added value: +"Inputs to run the extracted program with, one run per input"
  2. Changed1 schema field changedv0.11.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "title": "extract_functionDictOutput",
      +  "type": "object"
      +}
  3. Changed8 schema fields changedv0.2.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / call / title
      Added value: +"Call"
    • addedInput schema / properties / code / title
      Added value: +"Code"
    • addedInput schema / properties / function_name / title
      Added value: +"Function Name"
    • addedInput schema / properties / language / title
      Added value: +"Language"
    • addedInput schema / properties / test_inputs / title
      Added value: +"Test Inputs"
    • addedInput schema / title
      Added value: +"extract_functionArguments"
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": true,
      -  "type": "object"
      -}New value: +null
  4. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

The description discloses that the tool runs code in a sandbox, handles python3 exactly but other languages best-effort, and returns the extracted program plus per-input runs. This adds meaningful behavioral context beyond the annotations, which only cover mutability and idempotence. No contradiction with annotations is present.

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?

Three focused sentences, each earning its place: the first states the core action, the second covers language-specific behavior, and the third states the return value. The most important scoping information is front-loaded.

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 with five parameters, an output schema, and detailed per-parameter schema descriptions, the description covers all essential behavior: extraction scope, sandbox execution, language-dependent semantics, the `call` requirement, and return contents. Nothing critical is missing for an agent to invoke 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?

Schema coverage is 100%, so the input schema already documents all parameters and their descriptions. The description reinforces that `call` is needed for non-python languages and that language affects extraction behavior, but it does not add substantial new meaning beyond what the schema already states.

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 uses a specific verb ('Extract') with a clear resource ('a named function ... into a standalone program') and clarifies the scope ('with its imports + referenced helpers'). It also says it runs the program and returns results, which clearly distinguishes it from generic code execution tools like execute_code.

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

Usage Guidelines4/5

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

The description gives explicit context for language-specific usage: python3 uses exact AST extraction, while other languages use best-effort block extraction and require the `call` parameter. It does not name alternative tools or exclusion conditions, but it provides clear operational guidance for when to call this tool and how to configure it.

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