Skip to main content
Glama
yasuoskywalker233

SRA Simple MCP Server

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修改配置项目前操作起来及其不便,目前仅支持列出任务配置、任务执行功能

任务配置工具

工具

描述

list_all_config

列出所有任务配置

任务执行工具

工具

描述

run_sra_task

运行任务(支持超时设置)

环境要求

  • 仅支持 Windows - SRA 本身仅支持 Windows

  • 需要 .NET 10.0 - 用于运行 SRA GUI

  • 同步执行 - 任务执行会阻塞,超时时间可配置(默认 60 分钟)

许可证

MIT License

Available Tools

2 tools
list_all_configA

List all available task config names.

Returns: List of config names (e.g., ["Default", "MyConfig"])

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
config_nameYes
timeoutNo
adminNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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

A4.3/5.0
Disambiguation5/5

The two tools have completely distinct purposes: one lists configuration names, the other runs an SRA task. There is no overlap or ambiguity.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern in snake_case: 'list_all_config' and 'run_sra_task'. This is clear and predictable.

Tool Count3/5

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.

Completeness2/5

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

ActivityStale
ResponsivenessSyncing

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

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yasuoskywalker233/SRA_SimpleMCP'

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