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-calc-mcp how long to reach 99 woodcutting?"
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.
OSRS Calculator - XP, Goals and Time to 99 | OSRS Calc
A Model Context Protocol server that exposes the canonical OSRS Calc knowledge surface — calculators, training plans, and reference data, FAQ, official links — to MCP-compatible AI clients such as Claude Desktop, Cursor, Windsurf, and Continue. Read-only, no API keys, no quota, ~50 ms cold start.
Official website: https://osrs-calc.com
OSRS Calc is a browser-based Old School RuneScape planning toolkit. Its skill calculators estimate XP, actions, hours, and time to a target level across 24 skills, including Sailing.
The site also exposes DPS, Max Hit, Dry, Combat Level, prices, and wiki reference tools. This MCP provides the public calculator catalog and data caveats as read-only context; it does not access a player's account or promise that prices and wiki data are current outside the live site.
Old School RuneScape, RuneScape, and related names are owned by their respective rights holders. Check the live calculator and OSRS Wiki sources before making an in-game decision.
Related MCP server: Wiki OSRS MCP
get_calculator_overviewReturn the calculator workflows and reference-data boundaries the site exposes. (OSRS Calc)
Input: no parameters. Returns: text/markdown.
get_official_linksReturn the canonical list of official links for OSRS Calc (website, support, docs when available).
Input: no parameters. Returns: text/markdown.
site://osrs-calc/calculators — Public calculator workflows, training targets, and reference-data boundaries.
site://osrs-calc/faq — Short FAQ generated from public site metadata.
site://osrs-calc/links — Canonical URLs to share with users.
tell_me_about_osrs_calcSummarize what the site is, who it's for, and how it works. — OSRS Calc
plan_a_calculation_osrs_calcChoose a calculator workflow while respecting the site's data scope. — OSRS Calc
npx -y @smithery/cli install osrs-calc-mcp --client claude(Replace claude with cursor, windsurf, or continue for those clients.)
git clone https://github.com/rocnubie/osrs-calc-mcp.git
cd osrs-calc-mcp
pnpm installThen add to your MCP client config (claude_desktop_config.json for Claude Desktop, mcp.json for Cursor / Windsurf / Continue):
{
"mcpServers": {
"osrs-calc-mcp": {
"command": "node",
"args": [
"/absolute/path/to/osrs-calc-mcp/src/index.mjs"
]
}
}
}npx @modelcontextprotocol/inspector node src/index.mjsWebsite: https://osrs-calc.com
pnpm install
pnpm start # run the server over stdioMIT
Return the calculator workflows and reference-data boundaries the site exposes. (OSRS Calc)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description indicates a read-only retrieval (via 'Return'), but lacks details on authentication, rate limits, or other behavioral traits.
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 single sentence is concise and front-loaded, containing all essential information without superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, the description is largely complete for a simple retrieval, though the terms 'workflows' and 'reference-data boundaries' could be slightly ambiguous.
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?
With zero parameters and 100% schema coverage, the description adequately conveys no additional input is needed, earning the baseline of 4.
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 returns 'calculator workflows and reference-data boundaries' with context 'OSRS Calc', which distinguishes it from the sibling tool 'get_official_links'.
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 one needs calculator workflows and boundaries, but no explicit guidance on when to avoid this tool or compare with alternatives is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the canonical list of official links for OSRS Calc (website, support, docs when available).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the sole source. It describes returning a list but lacks details on formatting, ordering, or any limitations. For a simple read, it's minimally adequate but not thorough.
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 sentence, front-loaded with verb and resource, no wasted words. Highly concise and effective.
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 tool with no parameters, no output schema, and a single sibling, the description is complete: it specifies what the tool returns and for which platform. No obvious gaps.
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?
No parameters exist, so schema coverage is 100%. Description adds no parameter info, but none is needed. Baseline 4 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?
Description clearly states the verb 'Return' and the resource 'canonical list of official links for OSRS Calc'. It lists specific categories (website, support, docs) and is distinct from sibling tool get_calculator_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?
Does not explicitly state when to use this vs alternatives. While the purpose is clear, no guidance on when not to use or trade-offs with sibling tool. For a simple read tool, this is acceptable but not proactive.
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.
v0.1.0get_calculator_overviewget_official_linksScored across 2 tools
The two tools have clearly distinct purposes: one provides an overview of calculator workflows, the other returns official links. No overlap or ambiguity.
Both tools follow a consistent 'get_' prefix pattern, making the naming predictable and uniform.
With only two informational tools, the server feels severely under-scoped for a 'calculator' server. Users would expect actual calculation tools.
The server name suggests calculations, but no actual calculation tools are provided. The two tools only offer metadata (overview and links), leaving a massive gap in core functionality.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
GW1 build compiler: skill data, template code encode/decode, validation, hero roster. Read-only.
Read-only ROSCA and savings-circle answers and calculators, from Wiremi's public facts.
Read-only F1 game laps, telemetry, setups, leaderboard benchmarks, and progress.
Read-only access to your net worth, wealth percentile, projections, splits and budget.