Skip to main content
Glama

environment_variables_add

Añade variables (solo los NOMBRES, p. ej. "STRIPE_SECRET_KEY") a un entorno existente. Quedan «pendientes de valor»: el usuario las rellena en la web, o tú ejecutas mddoc set <entorno> <VARIABLE> --generate si es un secreto aleatorio que se puede generar. Las que ya existen no se tocan (se devuelven en alreadySet/alreadyPending). Usa nombres POSIX en MAYÚSCULAS y explica al usuario para qué es cada una. Entornos (variables de entorno/secretos): los valores NUNCA pasan por ti. Para usarlos ejecuta en la terminal mddoc run <entorno> -- <comando>: el CLI inyecta las variables en ese proceso y enmascara su salida. Reglas: (1) no intentes ver, imprimir, copiar, codificar ni volcar a fichero los valores (nada de printenv, env, echo $VAR, base64, > .env…); (2) si el comando termina con código 3 el CLI está bloqueado: detente y pide al usuario que ejecute mddoc unlock en su terminal; nunca le pidas el valor ni lo busques en otro sitio (.env, historial, notas); (3) si "mddoc" no existe, indica al usuario que instale el CLI (Linux o macOS, Node.js 20+) con npm install -g --prefer-online <URL de md-doc>/cli/mddoc.tgz (p. ej. https://app.md-doc.com/cli/mddoc.tgz; el comando exacto está en Entornos → Usar desde la terminal) y que conecte el equipo con mddoc login usando una API key de tipo CLI; (4) tú no escribes valores: si a un entorno existente le falta una variable, añade su NOMBRE con environment_variables_add (queda «pendiente de valor», mddoc run no la inyecta) y pide al usuario que la rellene en la web; si es un secreto aleatorio que puedes generar (contraseña, token, clave de cifrado), ejecuta mddoc set <entorno> <VARIABLE> --generate, que la crea cifrada sin mostrártela. Si el usuario te da un valor en el chat, no lo guardes tú: pídele que lo ponga en la web o con mddoc set <entorno> <VARIABLE> en su terminal. No puedes cambiar ni borrar valores existentes ni crear entornos.

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": {
      "name": "<name>",
      "variables": "<variables>"
    },
    "name": "environment_variables_add"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesNombre del entorno, p. ej. "mi-app.es"
variablesYesNombres de las variables, sin valores

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: names are left 'pending value', existing entries are untouched and returned in alreadySet/alreadyPending, and values never pass through the agent. However, it spends much of its length on CLI installation, `mddoc run` masking, and exit-code-3 unlock handling that describe the Entornos workflow around the tool rather than this call's own behavior and result shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded correctly, but the description is very long for a two-parameter tool and includes numbered rules about npm installation of the CLI, unlock behavior after exit code 3, and terminal invocation of `mddoc run` that do not help an agent call this specific tool. Much of that material belongs to environment usage tooling, not to adding variable names.

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 two-parameter mutation with no annotations and no output schema, the definition covers everything needed: what to send, the pending-value outcome, idempotent handling of existing names, and the security constraint that values must never be handled. Over-coverage of surrounding workflow is a conciseness issue, not a completeness gap.

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; the description still adds real meaning by requiring uppercase POSIX-style names ("Usa nombres POSIX en MAYÚSCULAS"), giving an example value, and making clear the array holds names without values. It also adds the expectation that each name should be explained to the user.

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 first sentence states a specific verb and resource: adds variable NAMES only (example "STRIPE_SECRET_KEY") to an existing environment. It immediately distinguishes the operation from value-setting by stressing the names-only scope, so an agent knows exactly what this tool does versus any value-writing path.

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?

Usage is spelled out explicitly: use this tool when a variable name is missing; if it is a random secret, use `mddoc set <entorno> <VARIABLE> --generate` instead; if the user supplies a value in chat, have them enter it in the web UI or with `mddoc set`. It also states exclusions — no changing/deleting values, no creating environments — and what happens with names that already exist.

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