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.
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