Cursor's Composer and Chat both read Markdown files in your project as context. Convert a spec PDF, drop the .md alongside your source, and the AI treats it as something to follow — not something to look up.
Cursor's mental model is the codebase: files in your repo are first-class context, anything outside is one-off. A PDF spec opened in a tab is invisible to the AI. Convert that PDF to Markdown, save it as `docs/spec.md`, and Cursor will reference it, paraphrase it, and follow its instructions exactly the same way it follows your README. For API specs, design briefs, or vendor documentation, this is the difference between Cursor producing accurate code and Cursor guessing.
Drop your PDF on t0md, hit Download .md, save it under your repo (a `docs/` or `specs/` folder works well). In Cursor, @-reference the file or just mention its path in Composer — the model picks it up. For repo-wide AI features (codebase search, Composer multi-file edits), the conversion only needs to happen once: the .md sits in git alongside your code and travels with the project.
Yes — Cursor supports MCP. Add t0md as a server and Composer can call the conversion tool inline. For one-off PDFs, though, the manual .md-in-repo flow is often simpler and the file stays in version control.
Usually yes. A Markdown spec is plain text — it diffs cleanly, reviews like code, and the AI can reference any version of it. Commit the .md, optionally keep the .pdf out via .gitignore.
Yes. Cursor indexes Markdown files in your project by default. Once it's in the repo, you can @-reference it or rely on Composer to find it.