osrs-companion

by isaachansen

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.2
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3.7/5 across 13 of 13 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under BSD 2-Clause "Simplified" License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![osrs-companion MCP server](https://glama.ai/mcp/servers/isaachansen/osrs-companion/badges/card.svg)](https://glama.ai/mcp/servers/isaachansen/osrs-companion)

Score Badge

Copy to your README.md:

[![osrs-companion MCP server](https://glama.ai/mcp/servers/isaachansen/osrs-companion/badges/score.svg)](https://glama.ai/mcp/servers/isaachansen/osrs-companion)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/isaachansen/osrs-companion'

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