Skip to main content
Glama

service_info

Retrieve detailed information about a specific Railway service, including configuration, deployment status, and health metrics for monitoring and management.

Instructions

[API] Get detailed information about a specific service

⚡️ Best for: ✓ Viewing service configuration and status ✓ Checking deployment details ✓ Monitoring service health

→ Prerequisites: service_list

→ Next steps: deployment_list, variable_list

→ Related: service_update, deployment_trigger

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
projectIdYesID of the project containing the service
serviceIdYesID of the service to get information about
environmentIdYesID of the environment to check (usually obtained from service_list)

Implementation Reference

  • The handler function for the 'service_info' MCP tool. It takes projectId, serviceId, and environmentId as inputs and delegates to serviceService.getServiceInfo() to fetch the service details.
    async ({ projectId, serviceId, environmentId }) => {
      return serviceService.getServiceInfo(projectId, serviceId, environmentId);
    }
  • Zod input schema for the 'service_info' tool defining the required parameters: projectId, serviceId, and environmentId.
    {
      projectId: z.string().describe("ID of the project containing the service"),
      serviceId: z.string().describe("ID of the service to get information about"),
      environmentId: z.string().describe("ID of the environment to check (usually obtained from service_list)")
    },
  • The 'service_info' tool is registered using createTool(), which defines its name, description, schema, and handler. This is added to the serviceTools array that gets exported and later registered with the MCP server.
    createTool(
      "service_info",
      formatToolDescription({
        type: 'API',
        description: "Get detailed information about a specific service",
        bestFor: [
          "Viewing service configuration and status",
          "Checking deployment details",
          "Monitoring service health"
        ],
        relations: {
          prerequisites: ["service_list"],
          nextSteps: ["deployment_list", "variable_list"],
          related: ["service_update", "deployment_trigger"]
        }
      }),
      {
        projectId: z.string().describe("ID of the project containing the service"),
        serviceId: z.string().describe("ID of the service to get information about"),
        environmentId: z.string().describe("ID of the environment to check (usually obtained from service_list)")
      },
      async ({ projectId, serviceId, environmentId }) => {
        return serviceService.getServiceInfo(projectId, serviceId, environmentId);
      }
    ),
  • All tools, including 'service_info' from serviceTools, are collected and registered with the MCP server using server.tool() in the registerAllTools function.
    export function registerAllTools(server: McpServer) {
      // Collect all tools
      const allTools = [
        ...databaseTools,
        ...deploymentTools,
        ...domainTools,
        ...projectTools,
        ...serviceTools,
        ...tcpProxyTools,
        ...variableTools,
        ...configTools,
        ...volumeTools,
        ...templateTools,
      ] as Tool[];
    
      // Register each tool with the server
      allTools.forEach((tool) => {
        server.tool(
          ...tool
        );
      });
    } 
  • The core helper method getServiceInfo() in ServiceService that fetches service instance details and recent deployments using the client API, formats the response, and is called by the tool handler.
      async getServiceInfo(projectId: string, serviceId: string, environmentId: string) {
        try {
          const [serviceInstance, deployments] = await Promise.all([
            this.client.services.getServiceInstance(serviceId, environmentId),
            this.client.deployments.listDeployments({ projectId, serviceId, environmentId, limit: 5 })
          ]);
    
          if (!serviceInstance) {
            return createErrorResponse(`Service instance not found.`);
          }
    
          const deploymentStatus = deployments.length > 0
            ? `\nLatest Deployment: ${deployments[0].status} (${deployments[0].id})`
            : '\nNo recent deployments';
    
          const info = `🚀 Service: ${serviceInstance.serviceName}
    ID: ${serviceInstance.serviceId}
    Region: ${serviceInstance.region || 'Not set'}
    Replicas: ${serviceInstance.numReplicas || 1}
    Root Directory: ${serviceInstance.rootDirectory || '/'}
    Build Command: ${serviceInstance.buildCommand || 'Not set'}
    Start Command: ${serviceInstance.startCommand || 'Not set'}
    Health Check Path: ${serviceInstance.healthcheckPath || 'Not set'}
    Sleep Mode: ${serviceInstance.sleepApplication ? 'Enabled' : 'Disabled'}${deploymentStatus}`;
    
          return createSuccessResponse({
            text: info,
            data: { serviceInstance, deployments }
          });
        } catch (error) {
          return createErrorResponse(`Error getting service details: ${formatError(error)}`);
        }
      }
Behavior4/5

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

With no annotations provided, the description carries full burden. It effectively communicates this is a read-only operation ('Get detailed information'), suggests it's for monitoring/checking purposes, and implies it returns configuration/status/health data. However, it doesn't explicitly mention rate limits, authentication needs, or error behaviors.

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 efficiently structured with clear sections (purpose, best for, prerequisites, next steps, related tools). Every sentence earns its place, and information is front-loaded with the core purpose stated first. The bullet-point format enhances readability without unnecessary verbosity.

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?

For a read-only tool with 3 parameters and 100% schema coverage, the description is quite complete. It provides purpose, usage context, and workflow relationships. The main gap is the lack of output schema, so the agent doesn't know the return format, but the description compensates somewhat by indicating what information will be returned (configuration, status, health, deployment details).

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?

Schema description coverage is 100%, so the schema already documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting for parameter documentation.

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 ('Get detailed information') and resource ('about a specific service'). It distinguishes from siblings like service_list (which lists services) and service_update (which modifies services). The '[API]' prefix further clarifies this is an API operation.

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 through the 'Best for' section listing three specific use cases, plus prerequisite ('service_list'), next steps ('deployment_list, variable_list'), and related tools ('service_update, deployment_trigger'). This gives clear context for when to use this tool versus alternatives.

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