Skip to main content
Glama

List Secrets

secrets_list
Read-only

Lists the metadata for an app's secrets and plain environment variables: secret_id, scope (app/env), key, is_secret, inherited, overridden_by_environment, created_by, created_at, updated_at. NEVER includes a value. This is a metadata-only listing, identical in spirit to what the secrets dashboard table shows before you reveal one. Takes the app_id returned by apps_list.

Without environment_id, it lists the app-level entries, which every environment inherits (inherited: false, overridden_by_environment: null). Pass environment_id (from environments_list) for what that environment really gets: its own entries plus every app-level entry, marked inherited: true. An app-level entry whose key the environment sets too stays listed, with overridden_by_environment: true: the environment's entry wins at deploy. Those entries are sorted by key, so an override sits next to what it replaces, and count counts every entry.

The variables Meridian itself injects at deploy are not here: call managed_variables_list for that other half.

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": {
      "app_id": "<app_id>"
    },
    "name": "secrets_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
app_idYesThe app uuid returned by `apps_list`.
environment_idNoList what this environment gets: its own entries plus the app-level ones it inherits. Uuid returned by `environments_list`.
organization_idNoAn organisation uuid or slug. When supplied, `app_id` is resolved within that organisation and may be a slug instead of a uuid, mirroring the Meridian web app.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and non-destructive, and the description goes well beyond them: it discloses that values are never returned, how inheritance is marked (inherited, overridden_by_environment), that environment entries win at deploy, and that results are key-sorted with an accurate count. This is real behavioral context an agent needs to interpret results correctly.

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?

Front-loaded with the return shape and the no-values guarantee, then the parameter modes, then the sibling callout — good ordering. It is slightly longer than necessary; the dashboard-table analogy and the deploy-override aside are helpful but cost words.

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?

There is no output schema, and the description compensates by naming every returned field plus ordering and count semantics. For a read-only list tool with three parameters this covers everything an agent needs to call it and read the result.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning for environment_id by explaining the inheritance/override semantics of the returned set rather than just restating the parameter. The organization_id parameter is only documented in the schema, which keeps this from a 5.

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?

States a specific verb and resource (lists metadata for an app's secrets and plain environment variables) and enumerates the exact fields returned, including the crucial constraint that no value is ever included. The agent can distinguish it from secrets_set, secrets_unset, and managed_variables_list without opening any schema.

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?

Explicitly routes the agent: use apps_list for app_id, environments_list for environment_id, and managed_variables_list for the variables Meridian injects at deploy. It also states the when-to-use condition for environment_id (per-environment effective view) versus omitting it (app-level inherited entries).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources