Click on "Deploy 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., "@OSRS-STAT show me the top 10 players for Attack skill"
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.
一个提供实时《Old School RuneScape》玩家统计数据和排行榜数据的Model Context Protocol (MCP)服务器，支持多种游戏模式和玩家比较功能。 A Model Context Protocol (MCP) server that provides real-time player statistics and ranking data of 'Old School RuneScape', supporting multiple game modes and player comparison functions.## 工具列表 Tool List
本MCP服务封装下列工具，可让模型通过标准化接口调用以下功能。 本MCP服务封装下列工具，可让模型通过标准化接口调用以下功能。
工具 Tool | 描述 Description |
get_player_stats | Retrieve comprehensive statistics for a specific OSRS player including skills, activities, and boss kill counts |
get_skill_leaderboard | Get top players for a specific skill |
get_activity_leaderboard | Get top players for activities (bosses, minigames, clues) |
compare_players | Compare statistics between multiple OSRS players |
工具在线测试： https://mcp.xiaobenyang.com/inspector/1777316659429379
Online Tool test https://mcp.xiaobenyang.com/inspector/1777316659429379
Related MCP server: mcp-server-runescape
如何获取 XBY-APIKEY ？ How to get XBY-APIKEY ?
访问小笨羊科技网站 https://xiaobenyang.com，注册用户即可获得APIKEY Visit XiaoBenYang website https://xiaobenyang.com, register and get the APIKEY.
{
"mcpServers": {
"OSRS玩家数据服务": {
"headers": {
"XBY-APIKEY": "<YOUR_XBY_APIKEY>"
},
"type": "sse",
"url": "https://mcp.xiaobenyang.com/1777316659429379/sse"
}
}
}{
"mcpServers": {
"OSRS玩家数据服务": {
"headers": {
"XBY-APIKEY": "<YOUR_XBY_APIKEY>"
},
"type": "streamable_http",
"url": "https://mcp.xiaobenyang.com/1777316659429379/mcp"
}
}
}{
"mcpServers": {
"OSRS玩家数据服务": {
"command": "npx",
"args": [
"-y",
"xiaobenyang-mcp"
],
"env": {
"XBY_APIKEY": "<YOUR_XBY_APIKEY>",
"mcpId": "1777316659429379",
},
"transport": "stdio"
}
}
}
Compare statistics between multiple OSRS players
| Name | Required | Description | Default |
|---|---|---|---|
| usernames | Yes | ||
| focus | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions comparing statistics but doesn't disclose what types of statistics, how the comparison is presented, whether it requires authentication, rate limits, or error handling. This leaves significant gaps for an agent to understand the tool's behavior.
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 a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It is front-loaded and appropriately sized for the tool's apparent complexity.
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 no annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain what statistics are compared, the output format, or behavioral constraints. For a tool with two parameters and comparison functionality, more context is needed for effective use.
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?
Schema description coverage is 0%, so the description must compensate but adds little. It implies 'usernames' parameter is for multiple players and 'focus' might narrow the comparison, but doesn't explain what 'focus' means (e.g., specific skills, activities) or format requirements (e.g., array of strings). This is inadequate given the low schema coverage.
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 the action ('compare statistics') and the resource ('multiple OSRS players'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_player_stats' or 'get_skill_leaderboard', which might also involve player statistics.
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?
No guidance is provided about when to use this tool versus alternatives like 'get_player_stats' (which might retrieve individual stats) or 'get_skill_leaderboard' (which might compare across many players). The description implies comparison between multiple players but doesn't specify contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top players for activities (bosses, minigames, clues)
| Name | Required | Description | Default |
|---|---|---|---|
| activity | Yes | ||
| gamemode | No | ||
| page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't clarify if it's safe, requires authentication, has rate limits, or describes pagination behavior. The mention of 'page' parameter hints at pagination, but this isn't explicitly explained.
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 a single, efficient sentence with zero waste. It's front-loaded with the core purpose and uses parentheses for concise clarification. Every word earns its place, making it highly readable and to-the-point.
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 complexity (3 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It lacks details on parameter usage, behavioral traits like pagination or safety, and output format. For a leaderboard tool with multiple parameters, this leaves significant gaps for an AI agent.
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?
Schema description coverage is 0%, so the schema provides no parameter details. The description mentions 'activities (bosses, minigames, clues)', which loosely relates to the 'activity' parameter, but doesn't explain 'gamemode' or 'page'. It adds minimal semantic value beyond the schema, failing to compensate for the coverage gap.
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 the tool's purpose: 'Get top players for activities (bosses, minigames, clues)'. It specifies the verb ('Get') and resource ('top players'), and identifies the scope ('activities'). However, it doesn't explicitly differentiate from sibling tools like 'get_skill_leaderboard', which likely serves a similar but distinct purpose.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_skill_leaderboard' or 'compare_players', nor does it specify prerequisites or exclusions. Usage is implied by the purpose but lacks explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve comprehensive statistics for a specific OSRS player including skills, activities, and boss kill counts
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | ||
| gamemode | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data but doesn't describe behavioral traits such as whether it's a read-only operation, potential rate limits, authentication needs, error handling, or what happens if the player doesn't exist. The description is minimal and doesn't 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary details. It avoids redundancy and waste, though it could be slightly more structured by separating key points. It earns its place by specifying what statistics are included.
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 complexity of a tool with 2 parameters (one optional), no annotations, and no output schema, the description is incomplete. It doesn't explain the return values, error cases, or parameter details, leaving significant gaps for an AI agent to understand how to invoke it correctly. The description is too brief for the tool's context.
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?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions retrieving statistics for a 'specific OSRS player,' which implies the 'username' parameter, but doesn't explain its format or constraints. It doesn't address the 'gamemode' parameter at all, leaving its purpose and possible values unclear. The description adds minimal 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 the tool's purpose with a specific verb ('Retrieve') and resource ('comprehensive statistics for a specific OSRS player'), including details about what statistics are retrieved (skills, activities, boss kill counts). It distinguishes from siblings like leaderboard tools by focusing on individual player data rather than comparisons or rankings, though it doesn't explicitly name the siblings.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'compare_players' for comparisons or 'get_activity_leaderboard' for leaderboard data, nor does it specify prerequisites or exclusions (e.g., when gamemode is required). Usage is implied by the purpose but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get top players for a specific skill
| Name | Required | Description | Default |
|---|---|---|---|
| skill | Yes | ||
| gamemode | No | ||
| page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action without disclosing behavioral traits like pagination behavior (implied by 'page' parameter), rate limits, authentication needs, or what 'top players' entails (e.g., count, sorting). It's minimal and leaves critical operational details unclear.
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 a single, efficient sentence with zero waste, front-loading the core purpose. It's appropriately sized for a simple tool, though brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on parameters, behavioral context, and output format, making it insufficient for an agent to use the tool effectively without guesswork.
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?
Schema description coverage is 0%, so the description must compensate but only mentions 'skill' implicitly. It doesn't explain 'gamemode' or 'page' parameters, their formats, or constraints. The description adds minimal value beyond the schema, failing to address the coverage gap adequately.
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 the verb ('Get') and resource ('top players for a specific skill'), making the purpose understandable. It distinguishes from siblings like 'get_activity_leaderboard' by specifying 'skill' focus, though it doesn't explicitly contrast with 'compare_players' or 'get_player_stats'.
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?
No guidance is provided on when to use this tool versus alternatives like 'get_activity_leaderboard' or 'get_player_stats'. The description implies usage for skill-based leaderboards but lacks explicit when/when-not instructions or prerequisite context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_playersget_activity_leaderboardget_player_statsget_skill_leaderboardScored across 4 tools
Each tool has a clearly distinct purpose with no ambiguity: compare_players focuses on direct comparisons between players, get_player_stats retrieves individual player data, and get_skill_leaderboard and get_activity_leaderboard target specific leaderboard types. The descriptions clearly differentiate between player-focused and leaderboard-focused operations.
All tools follow a consistent verb_noun pattern with clear, descriptive names. The naming convention is uniform throughout (compare_players, get_activity_leaderboard, get_player_stats, get_skill_leaderboard), making it easy to understand each tool's function at a glance.
With 4 tools, the count is reasonable for a statistics-focused server, though it feels slightly minimal. The tools cover core functionality (player stats, comparisons, leaderboards), but additional tools for historical data or more granular queries could enhance completeness without being overwhelming.
The tool set covers essential operations for OSRS statistics: retrieving player stats, comparing players, and accessing skill and activity leaderboards. Minor gaps exist, such as lack of tools for historical trends, clan statistics, or item/gear tracking, but agents can perform core tasks effectively with the provided tools.
App Store & Google Play keyword ranks, rivals, reviews, charts and AI visibility as an MCP server
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
Find the right MCP server for your task. 4,500+ servers ranked by community trust.
