Skip to main content
Glama

variable_set

Create or update environment variables in Railway.app projects to configure services, manage secrets, and set connection strings for deployments.

Instructions

[API] Create or update an environment variable

⚡️ Best for: ✓ Setting configuration values ✓ Updating connection strings ✓ Managing service secrets

⚠️ Not for: × Bulk variable updates (use variable_bulk_set) × Temporary configuration changes

→ Prerequisites: service_list

→ Alternatives: variable_bulk_set

→ Next steps: deployment_trigger, service_restart

→ Related: variable_list, variable_delete

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectIdYesID of the project containing the service
environmentIdYesID of the environment for the variable (usually obtained from service_list)
nameYesName of the environment variable
valueYesValue to set for the variable
serviceIdNoOptional: ID of the service for the variable, if omitted creates/updates a shared variable

Implementation Reference

  • Full registration of the 'variable_set' tool using createTool, including description, input schema, and handler function.
    createTool(
      "variable_set",
      formatToolDescription({
        type: 'API',
        description: "Create or update an environment variable",
        bestFor: [
          "Setting configuration values",
          "Updating connection strings",
          "Managing service secrets"
        ],
        notFor: [
          "Bulk variable updates (use variable_bulk_set)",
          "Temporary configuration changes"
        ],
        relations: {
          prerequisites: ["service_list"],
          nextSteps: ["deployment_trigger", "service_restart"],
          alternatives: ["variable_bulk_set"],
          related: ["variable_list", "variable_delete"]
        }
      }),
      {
        projectId: z.string().describe("ID of the project containing the service"),
        environmentId: z.string().describe("ID of the environment for the variable (usually obtained from service_list)"),
        name: z.string().describe("Name of the environment variable"),
        value: z.string().describe("Value to set for the variable"),
        serviceId: z.string().optional().describe("Optional: ID of the service for the variable, if omitted creates/updates a shared variable")
      },
      async ({ projectId, environmentId, name, value, serviceId }) => {
        return variableService.upsertVariable(projectId, environmentId, name, value, serviceId);
      }
    ),
  • Handler function that executes the tool logic by delegating to variableService.upsertVariable.
    async ({ projectId, environmentId, name, value, serviceId }) => {
      return variableService.upsertVariable(projectId, environmentId, name, value, serviceId);
    }
  • Zod schema defining the input parameters for the variable_set tool.
    {
      projectId: z.string().describe("ID of the project containing the service"),
      environmentId: z.string().describe("ID of the environment for the variable (usually obtained from service_list)"),
      name: z.string().describe("Name of the environment variable"),
      value: z.string().describe("Value to set for the variable"),
      serviceId: z.string().optional().describe("Optional: ID of the service for the variable, if omitted creates/updates a shared variable")
    },
  • MCP server registration loop that registers the variable_set tool (imported via variableTools).
    allTools.forEach((tool) => {
      server.tool(
        ...tool
      );
    });
  • Supporting service method upsertVariable called by the tool handler to perform the actual variable update via client API.
    async upsertVariable(projectId: string, environmentId: string, name: string, value: string, serviceId?: string) {
      try {
        await this.client.variables.upsertVariable({
          projectId,
          environmentId,
          name,
          value,
          serviceId
        });
    
        const variableType = serviceId ? "service variable" : "shared environment variable";
        return createSuccessResponse({
          text: `Successfully set ${variableType} "${name}"`
        });
      } catch (error) {
        return createErrorResponse(`Error setting variable: ${formatError(error)}`);
      }
    }
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior by indicating it can create or update variables, mentions prerequisites (service_list), and hints at next steps (deployment_trigger, service_restart). However, it lacks details on error handling, rate limits, or auth needs, which would be beneficial for a mutation tool.

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 well-structured and front-loaded with the core purpose, followed by organized sections (Best for, Not for, Prerequisites, etc.). Every sentence serves a clear purpose without redundancy, making it efficient and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (mutation with 5 parameters) and no annotations or output schema, the description does a good job by covering purpose, usage, prerequisites, and related tools. However, it could improve by mentioning the response format or error cases, which are missing despite the lack of output schema.

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

Parameters3/5

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

The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add any parameter-specific details beyond what the schema provides, such as examples or constraints. This meets the baseline for high schema coverage, but no extra value is added.

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 clearly states the tool's purpose with specific verbs ('Create or update') and resource ('environment variable'), distinguishing it from siblings like variable_bulk_set for bulk operations and variable_list for viewing. It directly answers what the tool does without ambiguity.

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 provides explicit guidance with 'Best for' and 'Not for' sections, naming specific use cases (e.g., setting configuration values) and exclusions (e.g., not for bulk updates). It also lists prerequisites (service_list), alternatives (variable_bulk_set), and related tools, offering comprehensive context for when to use this tool.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/epitaphe360/railway-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server