Railway MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose with well-defined boundaries, as evidenced by the detailed 'Best for' and 'Not for' sections that explicitly differentiate overlapping concepts. For example, deployment_trigger vs service_restart, variable_set vs variable_bulk_set, and domain_create vs tcp_proxy_create are all clearly distinguished with no ambiguity.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern throughout, such as project_list, service_create_from_repo, and variable_delete. The naming is highly predictable and uniform across all 36 tools, with no mixing of conventions or styles.
Tool Count2/5
With 36 tools, this server feels overly heavy for a Railway deployment platform, suggesting fragmentation of functionality. While the domain is broad, many tools could potentially be consolidated (e.g., multiple variable management tools) or handled through parameters rather than separate tools, making the surface area unnecessarily large.
Completeness5/5
The tool set provides comprehensive coverage of Railway's domain, including full CRUD operations for projects, services, deployments, domains, variables, volumes, and TCP proxies. The workflow tools like database_deploy_from_template and variable_copy fill important gaps, and the detailed descriptions show thoughtful consideration of the entire deployment lifecycle.
Average 4.3/5 across 36 of 36 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Update' implies a mutation operation, but the description doesn't specify whether this requires specific permissions, what happens on failure, if changes are reversible, or any rate limits. It mentions 'properties' but doesn't clarify if all or only some properties are updatable, leaving behavioral aspects unclear.
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 extremely concise with a single sentence ('Update a volume's properties'), front-loading the key action and resource. There is no wasted verbiage, making it efficient for quick comprehension, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It fails to address critical aspects like error handling, response format, or side effects, leaving the agent with insufficient context to use the tool effectively beyond basic parameter passing.
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%, with clear descriptions for both parameters ('volumeId' and 'name'), so the schema does the heavy lifting. The description adds minimal value beyond the schema by implying that 'properties' include 'name', but it doesn't explain parameter interactions or provide additional context like format examples or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('a volume's properties'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'volume_delete' or 'volume_list' beyond the verb, nor does it specify which properties can be updated beyond what's implied by the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'volume_create' or 'volume_delete', nor does it mention prerequisites (e.g., needing an existing volume). It lacks context about typical use cases or constraints, leaving the agent to infer usage from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a list operation, implying it's likely read-only and non-destructive, but doesn't confirm this or add details like pagination, sorting, error conditions, or authentication requirements. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 a single, efficient sentence that front-loads the core purpose ('List all environments in a project') with zero wasted words. It's appropriately sized for a simple list tool and earns its place by clearly stating the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is minimally complete but lacks depth. It covers the basic purpose but doesn't address behavioral aspects like return format or error handling, which would be helpful for an agent despite the simple nature of the 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 input schema has 100% description coverage, with the single parameter 'projectId' clearly documented in the schema. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't explain what an 'environment' is or how the project ID should be formatted), so it meets the baseline score when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all environments in a project'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'project_list' or 'domain_list', which follow similar patterns for different resources, so it doesn't reach the highest score for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid project ID), exclusions, or comparisons to related tools like 'project_info' or 'deployment_list', leaving the agent to infer usage context solely from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 mentions the tool is for 'viewing persistent storage configurations' and 'auditing storage usage' which implies read-only behavior, but doesn't explicitly state whether this is a read operation, what permissions are required, or describe pagination/rate limiting. The 'Best for' section adds some behavioral context but doesn't fully cover operational characteristics.
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 well-structured with clear sections (API label, purpose statement, Best for, Prerequisites, Next steps, Related). It's appropriately sized at 6 lines with no redundant information. Every sentence earns its place, though the emoji and formatting symbols could be considered slightly decorative rather than strictly necessary.
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 single-parameter list tool with no output schema, the description provides good contextual completeness. It covers purpose, use cases, prerequisites, next steps, and related tools. The main gap is lack of information about return format (what data is included in the volume list) and any limitations (pagination, filtering options). However, given the tool's relative simplicity and the comprehensive usage guidance provided, it's mostly complete.
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% with the single parameter 'projectId' well-documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema. With high schema coverage, the baseline score of 3 is appropriate since 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.
Purpose4/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 as 'List all volumes in a project' with a specific verb (list) and resource (volumes). It distinguishes from some siblings like volume_create/delete/update but doesn't explicitly differentiate from other list tools like service_list or domain_list. The purpose is clear but sibling differentiation could be more specific.
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 excellent usage guidance with explicit sections: 'Best for' with three use cases, 'Prerequisites: project_list', 'Next steps: volume_create', and 'Related: service_info, database_deploy'. This gives clear context about when to use this tool and how it fits into workflows with specific alternatives and prerequisites named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions 'recent deployments' and 'monitoring service updates' which imply read-only behavior, but doesn't explicitly state whether this is a read operation, what permissions are needed, or how results are returned (pagination, format). It adds some context but lacks comprehensive behavioral disclosure for a tool with no annotation coverage.
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 with clear sections (purpose, best for, prerequisites, next steps, related tools). Every sentence earns its place - the first sentence states the core purpose, and subsequent sections provide valuable guidance without redundancy. It's appropriately sized and front-loaded.
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 list tool with 100% schema coverage but no output schema, the description provides good contextual completeness. It covers purpose, usage guidelines, and relationships with other tools. The main gap is lack of output information (what the deployment list looks like), but given this is a list operation with clear sibling tools, it's reasonably complete.
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 parameters. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain how to obtain environmentId from service_list, though the schema hints at this). Baseline 3 is appropriate when schema does the heavy lifting.
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 verb ('List') and resource ('recent deployments for a service in a specific environment'). It distinguishes from siblings like deployment_logs (which shows logs) and deployment_trigger (which initiates deployments) by focusing on listing deployment history.
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' section listing specific use cases (viewing deployment history, monitoring service updates), prerequisites (service_list), next steps (deployment_logs, deployment_trigger), and related tools (service_info, service_restart). 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions the tool is for 'Get logs' (implying a read operation) and specifies use cases, but does not detail aspects like authentication requirements, rate limits, error handling, or log format. The description adds some context (e.g., what it's not for) but lacks depth on operational behavior, leaving gaps for an agent.
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 bullet points for best uses, exclusions, and related steps. Every sentence earns its place by providing clear, actionable information without redundancy or fluff, making it efficient for an agent to parse.
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 moderate complexity (2 parameters, no output schema, no annotations), the description is largely complete: it clarifies purpose, usage, and exclusions. However, it lacks details on behavioral aspects (e.g., log format, pagination) and output expectations, which could hinder an agent's ability to use it effectively. The absence of an output schema increases the need for more context, but the description partially compensates with usage guidelines.
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%, with both parameters (deploymentId, limit) clearly documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, such as format examples or constraints. Given the high coverage, the baseline score of 3 is appropriate, as the schema handles the heavy lifting.
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 a specific verb ('Get logs') and resource ('for a specific deployment'), distinguishing it from siblings like deployment_status (which checks status rather than logs) and deployment_list (which lists deployments rather than fetching logs). The title is null, so the description fully carries this burden.
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 ('Best for: Debugging deployment issues, Monitoring deployment progress, Checking build output') and when not to use it ('Not for: Service runtime logs, Database logs'). It also lists prerequisites ('deployment_list'), next steps ('deployment_status'), and related tools ('service_info, deployment_trigger'), offering comprehensive alternatives and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that the tool lists 'all domains (both service and custom)' and hints at its read-only nature through usage contexts like 'Viewing' and 'Auditing,' but it does not explicitly state whether it's a safe read operation, requires specific permissions, or details output format. It adds some value but lacks comprehensive behavioral disclosure.
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 bullet points for usage guidelines, prerequisites, next steps, and related tools. Every sentence earns its place by providing clear, actionable information without redundancy or fluff.
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 (a list operation with 3 parameters), no annotations, and no output schema, the description does a good job by covering purpose, usage, and context. However, it lacks details on output format (e.g., what data is returned) and behavioral aspects like pagination or error handling, which would be needed for full completeness.
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 (projectId, environmentId, serviceId) with descriptions. The description does not add any parameter-specific details beyond what the schema provides, such as format examples or dependencies, so it meets the baseline for high schema coverage.
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: 'List all domains (both service and custom) for a service.' It specifies the verb ('List'), resource ('domains'), and scope ('for a service'), and distinguishes it from siblings like domain_check, domain_create, domain_update, and domain_delete by focusing on listing rather than other operations.
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: 'Best for: Viewing service endpoints, Managing domain configurations, Auditing domain settings.' It also lists prerequisites ('service_list'), next steps ('domain_create, domain_update'), and related tools ('service_info, tcp_proxy_list'), clearly indicating context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates this is a read operation ('Get detailed information'), which is helpful, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what specific details are returned. The description adds some context but leaves significant gaps for a tool with no annotation coverage.
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 appropriately sized. It uses clear sections with bullet points and arrows for organization, front-loading the core purpose. Every sentence earns its place by providing distinct value (purpose, usage scenarios, prerequisites, next steps, related tools).
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 moderate complexity (single parameter, read operation) and lack of annotations/output schema, the description does a good job covering usage context. However, it doesn't explain what 'detailed information' includes or the response format, which would be helpful since there's no output schema. It's mostly complete but has minor gaps in behavioral transparency.
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%, with the single parameter 'projectId' fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides (e.g., format examples, where to find project IDs). This meets the baseline of 3 when the schema does the heavy lifting.
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 a specific verb ('Get detailed information') and resource ('about a specific Railway project'). It distinguishes from siblings like project_list (which lists projects) and project_update/project_delete (which modify projects) by focusing on retrieving detailed information for a single project.
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 ('Best for: Viewing project details and status, Checking environments and services, Project configuration review'), prerequisites ('Prerequisites: project_list'), next steps ('Next steps: service_list, variable_list'), and related alternatives ('Related: project_update, project_delete'). This comprehensive guidance helps the agent select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions prerequisites and next steps, which adds useful context, but lacks details on behavioral traits like permissions needed, rate limits, or what happens on creation (e.g., default settings, costs). The description doesn't contradict annotations, but could be more informative for a creation 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 with bullet points and symbols, front-loaded with the core purpose. Every sentence adds value (e.g., use cases, exclusions, prerequisites), with no wasted words, 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 no annotations and no output schema, the description does well by covering purpose, guidelines, and context (prerequisites, next steps). However, as a creation tool, it could benefit from more behavioral details (e.g., response format, error handling) to be fully complete, though it's largely adequate.
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 parameters. The description doesn't add specific meaning beyond the schema (e.g., format examples for image beyond what's in schema, or implications of optional name). Baseline 3 is appropriate as the schema does the heavy lifting.
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 creates a new service from a Docker image, specifying both the action (create) and resource (service from image). It distinguishes from sibling tools like service_create_from_repo and database_deploy, making it 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 with 'Best for' and 'Not for' sections, naming alternatives (database_deploy, service_create_from_repo) and stating prerequisites (project_list). This gives clear context on when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as a read operation ('Get detailed information'), which implies it's non-destructive, but doesn't explicitly state permission requirements, rate limits, or error behaviors. The description adds some context about what information is retrieved (configuration, status, deployment details, health) but lacks comprehensive behavioral disclosure.
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, Prerequisites, Next steps, Related). Every sentence earns its place by providing actionable guidance without redundancy or fluff.
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 moderate complexity (3 required parameters, no output schema, no annotations), the description provides good contextual coverage. It explains the tool's purpose, usage scenarios, prerequisites, and related tools. However, without annotations or output schema, it could benefit from more detail on return values or error handling to be fully complete.
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 (projectId, serviceId, environmentId) with clear descriptions. The description doesn't add any parameter-specific information beyond what's in the schema, such as format examples or relationships between parameters. Baseline 3 is appropriate when schema coverage is complete.
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 a specific verb ('Get') and resource ('detailed information about a specific service'). It distinguishes itself from siblings like service_list (which lists services) and service_update (which modifies services) by focusing on retrieving detailed information for a single service.
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' scenarios (viewing configuration, checking deployment details, monitoring health), prerequisites (service_list), next steps (deployment_list, variable_list), and related tools (service_update, deployment_trigger). This clearly indicates 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool lists services, finds IDs, and checks status, which implies a read-only operation, but doesn't explicitly state behavioral traits like whether it requires authentication, has rate limits, or returns paginated results. It adds some context (e.g., overview purpose) but lacks details on error handling or output format.
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 bullet-point sections for usage, prerequisites, and related tools. Every sentence earns its place by providing actionable information 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 low complexity (1 parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, and relationships, but lacks details on behavioral aspects like authentication or output format, which would be helpful since no annotations or output schema exist. It's sufficient but has minor gaps.
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%, with the single parameter 'projectId' fully documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides (e.g., format examples or constraints), so it meets the baseline of 3 for high schema coverage without extra 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 specific action ('List all services') and resource ('in a specific Railway project'), distinguishing it from siblings like service_info (detailed info), service_create_* (creation), and service_delete (deletion). It explicitly mentions the scope ('all services') and target ('specific Railway project'), making the purpose unambiguous.
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 a 'Best for' section listing three use cases, prerequisites ('project_list'), next steps ('service_info, deployment_list'), and related tools ('project_info, variable_list'). This clearly indicates when to use this tool versus alternatives, such as using service_info for details or project_list as a prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates this is a destructive operation ('Delete'), which implies irreversible removal, but lacks details on permissions, error handling, or confirmation steps. The description adds some behavioral context (e.g., security management use cases) but doesn't fully compensate for the absence of annotations, leaving gaps in transparency.
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 bullet points and symbols for readability, front-loading the core purpose and avoiding redundancy. Each section ('Best for', 'Not for', 'Prerequisites', 'Related') adds value without unnecessary elaboration, making it easy to scan and understand quickly.
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 destructive tool with no annotations and no output schema, the description does well by covering purpose, usage guidelines, and prerequisites. However, it lacks details on behavioral aspects like error responses or confirmation requirements, which are important for a delete operation. It's mostly complete but has minor gaps given the tool's complexity.
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%, with the single parameter 'proxyId' well-documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, such as format examples or validation rules. Given the high schema coverage, a baseline score of 3 is appropriate, as the description doesn't enhance parameter understanding but doesn't need to.
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 specific action ('Delete a TCP proxy') and resource ('TCP proxy'), distinguishing it from sibling tools like tcp_proxy_create or tcp_proxy_list. It uses a precise verb and identifies the exact resource type, leaving no ambiguity about its function.
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 it ('Best for: Removing unused proxies, Security management, Endpoint cleanup') and when not to use it ('Not for: Temporary proxy disabling, Port updates'), with clear alternatives implied (e.g., use service_update for updates). It also mentions prerequisites ('tcp_proxy_list') and related tools ('service_update'), offering comprehensive usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states this is a listing operation ('List all TCP proxies'), implying it's read-only and non-destructive, which is appropriate. However, it doesn't disclose behavioral details like pagination, rate limits, authentication requirements, or error conditions, leaving gaps for a tool with no annotation coverage.
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 in the first line. Each subsequent section ('Best for', 'Prerequisites', 'Next steps', 'Related') adds value without redundancy. Every sentence earns its place, making it efficient and easy to parse.
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 no annotations and no output schema, the description does well by covering purpose, usage guidelines, and relationships. However, it lacks details on return values (e.g., format of listed proxies) and behavioral aspects like error handling, which would improve completeness for a tool with no structured output documentation.
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 both parameters (environmentId and serviceId). The description adds context by mentioning 'environment' and 'service', but doesn't provide additional semantic details beyond what the schema offers. This meets the baseline for high schema coverage.
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 specific action ('List all TCP proxies'), resource ('for a service in a specific environment'), and scope ('all TCP proxies'). It distinguishes from siblings like tcp_proxy_create (creation) and tcp_proxy_delete (deletion) by focusing on listing operations.
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' scenarios (viewing configurations, managing access, auditing endpoints), prerequisites (service_list), next steps (tcp_proxy_create), and related tools (domain_list, service_info). This clearly indicates 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a write operation ('Create') but doesn't disclose behavioral traits like required permissions, whether the volume is immediately available, error handling, or rate limits. The description adds some context (e.g., 'persistent volume for a service') but lacks detailed behavioral information, resulting in a moderate score.
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 bullet points for usage guidelines and related steps. Every sentence earns its place by providing clear value without redundancy, making it efficient and easy to parse.
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 of creating a persistent volume with 4 required parameters and no output schema, the description is fairly complete. It covers purpose, usage guidelines, prerequisites, and related tools. However, it lacks details on behavioral aspects (e.g., permissions, errors) and doesn't explain return values, which slightly reduces completeness for a mutation tool with no annotations.
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%, meaning the input schema already documents all four parameters (projectId, environmentId, serviceId, mountPath) with descriptions. The description doesn't add any parameter-specific semantics beyond what the schema provides, so it meets the baseline of 3 without compensating for gaps.
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 a specific verb ('Create') and resource ('new persistent volume for a service'). It distinguishes itself from siblings like volume_list, volume_update, and volume_delete by focusing on creation rather than listing, updating, or deleting volumes.
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 ('Best for: Setting up database storage, Configuring persistent data, Adding file storage') and when not to use ('Not for: Temporary storage needs, Static file hosting, Memory caching'). It also lists related tools (service_update, database_deploy) and prerequisites (service_list), offering clear alternatives and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 communicates that this is a deployment tool (implying creation/mutation), mentions security defaults and best practices, and provides workflow context ('Next steps', 'Related'). However, it doesn't explicitly state permission requirements, rate limits, or error handling details.
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 well-structured with clear sections (workflow, best for, not for, prerequisites, alternatives, next steps, related) and uses bullet points and symbols for readability. While slightly verbose, every section adds value, and the information is front-loaded with the core purpose.
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 deployment tool with no annotations and no output schema, the description provides strong contextual completeness. It covers purpose, usage guidelines, prerequisites, alternatives, and related tools. The main gap is the lack of output information (what the tool returns), but given the workflow context and sibling tools, it's reasonably complete.
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 doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain parameter interactions or provide examples). This meets the baseline for high schema coverage.
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 specific action ('Deploy a pre-configured database') and resource ('using Railway's official templates and best practices'), distinguishing it from siblings like service_create_from_image by focusing on template-based database deployment. It explicitly mentions the scope ('Common database types') and differentiates from custom configurations.
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, clearly stating when to use (standard deployments, quick setup) and when not to use (custom versions, complex configurations). It names a prerequisite (database_list_types) and an alternative (service_create_from_image), offering comprehensive usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 hints at creation behavior ('Create a new domain') and mentions prerequisites, but lacks details on permissions, rate limits, or error handling. However, it adds useful context like HTTPS endpoints and Railway's automatic generation, which compensates partially for the annotation gap.
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 well-structured with bullet points and icons, making it easy to scan. However, it includes some redundancy (e.g., repeating 'railway will generate one for you' in the schema) and could be more front-loaded; the core purpose is clear but buried slightly in formatting.
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 of a creation tool with no annotations or output schema, the description does a good job covering usage, alternatives, and prerequisites. It lacks details on return values or error cases, but the structured guidance and clear purpose make it mostly complete for agent use.
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 5 parameters thoroughly. The description does not add any parameter-specific semantics beyond what the schema provides, such as explaining the interaction between domain and suffix. This meets the baseline of 3 for high schema coverage.
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 specific action ('Create a new domain') and resource ('for a service'), distinguishing it from siblings like domain_update, domain_list, and tcp_proxy_create. The title is null, making the description's clarity even more critical, and it successfully fulfills this role.
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 alternatives (tcp_proxy_create), prerequisites (service_list, domain_check), next steps (domain_update), and related tools (service_info, domain_list). This comprehensive coverage helps the agent understand when and how to use this tool effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 communicates that this is a mutation tool ('Create or update'), specifies prerequisites, and hints at operational context by linking to 'deployment_trigger' and 'service_restart' as next steps. However, it lacks details on permissions, error handling, or rate limits.
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 well-structured with bullet points and icons, making it easy to scan. It is appropriately sized, with each section adding value, though the 'Related' section could be slightly trimmed as it overlaps with sibling context. Overall, it is efficient and front-loaded with key information.
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 mutation tool with no annotations and no output schema, the description does a good job covering purpose, usage, and prerequisites. It links to relevant tools and next steps, providing operational context. However, it could improve by detailing output behavior or error scenarios, given the complexity of bulk operations.
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 semantics beyond what the schema provides, such as explaining variable naming conventions or value formats. It meets the baseline for high schema coverage.
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 specific action ('Create or update multiple environment variables at once') and distinguishes it from sibling tools by explicitly mentioning 'variable_set' as an alternative for single variable updates. It identifies the resource (environment variables) and scope (bulk operations).
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 dedicated 'Best for' and 'Not for' sections, naming specific use cases (migrating configuration, initial setup, bulk updates) and exclusions (single variable updates, temporary changes). It also lists prerequisites (service_list), alternatives (variable_set), and related tools, offering comprehensive usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses key behavioral traits: it's a workflow tool for environment migration/duplication, not for single updates. It mentions the optional serviceId parameter for shared vs. service-specific variables and implies batch operation. However, it doesn't detail potential side effects like rate limits or error handling.
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 well-structured with bullet points and icons, making it scannable and front-loaded. However, the 'Related' and 'Next steps' sections, while helpful, add some redundancy as these are already implied by sibling tool names, slightly reducing efficiency.
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 5-parameter mutation tool with no annotations and no output schema, the description does a good job covering purpose, usage, and context. It clearly indicates this is a write operation (copying variables) and provides workflow guidance. The main gap is lack of output format details, but given the tool's nature, the description is reasonably complete.
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 5 parameters thoroughly. The description adds minimal parameter semantics beyond the schema, mainly implying the serviceId distinction between shared and service-specific variables. This meets the baseline for high schema coverage.
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 verb ('Copy') and resource ('variables from one environment to another'), and distinguishes it from sibling tools like variable_set and variable_bulk_set. The [WORKFLOW] tag further emphasizes its scope as a batch 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 with 'Best for' and 'Not for' sections, naming specific alternatives (variable_set) and prerequisites (service_list). It also lists related tools and next steps, offering comprehensive context for when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It effectively describes the tool's purpose (authentication configuration), when it's needed ('only needed if not set in environment variables'), and hints at its mutating nature ('Configure', 'Token updates'), which is appropriate. However, it lacks details on potential side effects (e.g., token persistence, error handling) or response format, leaving some behavioral aspects unclear.
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 bullet points for best uses, exclusions, and related tools. Every sentence earns its place by providing clear, actionable information without redundancy or fluff, making it highly efficient and easy to parse.
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 (simple authentication setup with one parameter), no annotations, and no output schema, the description is largely complete. It covers purpose, usage guidelines, and exclusions effectively. However, it lacks details on behavioral outcomes (e.g., what happens after configuration, error scenarios), which would enhance completeness for a tool with no structured output information.
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%, with the parameter 'token' fully documented in the schema. The description does not add any additional meaning or context beyond what the schema provides (e.g., it doesn't explain token format, security implications, or validation rules). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 specific action ('Configure the Railway API token for authentication') and resource ('Railway API token'), distinguishing it from all sibling tools which focus on projects, services, deployments, domains, variables, volumes, etc. The purpose is unambiguous and directly addresses authentication setup rather than operational tasks.
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 ('Initial setup', 'Token updates', 'Authentication configuration') and when not to use it ('Not for: Project configuration, Service settings, Environment variables'). It also suggests next steps ('project_list, service_list') and related tools ('project_create'), offering clear alternatives and context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It effectively describes the tool's behavior as a read-only status check (implied by 'Check' and monitoring use cases), though it doesn't explicitly mention safety aspects like rate limits or error handling. The context is clear but could be more detailed on behavioral traits.
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 bullet points and icons, front-loading the core purpose and followed by organized sections (Best for, Not for, prerequisites, etc.). Every sentence earns its place with no wasted words, making it highly scannable and informative.
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 moderate complexity (single parameter, no output schema, no annotations), the description is largely complete—covering purpose, usage, and context well. However, it lacks details on return values or error cases, which would be helpful since there's no output schema, leaving a minor gap in full contextual understanding.
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 input schema has 100% description coverage, with the parameter 'deploymentId' well-documented in the schema itself. The description adds no additional parameter information beyond what the schema provides, so it meets the baseline of 3 for high schema coverage without extra 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 specific action ('Check the current status') and resource ('a deployment'), distinguishing it from sibling tools like deployment_list (which lists deployments) and deployment_logs (which provides logs). The purpose is precise and unambiguous.
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' (monitoring progress, verifying success, checking failures) and 'Not for' (service/database logs), plus prerequisites (deployment_list, deployment_trigger), next steps (deployment_logs), and related tools (service_info, service_restart, deployment_wait). This comprehensively defines when and how 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.
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 communicates that this tool triggers deployments for code changes, configuration updates, and rollbacks, and it clarifies exclusions (e.g., not for database changes). However, it lacks details on potential side effects like downtime or error handling, 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.). Each sentence adds value without redundancy, making it efficient and easy to parse.
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 of a deployment tool with no annotations and no output schema, the description does a strong job by covering purpose, usage guidelines, and exclusions. It could improve by detailing return values or error cases, but it provides sufficient context for an agent to understand when and how to use it effectively.
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 four parameters. The description does not add any parameter-specific information beyond what the schema provides, such as explaining how 'commitSha' relates to deployments. Thus, it meets the baseline of 3 without compensating for gaps.
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 a specific verb ('Trigger') and resource ('new deployment for a service'). It distinguishes from siblings by explicitly mentioning what it's not for (e.g., 'Restarting services (use service_restart)'), making the scope unambiguous.
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 alternatives (e.g., 'service_restart', 'service_update'). It also lists prerequisites ('service_list') and related tools, offering comprehensive context for when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only check ('Check if a domain is available') but doesn't disclose behavioral traits like rate limits, authentication needs, error handling, or what 'available' means (e.g., registered status, cost). It adds some context with usage scenarios but lacks detailed operational transparency.
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 appropriately sized and well-structured, with a clear purpose statement upfront, followed by bullet-pointed usage guidelines and related tools. Every sentence earns its place, and there is no wasted text.
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 low complexity (single parameter, no output schema, no annotations), the description is mostly complete. It covers purpose, usage, and next steps effectively. However, it lacks details on return values or error cases, which would be helpful since there's no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'domain' fully documented. The description doesn't add parameter-specific semantics beyond what the schema provides, but with only one parameter and high schema coverage, the baseline is strong. No additional value is added, but no compensation is needed.
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 a specific verb ('Check') and resource ('domain availability'), distinguishing it from siblings like domain_create, domain_list, and domain_update. It explicitly states 'Check if a domain is available for use,' which is precise and actionable.
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 usage guidance with a 'Best for' section listing specific scenarios (validating availability, pre-deployment checks, domain planning) and mentions 'Next steps: domain_create' and 'Related: domain_list,' clearly indicating 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.
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 communicates that this is a mutation tool ('Update'), specifies constraints (e.g., cannot change domain names, not for TCP proxy), and mentions prerequisites and next steps. However, it lacks details on permissions, rate limits, or error handling, which would be helpful 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 bullet-pointed sections for best uses, exclusions, and related actions. Every sentence adds value without redundancy, making it efficient and easy to scan for an AI agent.
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 of a domain update tool with 2 parameters, no annotations, and no output schema, the description does a good job covering purpose, usage guidelines, and exclusions. It mentions prerequisites and next steps, which adds helpful context. However, it could improve by detailing the response format or error cases, as there's no output schema to rely on.
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 both parameters (id and targetPort). The description adds some context by mentioning 'target ports' and 'ID of the domain', but this largely repeats what's in the schema. It doesn't provide additional semantics like format examples or constraints beyond the schema, so a baseline score of 3 is appropriate.
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 ('Update a domain's configuration') and distinguishes it from siblings like domain_create, domain_delete, and domain_list. It explicitly mentions what it updates (target ports, settings, endpoints), making the scope unambiguous.
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 (changing target ports, updating settings) and exclusions (changing domain names, TCP proxy configuration). It also lists prerequisites (domain_list), next steps (domain_list), and related tools (service_update), offering comprehensive 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It effectively communicates this is a read-only operation (implied by 'List' and 'Viewing/Auditing/Checking' use cases) and clarifies scope ('shared variables across all services' when serviceId not provided). However, it doesn't mention rate limits, authentication requirements, or pagination behavior, leaving some gaps.
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 statement, best for, prerequisites, next steps, related). Every sentence earns its place by providing distinct value: the opening statement defines the tool, bullet points offer practical guidance, and related tools provide context. No wasted words or redundancy.
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 listing tool with no output schema and no annotations, the description provides strong contextual completeness. It covers purpose, use cases, prerequisites, and related tools. The main gap is lack of information about return format (what the list actually contains), but given this is a listing operation and the schema covers inputs well, it's reasonably complete.
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 thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema (like explaining format constraints or providing examples). This meets the baseline expectation when schema coverage is complete.
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 verb ('List') and resource ('all environment variables for a service'). It distinguishes itself from sibling tools like service_info, variable_bulk_set, and variable_set by focusing exclusively on listing variables rather than creating, updating, or getting general service information.
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 dedicated sections: 'Best for' lists three specific use cases (viewing configuration, auditing, checking connection strings), 'Prerequisites' names service_list as required, 'Next steps' suggests variable_set and variable_delete, and 'Related' mentions service_info and variable_bulk_set. This gives clear context on 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this tool creates new projects (implying a write/mutation operation) and warns against using it for duplication, which adds useful behavioral context. However, it doesn't mention permissions, rate limits, or error handling, leaving some gaps for a creation 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 with bullet points and symbols (⚡️, ⚠️, →), making it easy to scan. It's front-loaded with the core purpose and efficiently uses every sentence to provide value without redundancy, such as listing best uses, exclusions, and related tools in a compact format.
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 no annotations and no output schema, the description does a good job covering the tool's purpose, usage guidelines, and behavioral aspects. It addresses complexity by guiding on when to use and what to avoid. However, it lacks details on output or error handling, which could be useful for a creation tool, keeping it from a perfect score.
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%, with both parameters (name, teamId) documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, such as formatting examples or constraints. With high schema coverage, the baseline of 3 is appropriate as the description doesn't compensate with extra details.
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 specific action ('Create a new Railway project') with the resource ('Railway project'), distinguishing it from siblings like project_delete, project_update, and project_list. It goes beyond just restating the name by specifying the domain (Railway) and the creation action.
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' (starting new applications, setting up development environments, creating project spaces) and 'Not for' (duplicating existing projects). It also lists 'Next steps' (service_create_from_repo, service_create_from_image, database_deploy) and 'Related' tools (project_delete, project_update), offering clear alternatives and context for when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It effectively discloses key behavioral traits: it's a creation/mutation tool (implied by 'Create'), suitable for build processes, and has prerequisites. However, it doesn't mention potential side effects, error conditions, or authentication requirements.
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 with clear sections (Best for, Not for, Prerequisites, Alternatives, Next steps, Related). Every sentence earns its place by providing actionable guidance without redundancy. It's front-loaded with the core purpose.
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 creation tool with no annotations and no output schema, the description provides excellent context about when to use it, alternatives, prerequisites, and related tools. The main gap is lack of information about return values or error behavior, which would be helpful given the mutation nature.
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 specific parameter semantics beyond what's in the schema (e.g., format examples for 'repo' are in schema). Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('Create a new service'), resource ('from a GitHub repository'), and scope ('[API]'), distinguishing it from sibling tools like service_create_from_image. It explicitly mentions deploying applications from source code and GitHub-hosted projects.
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 alternatives (service_create_from_image, database_deploy). It also lists prerequisites (project_list) and related tools, offering comprehensive usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 communicates that this is a destructive operation (implied by 'Delete' and 'Removing unused services'), specifies use cases that suggest permanence ('Cleaning up test services'), and distinguishes it from non-destructive alternatives. However, it doesn't mention potential side effects like data loss or irreversible consequences, which would be helpful for a deletion 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 with clear sections (purpose, best for, not for, prerequisites, alternatives, related), uses bullet points and symbols for readability, and every sentence adds value without redundancy. It's appropriately sized for a destructive operation that requires careful usage guidance.
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 destructive tool with no annotations and no output schema, the description does an excellent job covering purpose, usage guidelines, and behavioral context. It clearly indicates this is a deletion operation and when to use it versus alternatives. The main gap is the lack of information about what happens after deletion (e.g., confirmation message, error conditions, or irreversible effects), which would be valuable given the tool's nature.
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%, with both parameters (projectId and serviceId) clearly documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, such as format examples or relationship between the IDs. This meets the baseline expectation when schema coverage is complete.
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 specific action ('Delete a service from a project'), identifies the resource ('service'), and distinguishes it from sibling tools like service_restart and service_update. It goes beyond just restating the name by specifying the context (from a project).
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 alternatives (service_restart for temporary stoppage, service_update for configuration changes). It also lists prerequisites (service_list, service_info) and related tools (project_delete), offering comprehensive usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 communicates the tool's purpose (restarting a service) and practical use cases (applying config changes, clearing state, resolving issues), which implies a mutation operation with potential downtime. However, it lacks details on permissions, rate limits, or response format, leaving some behavioral aspects unspecified.
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 with bullet points and icons, making it easy to scan. It is front-loaded with the core purpose, followed by usage guidelines, prerequisites, and related tools. Every sentence earns its place without redundancy, achieving high efficiency in communication.
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 (a mutation operation with 2 parameters), no annotations, and no output schema, the description does a strong job by covering purpose, usage guidelines, prerequisites, and alternatives. It lacks details on output format or error handling, but for a restart tool, the provided context is largely sufficient for an agent to use it correctly.
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 both parameters (serviceId, environmentId) adequately. The description adds minimal value beyond the schema by mentioning that environmentId is 'usually obtained from service_info', but this is a minor enhancement. The baseline score of 3 is appropriate as the schema does the heavy lifting.
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 action ('Restart a service') and specifies the scope ('in a specific environment'), using a specific verb+resource combination. It distinguishes itself from sibling tools like service_delete (long-term stoppage) and service_update (config changes), making the purpose unambiguous.
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 alternatives (deployment_trigger, service_update, service_delete). It also includes prerequisites (service_list) and related tools (service_info, deployment_logs), offering comprehensive context for when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It does well by indicating this is a configuration update tool (implying mutation), listing related tools that suggest behavioral relationships, and mentioning prerequisites that imply dependencies. However, it doesn't explicitly state permission requirements, rate limits, or whether changes are reversible/destructive.
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 with clear sections (Best for, Not for, Prerequisites, Next steps, Related) and uses efficient bullet points and symbols. Every sentence earns its place by providing actionable guidance without redundancy. The information is front-loaded with the core purpose statement.
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 mutation tool with 10 parameters and no annotations/output schema, the description does an excellent job providing usage context, alternatives, and workflow relationships. The main gap is the lack of explicit behavioral warnings about permissions, destructiveness, or rate limits that would be important for a configuration update 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?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. However, it does provide context about environmentId being 'usually obtained from service_info' which adds practical usage insight.
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 explicitly states 'Update a service's configuration' which is a specific verb+resource combination. It clearly distinguishes this tool from siblings like service_restart, variable_set, and deployment_trigger by listing what it's not for, making its purpose unambiguous.
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 excellent usage guidance with explicit 'Best for' and 'Not for' sections, naming specific alternative tools for excluded use cases. It also lists prerequisites (service_list, service_info) and next steps (deployment_trigger), giving comprehensive context for when and how 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.
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 creation/mutation tool (implied by 'Create'), specifies use cases and exclusions, and references prerequisites and related tools. It doesn't mention permission requirements, rate limits, or error conditions, but provides substantial behavioral context for a creation 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 efficiently structured with clear sections (API label, purpose, best for, not for, prerequisites, alternatives, next steps, related). Every sentence earns its place with no redundant information, and it's appropriately sized for the tool's complexity.
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 creation tool with no annotations and no output schema, the description provides excellent context about when to use it, prerequisites, alternatives, and related tools. It doesn't describe the return value or creation confirmation details, but given the comprehensive usage guidance and clear purpose, it's nearly complete for agent selection.
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 thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for high schema coverage.
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 as 'Create a new TCP proxy for a service' with specific verb ('Create') and resource ('TCP proxy'), distinguishing it from sibling tools like domain_create for HTTP/HTTPS endpoints. It explicitly differentiates from alternatives and related tools.
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 (database access, external connections) and exclusions (HTTP/HTTPS endpoints, internal communication). It explicitly references prerequisites (service_list), alternatives (domain_create), and next steps (tcp_proxy_list).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 communicates that this is a destructive operation (implied by 'Delete' and 'Security cleanup'), specifies prerequisites and next steps, and clarifies that serviceId is optional for shared variables. However, it lacks details on error conditions, confirmation prompts, or irreversible effects, leaving some behavioral gaps.
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 earns its place by providing actionable guidance without redundancy, making it efficient and easy to parse for an AI agent.
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 (destructive operation with 4 parameters) and lack of annotations or output schema, the description does a strong job covering usage context, prerequisites, and related tools. However, it doesn't explain return values or error behaviors, which would be helpful for a deletion tool. It's largely complete but has minor gaps in output expectations.
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 parameters thoroughly. The description adds minimal value beyond the schema, only implying that environmentId is 'usually obtained from service_list' and noting serviceId's optionality for shared variables. This meets the baseline for high schema coverage but doesn't significantly enhance parameter understanding.
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 specific action ('Delete a variable for a service in a specific environment'), identifies the resource (variable), and distinguishes it from siblings like variable_list, variable_set, and variable_bulk_set by focusing on single-variable deletion. It goes beyond just restating the name to explain the operation's scope.
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 (removing unused configuration, security cleanup) and exclusions (temporary disabling, bulk removal). It also lists prerequisites (service_list), next steps (deployment_trigger, service_restart), and related tools (variable_list, variable_set), offering comprehensive 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It effectively discloses key behavioral traits: it's a mutation tool ('create or update'), implies persistence (not for temporary changes), and hints at scope (shared vs. service-specific variables via optional serviceId). However, it doesn't mention potential side effects like service restarts or rate limits, leaving some behavioral aspects uncovered.
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 appropriately sized, using bullet points and icons for clarity. Every sentence earns its place by providing actionable information (purpose, best uses, exclusions, prerequisites, alternatives, next steps, related tools) without redundancy or fluff.
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 lack of annotations/output schema, the description does an excellent job covering purpose, usage, and context. It mentions prerequisites, alternatives, and related tools, which helps the agent understand the ecosystem. The only minor gap is the lack of explicit output information, but this is mitigated by the clear action-oriented description.
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 5 parameters thoroughly. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain format constraints or provide examples). With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but doesn't detract either.
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'), and distinguishes it from sibling tools by explicitly mentioning what it's not for (bulk updates, temporary changes). The title is null, but the description fully compensates with precise action and scope.
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 ('Best for: Setting configuration values, Updating connection strings, Managing service secrets'), when not to use it ('Not for: Bulk variable updates, Temporary configuration changes'), and names alternatives ('variable_bulk_set'). It also lists prerequisites ('service_list') and related tools, making usage context very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 communicates that this is a destructive operation ('Delete'), implies permanent removal ('Storage cleanup'), and suggests caution with prerequisites and related tools. However, it lacks details on permissions, rate limits, or error handling, which would be valuable for a deletion 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 bullet-pointed guidelines and related information. Every sentence earns its place by providing actionable context 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 (destructive deletion), lack of annotations, and no output schema, the description does a good job covering purpose, usage, and prerequisites. However, it could improve by mentioning potential side effects (e.g., data loss irreversibility) or response expectations, which would enhance completeness for such a critical operation.
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%, with the parameter 'volumeId' fully documented in the schema. The description does not add any additional meaning or context about the parameter beyond what the schema provides, such as format examples or sourcing guidance. This meets the baseline score when schema coverage is high.
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 specific action ('Delete a volume from a service') with the resource ('volume') and scope ('from a service'), distinguishing it from siblings like volume_create, volume_list, and volume_update. It uses a precise verb and identifies the target resource explicitly.
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., 'Removing unused storage') and exclusions (e.g., 'Temporary data removal'). It also lists prerequisites ('volume_list') and related tools ('service_update'), offering clear when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 communicates the tool's purpose as a read-only discovery operation ('List all available database types'), implying no destructive actions. However, it lacks details on potential limitations like rate limits or authentication requirements, which would be beneficial for a tool with zero annotation coverage.
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 in the first sentence. Each subsequent section ('Best for', 'Not for', 'Alternatives', etc.) adds specific value without redundancy. The use of symbols (⚡️, ✓, ⚠️, ×, →) enhances readability without wasting space.
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 simplicity (0 parameters, no output schema, no annotations), the description is largely complete. It clearly explains the tool's purpose, usage, and context. However, without an output schema, it could benefit from briefly mentioning the expected return format (e.g., a list of database type names), though this is a minor gap for a discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description adds value by clarifying the scope ('database types that can be deployed using Railway's official templates'), which isn't captured in the schema. This compensates well, though it doesn't need to explain parameters since there are none.
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 specific action ('List all available database types') and the resource ('database types that can be deployed using Railway's official templates'). It distinguishes itself from sibling tools like 'database_deploy_from_template' by focusing on discovery rather than deployment.
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, clearly indicating when to use this tool (e.g., 'Discovering supported database types') and when not to (e.g., 'Listing existing databases'). It also names alternatives ('service_create_from_image') and related tools ('database_deploy'), offering comprehensive usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 clearly indicates this is a destructive operation ('Delete'), mentions use cases like 'Removing unused domains' and 'Cleaning up configurations', and implies permanent deletion rather than temporary disabling. However, it doesn't specify authentication requirements, rate limits, or error conditions.
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 (API context, Best for, Not for, Prerequisites, Alternatives, Related). Every sentence serves a distinct purpose with no wasted words, and critical information is front-loaded.
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 destructive tool with no annotations and no output schema, the description does well by clarifying the tool's purpose, usage context, and relationships. However, it doesn't describe what happens after deletion (e.g., confirmation message, error if domain doesn't exist) or potential side effects on related services.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents the single 'id' parameter. The description doesn't add parameter-specific information beyond what the schema provides, but with only one parameter and complete schema coverage, the baseline is appropriately high.
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 specific action ('Delete a domain from a service'), identifies the resource ('domain'), and distinguishes it from sibling tools like domain_update and domain_list. It uses precise language that leaves no ambiguity about the tool's function.
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, names specific alternatives (domain_update), mentions prerequisites (domain_list), and relates to other tools (service_update). This comprehensive guidance helps the agent understand when to use this tool versus other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 communicates the destructive nature ('Delete... and all its resources'), which is critical for a mutation tool. However, it doesn't mention potential side effects like irreversible deletion, confirmation requirements, or error handling, leaving some behavioral gaps.
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 (API note, purpose, guidelines, prerequisites, alternatives) using symbols and bullet points. Every sentence adds value without redundancy, and information is front-loaded with the core action first.
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 destructive deletion tool with no annotations and no output schema, the description does well by covering purpose, usage boundaries, and related tools. However, it lacks details on what 'all its resources' entails concretely (e.g., services, databases, volumes) and doesn't describe the return value or error cases, which are important for such a high-stakes operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter (projectId) well-documented in the schema. The description doesn't add parameter-specific details beyond what the schema provides, but with high schema coverage and only one parameter, the baseline is strong. It implies the parameter identifies the target project but doesn't elaborate further.
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 specific action ('Delete a Railway project and all its resources') and distinguishes it from sibling tools like service_delete. It explicitly mentions the scope ('all its resources'), making the purpose unambiguous 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 with 'Best for' (removing unused projects, cleaning up test projects) and 'Not for' (temporary deactivation, service-level cleanup), plus named alternatives (service_delete) and prerequisites (project_list, project_info). This gives comprehensive when-to-use and when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 purpose as a read-only listing operation ('List all projects'), implying safe, non-destructive behavior. However, it lacks details on rate limits, pagination, or authentication needs, which would be beneficial for a tool with no annotations.
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 bullet points for best use cases and clear next steps/related tools. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 low complexity (0 parameters, no annotations, no output schema), the description is largely complete for its purpose. It covers what the tool does, when to use it, and related actions. A minor gap is the lack of output format details, but this is acceptable for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, maintaining focus on the tool's purpose and usage. This aligns with the baseline expectation for tools with no parameters.
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 specific action ('List all projects') and resource ('in your Railway account'), distinguishing it from siblings like project_create, project_delete, project_info, and service_list. It explicitly mentions what the tool does without being vague or tautological.
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 ('Best for: Getting an overview of all projects, Finding project IDs, Project discovery and management') and suggests next steps (project_info, service_list) and related tools (project_create, project_delete), clearly differentiating it from alternatives in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![railway-mcp MCP server](https://glama.ai/mcp/servers/antonioevans/railway-mcp/badges/card.svg)](https://glama.ai/mcp/servers/antonioevans/railway-mcp)

Score Badge

Copy to your README.md:

[![railway-mcp MCP server](https://glama.ai/mcp/servers/antonioevans/railway-mcp/badges/score.svg)](https://glama.ai/mcp/servers/antonioevans/railway-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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

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