The osrs-wiki-mcp server is a read-only interface that gives structured, source-backed access to Old School RuneScape Wiki data through ten tools:
Search the Wiki – Find canonical article titles and text snippets by keyword, with pagination.
Get Wiki Page – Retrieve a cleaned, bounded version of any Wiki page along with its section index.
Get Wiki Sections – List all sections of a Wiki page.
Get Wiki Section – Read a specific section by numeric index (useful for large pages).
Get Item Info – View an item's description, combat bonuses, alch values, weight, member status, and creation/crafting details.
Find Shop – Paginate through every shop that stocks a given item, including price, stock, restock rate, location, and currency.
Find Drop Sources – Paginate through every monster or source that drops a given item, including rarity and quantity.
Get Item Sources – Get a bounded overview of all drops, shop listings, crafting recipes, and ground spawns for an item in one call.
Get Quest Requirements – Retrieve skill levels, prerequisite quests, required items, and other conditions for any quest.
Get Monster Info – View combat stats, attack styles, immunities, slayer info, map locations, access notes, and variant support.
All responses include provenance (source URLs, timestamps, revision IDs, license). Results are paginated, cached for up to 5 minutes, and bounded in size. The server does not provide Grand Exchange prices, player hiscores, DPS calculations, images, or persistent storage.
Click on "Install 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-wiki-mcp find drop sources for abyssal whip"
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.
A local, read-only Model Context Protocol server for the Old School RuneScape Wiki. It gives AI clients ten focused tools for Wiki research, with validated structured output and source provenance on every successful response.
Stateless: no player account, database, telemetry, or disk cache.
Source-backed: results include canonical Wiki URLs and fetch timestamps; parsed pages also include an exact revision link.
Bounded: response sizes, pagination, retries, and request time are capped.
Read-only: the server only retrieves public Wiki data.
Node.js 24 or newer and npx are required.
codex plugin marketplace add SSanderV/osrs-wiki-mcp --ref v1.1.3
codex plugin add osrs-wiki-mcp@osrs-wikiclaude plugin marketplace add SSanderV/osrs-wiki-mcp@v1.1.3 --scope user
claude plugin install osrs-wiki-mcp@osrs-wiki --scope usergemini extensions install https://github.com/SSanderV/osrs-wiki-mcp --ref v1.1.3The plugin and extension include the MCP setup plus a small Wiki-research
skill. All three launch the pinned npm package osrs-wiki-mcp@1.1.3.
Configure a standard-input/output server with:
{
"command": "npx",
"args": ["--yes", "osrs-wiki-mcp@1.1.3"]
}Start a fresh client session after installation. If you previously configured
an osrs-wiki MCP server directly, remove that registration first so the
plugin is the only provider of the server.
Related MCP server: OSRS MCP Server
Tool | Inputs | Use it for |
|
| Find canonical pages and snippets. |
|
| Read a bounded, cleaned page with its section index. |
|
| List a page's sections. |
|
| Read one section by its numeric index. |
|
| Get an item's description, properties, bonuses, and creation facts. |
|
| Page through complete shop listings. |
|
| Page through complete monster-drop listings. |
|
| Get a bounded overview of drops, shops, recipes, and ground spawns. |
|
| Get Wiki-sourced requirements without evaluating a player. |
|
| Get separate monster variants, map points, and access notes. |
Example requests:
“What are the requirements for Dragon Slayer I?”
“Where can an ironman obtain a rune scimitar?”
“Find the exact Wiki section explaining Hespori mechanics.”
All public text inputs accept 1–256 Unicode characters. Tool schemas declare
the exact limits and defaults. When results are truncated or upstream
pagination is incomplete, warnings explains the safe follow-up action.
Successful calls return:
content for clients that display readable text; and
structuredContent, validated against the tool's MCP output schema.
Provenance includes the contributing Wiki URLs, original fetchedAt time,
attribution, license details, and whether content was transformed. Parsed-page
responses additionally include the exact revision ID and revision URL.
Failures use stable error codes such as NOT_FOUND, UPSTREAM_TIMEOUT,
UPSTREAM_RATE_LIMITED, UPSTREAM_UNAVAILABLE,
UPSTREAM_INVALID_RESPONSE, and RESPONSE_TOO_LARGE. Invalid arguments remain
standard JSON-RPC parameter errors.
A tool call has a 30-second total budget; each upstream request gets at most 20 seconds within that budget.
Transient network and rate-limit failures receive at most two bounded
retries, respecting Retry-After only when time remains.
Responses are capped at 5 MiB. Large Bucket scans stop after 10,000 raw rows and report incomplete or truncated results.
Valid upstream responses may be cached in memory for five minutes. The cache is limited per process, never written to disk, and cleared on restart.
Standard output is reserved for MCP traffic. Sanitized diagnostics use standard error.
The server deliberately does not provide player progress, hiscores, Grand Exchange prices, DPS calculations, Wiki images, persistent storage, hosting, or a local Wiki mirror. Quest requirements are facts rather than met/missing evaluations, and monster variants are never combined.
npm.cmd ci --ignore-scripts
npm.cmd run typecheck
npm.cmd test
npm.cmd run build
npm.cmd run smoke:stdio
npm.cmd run pack:checkTests use synthetic fixtures and do not contact the live Wiki. The optional live smoke makes two low-volume requests and does not persist responses:
npm.cmd run test:liveSee CONTRIBUTING.md for development guidance and SECURITY.md for private vulnerability reporting.
The source code is MIT licensed. Retrieved Old School RuneScape Wiki content remains subject to CC BY-NC-SA 3.0, including its non-commercial and ShareAlike conditions. Downstream users are responsible for how they reuse that content. See THIRD_PARTY_NOTICES.md.
RuneScape and Old School RuneScape are trademarks of Jagex Limited. This independent project is not affiliated with, endorsed by, or sponsored by Jagex Limited, Weird Gloop, or the Old School RuneScape Wiki.
Get the complete paginated Old School RuneScape Wiki drop listing for an item; get_item_sources is the bounded overview.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Exact Wiki item name | |
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| item | Yes | |
| limit | Yes | |
| total | Yes | |
| offset | Yes | |
| sources | Yes | |
| returned | Yes | |
| warnings | Yes | |
| truncated | Yes | |
| incomplete | Yes | |
| nextOffset | No | |
| provenance | Yes | |
| skippedRows | Yes | |
| totalIsExact | Yes | |
| rawCapReached | Yes | |
| rawRowsExamined | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds 'complete paginated' indicating paginated retrieval, but does not elaborate on iteration or concurrency behavior. Adequate given annotation richness.
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: first states purpose, second contrasts with sibling. No fluff or redundant information.
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?
With a full output schema, rich annotations, and clear sibling context, the description covers the essential purpose and alternative. It omits no critical details given the tool's simplicity and available structured metadata.
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 low (33%: only item described). The description mentions 'paginated' giving context for limit/offset, but does not explain how to use them (e.g., offset increments, limit max). Inadequate compensation given 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 tool gets a 'complete paginated drop listing' for an item, and explicitly distinguishes it from sibling 'get_item_sources' as a bounded overview.
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 the alternative sibling tool ('get_item_sources' for bounded overview), guiding when to use this tool for a full paginated listing vs a summary. No explicit when-not or prerequisites, but the contrast is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete paginated Old School RuneScape Wiki shop listing for an item; get_item_sources is the bounded overview.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Exact Wiki item name | |
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
| item | Yes | |
| limit | Yes | |
| shops | Yes | |
| total | Yes | |
| offset | Yes | |
| returned | Yes | |
| warnings | Yes | |
| truncated | Yes | |
| incomplete | Yes | |
| nextOffset | No | |
| provenance | Yes | |
| skippedRows | Yes | |
| totalIsExact | Yes | |
| rawCapReached | Yes | |
| rawRowsExamined | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, covering safety and side effects. The description adds 'complete paginated' but does not detail pagination behavior (e.g., how to iterate) or other nuances, providing minimal incremental 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 sentence that conveys the core function and a sibling reference. It is concise and front-loaded, but could be slightly more structured (e.g., separating the sibling note). Overall efficient.
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 an output schema (though not provided in input) and three parameters. The description indicates pagination and completeness, but lacks details on pagination mechanics, required parameter behavior, and error cases. It is adequate for a simple tool but not fully comprehensive.
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 only 33% (only 'item' has a description). The description does not explain the 'limit' or 'offset' parameters, and the schema's description of 'item' as 'Exact Wiki item name' is minimal. The description fails to add meaning beyond what the schema provides, leaving parameter usage ambiguous.
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 retrieves 'the complete paginated Old School RuneScape Wiki shop listing for an item', specifying the resource (shop listings) and verb (get). It distinguishes from the sibling 'get_item_sources' by calling it 'the bounded overview', indicating scope differentiation.
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 mentions 'get_item_sources is the bounded overview', providing a direct comparison to a sibling tool. However, it does not elaborate on when to avoid using this tool or specify prerequisites beyond item name matching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get normalized facts from an Old School RuneScape Wiki item page; use get_item_sources for acquisition data.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Exact Wiki item name |
| Name | Required | Description |
|---|---|---|
| name | Yes | |
| title | Yes | |
| value | No | |
| weight | No | |
| bonuses | No | |
| examine | No | |
| members | No | |
| creation | No | |
| noteable | No | |
| warnings | Yes | |
| equipable | No | |
| questItem | No | |
| stackable | No | |
| tradeable | No | |
| lowAlchemy | No | |
| provenance | Yes | |
| description | Yes | |
| highAlchemy | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive nature. Description adds that it returns 'normalized facts', which is behavioral context but not essential given annotations. No contradictions.
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?
Single, concise sentence with no unnecessary words. Efficiently conveys purpose and includes cross-reference to sibling tool.
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?
With output schema present, description does not need to detail returns. 'Normalized facts' is sufficient. Single parameter fully described in schema. Complete for a simple read 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?
Only one parameter 'item' with schema description 'Exact Wiki item name'. Description does not add further parameter meaning, but schema coverage is 100%, so 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?
Description clearly states 'Get normalized facts from an Old School RuneScape Wiki item page' and distinguishes from sibling 'get_item_sources' with explicit guidance. Verb and resource are specific.
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?
Description explicitly says when to use this tool (get normalized facts) and when to use an alternative ('use get_item_sources for acquisition data'), providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a bounded Old School RuneScape Wiki acquisition overview; follow truncation warnings with find_shop or find_drop_sources.
| Name | Required | Description | Default |
|---|---|---|---|
| item | Yes | Exact Wiki item name | |
| perCategoryLimit | No |
| Name | Required | Description |
|---|---|---|
| item | Yes | |
| drops | Yes | |
| shops | Yes | |
| recipes | Yes | |
| coverage | Yes | |
| warnings | Yes | |
| provenance | Yes | |
| groundSpawns | Yes | |
| perCategoryLimit | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by mentioning boundedness and truncation warnings, providing behavioral context beyond annotations. It does not contradict 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 sentence followed by a brief instruction, with no unnecessary words. It front-loads the core purpose and fits within the constraints of providing enough guidance without being verbose.
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 two parameters (one required) and an output schema (providing return structure), the description covers the tool's main purpose and usage context with siblings. It lacks parameter-level details for perCategoryLimit, but overall it is adequate for the complexity.
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 50% (only 'item' described). The description does not add meaning for 'perCategoryLimit', which is undocumented in schema. It only mentions 'bounded' but does not explain the parameter's role. The agent gains no additional insight from the description.
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 with a specific verb ('Get') and resource ('bounded Old School RuneScape Wiki acquisition overview'). It distinguishes from sibling tools by mentioning truncation warnings and directing to find_shop or find_drop_sources.
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 tells the agent to 'follow truncation warnings with find_shop or find_drop_sources', providing clear guidance on when to use alternatives. This helps the agent decide when this tool is appropriate versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get separate Old School RuneScape Wiki monster variants and facts without combining variants or calculating DPS.
| Name | Required | Description | Default |
|---|---|---|---|
| monster | Yes | Exact Wiki monster name | |
| variant | No | Optional exact variant anchor |
| Name | Required | Description |
|---|---|---|
| monster | Yes | |
| variants | Yes | |
| warnings | Yes | |
| mapPoints | Yes | |
| provenance | Yes | |
| accessNotes | Yes | |
| totalVariants | Yes | |
| selectedVariant | No | |
| variantsTruncated | Yes | |
| totalVariantsIsExact | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral nuance by specifying that it returns separate variants and facts without combining or calculating DPS, providing useful context beyond the 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, well-structured sentence of 17 words. It is front-loaded with the key action and resource, contains no superfluous information, and is highly concise.
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 presence of a full output schema, annotations covering safety and idempotency, and the clear purpose statement, the description is complete enough for a simple lookup tool. No further details are necessary for an agent to use or select this tool correctly.
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 both parameters ('monster' and 'variant') having clear descriptions in the input schema. The description does not add additional parameter semantics beyond what the schema provides, so 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 verb 'Get' and the resource 'Old School RuneScape Wiki monster variants and facts', and adds distinguishing context by noting it avoids combining variants or calculating DPS. This sets it apart from sibling tools like get_wiki_page or search_wiki.
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 for obtaining separate variant data without DPS calculation, but does not explicitly state when to use this tool over alternatives. No exclusions or when-not scenarios are provided, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Old School RuneScape Wiki quest requirements without evaluating any player's progress.
| Name | Required | Description | Default |
|---|---|---|---|
| quest | Yes | Exact Wiki quest name |
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| quest | Yes | |
| skills | Yes | |
| warnings | Yes | |
| provenance | Yes | |
| description | No | |
| questPoints | No | |
| manualConditions | Yes | |
| prerequisiteQuests | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context beyond annotations by stating that the tool does not evaluate player progress, which is a key behavioral trait for an AI agent to understand.
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 that is concise, front-loaded with the core action, and contains no filler or redundant information.
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 simplicity (one parameter, no enums, comprehensive annotations, and an output schema), the description is fully sufficient. It covers purpose, key behavioral constraint, and is complete.
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% description coverage for the single parameter 'quest' (described as 'Exact Wiki quest name'). The tool description adds no additional parameter details, so it meets the baseline but does not exceed 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 verb 'Get', the specific resource 'Old School RuneScape Wiki quest requirements', and adds a key qualifier 'without evaluating any player's progress'. This distinguishes it clearly from sibling tools like get_wiki_page or search_wiki.
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 includes a usage guideline: 'without evaluating any player's progress', which explicitly tells the agent when to use this tool vs. alternatives like personalized quest requirement tools. However, it does not explicitly mention when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a bounded Old School RuneScape Wiki page. If truncated, use get_wiki_sections and get_wiki_section.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Exact Wiki page title |
| Name | Required | Description |
|---|---|---|
| title | Yes | |
| content | Yes | |
| sections | Yes | |
| warnings | Yes | |
| truncated | Yes | |
| provenance | Yes | |
| totalCharacters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that the page is 'bounded' (may be truncated), which is key behavioral context beyond annotations. No contradiction.
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 that conveys both purpose and usage guidelines. No extraneous information.
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 simplicity (1 parameter, output schema exists, annotations complete), the description is fully adequate. It addresses the truncation behavior and provides fallback tools.
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 a clear description for the single 'title' parameter. The description does not add any additional semantics beyond what the schema already provides.
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 resource ('bounded Old School RuneScape Wiki page'). It distinguishes from siblings by mentioning truncation and naming alternative tools (get_wiki_sections, get_wiki_section) for when the page is truncated.
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 explicit guidance on when not to use this tool (if truncated) and directs to alternative tools. It does not explain when to use it, but the purpose is self-evident given the context of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one bounded Old School RuneScape Wiki section by the numeric index returned by get_wiki_sections.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Exact Wiki page title | |
| section | Yes | Section index from get_wiki_sections |
| Name | Required | Description |
|---|---|---|
| title | Yes | |
| content | Yes | |
| section | Yes | |
| warnings | Yes | |
| truncated | Yes | |
| provenance | Yes | |
| totalCharacters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive. Description adds the 'bounded' nature and dependency on another tool, which is useful but not extensive.
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?
Single sentence directly stating purpose and dependency. No unnecessary words.
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?
Simple tool with full annotation coverage, output schema present, and clear params. Description adequately covers what is needed for an agent to use it correctly.
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 covers both parameters with descriptions (100% coverage). Description does not add new meaning beyond reinforcing the connection to get_wiki_sections.
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?
Clearly states it gets a wiki section by numeric index from get_wiki_sections. Distinguishes from sibling tools like get_wiki_page and get_wiki_sections.
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?
Explicitly ties input to output of get_wiki_sections, implying workflow. Does not provide explicit when-not-use or list alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List bounded section metadata for an Old School RuneScape Wiki page before calling get_wiki_section.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Exact Wiki page title |
| Name | Required | Description |
|---|---|---|
| title | Yes | |
| total | Yes | |
| returned | Yes | |
| sections | Yes | |
| warnings | Yes | |
| truncated | Yes | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds 'bounded section metadata' but does not explain what 'bounded' means or what metadata fields are included. With rich annotations, the description adds marginal value.
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 concise sentence that front-loads the action and purpose, with no wasted words.
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 output schema exists (not shown but indicated), the description need not explain return values. For a simple tool with one parameter and thorough annotations, the description covers the essential task and usage context fully.
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% and the schema clearly describes the 'title' parameter as 'Exact Wiki page title'. The description adds no additional parameter information beyond the schema, so baseline score 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 tool lists 'bounded section metadata' for a Wiki page and explicitly positions it as a prerequisite to get_wiki_section, distinguishing it from that sibling.
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 to use this tool 'before calling get_wiki_section', providing clear when-to-use guidance. It does not explicitly mention when not to use it, but the context implies it's for exploring sections.
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 canonical article titles and snippets.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Wiki search query | |
| offset | No |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| offset | Yes | |
| results | Yes | |
| nextOffset | No | |
| provenance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds that it returns 'canonical article titles and snippets', but no additional behavioral traits are disclosed beyond the 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 concise sentence with no unnecessary words, effectively summarizing the tool's function.
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 annotations and output schema, the description is mostly complete. It identifies the tool's purpose and output type. However, it could hint at using get_wiki_page for full content retrieval after searching.
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?
Only the 'query' parameter has a minimal description in the schema; 'limit' and 'offset' lack any semantic explanation in the description. The description does not compensate for the low schema coverage (33%).
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 searches the Old School RuneScape Wiki for canonical article titles and snippets, distinguishing it from sibling tools like get_wiki_page (retrieves full page) and find_drop_sources (different search 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?
No guidance is provided on when to use this tool over alternatives such as get_wiki_page for full content or other search tools. The description only states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct aspect of the Old School RuneScape Wiki: drops vs shops, item info vs sources, monster info, quest requirements, wiki page browsing (page, sections, section), and search. No overlap is apparent.
All tools follow a consistent verb_noun pattern using snake_case (e.g., find_drop_sources, get_item_info, search_wiki). There are no deviations or mixed conventions.
10 tools cover the main functionalities needed to interact with the OSRS Wiki: item lookup, monster info, quest requirements, wiki page retrieval and search. This is well-scoped and neither too many nor too few.
The tool set covers core wiki operations: searching, reading pages and sections, and extracting data on items, monsters, and quests. Minor gaps exist (e.g., no direct quest detail tool beyond requirements, no equipment info), but the surface is largely complete for a read-only wiki MCP.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only MCP for the Eco game wiki: search, Markdown pages, and wiki_* lookups. No keys, no writes.
Wikidata MCP — wraps Wikidata API (wikidata.org/w/api.php)
Wikipedia MCP — wraps Wikipedia REST API (free, no auth)
Read and write your team's shared, AI-readable wiki from any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SSanderV/osrs-wiki-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server