DEV Community: PromptOT

PromptOT MCP: Manage and version LLM prompts from your AI tools

PromptOT — Sat, 18 Jul 2026 11:03:46 +0000

PromptOT MCP: Manage and version LLM prompts from your AI tools

Prompts often start as simple strings in code.

Then the product grows.

You add a better system prompt. Then a guardrail. Then a different version for production. Then a customer-specific variable. Then test cases. Then someone wants to roll back to the version from last week.

At that point, prompts are no longer just text. They become part of the application layer.

That is the problem PromptOT is built around.

PromptOT is a prompt management platform for LLM applications. It lets teams build, version, evaluate, and deliver system prompts through an API without redeploying the app every time a prompt changes.

The new part I want to share is the PromptOT MCP server.

It lets you manage your PromptOT prompts directly from MCP-compatible AI tools like Claude Desktop, Cursor, Codex, ChatGPT, claude.ai, and other clients.

What is MCP?

MCP stands for Model Context Protocol.

It gives AI tools a standard way to connect with external systems. Instead of only chatting with an assistant, you can give the assistant controlled tools for reading and changing real application data.

For PromptOT, that means your AI assistant can help with things like:

listing prompts
editing prompt blocks
managing variables
saving drafts
publishing versions
rolling back versions
creating test cases
comparing prompt versions

The goal is not just to generate prompt text. The goal is to manage prompt operations as part of the development workflow.

What PromptOT does

PromptOT lets you structure prompts as versioned assets instead of hardcoded strings.

A prompt can be composed from typed blocks, such as:

role
context
instructions
guardrails
output format

It also supports variables like:

{{customer_name}}
{{tone}}
{{product_context}}

Those variables can be resolved when your application fetches the prompt.

So instead of redeploying your app every time you adjust a prompt, your app can fetch the latest published prompt through an API.

What the MCP server adds

The PromptOT MCP server exposes 23 tools across five areas:

Area	What you can do
Prompts	List, get, compile, create, update, and delete prompts
Blocks	Create, edit, delete, and reorder typed prompt blocks
Variables	Manage `{{key}}` placeholders
Versions	Save drafts, publish, diff, and roll back
Test cases	Create and manage prompt evaluation inputs

That makes it possible to work on prompts from inside the AI tools developers already use.

For example, you can ask your assistant to:

Show me the current support-agent prompt.

Then:

Add a stricter refund-policy guardrail as a new block, but save it as a draft.

Then:

Compare this draft with the currently published version.

Then:

Publish the draft if the changes look safe.

The assistant is not just writing text in a chat window. It is using scoped PromptOT tools to work with real prompt objects.

Installation

The MCP package is available as:

npx @prompt-ot/mcp

You will need a scoped PromptOT API key from your PromptOT dashboard.

Claude Desktop

Add this to your Claude Desktop MCP config:

{
  "mcpServers": {
    "promptot": {
      "command": "npx",
      "args": ["-y", "@prompt-ot/mcp"],
      "env": {
        "PROMPTOT_API_KEY": "pot_...",
        "PROMPTOT_MCP_CLIENT": "claude-desktop"
      }
    }
  }
}

PromptOT also provides a desktop extension bundle for Claude Desktop:

https://www.promptot.com/downloads/promptot.mcpb

Cursor

Add this to your Cursor MCP config:

{
  "mcpServers": {
    "promptot": {
      "command": "npx",
      "args": ["-y", "@prompt-ot/mcp"],
      "env": {
        "PROMPTOT_API_KEY": "pot_...",
        "PROMPTOT_MCP_CLIENT": "cursor"
      }
    }
  }
}

Codex CLI

Add this to your Codex config:

[mcp_servers.promptot]
command = "npx"
args = ["-y", "@prompt-ot/mcp"]
env = { PROMPTOT_API_KEY = "pot_...", PROMPTOT_MCP_CLIENT = "codex-cli" }

Hosted MCP

PromptOT also has a hosted MCP endpoint:

https://mcp.promptot.com/mcp

This can be used by clients that support hosted MCP connections with OAuth.

Example workflow

Here is a realistic workflow.

You are building an AI support agent. The current system prompt is hardcoded in your app. Every time you want to update the refund policy, escalation rules, or tone, you need to change code, open a pull request, wait for CI, and deploy.

With PromptOT, you can move that system prompt into a managed prompt.

You split it into blocks:

Role
Context
Instructions
Refund policy
Escalation rules
Output format
Guardrails

Your app fetches the published version through the PromptOT API.

Then, with the MCP server connected, you can ask your AI tool to help manage changes:

Open the support-agent prompt and create a draft version with a stricter escalation rule for billing-related complaints.

Then:

Show me the diff between the published version and this draft.

Then:

Create a test case for an angry customer asking for a refund outside the refund window.

Then:

Publish the draft.

This keeps prompt work closer to the tools where developers and AI engineers already think through changes.

Why this matters

Prompt management gets messy because prompts sit between product, engineering, support, and evaluation.

They are not exactly code, but they affect production behavior like code.

A few things become important quickly:

Who changed this prompt?
What changed between versions?
Which version is live?
Can we roll back?
Can we test this prompt before shipping it?
Can we update prompts without redeploying the app?
Can AI tools help maintain prompts safely?

PromptOT is designed around those questions.

The MCP server adds another layer: instead of only clicking through a dashboard, you can let your AI development tools interact with the prompt system directly.

Safety model

PromptOT uses scoped API keys for MCP access.

That matters because an MCP server can expose powerful actions. PromptOT separates tool capabilities so clients can understand whether a tool is read-only, destructive, or idempotent.

The goal is to make prompt operations useful without turning every assistant action into an unsafe production change.

Final thought

LLM apps are moving from simple prompt strings to real prompt infrastructure.

Once prompts need versions, variables, publishing, rollback, evaluations, and team workflows, they deserve their own operational layer.

PromptOT MCP is one step toward making prompt management feel native inside the AI tools developers already use.

Hardcoding LLM prompts is fine until it isn't. Here's what we built instead.

PromptOT — Tue, 30 Jun 2026 06:53:54 +0000

I had a bug last month that took most of a Saturday to find. A support bot we shipped started promising refund timelines that didn't match policy. Customer complaints, frantic Slack messages, the usual.

The prompt had changed three weeks earlier. Nobody could remember why. Git blame pointed to a one-line edit inside a 200-line SYSTEM_PROMPT constant. No PR description, no diff worth reading.

That's when I knew I'd been writing prompts wrong for the last two years.

PromptOT - Prompt Management Platform

Compose prompts from typed blocks, version safely, and deliver to your apps via API. The prompt management platform built for AI engineering teams.

promptot.com

Prompts are code, but we treat them like Notion docs

A typical system prompt for anything useful crams five things into one string:

You are a friendly support agent for Acme. Use this knowledge: {{kb}}.
Follow escalation rules. Never share internal ticket IDs. Reply in plain
text, two to four paragraphs.

That's a role, context, instructions, guardrails, and an output format all jammed together. When the PM wants to soften the tone, they're editing the same string an engineer uses to update the knowledge base. When security adds a guardrail, it lands inches from the response format. One bad edit and every reply ships broken.

We wouldn't write code this way. So why are prompts always a 200-line const somewhere in lib/?

What I built

PromptOT is a prompt management platform. The core idea is small: typed blocks instead of flat strings.

You break a prompt into pieces. Each piece has a type — role, context, instructions, guardrails, output_format, custom. Each one is independently editable, can be toggled on or off, and has its own version history. The compiler joins them into a single prompt string at delivery time.

Block 1 — role:          "You are a support agent for Acme..."
Block 2 — context:       "Knowledge base: {{kb}}..."
Block 3 — instructions:  "1. Acknowledge the issue..."
Block 4 — guardrails:    "Never share internal ticket IDs..."
Block 5 — output_format: "Plain text, two to four paragraphs..."

Now the PM edits one block. The security review adds a guardrail without touching anything else. Each save is a version. Publishing a version makes it immutable. If something breaks in prod, you roll back from the dashboard in two clicks.

The delivery layer

Apps fetch the compiled prompt through a simple API. Production keys return the published version. Development keys return whatever draft is currently being iterated on. Variables resolve at fetch time:

curl https://api.promptot.com/api/v1/prompts/support-bot/compiled \
  -H "Authorization: Bearer pk_live_..." \
  -d '{"customer_name": "Maya", "kb": "..."}'

That's it. No SDK to install. No prompt strings sitting in your codebase. Updating a prompt does not require a deploy.

The part I'm proudest of

PromptOT ships an MCP server with 23 tools, so your AI assistant can manage prompts for you. I can be in Claude Desktop or Cursor and say:

Read my support-bot prompt and add a guardrail about not promising refund timelines.

Claude calls get_prompt, drafts the change, and calls save_draft_version. I review the diff and publish. The whole loop happens in chat. No tab-switching, no dashboard.

claude.ai and ChatGPT connect via OAuth, so they never see a raw key. Other clients (Claude Desktop, Cursor, Codex CLI, Windsurf, Zed) get a scoped install snippet from the dashboard.

Try it

Free tier covers most side projects — 3 projects, 5 prompts each, 1,000 API calls a month, MCP included. No credit card.

Site: promptot.com
Docs: promptot.com/docs
MCP install: promptot.com/docs/mcp/install

If your LLM prompts currently live as constants in a TypeScript file with a TODO from six months ago, you'll know what this fixes.

What's the worst prompt bug you've shipped to production? Curious which patterns repeat.

DEV Community: PromptOT

PromptOT MCP: Manage and version LLM prompts from your AI tools

PromptOT MCP: Manage and version LLM prompts from your AI tools

What is MCP?

What PromptOT does

What the MCP server adds

Installation

Claude Desktop

Cursor

Codex CLI

Hosted MCP

Example workflow

Why this matters

Safety model

Links

Final thought

Hardcoding LLM prompts is fine until it isn't. Here's what we built instead.

PromptOT - Prompt Management Platform

Prompts are code, but we treat them like Notion docs

What I built

The delivery layer

The part I'm proudest of

Try it