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-companion search OSRS Wiki for dragon scimitar"
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.
An MCP server for Old School RuneScape that gives AI assistants access to wiki search, Grand Exchange prices, and your synced player data — all running locally on your machine.
Wiki Search — Search the OSRS Wiki for any article
Page Summaries — Get introductory summaries of wiki pages
GE Prices — Look up current Grand Exchange buy/sell prices
WikiSync Player Data — Fetch player data via the WikiSync plugin
Local Player Sync — Read detailed player data saved by the companion RuneLite plugin (bank, skills, quests, equipment, inventory, diaries, combat achievements)
Related MCP server: RuneScape Wiki MCP Server
For the local player sync tools, install the OSRS MCP Companion RuneLite plugin. Wiki search, summaries, and GE prices work without it.
Add to your MCP configuration:
{
"mcpServers": {
"osrs-companion": {
"command": "npx",
"args": ["-y", "osrs-companion"]
}
}
}npx -y osrs-companionTool | Description |
| Search the OSRS Wiki for articles |
| Get the intro summary of a wiki page |
| Look up Grand Exchange prices |
| Fetch player data via WikiSync |
Tool | Description |
| List players with synced data |
| Full player summary |
| Search bank contents |
| Skill levels and XP |
| Quest completion status |
| Currently equipped items |
| Current inventory |
| Achievement diary progress |
| Combat achievement status |
The MCP server runs locally via stdio transport. Wiki and price tools
fetch from public OSRS APIs. Player sync tools read JSON files from
~/.runelite/osrs-companion/ that are written by the companion RuneLite plugin.
No data is stored in the cloud. No API keys required.
Wiki content returned by the search and summary tools is sourced from the
Old School RuneScape Wiki, which is licensed
under CC BY-NC-SA 3.0.
All wiki tool responses include an attribution notice automatically.
Grand Exchange price data is provided by the OSRS Wiki Prices API. Player data is fetched via the WikiSync API or read from local files saved by the RuneLite plugin — neither contains wiki article content.
BSD 2-Clause "Simplified" License. See LICENSE.
Search and browse the player's synced bank contents. Supports filtering by item name, bank tab, and minimum quantity.
| Name | Required | Description | Default |
|---|---|---|---|
| tab | No | Bank tab number to filter (0-indexed) | |
| search | No | Search term to filter items by name (case-insensitive) | |
| username | Yes | Player username | |
| minQuantity | No | Only show items with at least this quantity |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. 'Search and browse' implies a non-destructive read operation, and 'synced' hints that data may be from a synchronization rather than live. However, it does not explicitly state that no modifications occur, nor does it mention pagination, rate limits, or sync lag, leaving some transparency gaps.
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 two concise sentences, front-loaded with the primary action followed by supported filters. Every word adds value, with no redundancy or filler.
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 low complexity and rich schema, the description adequately covers its purpose and filtering options. It does not describe the output format, but no output schema is provided, and for a simple 'get my bank' tool, the expected return is fairly obvious. Minor gaps include handling of unsynced data or empty results, but overall it is complete enough for an 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?
The input schema has 100% coverage with descriptions for all parameters. The description restates the filtering capabilities (item name, tab, quantity) but adds no new semantic detail beyond the schema. Baseline 3 is appropriate since the schema already documents parameter meanings effectively.
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 identifies the tool's purpose: searching and browsing the player's synced bank contents. It uses specific verbs ('search', 'browse') and a distinct resource ('bank contents'), which distinguishes it from sibling tools like get_my_inventory or get_my_equipment.
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 usage context by focusing on the player's own bank and mentions supported filtering capabilities. It does not explicitly exclude alternatives or provide when-not-to-use guidance, but the scope is clear enough for an agent to select this tool for bank-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the player's combat achievement completion status. Optionally search by task name.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Search term to filter by task name | |
| username | Yes | Player username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior, but it only restates the basic action without explaining return format, pagination, authentication, or any side effects. The optional search parameter is mentioned, but no additional behavioral context is provided.
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 immediately states the core purpose and includes the optional search capability. There is no redundant or extraneous wording.
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 simple two-parameter read tool, the description provides adequate basic information, but it lacks details about the output structure or whether results are a list, which could be important for an agent. While the schema covers parameters and the name is descriptive, the description alone does not fully convey expected return behavior.
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 100% for both parameters, so the schema already defines 'username' and 'search'. The description only adds that search is by task name, which aligns with the schema but does not introduce new meaning beyond it.
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 ('Get') and the resource ('the player's combat achievement completion status'), which distinguishes it from sibling get_my_* tools that target different data. It also mentions the optional search by task name, adding scope precision.
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 use for retrieving combat achievement completion data, but it does not explicitly state when to use this tool over alternatives or provide clear exclusions. Context from sibling names suggests specialization, but the description itself offers no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the player's achievement diary completion status. Optionally filter by region.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Specific diary region (e.g. 'ARDOUGNE', 'VARROCK') | |
| username | Yes | Player username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. 'Get' implies a read-only operation, and the description mentions optional filtering, but it does not disclose potential rate limits, authentication requirements, or any side effects. For a simple getter, this is adequate but not rich.
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 one concise sentence with no filler. It front-loads the main purpose and includes the key optional behavior, earning every word.
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 low-complexity getter with only two parameters and no output schema, the description is sufficiently complete. It defines what the tool returns (completion status) and the optional filter. A slightly higher score is not needed because no return structure or edge cases are described, but these are not critical for this simple tool.
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?
The input schema already provides 100% coverage with descriptions for both 'username' and 'region'. The description adds the phrase 'optionally filter by region,' which restates the schema's meaning without adding new detail. Since coverage is high, the baseline score of 3 applies.
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 ('Get') and the resource ('player's achievement diary completion status'). It explicitly mentions the optional filter by region, making the tool's purpose unambiguous and distinguishable from sibling tools like get_my_quests or get_my_combat_achievements.
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 when to use this tool (to check diary completion) but does not provide explicit guidance on when not to use it or which alternative tools to prefer. The optional region filter hints at a use case, but no direct comparison to siblings is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the player's currently equipped items (last synced state).
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Player username |
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 adds the important caveat 'last synced state', indicating the data may be cached or not live. It doesn't mention return format or error scenarios, but for a simple getter, this is a reasonable level of transparency.
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, focused sentence that front-loads the verb and resource. It contains no unnecessary words or repetition, making it highly concise and structured effectively.
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 simple tool with one parameter and no output schema, the description is fairly complete. It conveys the purpose and the synced-state behavior, which is the key contextual nuance. It could mention what the return value looks like, but 'items' is enough for a basic invocation.
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?
The schema documentation covers 100% of the parameters (username with description 'Player username'), so the description need not add parameter details. The tool's description does not elaborate on the username parameter, but since schema coverage is high, a baseline score of 3 is appropriate.
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 gets the player's currently equipped items, using a specific verb and resource. The phrase 'last synced state' adds clarity about the data source, and 'equipped items' distinguishes it from sibling tools like get_my_inventory.
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 clear context for when to use this tool (to fetch equipped items), but it doesn't explicitly mention when not to use it or reference alternative tools. The name and description make it self-evident, so this is sufficient without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the player's current inventory contents (last synced state).
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Player username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It adds the important detail that the inventory is the 'last synced state', indicating potential staleness, but does not mention error cases, permissions, or return format.
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, tight sentence with no redundant wording. Every word serves a purpose, making it highly concise and 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?
For a simple getter tool with no output schema, the description explains what it returns but not the structure (e.g., list of items, quantities). The 'last synced state' context is useful, but more detail about the response format would improve completeness.
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?
The input schema already fully describes the single 'username' parameter with a clear description. The tool description adds no extra meaning beyond what the schema provides, so the baseline of 3 is appropriate.
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 gets the player's current inventory contents, using a specific verb and resource. It distinguishes itself from sibling tools like get_my_bank or get_my_stats by naming 'inventory contents'.
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 usage by the tool's name and resource focus, but it does not explicitly state when to use this tool versus alternatives. The 'last synced state' phrase hints at data freshness expectations but lacks explicit guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a full summary of synced player data including stats, quest count, bank size, and diary progress. Data is synced from RuneLite via the MCP Sync plugin.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Player username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only notes that data is synced from RuneLite via the MCP Sync plugin. It does not mention read-only behavior, error handling, response format, or data freshness, leaving significant gaps for an agent to understand what to expect.
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 (two sentences) and front-loaded with the tool's purpose. The first sentence explains what the tool returns, and the second provides useful source context. Every word earns its place with no redundancy.
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 simple read-only profile tool with one well-documented parameter and no output schema, the description provides sufficient context about what data is included (stats, quest count, bank size, diary progress). It could be more complete by explaining response shape or potential errors, but it covers the essential 'what' for an agent to invoke it effectively.
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?
The input schema fully describes the single parameter 'username' with 'Player username', achieving 100% schema description coverage. Per the baseline rule, a score of 3 is appropriate; the description adds no extra context about username requirements or formatting 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 function: 'Get a full summary of synced player data including stats, quest count, bank size, and diary progress.' The verb 'get' and resource 'full summary' are specific, and listing the included categories distinguishes it from sibling tools like get_my_stats and get_my_bank, which focus on individual aspects.
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 use for an overall player profile overview but does not explicitly state when to use this tool versus alternatives like get_my_stats or get_my_bank. It neither names sibling tools nor provides exclusions, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the player's synced quest completion status. Filter by state or search by name.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Filter by quest state | |
| search | No | Search term to filter quests by name | |
| username | Yes | Player username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It states 'Get' implying a read-only operation and 'synced' hints at data sourcing, but it doesn't disclose response format, error handling, or any side effects, leaving notable gaps.
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?
One concise sentence effectively conveys both purpose and filtering capability, with no redundant or filler content.
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?
Without output schema or annotations, the description doesn't specify the return structure or behavior for edge cases. It is sufficient for a simple getter but lacks details like pagination or default state, relying on sibling context for completeness.
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 has 100% parameter description coverage, so baseline is 3. The description adds 'Filter by state or search by name' which aligns with the parameters but doesn't provide extra meaning like how state and search interact (AND/OR logic), so it adds little beyond 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?
Description uses specific verb 'Get' with resource 'player's synced quest completion status', clearly distinguishing it from sibling tools like get_my_bank or get_my_stats. The filtering options further reinforce its unique scope.
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 mentions 'Filter by state or search by name', which implies when to use this tool for quest-related data. Sibling tool names make the context clear, though no explicit exclusions or alternative recommendations are given, preventing a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the player's synced skill levels and XP. Optionally filter to a specific skill.
| Name | Required | Description | Default |
|---|---|---|---|
| skill | No | Specific skill name (e.g. 'ATTACK', 'MINING'). Omit for all skills. | |
| username | Yes | Player username |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether the operation is read-only (implied by 'Get'), what 'synced' means regarding data freshness, or error behavior. The word 'synced' introduces uncertainty without explanation.
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?
Two concise sentences with the primary action front-loaded and an optional modifier in the second sentence. No filler or redundancy.
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?
The description covers the core function and output content (skill levels and XP), but omits return structure, sync semantics, and error scenarios. Given no output schema and no annotations, the description is minimally complete but not rich.
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 coverage is 100% with descriptions for both parameters. The description adds no meaning beyond the schema, merely restating the optional skill filter already documented. Baseline 3 is appropriate.
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 gets a player's synced skill levels and XP, with an optional skill filter. This specific verb-resource pairing distinguishes it from sibling tools like get_my_bank or get_my_quests.
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 usage when skill data is needed, but it does not explicitly mention alternatives or when not to use it. With siblings like get_my_profile potentially overlapping, clearer exclusions would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all players that have synced data from RuneLite. Use this first to find available usernames.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 clearly states the behavior (listing synced players) and the intended use, which is transparent for a zero-parameter read-only tool. It does not disclose potential edge cases or output format, but for this tool the behavior is straightforward.
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 two concise sentences, with the core action front-loaded. No wasted words; it efficiently conveys the tool's purpose and usage.
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 low complexity (no parameters, no output schema), the description is sufficiently complete. It indicates the return concept (usernames) and workflow position ('Use this first'), but does not explicitly describe the return format. Still, for a discovery list tool, this is enough.
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?
The tool has zero parameters, and the baseline for 0 parameters is 4. The description correctly avoids adding parameter details since there are none, and it still clarifies the tool's scope.
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 uses the specific verb 'List' with the resource 'all players that have synced data from RuneLite', clearly distinguishing it from sibling tools like 'player' or 'search'. It also states its role as a discovery tool: 'Use this first to find available usernames.'
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 explicitly says 'Use this first to find available usernames', giving clear when-to-use context. However, it does not mention when not to use it or alternative tools, but given the simple list nature, this is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch RuneLite player data via the WikiSync plugin (requires RuneLite client)
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | RuneLite username | |
| forceRefresh | No | Force refresh cached data |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the RuneLite client requirement but omits behavioral details such as caching behavior (forceRefresh exists), failure modes (e.g., player not synced), or data scope. This is insufficient for a data-fetching tool.
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 sentence, front-loaded with the action and resource, and every word adds value. It is appropriately concise without unnecessary filler.
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?
The tool has no output schema and no annotations, so the description must explain what 'player data' includes and how it relates to WikiSync. This is missing, making the description inadequate for a 2-parameter tool that returns undefined data.
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?
The schema already documents both parameters (username, forceRefresh) with full coverage. The description adds no additional meaning beyond the schema, so 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Fetch'), resource ('RuneLite player data'), and mechanism ('via WikiSync plugin'). However, it does not explicitly distinguish itself from sibling tools like get_my_profile or list_synced_players, which also deal with player data.
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 explicit guidance on when to use this tool versus alternatives. It only mentions a prerequisite (requires RuneLite client) but not when to prefer player over get_my_profile or list_synced_players.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the current Grand Exchange price for an item
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Item name (e.g. 'Abyssal whip', 'Dragon bones') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits itself. 'Look up' implies a safe read-only operation, but the description does not disclose potential error conditions, data freshness, or any side effects. It is honest but minimal, providing only basic behavioral clarity.
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, focused sentence that directly states functionality without any redundant or extraneous content. It is front-loaded with the action and purpose.
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 simple lookup tool with one well-documented parameter and no output schema, the description is nearly sufficient. It clearly indicates the tool returns the current GE price, though it does not specify the exact response format. This is a minor gap given the tool's simplicity.
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?
The schema provides 100% coverage for the single parameter, including examples ('Abyssal whip', 'Dragon bones'). The tool description adds no additional parameter meaning, so the baseline of 3 applies.
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 uses a specific verb ('look up') with a clear resource ('current Grand Exchange price for an item'), making the tool's purpose unambiguous. It distinguishes from siblings like search (general search) and player (profile info) by focusing specifically on price lookup.
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 usage when a GE price is needed but does not explicitly state when to use this tool versus alternatives. There are no exclusions or alternative tool references, leaving usage guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Old School RuneScape Wiki for articles matching a query
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-50) | |
| query | Yes | Search query (e.g. 'dragon scimitar', 'Zulrah') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the purpose and does not mention whether it is read-only, how results are returned, pagination behavior, or any limitations. This is a notable gap for a search tool.
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 is front-loaded with the action and resource. It is appropriately concise with no waste or redundancy.
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?
This is a simple tool with only two parameters and a clear purpose, so the description is mostly adequate. However, since there is no output schema, the description does not explain what the search results look like (e.g., titles, URLs), which would be useful for an agent. This gap prevents a higher score.
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?
The schema description coverage is 100%, with both 'query' and 'limit' fully documented. The description adds no additional parameter semantics, so 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool searches the Old School RuneScape Wiki for articles matching a query. The verb 'search' is specific, the resource is defined, and it is easily distinguished from sibling tools that handle player data, item prices, or summaries.
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 makes it clear the tool is for searching wiki articles, which implies its usage context. However, it provides no explicit guidance on when to use it versus alternatives (e.g., 'summary') or when not to use it, so it only meets the 'implied usage' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the introductory summary of an OSRS Wiki page
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Exact page title (e.g. 'Abyssal whip', 'Farming') |
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 does not mention return format, potential errors, rate limits, or any side effects. The description adds no behavioral context beyond the basic action.
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, front-loaded sentence with no redundant information. It efficiently communicates the tool's purpose without any filler.
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 simple one-parameter schema and no output schema, the description is minimally complete—it states what the tool does. However, it does not describe the shape or format of the returned summary or error behavior, so it is not fully self-contained.
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?
The schema already documents the 'title' parameter with a clear description and examples. The tool description adds no additional meaning beyond identifying the page as an OSRS Wiki page, which is already implied by the tool's purpose. Thus, the schema fully covers 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 uses the specific verb 'Get' and clearly identifies the resource as the introductory summary of an OSRS Wiki page. This distinguishes it from sibling tools like search or price, which serve different purposes.
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 does not provide any explicit guidance on when to use this tool versus alternatives such as search or player. It only states what it does, leaving the agent to infer usage context on its own.
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.
v1.0.2get_my_bankget_my_combat_achievementsget_my_diariesget_my_equipmentget_my_inventoryget_my_profileget_my_questsget_my_statslist_synced_playersplayerpricesearchsummaryScored across 13 tools
Each tool has a clearly distinct purpose: wiki search, summary, price, and the player data tools are all narrowly scoped (profile, bank, stats, quests, equipment, inventory, diaries, combat achievements). The 'player' tool is slightly generic but is differentiated from list_synced_players by fetching raw data, and from get_my_* by being a lower-level operation. No two tools appear to do the same thing.
The player data tools consistently follow a 'get_my_*' pattern, but the wiki tools use simple verbs/nouns (search, summary, price) and 'player' is a bare noun. This creates minor inconsistency across the set, but within each functional group the naming is predictable and readable.
Thirteen tools is well within the ideal 3-15 range for a server with two clear purposes: wiki lookup and player data retrieval. Every tool serves a distinct need without redundancy, making the set feel appropriately scoped.
The server covers the core companion features: wiki search with summary and price lookup, and comprehensive synced player data including profile, bank, stats, quests, equipment, inventory, diaries, and combat achievements. There are no obvious missing operations for the stated domain, as it is a read-only companion tool.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Savecraft serves real save game data and expert game knowledge to AI assistants.