Skip to main content
Glama
railwayapp

Railway MCP Server

Official
by railwayapp

Get Railway Logs

get-logs

Retrieve build or deployment logs from Railway projects to monitor application performance, troubleshoot errors, and analyze system behavior. Supports filtering by deployment ID, service, environment, and search terms.

Instructions

Get build or deployment logs for the currently linked Railway project. This will only pull the latest successful deployment by default, so if you need to inspect a failed build, you'll need to supply a deployment ID. You can optionally specify a deployment ID, service, and environment. If no deployment ID is provided, it will get logs from the latest deployment. The 'lines' and 'filter' parameters require Railway CLI v4.9.0+. Use 'lines' to limit the number of log lines (disables streaming) and 'filter' to search logs by terms or attributes (e.g., '@level:error', 'user', '@level:warn AND rate limit'). For older CLI versions, these parameters will be ignored and logs will stream.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workspacePathYesThe path to the workspace to get logs from
logTypeYesType of logs to retrieve: 'build' for build logs or 'deploy' for deployment logs
deploymentIdNoDeployment ID to pull logs from. Omit to pull from latest deployment
serviceNoService to view logs from (defaults to linked service)
environmentNoEnvironment to view logs from (defaults to linked environment)
linesNoNumber of log lines to return (disables streaming). Requires Railway CLI v4.9.0+. Useful for searching through recent logs.
filterNoFilter logs by search terms or attributes. Requires Railway CLI v4.9.0+. Examples: 'error', '@level:error', '@level:warn AND rate limit', 'user login', '@status:500'. See https://docs.railway.com/guides/logs for more info.
jsonNoJSON provides structured log data with more information (e.g. timestamps) but uses more tokens. Defaults to false to save tokens. Set to true for more detailed logs.

Implementation Reference

  • The main handler function for the 'get-logs' tool. It determines whether to fetch build or deploy logs, checks CLI feature support for advanced options like lines and filter, constructs the appropriate CLI call via helper functions, and handles errors with user-friendly messages.
    handler: async ({
      workspacePath,
      logType,
      deploymentId,
      service,
      environment,
      lines,
      filter,
      json,
    }: GetLogsOptions) => {
      try {
        const features = await getCliFeatureSupport();
        const supportsFiltering =
          features.logs.args.lines && features.logs.args.filter;
        let versionWarning = "";
    
        if ((lines !== undefined || filter !== undefined) && !supportsFiltering) {
          versionWarning =
            "⚠️ **Note:** Your Railway CLI version does not support the 'lines' and 'filter' parameters. " +
            "Please upgrade to Railway CLI v4.9.0 or later to use these features. " +
            "Logs will be streamed without filtering.\n\n";
        }
    
        let result: string;
        if (logType === "build") {
          result = await getRailwayBuildLogs({
            workspacePath,
            deploymentId,
            service,
            environment,
            lines,
            filter,
            json,
          });
        } else {
          result = await getRailwayDeployLogs({
            workspacePath,
            deploymentId,
            service,
            environment,
            lines,
            filter,
            json,
          });
        }
    
        return createToolResponse(versionWarning + result);
      } catch (error: unknown) {
        const errorMessage =
          error instanceof Error ? error.message : "Unknown error occurred";
        return createToolResponse(
          `❌ Failed to get Railway ${logType} logs\n\n` +
            `**Error:** ${errorMessage}\n\n` +
            "**Next Steps:**\n" +
            "• Ensure you have a Railway project linked\n" +
            "• Check that the deployment ID is valid (if provided)\n" +
            "• Verify the service and environment exist\n" +
            "• Run `railway link` to ensure proper project connection"
        );
      }
    },
  • Zod-based input schema defining parameters for the 'get-logs' tool, including workspace path, log type, optional deployment/service/environment IDs, lines, filter, and JSON output flag.
    inputSchema: {
      workspacePath: z
        .string()
        .describe("The path to the workspace to get logs from"),
      logType: z
        .enum(["build", "deploy"])
        .describe(
          "Type of logs to retrieve: 'build' for build logs or 'deploy' for deployment logs"
        ),
      deploymentId: z
        .string()
        .optional()
        .describe(
          "Deployment ID to pull logs from. Omit to pull from latest deployment"
        ),
      service: z
        .string()
        .optional()
        .describe("Service to view logs from (defaults to linked service)"),
      environment: z
        .string()
        .optional()
        .describe(
          "Environment to view logs from (defaults to linked environment)"
        ),
      lines: z
        .number()
        .optional()
        .describe(
          "Number of log lines to return (disables streaming). Requires Railway CLI v4.9.0+. Useful for searching through recent logs."
        ),
      filter: z
        .string()
        .optional()
        .describe(
          "Filter logs by search terms or attributes. Requires Railway CLI v4.9.0+. Examples: 'error', '@level:error', '@level:warn AND rate limit', 'user login', '@status:500'. See https://docs.railway.com/guides/logs for more info."
        ),
      json: z
        .boolean()
        .optional()
        .describe(
          "JSON provides structured log data with more information (e.g. timestamps) but uses more tokens. Defaults to false to save tokens. Set to true for more detailed logs."
        ),
    },
  • src/index.ts:21-31 (registration)
    Dynamic registration of all tools (including 'get-logs') with the MCP server by iterating over the tools object imported from './tools' and calling registerTool for each.
    Object.values(tools).forEach((tool) => {
    	server.registerTool(
    		tool.name,
    		{
    			title: tool.title,
    			description: tool.description,
    			inputSchema: tool.inputSchema,
    		},
    		tool.handler,
    	);
    });
  • src/tools/index.ts:7-7 (registration)
    Export of the getLogsTool object, making it available via barrel export for inclusion in the tools namespace used during MCP server registration.
    export { getLogsTool } from "./get-logs";
  • Helper function to execute Railway CLI command for build logs, handling command construction, project linking check, execution, and error analysis.
    export const getRailwayBuildLogs = async ({
      workspacePath,
      deploymentId,
      service,
      environment,
      lines,
      filter,
      json,
    }: GetLogsOptions): Promise<string> => {
      const command = await buildLogCommand({
        type: "build",
        deploymentId,
        service,
        environment,
        lines,
        filter,
        json,
      });
      try {
        await checkRailwayCliStatus();
        const result = await getLinkedProjectInfo({ workspacePath });
        if (!result.success) {
          throw new Error(result.error);
        }
    
        const { output } = await runRailwayCommand(command, workspacePath);
    
        return output;
      } catch (error: unknown) {
        return analyzeRailwayError(error, command);
      }
    };
Behavior4/5

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: default behavior (pulls latest successful deployment), prerequisites (requires linked project), version dependencies (CLI v4.9.0+ for some parameters), and effects (disables streaming with 'lines'). However, it lacks details on rate limits, error handling, or authentication needs, which are common for API tools.

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?

The description is appropriately sized and front-loaded, starting with the core purpose and default behavior. Each sentence adds useful information, such as version requirements and parameter usage, with no wasted text. However, it could be slightly more streamlined by integrating some details more cohesively.

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 complexity (8 parameters, no output schema, no annotations), the description does a good job of covering usage, behavior, and parameter context. It explains defaults, version dependencies, and practical examples. However, without an output schema, it doesn't detail the return format or structure, which is a minor gap for a log retrieval tool.

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 adds some context, such as explaining that 'lines' and 'filter' require Railway CLI v4.9.0+ and providing examples for 'filter', but this is minimal beyond the schema. This meets the baseline of 3 for high schema coverage without significant added value.

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 retrieves 'build or deployment logs for the currently linked Railway project,' specifying both the verb ('Get') and resource ('logs'). It distinguishes itself from siblings like 'list-deployments' or 'check-railway-status' by focusing on log retrieval rather than listing or status checking, making the purpose specific and differentiated.

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 on when to use this tool versus alternatives: it specifies that it 'will only pull the latest successful deployment by default' and that for failed builds, you need to supply a deployment ID. It also mentions using 'lines' and 'filter' parameters for specific versions of the Railway CLI, offering clear context and exclusions for usage.

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/railwayapp/railway-mcp-server'

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