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.2.1
Disambiguation4/5
The tools are generally well-differentiated with clear boundaries, as each targets specific resources and actions (e.g., deployment_trigger vs. service_restart). However, some overlap exists, such as variable_set and variable_bulk_set, where the distinction between single and bulk updates might cause minor confusion, but descriptions help clarify.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as project_list, service_create_from_repo, and variable_delete. There are no deviations in naming conventions, making the set predictable and easy to navigate.
Tool Count2/5
With 36 tools, the count is excessive for the Railway domain, leading to a heavy and potentially overwhelming interface. While the domain is broad, many tools could be consolidated or streamlined, as some serve similar purposes (e.g., multiple variable management tools).
Completeness5/5
The tool surface provides comprehensive coverage for Railway's domain, including project, service, deployment, domain, variable, volume, and TCP proxy management. It supports full CRUD operations and workflows, with no obvious gaps, ensuring agents can handle most tasks without dead ends.
Average 4.2/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 is passing
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, if changes are reversible, what happens to unspecified properties, or any rate limits. It lacks critical context for safe and effective use in an automated environment.
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 with zero wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly. Every word earns its place by directly conveying the tool's purpose.
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 insufficient. It doesn't address behavioral risks, response format, error conditions, or dependencies. For a tool that modifies resources, more context is needed to ensure reliable agent operation, especially with sibling tools like volume_delete that could interact.
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 clear documentation for both parameters (volumeId and name). The description adds minimal value beyond the schema, as 'Update a volume's properties' only vaguely hints at the parameters without providing additional syntax, constraints, or 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('a volume's properties'), making the purpose immediately understandable. It distinguishes from sibling tools like volume_create, volume_delete, and volume_list by focusing on modification rather than creation, deletion, or listing. However, it doesn't specify which properties can be updated beyond what's implied by the input 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. It doesn't mention prerequisites (e.g., needing an existing volume), exclusions (e.g., what can't be updated), or comparisons to siblings like volume_create for initial setup or service_update for related operations. Usage is implied only through the tool name and context.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a list operation (implied read-only), but doesn't mention pagination, sorting, filtering capabilities, error conditions, authentication requirements, rate limits, or what format the environments are returned in. 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 states exactly what the tool does without any wasted words. It's appropriately sized for a simple list operation and gets straight to the point with no unnecessary elaboration.
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?
For a simple list tool with one well-documented parameter but no annotations or output schema, the description is minimally adequate. It tells what the tool does but lacks behavioral context about how it works, what it returns, or when to use it. The combination of purpose clarity and parameter documentation meets basic requirements but leaves gaps in usage and behavior.
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 information beyond what the schema provides (it doesn't explain what constitutes a valid project ID or where to find it). With complete schema coverage, the baseline score of 3 is appropriate.
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 'List all environments in a project' clearly states the action (list) and resource (environments in a project). It distinguishes from siblings like project_list (lists projects) and deployment_list (lists deployments), but doesn't explicitly differentiate from domain_list or volume_list which list different resources. The purpose is specific but could be more distinctive.
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, timing considerations, or compare with sibling tools like deployment_list or service_list that might list related resources. The agent must infer usage from the tool name and context alone.
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 describes the tool's purpose and usage context but doesn't mention important behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, or what format the service list returns. The 'Best for' section provides some behavioral context about what the output can be used for.
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/section earns its place by providing useful information without redundancy or fluff.
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?
For a simple list tool with 1 parameter and 100% schema coverage, the description provides adequate context about purpose and usage. However, with no annotations and no output schema, it should ideally mention more about the return format or behavioral constraints. The 'Best for' section helps but doesn't fully compensate for the lack of 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% for the single parameter 'projectId', so the schema already documents it adequately. The description doesn't add any additional parameter semantics beyond what's in the schema. With high schema coverage, baseline 3 is appropriate as the description doesn't need to compensate.
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: 'List all services in a specific Railway project' - a specific verb (list) and resource (services) with scope (Railway project). However, it doesn't explicitly differentiate from siblings like 'service_info' or 'deployment_list' beyond mentioning them as 'next steps'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context with 'Best for' scenarios and prerequisite/next step relationships. It mentions 'project_list' as a prerequisite and 'service_info, deployment_list' as next steps, giving good guidance. However, it doesn't explicitly state when NOT to use this tool or provide alternatives for similar functionality.
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 the tool lists domains, implying a read-only operation, but doesn't disclose behavioral traits like whether it's paginated, rate-limited, or what format the output takes. The 'Best for' section adds some context about use cases but lacks operational 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 (API tag, Best for, Prerequisites, Next steps, Related) and uses bullet points for readability. It's appropriately sized for the tool's complexity, though the 'Best for' section could be more concise. Every sentence adds value without 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?
Given the tool's moderate complexity (3 required parameters, no output schema, no annotations), the description provides good contextual coverage with usage guidelines, prerequisites, and related tools. It lacks details on output format or behavioral constraints, but for a list operation with full schema coverage, 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 fully documents the three required parameters (projectId, environmentId, serviceId). The description doesn't add any parameter-specific information beyond what's in the schema, such as explaining relationships between parameters or providing examples. Baseline 3 is appropriate 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists domains for a service, specifying both service and custom domains. It uses the verb 'list' with the resource 'domains', making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like domain_check or tcp_proxy_list beyond the 'Best for' section.
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' use cases (viewing endpoints, managing configurations, auditing), prerequisites (service_list), next steps (domain_create, domain_update), and related tools (service_info, tcp_proxy_list). 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.
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 this. It mentions the tool is for viewing/checking/reviewing, which suggests read-only behavior, but doesn't address authentication needs, rate limits, or error conditions. The description adds some behavioral context but doesn't fully compensate for the lack of 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 appropriately sized. It uses clear section headers (Best for, Prerequisites, Next steps, Related) and bullet points for readability. Every sentence earns its place by providing specific guidance without redundancy. The information is front-loaded with the core purpose first, followed by 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?
Given the tool's moderate complexity (single parameter, read operation) and lack of both annotations and output schema, the description does a good job of providing context. It explains the purpose, when to use it, prerequisites, next steps, and related tools. However, it doesn't describe the return format or what specific information is included in 'detailed information,' 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the single parameter projectId has a clear description in the schema). The tool description doesn't add any parameter-specific information beyond what's already in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter info in the description, which applies here.
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: 'Get detailed information about a specific Railway project' with specific verb ('Get') and resource ('Railway project'). It distinguishes from siblings like project_list (which lists projects) and project_update/project_delete (which modify projects). However, it doesn't explicitly differentiate from service_info (which gets service details) or project_environments (which focuses on environments).
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' lists specific use cases (viewing details, checking environments, configuration review), 'Prerequisites' specifies project_list as a required prior step, 'Next steps' suggests follow-up tools (service_list, variable_list), and 'Related' identifies alternative/modification tools (project_update, project_delete). 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a listing/read operation ('List all volumes') but doesn't specify whether it returns all volumes at once or uses pagination, what format the output takes, or any rate limits. The description adds some context about storage configurations but leaves important 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 and front-loaded with the core purpose, followed by organized sections (Best for, Prerequisites, Next steps, Related). Every element serves a clear purpose with no wasted words, making it highly efficient and scannable.
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 read operation with no output schema, the description provides strong contextual completeness. It covers purpose, usage scenarios, prerequisites, and related tools. The main gap is the lack of output format information, which would be helpful since there's no output schema, but the description otherwise gives good context for agent decision-making.
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 has 100% description coverage (projectId parameter is fully documented), so the baseline is 3. The description doesn't add any parameter-specific information beyond what's in the schema, but it doesn't need to since the schema already provides complete 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 action ('List all volumes') and resource ('in a project'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other volume-related siblings like volume_create or volume_delete, which would require more specific scope definition.
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' scenarios (viewing configurations, managing volumes, auditing usage), clear prerequisites (project_list), next steps (volume_create), and related tools (service_info, database_deploy). This gives comprehensive context about when and why 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.
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. It explains this is for authentication configuration and mentions it's only needed if not set in environment variables, which adds useful context. However, it doesn't disclose important behavioral aspects like whether this persists the token, what format it expects, or potential 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 well-structured with clear sections (utility tag, main description, best for/not for lists, next steps, related tools). Every sentence earns its place, and the information is front-loaded with the core purpose stated 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 single-parameter authentication configuration tool with no output schema, the description provides good contextual information about when to use it and what it's not for. However, without annotations and with no output schema, it could benefit from more details about what happens after configuration (e.g., token validation, persistence mechanism).
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 the single 'token' parameter with its description. The description doesn't add any additional parameter semantics 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 specific action ('Configure the Railway API token for authentication') and resource ('Railway API token'), distinguishing it from sibling tools like project configuration or service settings. It explicitly mentions this is for authentication setup only, not for other configuration 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 with 'Best for' and 'Not for' sections, clearly indicating when to use this tool (initial setup, token updates, authentication configuration) and when not to use it (project configuration, service settings, environment variables). It also suggests next steps and related tools.
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. It states this is a list operation (implied read-only) and mentions it returns 'recent' deployments with a default limit of 10, which adds useful behavioral context. However, it doesn't disclose pagination behavior, error conditions, or authentication requirements, leaving some 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 with clear sections (API tag, purpose, best for, prerequisites, next steps, related tools) and uses bullet points/arrows for readability. Every sentence earns its place by providing distinct guidance without 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 list tool with no annotations and no output schema, the description provides good contextual guidance (prerequisites, next steps, related tools) and clear purpose. However, it doesn't describe the return format or structure, which would be helpful given the lack of output schema. The completeness is strong but not perfect.
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 4 parameters thoroughly. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain format of IDs or how 'recent' relates to the limit parameter). 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 ('List recent deployments'), resource ('for a service in a specific environment'), and scope ('recent'). It distinguishes from sibling tools like deployment_logs (which gets logs for a specific deployment) and deployment_trigger (which initiates new deployments), 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' sections (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 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.
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's purpose and usage context well but lacks details on behavioral traits like rate limits, authentication needs, error handling, or what specific status information is returned. The description doesn't contradict any 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 with bullet points and symbols, front-loading the core purpose. Every section (Best for, Not for, Prerequisites, etc.) adds value 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 moderate complexity (single parameter, no output schema, no annotations), the description is quite complete for usage guidance and purpose. However, it lacks details on return values or behavioral constraints, 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.
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 'deploymentId' clearly documented in the schema. The description doesn't add any parameter-specific information beyond what the schema provides, 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 specific action ('Check the current status') and resource ('a deployment'), distinguishing it from sibling tools like deployment_list (lists deployments) or deployment_logs (gets logs). It's not a tautology and provides precise functionality.
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 explicitly includes 'Best for' and 'Not for' sections, providing clear when-to-use and when-not-to-use guidance. It also lists prerequisites (deployment_list, deployment_trigger) and next steps (deployment_logs), 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions deployment actions but doesn't specify whether this requires specific permissions, what happens to running services during deployment, whether rollbacks are automatic, or any rate limits. The description adds some context about use cases but lacks operational details needed 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 with clear sections (Best for, Not for, Prerequisites, Alternatives, Next steps, Related) and uses efficient bullet points. Every sentence earns its place, and the information is front-loaded with the core purpose first. The formatting with symbols enhances readability without adding 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?
For a deployment triggering tool with no annotations and no output schema, the description provides good contextual coverage. It explains when to use the tool, distinguishes it from alternatives, and provides workflow guidance. However, it lacks details about what the tool returns or any error conditions, which would be helpful given the mutation nature of the 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?
Schema description coverage is 100%, so the schema already documents all four parameters. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. It mentions 'deploying code changes' and 'specific commit SHA' which aligns with the commitSha parameter but doesn't provide additional semantic context.
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'), distinguishing it from siblings like service_restart and service_update. It provides a concise API-focused statement that immediately communicates the core 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, naming specific alternatives (service_restart, service_update). It includes prerequisites (service_list), alternatives, next steps, and related tools, offering comprehensive usage context that helps the agent choose correctly among deployment and service management tools.
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 the tool checks domain availability, which implies a read-only operation without side effects, but it doesn't disclose behavioral traits like rate limits, authentication needs, error conditions, or what 'available for use' entails (e.g., registration status). The description adds basic context but lacks detailed behavioral information.
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 concise, with a clear purpose statement upfront, followed by bullet-point usage guidelines and related tool references. Every sentence earns its place by providing actionable information without redundancy, making it easy to scan and understand.
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 (one parameter, no output schema, no annotations), the description is reasonably complete. It covers purpose, usage guidelines, and related tools, but lacks details on behavioral aspects like response format or error handling. For a simple read operation, this is mostly adequate, though some gaps remain in 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?
The schema description coverage is 100%, with the single parameter 'domain' fully documented in the schema. The description doesn't add any parameter-specific semantics beyond what the schema provides (e.g., no format examples like 'example.com' or validation rules). Since schema coverage is high, the 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: 'Check if a domain is available for use.' It uses a specific verb ('Check') and resource ('domain'), and distinguishes it from sibling tools like domain_create, domain_list, domain_update, and domain_delete by focusing on availability validation rather than creation, listing, modification, or deletion.
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 guidelines with a 'Best for' section listing specific scenarios (validating domain availability, pre-deployment checks, domain planning) and includes 'Next steps: domain_create' and 'Related: domain_list' to guide when to use alternatives. This clearly indicates when this tool is appropriate versus other domain-related tools.
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 destructive behavior ('Delete') but doesn't disclose critical details like whether deletion is permanent, requires specific permissions, has rate limits, or what happens to associated resources. The description adds some context (e.g., not for temporary disabling) but lacks comprehensive 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 well-structured and front-loaded with the core purpose, followed by bullet-pointed guidelines 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 (destructive operation with 1 parameter), no annotations, and no output schema, the description is mostly complete. It covers purpose, usage, and alternatives well, but lacks details on behavioral aspects like permanence or side effects, which are important for a delete 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?
Schema description coverage is 100% (the 'id' parameter is fully documented in the schema as 'ID of the domain to delete'), so the baseline is 3. The description doesn't add any parameter-specific information beyond what the schema provides, such as format examples or validation rules.
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') with the resource ('domain'), distinguishing it from siblings like domain_update (for updates) and domain_list (for listing). It avoids tautology by specifying the operation and target.
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 domains, cleaning up configurations, domain management) and 'Not for' (temporary domain disabling, port updates), plus named alternatives (domain_update) and prerequisites (domain_list). This clearly defines 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 this is a read-only operation by listing 'Best for' scenarios like viewing and auditing, but doesn't explicitly state whether it's safe, requires authentication, or has rate limits. The description adds some context about listing shared variables when serviceId is omitted, but lacks details on output format or pagination.
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 adds value 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 moderate complexity (listing variables), no annotations, and no output schema, the description does a good job covering usage context, prerequisites, and related tools. However, it lacks details on behavioral aspects like authentication needs or output format, which would be helpful for a tool with no structured output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description doesn't add any parameter-specific details beyond what's in the schema, such as clarifying the relationship between environmentId and serviceId. Baseline 3 is appropriate when the schema provides complete parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all environment variables for a service'), making the purpose specific and unambiguous. It distinguishes this tool from sibling tools like variable_set or variable_delete by focusing on listing rather than modifying variables.
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, auditing, checking connection strings), prerequisites (service_list), next steps (variable_set, variable_delete), and related tools (service_info, variable_bulk_set). This comprehensively covers 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a write operation ('Create a new Railway project') but doesn't specify permissions, rate limits, or response format. The 'Next steps' and 'Related' sections add useful context about workflow, but key behavioral traits like authentication needs or potential side effects are missing.
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. Every sentence earns its place: the first states the action, the next sections provide usage context, and the last links to related tools. 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 creation tool with no annotations and no output schema, the description does well by covering purpose, usage guidelines, and workflow context. However, it lacks details on behavioral aspects like permissions or response format, which would be helpful given the mutation nature. The high schema coverage compensates partially, but some gaps remain.
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 fully documents the two parameters (name and teamId). The description doesn't add any parameter-specific information beyond what's in the schema, such as naming constraints or teamId usage details. Baseline 3 is appropriate when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Create') and resource ('new Railway project'), distinguishing it from siblings like project_delete, project_update, and project_list. It goes beyond the name/title by specifying it's for creating new projects, not duplicating existing ones.
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, listing specific use cases (starting new applications, setting up dev environments, creating project spaces) and exclusions (duplicating existing projects). It also suggests next steps and related tools, 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.
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 states this is an API tool for listing projects, implying a read-only operation, but doesn't disclose behavioral details like authentication requirements, rate limits, pagination, or response format. The description adds basic context but lacks 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (API context, Best for, Next steps, Related) and uses bullet points for readability. It's appropriately sized for a simple tool, though the emoji and formatting slightly reduce conciseness. Every sentence adds value without waste.
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 simplicity (0 parameters, no output schema, no annotations), the description covers purpose and usage well but lacks behavioral context like response format or error handling. It's adequate for a basic list tool but could be more complete by addressing what the output contains or how to interpret results.
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 doesn't discuss parameters, focusing instead on usage and context. A baseline of 4 is applied since no parameters exist, and the description adds value without redundancy.
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_info (detailed info), project_create (creation), and project_delete (deletion). The title 'project_list' aligns perfectly with the described functionality.
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 use cases (overview, finding IDs, discovery/management) and 'Next steps' suggesting follow-up tools (project_info, service_list). It also mentions 'Related' tools (project_create, project_delete) to clarify 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 creation/mutation operation but doesn't disclose behavioral traits like required permissions, error handling, or rate limits. The description adds some context (e.g., prerequisites) but lacks details on what happens upon creation or potential side effects.
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 sections, making it easy to scan. Every sentence adds value (e.g., use cases, exclusions, prerequisites), and it's front-loaded with the core purpose. No wasted words.
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 usage guidelines and prerequisites. However, it lacks details on return values or error conditions, which would be helpful for a mutation tool. It's mostly complete but has minor gaps in behavioral context.
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 (projectId, image, name). The description doesn't add meaning beyond the schema, such as explaining parameter interactions or constraints. 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') and resource ('from a Docker image'), distinguishing it from sibling tools like 'service_create_from_repo' and 'database_deploy'. It explicitly mentions Docker image usage, 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' and 'Not for' sections, naming specific alternatives like 'database_deploy' and 'service_create_from_repo'. It includes prerequisites ('project_list') and related next steps, 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions prerequisites and related tools, adding useful context about workflow dependencies. However, it doesn't describe mutation behavior (e.g., whether creation is reversible, permissions needed, or rate limits), which is a gap for a write operation 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, next steps, related). Every sentence adds value, and information is front-loaded with the core purpose stated first. 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 creation tool with no annotations and no output schema, the description does well by covering usage context, alternatives, and workflow dependencies. However, it lacks details on mutation behavior (e.g., what happens on failure, response format) which would be helpful given the absence of structured safety hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description doesn't add any parameter-specific details beyond what the schema provides (e.g., format examples for 'repo' are in the 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]'). It explicitly distinguishes from sibling tools like service_create_from_image and database_deploy, 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' 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 beyond basic functionality.
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 effectively describes the tool's purpose and use cases but lacks details on potential side effects, authentication requirements, rate limits, or error conditions. The description doesn't contradict any annotations (none exist), but for a read operation with no annotation coverage, it provides only basic behavioral context.
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 efficiently organized with clear sections (purpose, best for, prerequisites, next steps, related tools). Every sentence adds value without redundancy, and the information is front-loaded with the core purpose stated first. The use of bullet points and symbols enhances readability without adding 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?
For a read-only tool with 3 parameters and 100% schema coverage but no output schema, the description provides strong contextual completeness. It clearly explains the tool's purpose, use cases, and workflow relationships. The main gap is the lack of output information (since no output schema exists), but the description compensates well with comprehensive usage guidance and sibling tool references.
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 all three parameters (projectId, serviceId, environmentId) 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 details between parameters. 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 a specific verb ('Get detailed information') and resource ('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 configuration, status, and health data 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 on when to use this tool ('Best for: Viewing service configuration and status, Checking deployment details, Monitoring service health'), prerequisites ('Prerequisites: service_list'), next steps ('Next steps: deployment_list, variable_list'), and related alternatives ('Related: service_update, deployment_trigger'). This comprehensive guidance helps the agent understand the tool's context and workflow integration.
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 is for 'Viewing TCP proxy configurations' and 'Auditing service endpoints,' which implies it's a read-only operation, but it doesn't explicitly state behavioral traits like whether it requires authentication, has rate limits, or what the output format looks like. The description adds some context but lacks detailed 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, starting with the core purpose in the first sentence, followed by bullet-point sections for usage guidelines. Every sentence earns its place by providing clear value, such as listing use cases and related tools, without unnecessary verbosity or repetition.
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 read operation with 2 parameters), no annotations, and no output schema, the description is mostly complete. It covers purpose, usage guidelines, and relationships well, but it lacks details on behavioral aspects like output format or error handling. This is a minor gap, so it scores slightly above the minimum viable level.
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 (environmentId and serviceId) fully documented in the input schema. The description doesn't add any parameter-specific details beyond what's in the schema, such as explaining how to obtain these IDs or their formats. With high schema coverage, 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 verb ('List') and resource ('all TCP proxies for a service in a specific environment'), making the purpose specific and unambiguous. It distinguishes this tool from its siblings like tcp_proxy_create and tcp_proxy_delete by focusing on listing rather than creating or deleting proxies.
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 sections like 'Best for' (listing use cases), 'Prerequisites' (service_list), 'Next steps' (tcp_proxy_create), and 'Related' (domain_list, service_info). This clearly indicates when to use this tool and how it relates to alternatives, such as directing users to tcp_proxy_create for creation tasks.
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 for standard configurations with security defaults, implying it's a write operation. However, it doesn't explicitly mention permission requirements, rate limits, or what happens on failure, 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 clear sections (workflow context, best for, not for, prerequisites, alternatives, next steps, related tools) and uses bullet points and symbols efficiently. Every sentence earns its place by providing actionable guidance without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deployment tool with 5 parameters, 100% schema coverage, but no annotations or output schema, the description provides strong contextual completeness. It covers purpose, usage guidelines, prerequisites, alternatives, and next steps. The only gap is the lack of explicit behavioral details like error handling or response format, which would be more critical if the schema coverage were lower.
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 significant meaning beyond what's in the schema, though it contextualizes the tool as using 'pre-configured templates' which aligns with the enum options. The baseline of 3 is appropriate 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 specific action ('Deploy a pre-configured database') and resource ('using Railway's official templates and best practices'), distinguishing it from sibling tools like service_create_from_image. It explicitly mentions the workflow context and standard database types, providing a precise purpose statement.
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 a prerequisite (database_list_types), and specifies an alternative (service_create_from_image). It also suggests next steps and related tools, offering comprehensive usage context that helps differentiate 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 of behavioral disclosure. It effectively describes the tool's purpose and constraints (e.g., not for service runtime logs), and implies it's a read operation ('Get logs'), which is appropriate. However, it doesn't mention potential behavioral aspects like rate limits, authentication needs, 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 well-structured and front-loaded with the core purpose, followed by bullet-point sections for best uses, exclusions, 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 moderate complexity (2 parameters, no output schema, no annotations), the description is quite complete. It covers purpose, usage guidelines, and related tools effectively. However, without annotations or an output schema, it could benefit from more details on return values or error handling, but it's largely sufficient 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 both parameters (deploymentId, limit) adequately. The description doesn't add any parameter-specific information beyond what's in the schema, such as format details or usage examples. This meets the baseline of 3 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 tool's purpose with a specific verb ('Get logs') and resource ('for a specific deployment'). It distinguishes from siblings by explicitly stating what it's not for (service runtime logs, database logs), which helps differentiate from tools like service_info or database-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 (debugging, monitoring, checking build output) and exclusions. It also lists prerequisites (deployment_list), next steps (deployment_status), and related tools (service_info, deployment_trigger), giving 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 full burden. It adds context about prerequisites, next steps, and related tools, which helps understand workflow dependencies. However, it doesn't explicitly mention permissions, rate limits, or mutation effects beyond the creation action, leaving some behavioral aspects implicit.
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. Every sentence earns its place by providing clear guidance without redundancy. It's appropriately sized and 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?
Given no annotations and no output schema, the description compensates well with usage guidelines and workflow context. However, it doesn't describe the return value or error cases, which could be important for a creation tool. The completeness is strong but not exhaustive.
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, such as explaining interactions between parameters or providing examples. 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 creates a new domain for a service, specifying the verb 'Create' and resource 'domain for a service'. It distinguishes from siblings like tcp_proxy_create and domain_update, making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with 'Best for' and 'Not for' sections, naming alternatives (tcp_proxy_create) and prerequisites (service_list, domain_check). It also mentions next steps (domain_update) 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 this is a mutation tool ('Update'), specifies constraints (not for changing domain names or TCP proxy configuration), and mentions prerequisites. However, it doesn't address potential side effects, error conditions, or what happens to unspecified settings during updates.
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 (API label, best for, not for, prerequisites, next steps, related). Every sentence earns its place by providing specific guidance without redundancy. The information is front-loaded with the core purpose immediately stated.
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 well by specifying purpose, usage boundaries, prerequisites, and related tools. However, it lacks information about return values, error handling, or what constitutes a successful update. Given the complexity of domain configuration updates, some behavioral details are missing.
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 (id and targetPort). The description adds context about what these parameters enable ('Changing target ports', 'Updating domain settings'), but doesn't provide additional syntax, format details, or constraints beyond what the schema specifies. 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 verbs ('Update a domain's configuration') and distinguishes it from siblings by listing what it's best for (changing target ports, updating settings, reconfiguring endpoints). It explicitly differentiates from domain_create, domain_delete, and tcp_proxy_create 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 alternatives (delete and recreate for domain name changes). It also includes prerequisites (domain_list) and related tools (service_update), giving 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.
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 states that deletion affects 'all its resources', implying destructive behavior, and mentions prerequisites (project_list, project_info) for proper use. However, it lacks details on permissions, rate limits, or confirmation steps, which would be helpful for a destructive operation.
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 is front-loaded with the core purpose, followed by usage guidelines, prerequisites, and alternatives, with no wasted sentences. Every section adds value without 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?
Given the tool's complexity (destructive deletion) and lack of annotations or output schema, the description does a good job covering purpose, usage, and alternatives. However, it could improve by including more behavioral details like irreversible effects or error handling, 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.
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 'projectId' documented in the schema. The description does not add any parameter-specific information beyond what the schema provides, such as format examples or sourcing details. Baseline 3 is appropriate since the schema handles parameter documentation adequately.
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 the verb 'Delete' and resource 'Railway project and all its resources', making the purpose specific and clear. It distinguishes from siblings like service_delete by emphasizing project-level deletion versus service-level cleanup.
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 (removing unused projects) versus alternatives (service_delete for service-level cleanup). It also lists prerequisites 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 this is a destructive operation ('Delete'), provides context about when it's appropriate (removing unused services, cleaning up test services), and warns against misuse (not for temporary stoppage). However, it doesn't mention potential side effects like data loss or irreversible consequences, 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 with clear sections (API tag, best for, not for, prerequisites, alternatives, related). Every sentence earns its place by providing distinct value - no redundancy or wasted words. The information is front-loaded with the core purpose stated 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 operation with no annotations and no output schema, the description does an excellent job providing context about usage scenarios, alternatives, and prerequisites. The main gap is the lack of information about what happens after deletion (confirmation, error handling, or return values), which would be helpful given there's no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (projectId and serviceId). The description doesn't add any parameter-specific information beyond what's in the schema. 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 siblings like service_restart and service_update. The opening line provides a precise verb+resource combination 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 dedicated 'Best for' and 'Not for' sections, naming specific alternatives (service_restart, service_update). It also lists prerequisites (service_list, service_info) and related tools (project_delete), giving 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 the full burden of behavioral disclosure. It effectively communicates that this is a mutation operation (restart implies state change) and provides context about what the restart accomplishes ('Applying configuration changes', 'Clearing service state', 'Resolving runtime issues'). However, it doesn't mention potential side effects like downtime, permissions needed, or rate limits, which would be valuable 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 perfectly structured and front-loaded with the core purpose, followed by organized sections using symbols and clear formatting. Every sentence earns its place by providing distinct value: purpose statement, usage guidelines, exclusions, prerequisites, and related tools. 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 mutation tool with no annotations and no output schema, the description does an excellent job covering usage context, alternatives, and prerequisites. However, it doesn't describe what happens after restart (success indicators, error conditions, or return values), which would be valuable given the lack of output schema. The comprehensive sibling tool differentiation partially compensates for this gap.
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 thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline score of 3 reflects adequate coverage when the schema does the heavy lifting, though the description could have provided additional context about parameter relationships or typical values.
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 ('Restart a service') and resource ('in a specific environment'), distinguishing it from sibling tools like service_update, service_delete, and deployment_trigger. The opening line provides a precise verb+resource combination 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 dedicated sections: 'Best for' lists three appropriate use cases, 'Not for' names three alternatives with specific tool names, and additional sections mention prerequisites (service_list) and alternatives (deployment_trigger). This comprehensive guidance clearly defines 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It effectively communicates that this is a mutation tool ('Update'), specifies prerequisites and related tools, and implies configuration changes. However, it doesn't explicitly mention potential side effects (e.g., service downtime, irreversible changes) or permission requirements, which would be helpful for a tool with 10 parameters and no output schema.
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 and exclusions, and clear sections for prerequisites, next steps, and related tools. Every sentence earns its place by adding 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 complexity (10 parameters, no output schema, no annotations), the description does a strong job by clarifying purpose, usage boundaries, prerequisites, and related tools. However, it lacks details on behavioral aspects like error handling, response format, or confirmation prompts, which would enhance completeness for a mutation tool with many optional parameters.
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 all parameters are documented in the input schema. The description doesn't add specific parameter details beyond what's in the schema, but it contextually explains that the tool updates 'service settings', 'resource limits', and 'deployment configuration', which aligns with parameters like numReplicas, buildCommand, and region. This provides high-level semantic context without redundant 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 tool's purpose with the specific verb 'Update' and resource 'service's configuration'. It distinguishes from siblings by explicitly listing what it's not for (updating environment variables, restarting services, triggering deployments), making the scope precise and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Best for: Changing service settings, Updating resource limits, Modifying deployment configuration') and when not to use it ('Not for: Updating environment variables, Restarting services, Triggering new deployments'), with clear alternative tools named (variable_set, service_restart, deployment_trigger). It also lists prerequisites (service_list, service_info) and next steps (deployment_trigger), 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. It effectively discloses behavioral context: it's a creation/mutation tool (implied by 'Create'), specifies use cases (database access, external connections), and outlines prerequisites and related operations. However, it doesn't mention potential side effects, permissions, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points and icons, front-loading the core purpose. Every sentence adds value (use cases, exclusions, prerequisites, alternatives), with 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 creation tool with no annotations and no output schema, the description provides strong contextual completeness: clear purpose, usage guidelines, prerequisites, and related tools. It lacks details on return values or error responses, but covers most essential context given the 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%, so the schema already documents all three parameters. The description adds no additional parameter semantics beyond what's in the schema, but the baseline is 3 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 ('Create a new TCP proxy') and resource ('for a service'), distinguishing it from sibling tools like domain_create (for HTTP/HTTPS) and tcp_proxy_list (for listing). The purpose is 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' and 'Not for' sections, naming alternatives (domain_create) and prerequisites (service_list). It clearly defines when to use this tool versus other options, including related tools for next steps.
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 destructive operation ('Delete') but doesn't explicitly state whether deletion is permanent, reversible, or requires specific permissions. The 'Security management' hint adds some context, but more behavioral details (like confirmation prompts or side effects) would be helpful.
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, icons, and clear sections (Best for, Not for, Prerequisites, Related). Every sentence earns its place by providing actionable guidance without unnecessary elaboration.
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 no annotations or output schema), the description does well by covering purpose, usage guidelines, and prerequisites. However, it lacks details on behavioral outcomes (e.g., what happens post-deletion, error conditions), which would make it more complete for a mutation 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?
With 100% schema description coverage (the single parameter 'proxyId' is well-documented in the schema), the baseline is 3. The description doesn't add parameter-specific details beyond the schema, but since there's only one parameter and the schema covers it fully, a score of 4 reflects adequate clarity without redundancy.
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 and tcp_proxy_list. It goes beyond just restating the name by specifying it's an API operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use ('Best for: Removing unused proxies, Security management, Endpoint cleanup') and when not to use ('Not for: Temporary proxy disabling, Port updates'), plus mentions prerequisites ('tcp_proxy_list') and a related alternative ('service_update').
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 function (create/update multiple variables) and context (environment variables, bulk operations), but lacks details on permissions, error handling, or rate limits. However, it adds value by specifying prerequisites and related tools, compensating 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.
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, prerequisites, and related tools. Each sentence earns its place by providing actionable information without redundancy, making it highly 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 complexity of a bulk mutation tool with no annotations or output schema, the description does a good job by covering purpose, usage guidelines, and context. However, it lacks details on behavioral aspects like side effects or response format, which would be beneficial for a tool with no output schema. It's mostly complete but has minor gaps in 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?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description does not add specific parameter semantics beyond what the schema provides, such as explaining variable naming conventions or value formats. It meets the baseline by not contradicting the schema but offers no extra insights.
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 or update multiple environment variables at once,' specifying both the verb (create/update) and resource (environment variables) with the scope (multiple/bulk). It distinguishes itself from sibling 'variable_set' by emphasizing bulk operations versus single updates.
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 (migrating configuration, initial setup, bulk updates) and exclusions (single variable updates, temporary changes). It also lists prerequisites (service_list), alternatives (variable_set), and next steps (deployment_trigger, service_restart), 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 describes the tool's function as a bulk copy operation for environment migration, implies it's a write operation (copying variables), and mentions related actions like deployment_trigger and service_restart as next steps. However, it doesn't detail potential side effects (e.g., impact on services during overwrite) or error conditions, 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-pointed sections for best uses, exclusions, prerequisites, and related tools. Every sentence earns its place by providing actionable guidance 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 (environment-to-environment variable copying with 5 parameters) and the absence of annotations and output schema, the description does a strong job by covering purpose, usage guidelines, and workflow context. It could improve by detailing output format or error handling, but it compensates well with practical guidance on when and how to use the tool in relation to siblings.
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 five parameters thoroughly. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the interaction between serviceId and shared variables or the implications of the overwrite flag. 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: 'Copy variables from one environment to another.' It specifies the verb ('copy'), resource ('variables'), and scope ('from one environment to another'), and distinguishes it from sibling tools like variable_set and variable_bulk_set by emphasizing bulk copying across environments rather than single updates.
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 (environment migration, configuration sharing, duplication) and exclusions (single variable updates, temporary changes). It also lists prerequisites (service_list), alternatives (variable_set), next steps (deployment_trigger, service_restart), and related tools (variable_list, service_update), 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. It clearly indicates this is a destructive operation ('Delete'), mentions security implications ('Security cleanup'), and hints at prerequisites and next steps. However, it doesn't specify authentication requirements, rate limits, or error behavior, 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?
Well-structured with clear sections (API description, Best for, Not for, Prerequisites, Next steps, Related). Every sentence earns its place by providing distinct value. The information is front-loaded with the core purpose first, followed by 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 provides good context about usage scenarios, prerequisites, and related tools. However, it doesn't describe what happens after deletion (e.g., whether changes are immediate, if confirmation is required, or what the response looks like), leaving some gaps in 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 parameters are well-documented in the schema. The description doesn't add additional parameter semantics beyond what's in the schema (e.g., it doesn't explain format of IDs or variable naming conventions). 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 ('Delete a variable'), target resource ('for a service in a specific environment'), and distinguishes from siblings like variable_set (create/update) and variable_list (read). It goes beyond just restating the name by specifying the scope of deletion.
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?
Explicitly provides 'Best for' scenarios (removing unused configuration, security cleanup, configuration management) and 'Not for' exclusions (temporary variable disabling, bulk variable removal). Also lists prerequisites (service_list) and related tools (variable_list, variable_set), giving clear guidance 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 the tool can both create and update variables, mentions it's for configuration values, connection strings, and secrets, and implies it's for persistent changes (not temporary). However, it doesn't detail error conditions, rate limits, or authentication requirements, 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 with bullet points, icons, and clear sections, making it easy to scan. Every sentence adds value—no redundant information. It's front-loaded with the core purpose, followed by detailed 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?
Given the complexity (a mutation tool with 5 parameters), no annotations, and no output schema, the description does a good job by covering purpose, usage, prerequisites, and alternatives. However, it lacks details on return values or error handling, which would be helpful for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description doesn't add any parameter-specific details beyond what's in the schema, such as explaining the relationship between serviceId and shared variables. Baseline 3 is appropriate when the schema provides complete parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create or update an environment variable') and resource ('environment variable'), distinguishing it from sibling tools like variable_bulk_set, variable_list, and variable_delete. The title is null, so the description fully defines the purpose.
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 a specific alternative (variable_bulk_set), lists prerequisites (service_list), and suggests next steps (deployment_trigger, service_restart). This comprehensively covers when to use and avoid 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 the full burden of behavioral disclosure. It effectively communicates that this is a creation/mutation tool (implied by 'Create'), specifies use cases and exclusions, and mentions prerequisites and next steps. However, it lacks details on permissions, rate limits, or error handling, which would be valuable 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, Next steps, Related). 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 complexity as a mutation operation with no annotations and no output schema, the description does a good job covering purpose, usage guidelines, and workflow context. However, it could improve by including more behavioral details like response format or error scenarios, which are important for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description does not add any parameter-specific information beyond what the schema provides, such as format examples or constraints. This meets the baseline expectation 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 tool's purpose with a specific verb ('Create') and resource ('new persistent volume for a service'), distinguishing it from siblings like volume_list, volume_delete, and volume_update. It explicitly defines the scope as persistent storage creation.
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, listing specific use cases (database storage, persistent data, file storage) and exclusions (temporary storage, static hosting, caching). It also mentions prerequisites (service_list) and next steps (volume_list), offering clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 conveys that this is a destructive operation (implied by 'Delete' and cleanup context) and adds practical guidance like recommending volume_backup for data backup, though it lacks details on permissions, rate limits, or irreversible effects, which would be beneficial 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 references. Each sentence earns its place by providing clear, actionable information without redundancy, making it highly 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 as a destructive operation with no annotations or output schema, the description does a good job covering purpose, usage, and prerequisites. However, it could be more complete by explicitly warning about data loss or confirming deletion irreversibility, which are critical for such a tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'volumeId' fully documented in the schema as 'ID of the volume to delete'. The description does not add any additional semantic 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 ('Delete a volume from a service') with the resource ('volume') and context ('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 without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance with 'Best for' and 'Not for' sections, naming specific use cases (e.g., 'Removing unused storage') and exclusions (e.g., 'Temporary data removal'), and references prerequisites ('volume_list') and related tools ('service_update'), 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. It effectively communicates this is a read-only discovery tool (implied by 'List all available'), specifies the scope ('Railway's official templates'), and clarifies what it doesn't do. However, it doesn't mention potential rate limits, authentication needs, or response format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with clear sections (purpose, best for, not for, alternatives, next steps, related). Every sentence adds value without redundancy, and the information is front-loaded with the core purpose statement 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 zero-parameter read tool with no output schema, the description provides excellent context about purpose, usage boundaries, and related tools. The main gap is the lack of information about return format or potential limitations, but given the tool's simplicity, this is a minor omission.
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 baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on the tool's purpose and usage context.
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 resource ('database types that can be deployed using Railway's official templates'). It distinguishes from siblings by explicitly stating what it's not for ('Not for: Listing existing databases'), 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 explicit guidance with 'Best for' and 'Not for' sections, names a specific alternative ('service_create_from_image'), and includes 'Next steps' and 'Related' sections. This gives clear context on when to use this tool versus alternatives like listing existing databases or getting connection details.
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/RuKapSan/railway-mcp/badges/card.svg)](https://glama.ai/mcp/servers/RuKapSan/railway-mcp)

Score Badge

Copy to your README.md:

[![railway-mcp MCP server](https://glama.ai/mcp/servers/RuKapSan/railway-mcp/badges/score.svg)](https://glama.ai/mcp/servers/RuKapSan/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/RuKapSan/railway-mcp'

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