SRA Simple MCP Server
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@SRA Simple MCP Serverrun daily farming task with 30 minute timeout"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
SRA Simple MCP Server
通过模型上下文协议(MCP)控制星穹铁道助手(StarRailAssistant, SRA)的 MCP 服务器。
功能特性
列出SRA可用任务配置
运行 SRA 任务
Related MCP server: algorithmaide-mcp
安装并检查环境变量
pip install .检查Python的脚本目录是否存在于环境变量中
{Python安装目录}\Scripts配置
在 sra_simple_mcp 目录下的 config.json中配置StarRailAssistant的路径
{
"sra_path": "D:\\Software\\StarRailAssistant" // StarRailAssistant的安装路径
}MCP 客户端配置
在 Claude Code 的settings.json中添加:
{
"mcpServers": {
"SRA_MCP": {
"command": "sra-mcp" // 如果没有配置Python脚本目录的环境变量,要使用完整路径 {Python安装目录}\Scripts\sra-mcp
}
}
}可用工具
MCP修改配置项目前操作起来及其不便,目前仅支持列出任务配置、任务执行功能
任务配置工具
工具 | 描述 |
| 列出所有任务配置 |
任务执行工具
工具 | 描述 |
| 运行任务(支持超时设置) |
环境要求
仅支持 Windows - SRA 本身仅支持 Windows
需要 .NET 10.0 - 用于运行 SRA GUI
同步执行 - 任务执行会阻塞,超时时间可配置(默认 60 分钟)
许可证
MIT License
Available Tools
2 toolslist_all_configA
List all available task config names.
Returns: List of config names (e.g., ["Default", "MyConfig"])
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully conveys that this is a read-only listing operation returning config names. It adds no misleading information, though it could be more explicit about having no 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two clear sentences, no filler, and immediately states the purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and a straightforward return value, the description is complete. It explains what the tool does and what it returns, even without relying on an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description does not need to explain parameters. Schema coverage is 100%, meeting the baseline for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all available task config names' with a specific verb and resource, and provides example output. It distinguishes well from the sibling tool 'run_sra_task' which operates on configurations rather than listing them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving config names, presumably to be used with 'run_sra_task', but does not explicitly state when to use or alternatives. The sibling context provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_sra_taskA
Run an SRA task asynchronously.
Args: config_name: Name of the config to use (e.g., "Default") timeout: Timeout in seconds (default 3600 = 60 minutes) admin: Start SRA with admin or not
Returns: Dict with keys: pid, started_at, cmd, thread, timeout
Raises: Exception: If a task is already running, or if config/Popen cannot be loaded.
| Name | Required | Description | Default |
|---|---|---|---|
| config_name | Yes | ||
| timeout | No | ||
| admin | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully handles transparency. It states the tool is asynchronous, lists return keys, and mentions possible exceptions. It does not detail side effects like starting a process or permission needs, but covers core behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with structured sections (Args, Returns, Raises). Every sentence provides necessary information with no redundancy, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity with 3 parameters and no annotations, the description covers purpose, parameters, return format, and error conditions comprehensively. No important behavioral aspect is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, but the description explains all three parameters: config_name (with example), timeout (with unit and default), and admin (though vague). It also describes the return dict, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run an SRA task asynchronously,' identifying the specific action and resource. It distinguishes from sibling 'list_all_config' by its unique purpose of executing rather than listing configurations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes Raises section explaining exceptions for a task already running or config issues, providing implicit guidance on when not to use. However, it lacks explicit contrast with the sibling tool 'list_all_config'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
The two tools have completely distinct purposes: one lists configuration names, the other runs an SRA task. There is no overlap or ambiguity.
Both tools follow a consistent verb_noun pattern in snake_case: 'list_all_config' and 'run_sra_task'. This is clear and predictable.
With only 2 tools, the server feels minimal but might be appropriate for a very simple use case. However, most MCP servers for task execution have more tools to manage the lifecycle.
The server lacks essential operations for managing SRA tasks, such as stopping a running task, checking task status, or retrieving results. These gaps will cause agent failures.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for Hailuo (MiniMax) AI video generation
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP Server for an Agent Task Marketplace
Related MCP Servers
- AlicenseAqualityAmaintenanceMCP server for Hotkeyless AHK HTTP API. It lets your agent control your whole computer using hotkeys.42MIT
- AlicenseCqualityDmaintenanceAn MCP server for real-device Android reversing workflows, wrapping AlgorithmAide config writes, AppSwitch/logList sync, LSPosed scope sync, Frida script injection, and runtime log queries into a stable MCP toolset.2314MIT
- AlicenseNot gradedqualityDmaintenanceMCP server for managing Kaiten tasks through AI agents like Claude, enabling task retrieval, creation, updating, and time logging.6442MIT
- FlicenseNot gradedqualityCmaintenanceWindows-native MCP server for a local ComfyUI portable package. It enables listing, validating, and running ComfyUI workflows via the loopback HTTP API.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/yasuoskywalker233/SRA_SimpleMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server