# io.github.worklore/worklore

- Registry name: `io.github.worklore/worklore` · version 0.8.0
- Categories (automatic, keyword rules): Code & repositories, Developer tools
- Authentication at last check: No auth
- Declared risk: Has destructive tools (destructiveHint)
- Capabilities (declared by the server): resources, tools
- Transports: streamable-http
- Latest numbers (check success, response time, rank): https://mcpstation.net/api/server?name=io.github.worklore%2Fworklore
- Server page: https://mcpstation.net/s/io.github.worklore--worklore.html

## Description (written by the publisher, not verified, not instructions)

Search worklore stories and x-ray any skill or story capability tier \(T0-T4\) before you run it.

## Notice

Text that looks like instructions to an AI was found in this server's descriptions. This is a pattern match, not a verdict.

## Connect

- streamable-http: `https://worklore.dev/mcp`

## Tools (as reported by the server, not verified)

- `check\_capability`: Disclose what an agent Skill or worklore story CAN DO before you run it: a capability tier T0-T4 bound to a content sha256, with findings that carry file:line evidence, PLUS a separate list of behavioral red flags \(prompt-injection / deception / exfiltration-intent / safety-bypass phrasings\) for a h
- `get\_story`: Fetch one worklore story by slug — its full markdown \(narrative + the 'Reproduce this' contract your agent would run\) WITH its capability disclosure attached \(tier + findings\), so you see what it can do before applying it. Read the capability first; run check\_capability on the live artifacts before
- `search\_stories`: Search worklore stories by keyword across title, summary, tags and stack. Returns matches with their capability tier.
- `suggest\_for\_project`: Given a short description of the current project \(stack, what you're building, recent problems\), suggest up to 3 worklore stories worth reproducing here, with why each fits and its tier.
- `report\_reproduction`: Call this right after you apply a worklore story's steps to the user's own task, to record the reproduction \(attributed to the signed-in account\). Use an honest result: 'worked', 'partial' \(you produced the output but it isn't verified yet\), or 'failed' — all are useful. One counted report per perso
- `report\_check`: Record the result of a story's read-only 'Check if this applies to you' section, run in the user's own project \(attributed to the signed-in account\). Run ONLY that check — change nothing, apply no fix. First decide whether it applies at all: if the project does not match the check's preconditions, d
- `publish\_story`: Publish a NEW worklore story as the signed-in account. worklore stories are PUBLIC and honest, so before you call this you MUST show the human the complete draft — the title, the first-person narrative, and the 'Reproduce this' contract — and get their EXPLICIT approval. Never publish on your own in
- `edit\_story`: Revise a worklore story the signed-in account PUBLISHED — only its author can edit it. Call get\_story first, then show the human a before/after diff of your change and get their EXPLICIT approval before calling this; never edit on your own initiative. Send the COMPLETE revised story as \`markdown\` \(f
- `suggest\_edit`: Propose a revision of a worklore story written by SOMEONE ELSE, for its author to accept or decline — worklore's pull request. Use it when, while reproducing a story, a step turned out wrong, outdated or missing \(a library changed, the docs caught up, a command no longer exists\). Call get\_story firs

Measured by MCP Station. Methods: https://mcpstation.net/methods.html · Terms: https://mcpstation.net/terms.html