Skip to main content
Glama

manage_modal_secret

Destructive

Create or delete Modal secrets with key-value pairs, dotenv, or JSON, with force overwrite. Values are redacted to prevent leaks.

Instructions

Create or delete a secret. To list secret names use
list_modal_resources(resource="secrets") — values are never readable.

Values are redacted from every field returned (command, stdout, stderr, error), so
they cannot leak back into the transcript on failure.

Args:
    action: "create" or "delete".
    secret_name: Secret name.
    key_values: For "create": {"API_KEY": "abc", ...}.
    from_dotenv / from_json: For "create": load key/values from a local file instead.
    force: For "create": overwrite an existing secret.
    env: Modal environment to target.

Returns: {message, stdout, stderr} or {error}, with values redacted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
envNo
forceNo
actionYes
from_jsonNo
key_valuesNo
from_dotenvNo
secret_nameYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.2

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already mark the tool as destructive and not read-only, and the description aligns with those flags. It adds valuable context by stating that values are never readable and are redacted from every returned field, including error fields, preventing transcript leaks.

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 tight and well-structured: a one-line purpose, a critical security note, a compact Args list, and a return-shape line. Every sentence adds useful information and no space is wasted.

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?

Given the tool's complexity, an output schema exists, and the description covers all parameters, the create/delete distinction, file-based alternatives, overwrite behavior, environment targeting, and security-redaction behavior. Nothing essential is missing for correct invocation.

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%, so the description carries the full burden for all seven parameters. It explains action, secret_name, key_values, from_dotenv/from_json, force, and env, including which parameters apply to 'create' and the shape of key_values.

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 'Create or delete a secret,' naming the specific verb and resource. It also distinguishes itself from the listing path by directing users to list_modal_resources(resource='secrets'), making its scope unmistakable.

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 explicitly tells users to use list_modal_resources for listing secret names, which is the main alternative. It does not exhaustively enumerate when to choose inspect_modal_secret or other siblings, but the create/delete scope is clear enough for appropriate routing.

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