MCP Server

The dot•requirements MCP server connects your AI chat app — Claude, or another MCP-capable assistant — to your requirements. Describe a feature in chat, and the assistant writes the spec into your workspace, where it’s published, has its own URL, and can be pulled into any repo on the project.

Use it when you’re already talking a feature through and want the result captured without switching to another tool. What you work out in the conversation becomes a requirements document the rest of your team can build from.

Connect

Add a custom connector in your chat app pointing at:

https://app.dotrequirements.io/mcp

In Claude: Settings → Connectors → Add custom connector. You’ll sign in with your dot•requirements account.

Name it with plain letters — Dotrequirements, not dot•requirements. If the name you give the connector contains a bullet, a dot, or a curly apostrophe, Claude will show it as connected and list all its tools under Settings, but never actually use them in a conversation. There’s no error to go on, so it’s worth getting right the first time. (Already hit this? Remove the connector and add the same URL again under a plain-letters name — your tool permissions carry over.)

No account yet? The first time you connect, it creates your account and workspace for you, so you start with a team and a project.

What you can do

You don’t run commands. You talk to your assistant, and it uses the MCP server on your behalf:

• Ask what’s specified and how well it’s tested. Things like “what do we have for checkout?” or “which requirements are untested on main?”. The answers come from your team’s specs and test runs.
• Pull up a spec to review together. Ask to see a document — “show me the login spec” — and it appears in the conversation as styled requirement cards, the way it looks in the composer, with a link back to the editor.
• Draft a spec and publish it. The assistant writes it up as a requirements document and gives you a link to share.
• Get style feedback before you ship. The same review you’d run in the web app or CLI, on your draft.

What it will and won’t do

• It asks before it writes. Publishing or editing a document goes through your chat app’s approval prompt, so nothing changes in your workspace unless you approve it. Turn on “always ask” if you want to confirm every write.
• Writing is live, the way editing a Notion page or a Linear issue is. There’s no draft-then-publish step; each save publishes a new version.
• It won’t overwrite a teammate’s work. If a document changed since the assistant last read it, the edit is rejected and it re-reads before trying again. It leaves unpublished drafts in the web editor alone.
• It only reaches your own projects. The MCP server exposes exactly what your account already has access to, and nothing else.

A typical session

1. “What do we have specced for checkout so far?” The assistant pulls up the relevant requirements and their coverage.
2. You talk through the new feature, and the assistant drafts a spec in the conversation.
3. “Check the style before we save it.” It reviews the draft against your project’s style rubric.
4. “Ship it.” It publishes the spec, shows you the finished document as requirement cards, and gives you a link to share.

Developers then sync it into the repo with dotreq sync, and the requirements drive implementation and tests. See the Agent Workflow.

Coverage, not just documents

The MCP server reads the same data as the web app, so coverage questions work from chat too. Ask “which checkout requirements are untested on main?” and the answer comes from your team’s test runs.