StageSpirit

Overview Schema Source Related Servers Discussions Admin

运行状态

runtime_status

Read-onlyIdempotent

Retrieve a fixed summary of current runtime configuration, data generation, instance identity, and active modules to verify service state and diagnose startup issues.

Instructions

读取当前运行配置、数据代际、实例身份和已启动模块的固定摘要。

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "runtime_status"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`state`	Yes
`modules`	Yes
`version`	Yes	已安装的 StageSpirit 版本
`uptime_ms`	Yes
`process_id`	Yes
`profile_id`	Yes	当前运行配置
`started_at`	Yes
`instance_id`	Yes	本次服务进程的运行实例
`data_generation`	Yes	持久数据集的代际身份
`capability_groups`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A3.7/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds that this reads a '固定摘要' (fixed/stable summary) and names the four content categories, which is modest extra context. It does not discuss data freshness, caching, or whether the snapshot is live versus periodically refreshed.

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?

A single compact sentence that front-loads the verb and enumerates the returned content. No filler, no redundant restatement of the title, and nothing an agent must read past to reach the substance.

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?

An output schema exists, so the description need not explain return values, and with zero parameters there are no input semantics to cover. The one residual gap is the meaning of '固定摘要' (a fixed summary) — an agent cannot tell whether the snapshot is stale-tolerant or always current, which mildly matters for a status tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema declares zero parameters, so there is nothing for the description to disambiguate. The baseline for a parameterless tool is 4, and nothing in the description creates ambiguity about inputs.

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 states a specific verb (读取 / read) and enumerates the resources returned: runtime configuration, data generation, instance identity, and started modules. This is far more than a restatement of the name. It stops short of a 5 only because there are no sibling tools to be distinguished from, so no comparative scoping is possible.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The tool describes what it reads but gives no explicit when-to-use or when-not-to-use guidance. For a zero-parameter, side-effect-free status reader the implied usage is fairly self-evident, which keeps this at a minimum-viable 3 rather than lower.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools

runtime_statusA