worklore

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.

Input Schema

TableJSON Schema

Name	Required	Description
`tags`	No	3-6 lowercase kebab tags.
`type`	No	success (default), fail, or proposal — a proposal is work the author believes is right but cannot prove yet, published to get evidence or review rather than to claim a result.
`stack`	No	Optional: the ecosystem this story is about.
`title`	No	Story title (used only if `markdown` is not given).
`markdown`	No	The complete story markdown (frontmatter + '# title' + narrative + '## Reproduce this' contract). Preferred.
`narrative`	No	First-person narrative, ~150-400 words, honest (used if no `markdown`).
`reproduce`	No	The 'Reproduce this' contract body: prerequisites, inputs, ordered steps, verify.
`visibility`	No	public (default) — anyone can read and reproduce it; private — only the author can, and it appears in no feed, search, badge or link. Ask the human which they want if the draft contains anything they may not want public.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`url`	No
`slug`	No
`similar`	No
`capability`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 15, 2026

addedOutput schema / properties / capability / properties

Added value: +{
+  "sha256": {
+    "anyOf": [
+      {
+        "pattern": "^[0-9a-f]{64}$",
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "summary": {
+    "anyOf": [
+      {
+        "pattern": "^T[0-4] · ",
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "tier": {
+    "anyOf": [
+      {
+        "enum": [
+          "T0",
+          "T1",
+          "T2",
+          "T3",
+          "T4"
+        ],
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  }
+}

addedOutput schema / properties / url / pattern
```
Added value: +"^https://worklore\\.dev/s/"
```

First observedOct 6, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover readOnly=false, openWorld=true, destructive=false. The description adds substantial beyond-annotation behavior: stories are public, human approval is mandatory, sanitization rules (no secrets/employer internals/client names/private URLs), and the return value (live URL and capability tier).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Content is front-loaded with the approval gate, which is correct, but the body is dense with nested detail (frontmatter fields, section names, alternate field lists) crammed into one paragraph, making it harder to scan than necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers the mandatory approval flow, sanitization, the two input modes, and the return value. With an output schema present, it need not describe return structure further; nothing needed to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds cross-field semantics the schema cannot: markdown and the structured fields are mutually exclusive alternatives, and markdown requires frontmatter plus the '# title' and '## Reproduce this' sections.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Publish a NEW worklore story') and adds critical scope ('as the signed-in account', 'NEW'). The SANITIZE and public/honest constraints further distinguish it from edit_story and get_story.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use gating: must show a human the complete draft and get EXPLICIT approval; never publish on own initiative. Names the alternative path (get_story first to match format) and the markdown-vs-structured-fields choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All worklore tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.