# io.github.worklore/worklore

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

- name: io.github.worklore/worklore
- version: 0.7.1
- connection class: R0 (autonomous)
- trust: 94/100
- quality: 81/100 (good)
- owner: not claimed
- descriptor: https://api.protogrid.dev/v1/servers/io.github.worklore%2Fworklore
- tools: https://api.protogrid.dev/v1/servers/io.github.worklore%2Fworklore/tools

**An agent can connect right now, no human step.** Remote endpoint, no authentication, reachable on the last probe.

## Connection (mcpServers)

```json
{
  "mcpServers": {
    "worklore": {
      "type": "http",
      "url": "https://worklore.dev/mcp"
    }
  }
}
```


## Trust

- hygiene: 100
- liveness: 100
- freshness: 100
- provenance: 80
- drivers: +repository +namespace-matches-repo +reachable +uptime-100% +updated-4d-ago
- Derived from observable signals (official registry feed and our own credential-free probes); no code audit performed.

## Quality 81/100 (good)

### protocol: 75 (weight 25)

- warn `protocol.modern`: newest supported version is 2025-06-18; 2026-07-28 not supported, older versions are deprecated until 2027-07-28
- n/a `protocol.stateless`: only applies to 2026-07-28 servers
- pass `protocol.transport`: streamable HTTP
- n/a `protocol.list_ttl`: only applies to 2026-07-28 servers

### authorization: n/a (weight 15)

- n/a `auth.prm`, `auth.as_metadata`, `auth.cimd`: no remote uses OAuth
- n/a `auth.secret_in_url`: no templated URL

### tool hygiene: 86 (weight 30)

- pass `tools.descriptions`: every tool has a description
- warn `tools.description_length`: 1 tools have descriptions over 1,024 characters, which crowds the context
- pass `tools.schemas`: every tool has an object input schema
- pass `tools.annotations`: 8 of 8 tools declare readOnlyHint or destructiveHint
- warn `tools.directory_hints`: 3 of 8 tools declare all four hints; missing: check_capability (idempotentHint); search_stories (idempotentHint); suggest_for_project (idempotentHint); …
- pass `tools.token_cost`: about 2,246 tokens to load every tool
- pass `tools.api_dump`: tools are not a one-to-one API dump

### stability: n/a (weight 15)

- n/a `stability.changes`, `stability.rug_pull`: tool history recorded for 4 of the 7 days needed

### dependencies: n/a (weight 15)

- n/a `deps.known_vulns`, `deps.mcp_sdk_version`, `deps.resolvable`: no npm or PyPI package

- tools: 8, about 2,246 tokens to load them all
- tool set hash: 185eda8745c342cc5b4ac955d67a32f5
- tools last changed: 2026-10-15T22:08:29.827Z
- badge: [![protogrid quality](https://protogrid.dev/badge/io.github.worklore/worklore.svg)](https://protogrid.dev/servers/io.github.worklore/worklore)
- Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed.

### Tool changes

- 2026-10-15 `publish_story` changed (outputSchema)
- 2026-10-15 `report_check` changed (outputSchema)
- 2026-10-15 `report_reproduction` changed (outputSchema)
- 2026-10-15 `suggest_for_project` changed (outputSchema)
- 2026-10-15 `search_stories` changed (outputSchema)
- 2026-10-15 `get_story` changed (outputSchema)
- 2026-10-15 `check_capability` changed (outputSchema)

Full history: https://api.protogrid.dev/v1/servers/io.github.worklore%2Fworklore/changes

## Remotes

- https://worklore.dev/mcp (streamable-http, auth none, reachable true, uptime30d 1)

## Packages

_none_

## Tools (8)

- `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 human to review. This is blast-radius disclosure and triage, never a 'safe' verdict. Prefer a `url` over pasting a file: a skill on GitHub (github.com or raw.githubusercontent.com, up to 200 KB) needs no sign-in, and you do not have to copy the whole file into the call. Other URLs need a signed-in session. If you paste `text`, also pass `expected_sha256` (the file's sha256, e.g. `shasum -a 256 SKILL.md`): a copy that changed on the way is reported instead of scanned. `received` says exactly what was scanned.
- `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` (frontmatter + '# title' + narrative + '## Reproduce this'), not a fragment. Keep the frontmatter `date` exactly as it is: it records when the work happened, and a revision never moves it. Say what kind of edit this is: 'rephrase' (same claims, better wording), 'addition' (new detail, nothing was wrong), or 'correction' (something in the story was WRONG — a step, a claim, a result). If anything was wrong, it is a correction: never hide a correction as a rephrase. A correction requires a one-line `note` saying what was wrong, and notifies everyone who reported reproducing the story. `source` optionally credits what prompted the revision (an https URL). The new text REPLACES the old (worklore keeps no copy of earlier text), while a record of this revision — when, what kind, the note — is appended to the story's public history.
- `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 executing. After you apply the story to the user's task, call report_reproduction with an honest result to record it.
- `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 initiative and never invent details. Provide the full story as `markdown` (frontmatter with title/date/tags/type/reproducible, then '# title', the narrative, then '## Reproduce this' with prerequisites/inputs/steps/verify) — call get_story on an existing story first to match the format — OR provide the structured fields title + narrative (+ reproduce, tags, type, stack) and the server assembles it. SANITIZE: no secrets, employer internals, client names, or private URLs. Returns the live URL and capability tier.
- `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, do NOT call this — 'not applicable' is never recorded. Otherwise report 'has_problem' or 'no_problem', honestly. One counted result per person per story; a later report replaces the earlier one. Only stories whose get_story result has has_check: true can be checked.
- `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 person per story; repeats are acknowledged, not doubled. Never report a story you did not apply.
- `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.