Skip to main content
Glama

inspect_modal_secret

Lists key names inside a Modal secret without exposing values. Starts a short-lived container to read environment variable names, filtering out runtime defaults, so only secret-defined keys remain.

Instructions

List the KEY NAMES inside a Modal secret — never the values.

Modal exposes no API for this: neither the CLI, the SDK, nor the gRPC layer can read
a secret's contents, by design. The only way to see which keys a secret defines is to
mount it in a container and look at the environment variable names. So this tool
starts a short-lived container (`modal shell --secret ...`), prints the variable NAMES
only, and subtracts the ones the image and the Modal runtime would have set anyway.

That means, unlike every other read in this server, a call here **starts remote
compute and costs a few cents** (and takes tens of seconds — longer on the first run
for a given image, which has to be built). It is not a free lookup: use
list_modal_resources(resource="secrets") to see which secrets exist, and reach for
this only when you need to know what is inside one.

Values never leave the container: the probe is `compgen -e`, a bash builtin that
prints exported variable NAMES only, so no value is ever printed or read.

Args:
    secret_name: Name of the secret, from list_modal_resources(resource="secrets").
    env: Modal environment the secret lives in.
    image: Optional container image. Omit it to use Modal's default image, which is
        built to match this server's Python — that is the most reliable choice. Pass one
        (e.g. "python:3.12-slim") if the workspace's image builder rejects that Python.
    timeout_seconds: Max seconds to wait, including image build. Default 300.

Returns: {keys: [...names...], all_env_names: [...], filtered_out: n}. `all_env_names`
    is the unfiltered list, so a key that looks like a runtime variable (e.g. one
    literally named "PATH") is still visible rather than silently dropped.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
envNo
imageNo
secret_nameYes
timeout_secondsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.2

TDQS

A5/5.0
Behavior5/5

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

The description goes well beyond the annotations by disclosing that a call starts remote compute, costs money, takes tens of seconds, and may trigger an image build on first run. It also explains the probe mechanism and assures that values never leave the container. These are critical behavioral traits not captured by readOnlyHint=false or destructiveHint=false. There is no contradiction with annotations.

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?

Although the description is long, it is front-loaded with the most critical information (keys only, not values) and the cost warning. The explanation of why no API exists, the specifically scoped probe detail, and the per-parameter Args all earn their place. The structure is clean and skimmable.

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?

The description covers return value semantics even beyond the output schema, explaining filtered vs unfiltered results. It also addresses cost, latency, prerequisites, alternatives, and parameter provenance. For a tool with remote side effects and unusual constraints, nothing important is missing.

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?

With schema description coverage at 0%, the description fully compensates via an Args section. Each parameter is explained: secret_name's source, env's purpose, image's optionality and recommended fallback, and timeout_seconds' default and meaning. This addresses the gaps left by the bare schema.

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 opens with a specific action and scope: 'List the KEY NAMES inside a Modal secret — never the values.' It clearly names the resource and differentiates this tool from sibling tools like list_modal_resources and manage_modal_secret by emphasizing it inspects secret contents, not resource existence or management.

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?

The description explicitly states when to use the tool versus alternatives: 'use list_modal_resources(resource="secrets") to see which secrets exist, and reach for this only when you need to know what is inside one.' It also warns that this is 'not a free lookup' and should be used sparingly, giving clear decision guidance.

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