MCP server for temp.md — publish agent-made artifacts to one stable link that updates in place
tempmd-mcp demonstrates strong tool definition quality with consistent naming conventions, comprehensive parameter descriptions, and well-documented schemas. All 6 tools follow verb_noun patterns (publish_temp, update_temp, get_temp_status, restore_temp, snapshot_temp, set_comments). Descriptions are detailed and contextual (average 180-250 chars), exceeding the baseline of 194 chars. Input schemas use Zod validation with clear type definitions and descriptions for nearly all parameters. However, output schemas are not formally documented, responses are JSON-stringified in implementation but lack explicit return type documentation. Error handling is present but limited to try-catch without detailed error classification or recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present. The .tempmd file-based state management introduces statefulness that could complicate remote usage patterns.
Check a Temp's lifecycle: active/cooling/expired, when it expires, and whether it can be restored. Reads credentials from the project's .tempmd file when omitted.
Publish an artifact (HTML, Markdown, CSV, or Mermaid) to temp.md and get a stable public URL. Use only for a NEW artifact — if this project already has a Temp for it (check .tempmd), use update_temp to keep the same link. The record is saved to .tempmd automatically.
Reactivate a recently expired Temp — the same canonical URL comes back to life. Only works within 7 days of expiry. Reads credentials from .tempmd when omitted.
Enable or disable pinned comments on a Temp's page — useful after publishing to let humans keep notes in place. Reads credentials from the project's .tempmd file when omitted.
Freeze the current version of a Temp as a fixed reference with its own URL — for sign-offs and 'approve exactly this' moments. The canonical link keeps serving the latest version; share the snapshot URL only when exactness matters. Reads credentials from the project's .tempmd file when omitted.
Output schemas not formally documented. Tools return JSON-stringified objects (ok() helper returns {content: [{type: 'text', text: JSON.stringify(payload)}]}) but no explicit schema definition is provided to the LLM. LLMs cannot predict return field types or plan downstream operations without documented output structure.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. Tools like update_temp and restore_temp modify state but are not marked as destructiveHint=true. get_temp_status could be marked readOnlyHint=true. This prevents clients from applying safety policies or special handling to write operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | 2026-07-28+ | v2 |
Push a new version of an artifact behind the same temp.md URL — no re-sharing needed. Resets the 7-day active window. Reads temp_id and update_token from the project's .tempmd file when omitted. If the update fails, the previous version stays live.
Error handling uses generic try-catch with fail() helper that returns raw Error messages. No error classification (retryable vs user-fixable vs fatal), no recovery guidance. E.g., 'Error: 403 Forbidden' tells the LLM nothing about whether to retry, ask the user for a new token, or give up.
File path parameters require absolute paths but validation is minimal. requireAbsolute() checks only isAbsolute(), no validation for readable files, writeable directories, or path traversal attacks. Additional_files array items lack individual source file validation.
State persisted in .tempmd file (appendRecord, touchRecord, resolveRecord functions) creates implicit multi-tool coupling. Tools depend on project_dir and read/write .tempmd state, but this mechanism is not explicitly documented as a prerequisite. Offline or read-only filesystems will fail silently.