wiseoldman-mcp
wiseoldman-mcp
An MCP server that wraps the Wise Old Man OSRS stat-tracking API (https://docs.wiseoldman.net/api), exposing it as tools for MCP-compatible clients (Claude Code, Claude Desktop, etc).
Covers the full documented API surface: players, groups, competitions, records, deltas,
name changes, and efficiency (EHP/EHB) — 54 tools total, all prefixed wom_.
Setup
npm install
npm run buildOptionally copy .env.example to .env and set WOM_API_KEY (raises the rate limit from
20 to 100 requests/60s — request one in the WOM Discord).
Mutating actions (create/edit/delete groups & competitions) don't need this key; they use a
per-resource verificationCode returned when you create that resource.
Running locally
npm run dev # run directly with tsx, no build step
npm run inspector # open the MCP Inspector against the server for manual testingRegister with Claude Code
claude mcp add wiseoldman -- node /path/to/wiseoldman_mcp/dist/index.js(Run npm run build first so dist/index.js exists. Re-run the build after pulling changes.)
Register with Claude Desktop
Add to claude_desktop_config.json:
{
"mcpServers": {
"wiseoldman": {
"command": "node",
"args": ["/path/to/wiseoldman_mcp/dist/index.js"],
"env": { "WOM_API_KEY": "..." }
}
}
}Project layout
src/womClient.ts— thin fetch wrapper around the WOM REST API (auth headers, error normalization). Nothing here is MCP-specific.src/enums.ts— reference lists (skills, bosses, periods, etc) baked into tool descriptions. Kept as plain strings rather than strict zod enums, since WOM adds new bosses/activities over time — the live API remains the source of truth for validation.src/toolHelpers.ts— shared result/error formatting for tool handlers.src/tools/*.ts— one file per API resource, each registering its tools on theMcpServerinstance.src/index.ts— wires everything together and connects over stdio.
Roadmap: remote hosting with OAuth (Authentik)
Right now this only runs locally over stdio, which is fine for a single user's local clients. Deploying it as a shared/remote server later will need:
Swapping
StdioServerTransportfor the SDK'sStreamableHTTPServerTransport, run behind an actual HTTP server (e.g. Express/Hono).An OAuth layer in front of it (the MCP spec expects OAuth 2.1 with PKCE for remote servers) — Authentik can act as the authorization server; the transport setup would validate the bearer token per-request against Authentik's introspection/JWKS endpoint.
The
womclient and all tool registration code is transport-agnostic already, so none ofsrc/tools/*orsrc/womClient.tsshould need to change — onlysrc/index.tsand a new auth-checking layer around it.
Not implemented yet — flagging so the current structure doesn't need rework when we get there.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/jhaenen/wiseoldman_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server