AI agents

Give an AI agent access to your turboEnv configuration over MCP, without putting secret values into its conversation history.

turboenv-mcp lets an agent — Cursor, Claude Desktop, or anything else speaking MCP — work with your configuration.

{
  "mcpServers": {
    "turboenv": {
      "command": "npx",
      "args": ["-y", "turboenv-mcp"],
      "env": { "TURBOENV_TOKEN": "tenv_live_..." }
    }
  }
}

Use a project-scoped token here, created by leaving the environment blank when you make it. That lets the agent compare environments, which is most of what makes this useful, while still being confined to one project.

The problem this is shaped around

Anything a tool returns to an agent lands in a conversation transcript. It gets sent to a model provider, kept in history, and is reachable by a prompt injection. Handing an agent a decrypted .env recreates exactly the problem turboEnv exists to solve, with more copies.

So the tools are arranged so that most work needs no values at all:

write_env_file is the one that makes this practical. Ask the agent to set up your local environment and the secrets reach the file on disk; the agent only learns how many there were. It never sees them, so they never enter the transcript.

That covers most of what you actually want an agent to do: "which variables does staging define that production does not", "set up my .env for this project", "what changed in version 12".

Customer-managed projects

Add TURBOENV_KEY_FILE pointing to a secret mount, or set TURBOENV_KEY. Metadata tools still work when it is absent. Value, diff and file-write tools decrypt locally when it is present. The key does not bypass secret redaction: TURBOENV_ALLOW_SECRET_VALUES=true remains a separate, explicit opt-in.

Letting an agent read secret values

If you genuinely need it, two separate things must both be true:

1. The server is started with TURBOENV_ALLOW_SECRET_VALUES=true
2. The call passes revealSecrets: true

Both are required by design. The environment variable is set by a person editing their MCP config, so an agent cannot turn this on for itself, and an injected instruction telling it to pass the flag achieves nothing unless you already decided to allow it.

Think about it before you do. Values become part of a transcript held by whoever runs the model.

Writes are not exposed

There are no tools for changing or deleting anything, and the credential rules mean there could not usefully be. This server authenticates with a project token, and a project token is read-only: the endpoints that save a version or delete a project both refuse anything except a credential from turboenv login, which lives on a person's machine and never in an agent's configuration.

So an agent can read your configuration and write a local file, and cannot alter what your production deployment will pick up, nor destroy the project it is reading. Variables are changed in the dashboard or with turboenv push, and projects are deleted in the dashboard or with turboenv delete, by a person.

Without MCP

An agent that can make HTTP requests does not need this server at all. The OpenAPI spec is public, unauthenticated and CORS-enabled, so an agent that finds a turboEnv URL can read the contract and call the API directly, or generate itself a client.

The site also publishes /llms.txt, which points models at the spec, these docs and the tools, in the format described at llmstxt.org.

If you go that route, prefer GET /v1/variables over GET /v1/env. It answers "what does this application expect to be configured" without decrypting anything, which is the right default for a caller whose output is a transcript.