# Package Naming: Brainstorm & Selection

## Critical Finding

`docling-mcp` is **taken** — by IBM Research Zurich, the team that built Docling itself. It's a full-featured package at v1.3.2 on PyPI. This isn't a squatter; it's the upstream author. The naming strategy must go a different direction entirely. The pitch shifts from "Docling for Claude" to "one tool, zero config, five minutes."

---

## Top Six

| Rank | Name | 12-Word Pitch | Known Conflicts | Risk |
|------|------|---------------|-----------------|------|
| 1 | `pulp-mcp` | Layout-aware PDF to markdown; raw material for Claude's reasoning. | `pulp` exists (unrelated audio tool); `pulp-mcp` clear | Low |
| 2 | `folio-mcp` | One command converts any PDF into structured, reasoned markdown. | `folio` exists (Node.js CMS); `folio-mcp` not on PyPI | Low |
| 3 | `clearpage` | Like the LaTeX command: clears the layout, reveals the clean text. | Not on PyPI; niche LaTeX reference lands with the right crowd | Low |
| 4 | `pdf-porter` | Carries your PDF across the gap between print layout and LLMs. | Not on PyPI; "porter" is a common word, low collision risk | Low |
| 5 | `unfold-mcp` | Unfolds structure buried inside every PDF, in one tool call. | `unfold` exists (data tool, unrelated); `unfold-mcp` clear | Low |
| 6 | `pageflow` | Restores correct reading order from PDFs Claude can't parse alone. | `pageflow` exists on PyPI (Ruby CMS binding); real collision | Medium |

---

## All 32 Candidates

### Functional / Descriptive

1. `pdf-to-md` — literal, findable; conflicts with markpdf family
2. `pdf-porter` — porter as in carry/transform; pleasant and clear
3. `papyrus` — ancient document material; evocative but unrelated to MCP
4. `papyrus-mcp` — same with MCP suffix; cleaner
5. `folio-mcp` — folio = document leaf; elegant, archival connotation
6. `folio` — same without suffix; shorter but more ambiguous
7. `pagemark` — mark the page; also sounds like bookmark, which confuses
8. `pagemind` — page + mind; slightly precious
9. `paperback-mcp` — unexpected, fun, implies something approachable
10. `readpaper` — functional but sounds like a research reading app
11. `pdfmind` — direct; no obvious conflicts but not very evocative

### Transformation Verbs

12. `unfold-mcp` — unfolding structure within a document; clean metaphor
13. `parse-pdf` — nothing subtle; findable but forgettable
14. `distill-pdf` — distillation as essence extraction; slightly overloaded word
15. `render-md` — render to markdown; technical but clear
16. `pdf-render` — same reversed; less natural

### Layout / Structure Emphasis

17. `layoutread` — layout-aware reading; accurate but clunky
18. `structpdf` — structured PDF extraction; sounds like a variable name
19. `pdfstructure` — same reversed; no better
20. `clearpage` — LaTeX command for page break; here means clarity, clean slate
21. `pageflow` — reading order, flow of content; real PyPI conflict
22. `colbreak` — column break; insider joke for the LaTeX/typesetting crowd

### Claude / MCP Context

23. `claude-pdf` — clear but couples the package to a specific client
24. `mcp-pdf` — descriptive but generic; won't age well
25. `mcp-paperwork` — playful; might confuse enterprise users
26. `mcp-reader` — too vague to be useful
27. `mcp-page` — same problem

### Wordplay / Personality

28. `flatpaper` — flattening a PDF into text; also sounds like flatbread, which is fine
29. `pulp` — paper pulp; raw material; also Pulp Fiction; short and memorable
30. `pulp-mcp` — same with MCP context; best of the bunch
31. `ledger-mcp` — ledger as record/document; too finance-coded
32. `folio-reader` — folio as archival document term; pleasant but passive

---

## Reflections

The naming exercise revealed something useful: the obvious names are gone, and that's fine.

`docling-mcp` being taken by IBM Research is the best possible outcome short of the name being free. It means the upstream team ships their own MCP server. That changes the product question entirely. You're not building the official integration — you're building an opinionated, minimal, single-tool wrapper for people who don't want the full Docling MCP surface area. That's a legitimate niche, but it needs to be stated in the README. The pitch becomes "one tool, zero config" rather than "Docling for Claude."

The naming clusters exposed a real tradeoff. Functional names (`parse-pdf`, `pdf-porter`) are findable but forgettable. Evocative names (`pulp`, `folio`, `clearpage`) are memorable but require a moment's explanation. For a developer tool distributed by word of mouth on GitHub and Mastodon, memorability beats SEO. People share things they can describe in a sentence.

`pulp-mcp` wins because it's short, has no real conflict, carries the right connotation (raw material, unprocessed content), and is slightly fun without being cute. `folio-mcp` is the safer, more neutral choice. `clearpage` is the most elegant but requires knowing LaTeX to appreciate the joke.

One pattern worth noting: the clean namespace lives almost entirely in the `[word]-mcp` compound form. The single-word space is picked over. If you plan to publish more MCP tools, a consistent `-mcp` suffix becomes a personal namespace by convention — no registration required.

Given that IBM's `docling-mcp` exists and is well-maintained, the README should probably reference it directly: "if you want the full Docling toolset, see docling-mcp; this package does one thing." That's not weakness — it's good documentation, and it positions the tool honestly against the upstream.