Loading ToolBench
Cross-platform MCP server that wraps ZMediumToMarkdown so LLMs can read or download Medium posts as Markdown.
Three tools with explicit schemas and detailed descriptions. Tool naming follows verb_noun pattern (read_, download_, validate_). Descriptions are comprehensive (150-300 chars) and include usage guidance. Input schemas are present with type and description for all parameters. However, output schemas are not documented in the source code, and error handling lacks structured recovery guidance. Tool composition is sound, each has a single responsibility. Parameter descriptions are thorough and include format hints (e.g., URL patterns, directory paths).
Download a single Medium post AND its assets (images / iframe thumbnails) to local disk. **Use this tool when the user shares a Medium URL and explicitly wants the post saved to disk, archived, exported, or wants the images downloaded** — accepts medium.com, *.medium.com, and Medium custom-domain publications. Markdown lands in `<output_dir>/Output/zmediumtomarkdown/<date>-<slug>.md`; images go into `Output/zmediumtomarkdown/assets/<post_id>/`. Re-runs are skip-if-unchanged. Plain (non-Jekyll) layout. Defaults to writing under the current working directory. Use `read_medium_post` instead if the user just wants to read / summarize / discuss the post in chat without files on disk.
Fetch a single Medium post by URL and return its full content as Markdown. **Use this tool whenever the user shares, mentions, asks to read, summarize, translate, or analyze a URL that points to a Medium post** — including medium.com, *.medium.com, and Medium publications on custom domains. If the URL ends in a 12-char lowercase hex slug suffix like `-a1b2c3d4e5f6`, it is almost certainly a Medium post regardless of host; pass it here. Image references in the returned Markdown stay as remote URLs (nothing is downloaded; use `download_medium_post` if you need files on disk). Public posts work with no configuration. The response prepends a step-by-step recovery script when Medium returns only the public preview (paywalled).
Inspect the dependency state and (optionally) run a live test request. Use this after the user populates the gem cookie cache, to confirm the configuration before re-issuing the user-facing request. Pass `test_url` (with the URL the user is trying to read) to verify cookies grant access.
Output schemas not documented. Tool descriptions mention what is returned (Markdown, files, status) but do not specify the structured response schema (fields, types, pagination). LLMs cannot plan downstream operations without knowing response structure.
Error handling lacks recovery guidance. Descriptions mention 'recovery script' and 'step-by-step' instructions for paywalled/Cloudflare blocks, but the actual error response structure and actionable guidance are not visible in the source. LLMs need explicit 'what to do next' in error messages.
validate_setup tool purpose is unclear. Description says 'inspect dependency state' and 'run live test' but does not explain when an LLM should call it vs. calling read_medium_post directly. Dependency validation is a setup concern, not a runtime tool, consider moving to server initialization.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Parameter 'output_dir' in download_medium_post accepts '~/...' but does not specify tilde expansion behavior or validation. LLMs may pass literal '~' strings. Add explicit format constraint: 'Absolute path or ~/... (tilde expanded by server).'
No pagination or result-limiting parameters. If a Medium post contains thousands of images or very long content, response could exhaust context window. No documented limit on returned content size or guidance on chunking.