Skip to main content
Glama

run_modal_app

Run a Modal app's function or entrypoint and collect its output to test the app on Modal compute.

Instructions

Run a Modal function or local entrypoint once and collect its output (`modal run`).
Use this to test on Modal compute; use deploy_modal_app to publish.

Args:
    absolute_path_to_app: Absolute path to the app file. Its directory must use `uv`
        and have `modal` installed in its virtualenv.
    function_name: Function/entrypoint name, e.g. "main". Omit if the module has
        exactly one.
    env: Modal environment to target.
    detach: Keep the run alive on Modal past this call (`--detach`) — for long jobs.
    timeout_seconds: Max seconds to collect output. Default 120.

Returns: {output, urls, truncated (still running at the timeout), output_capped}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
envNo
detachNo
function_nameNo
timeout_secondsNo
absolute_path_to_appYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

Annotations are sparse (no readOnly, no idempotency), so the description carries the disclosure burden. It explains one-shot execution, output collection, detach persistence, and timeout truncation behavior—valuable details beyond the structured fields.

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 compact and front-loaded with purpose and alternative routing, followed by a scannable Args list and a sharp Returns line. Every sentence adds functional value.

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?

Despite no schema descriptions, the definition covers prerequisites, parameter behavior, return shape, timeout handling, and the publish alternative. It is complete enough for an agent to invoke the tool correctly without external information.

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?

Schema description coverage is 0%, and the description fully compensates by explaining each parameter: absolute path requirements (uv + modal installed), function_name disambiguation, env target, detach semantics, and timeout default. This adds meaning the schema alone does not provide.

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 states a specific verb ('Run') and resource ('Modal function or local entrypoint') and explicitly contrasts with deploy_modal_app ('use deploy_modal_app to publish'). This clearly differentiates the tool from its main sibling.

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 says 'Use this to test on Modal compute; use deploy_modal_app to publish,' giving direct when-to-use and when-not-to-use guidance. It also notes detach for long jobs, helping agents select the right mode for the task.

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