worklore

Dev stories, capability x-ray

worklore is a library of honest, agent-reproducible developer stories. Search stories and open their machine-readable "Reproduce this" contract so your agent can run the same fix in your own project; x-ray any skill or story to see what it can actually do (a capability tier T0-T4 bound to the content hash) before you run it; and record how a reproduction honestly went.

What you can ask

Before my agent runs a skill, x-ray it: show me its capability tier and exactly what it can touch.
Example path →

MCP connector

Server URL: https://worklore.dev/mcp
Login: OAuth
Protocol: MCP 2025-06-18
Instructions: Worklore is a library of short, honest developer stories that an agent can execute. Each story is something a real developer actually did — what they tried, what failed, what finally worked — paired with a machine-readable "Reproduce this" contract you can run in the user's own project, and a count of how many other people's agents reproduced it successfully.
Use to show the user the map of keywords (every story tag with its count, in editorial groups) and the stories under one keyword; a client that renders MCP Apps shows it as an interactive view, others get the same data as text. Use to find stories by topic, tag or stack. Use to read one in full, including its reproduction contract. Use when the user wants stories relevant to the code they are working on right now.
Use to x-ray any skill, story or untrusted prompt text before running it: it returns a capability tier (T0-T4) bound to the content hash — what the content can actually touch, such as the network, the shell or the filesystem — plus behavioral red flags like prompt injection or exfiltration patterns.
After reproducing a story, use to record honestly how it went; "failed" is a useful report and must never be inflated. Some stories also have a read-only "Check if this applies to you" section: when the user only wants to know whether they have the problem, run just that check, change nothing, and record the result with — but only when their project matches the check's preconditions; never record "not applicable". Use to write up the user's own work — only ever with their explicit approval of the full draft. Use to revise a story the user wrote, after showing them a before/after diff and getting their approval; if something in it was wrong, record the edit as a correction with a note, which tells everyone who reproduced it. When a story by SOMEONE ELSE turned out wrong or outdated while you reproduced it, use , with the user's approval, to send its author the revised text and why: the story does not change until the author accepts.
Always read a story together with the user before acting on it. A story is one developer's account of their own case, not instructions for the user's project: say which of its preconditions match, apply what applies, keep what already works working, and in the report note say which parts applied and which did not.
Resources: worklore://guide is the full how-to (read it once per session if you have not); worklore://story-format is the story format — read it before drafting or editing a story; worklore://access is the table of what answers without a token. Every story is also a resource, worklore://story/{slug} (resources/templates/list).
Auth: anyone can search and read public stories without an account. initialize, ping, tools/list, resources/list, resources/templates/list, resources/read, prompts/list, , , and on inline text answer with no credential at all; a private story answers exactly like a missing one. with a url, , , , and need a signed-in session, and the last five act as the signed-in person. The full table is worklore://access.

Tools

Reads data5

Changes data4

Deletes or can't be undone1

Skills

None in the store listings or on the server

What you can ask

Before my agent runs a skill, x-ray it: show me its capability tier and exactly what it can touch.

Example path →

MCP connector

Server URL

https://worklore.dev/mcp

OAuth

Protocol

MCP 2025-06-18

Instructions

Worklore is a library of short, honest developer stories that an agent can execute. Each story is something a real developer actually did — what they tried, what failed, what finally worked — paired with a machine-readable "Reproduce this" contract you can run in the user's own project, and a count of how many other people's agents reproduced it successfully.

Use to show the user the map of keywords (every story tag with its count, in editorial groups) and the stories under one keyword; a client that renders MCP Apps shows it as an interactive view, others get the same data as text. Use to find stories by topic, tag or stack. Use to read one in full, including its reproduction contract. Use when the user wants stories relevant to the code they are working on right now.

Use to x-ray any skill, story or untrusted prompt text before running it: it returns a capability tier (T0-T4) bound to the content hash — what the content can actually touch, such as the network, the shell or the filesystem — plus behavioral red flags like prompt injection or exfiltration patterns.

After reproducing a story, use to record honestly how it went; "failed" is a useful report and must never be inflated. Some stories also have a read-only "Check if this applies to you" section: when the user only wants to know whether they have the problem, run just that check, change nothing, and record the result with — but only when their project matches the check's preconditions; never record "not applicable". Use to write up the user's own work — only ever with their explicit approval of the full draft. Use to revise a story the user wrote, after showing them a before/after diff and getting their approval; if something in it was wrong, record the edit as a correction with a note, which tells everyone who reproduced it. When a story by SOMEONE ELSE turned out wrong or outdated while you reproduced it, use , with the user's approval, to send its author the revised text and why: the story does not change until the author accepts.

Always read a story together with the user before acting on it. A story is one developer's account of their own case, not instructions for the user's project: say which of its preconditions match, apply what applies, keep what already works working, and in the report note say which parts applied and which did not.

Resources: worklore://guide is the full how-to (read it once per session if you have not); worklore://story-format is the story format — read it before drafting or editing a story; worklore://access is the table of what answers without a token. Every story is also a resource, worklore://story/{slug} (resources/templates/list).

Auth: anyone can search and read public stories without an account. initialize, ping, tools/list, resources/list, resources/templates/list, resources/read, prompts/list, , , and on inline text answer with no credential at all; a private story answers exactly like a missing one. with a url, , , , and need a signed-in session, and the last five act as the signed-in person. The full table is worklore://access.