DEV Community: PromptOT

Your Prompt Is Production Logic So Why Are You Managing It Like Text?

PromptOT — Wed, 12 Aug 2026 12:03:42 +0000

AI applications often begin with a prompt stored directly inside the codebase:

const systemPrompt = `
You are a helpful customer-support assistant.
Answer the customer clearly and politely.
`;

This works perfectly for an early prototype.

But as the application grows, the prompt becomes more than a string. It starts controlling product behaviour:

What the AI is allowed to say
How it handles sensitive requests
When it should escalate to a human
Which output format it must follow
How reliably it responds to edge cases

At that point, changing a prompt is effectively changing production logic.

Yet many teams continue managing prompts through hardcoded strings, documents, spreadsheets or provider playgrounds.

The problem with hardcoded prompts

Imagine that a product manager wants to make the support assistant more concise.

The change may look harmless:

- Answer the customer clearly and politely.
+ Answer the customer in no more than three sentences.

But that small edit could affect refund explanations, security warnings or escalation instructions.

The code diff tells us what changed, but it does not tell us how the AI’s behaviour changed.

This creates several problems.

Every prompt change requires a deployment

Even a one-line wording update may need a pull request, review, CI pipeline and application deployment.

That makes prompt experimentation unnecessarily slow.

It is difficult to know which prompt is live

Teams may have different versions in source code, staging environments, documents and model playgrounds.

Eventually, someone asks:

Which version is actually running in production?

The answer is often less obvious than it should be.

Rollback is incomplete

Git can restore the previous prompt text, but prompt behaviour also depends on variables, model configuration, test inputs and surrounding context.

Restoring one string does not necessarily restore the complete working state.

Visual diffs cannot predict behavioural regressions

A small wording change can create a large output difference.

Traditional code review remains useful, but prompts also need behavioural testing.

Treat prompts as release artifacts

A production prompt should have a lifecycle similar to application code:

Create → Test → Review → Version → Publish → Monitor → Roll back

The important change is separating the editable draft from the version used by the live application.

A team should be able to experiment without immediately affecting production. When the new version is ready, it can be published deliberately.

If the behaviour regresses, the previous version should remain available for immediate rollback.

Structure improves prompt reviews

Large prompts are difficult to review when everything is stored in one text field.

A more maintainable prompt can be divided into sections:

Role
Context
Instructions
Guardrails
Output format

For example:

Role:
You are a customer-support assistant for {{company_name}}.

Instructions:
Identify the customer’s problem and provide the next appropriate action.

Guardrails:
Never request passwords, card numbers or security codes.

Output format:
Return the category, escalation status and customer-facing response.

This makes changes easier to understand.

If someone modifies the guardrails, reviewers can immediately see that the change affects safety rather than tone or formatting.

Structured blocks are not intended to make prompts more complicated. They make the responsibility of each instruction clearer.

Test behaviour before publishing

Prompt testing should include more than one ideal input.

For a customer-support prompt, a useful test set might contain:

Normal request:
How can I update my billing address?

Edge case:
I was charged twice and need help immediately.

Security case:
Can I send you my password so you can inspect my account?

Off-topic case:
Write a poem about the weather.

Expected behaviour can include:

Correct request classification
Required words or information
Forbidden content
Escalation when appropriate
A valid output structure

These tests will not prove that a prompt is perfect. They provide a repeatable signal that important behaviour has not been accidentally removed.

Delivery should not require redeployment

After publishing a prompt, the application should retrieve the approved version through an API rather than requiring the prompt to be bundled into application code.

Conceptually:

const prompt = await getPublishedPrompt("support-assistant");

A production integration should also consider:

Client-side caching
Request timeouts
Version pinning
A last-known-good fallback
Safe behaviour if the prompt service is unavailable

The objective is to make prompt updates faster without introducing unnecessary runtime risk.

Where MCP fits

Many developers now work from tools such as Claude, Cursor and Codex.

The Model Context Protocol, or MCP, can let those tools interact with a prompt-management system using controlled operations.

For example, a developer could ask their AI client to:

Load the support assistant prompt, create three security test cases,
save a new draft and show me the changes.

MCP does not replace versioning, permissions or review.

It provides another interface to the same governed workflow. Changes should still be attributable, versioned and published deliberately.

What we are building with PromptOT

We built PromptOT around this production-prompt workflow.

It provides a shared workspace where teams can:

Compose prompts using typed blocks
Create reusable variables
Save and compare versions
Maintain test cases
Run prompt evaluations
Publish an approved version
Deliver published prompts through an API
Manage prompt workflows through compatible MCP clients
Roll back when a change causes problems

The aim is not to replace source control.

Application code should remain in Git. PromptOT provides a dedicated lifecycle for the prompts that control AI behaviour and often need to evolve independently from application deployments.

The practical starting point

You probably do not need a prompt-management platform if you have one prompt, one developer and no production users.

The need becomes more visible when:

Multiple people modify prompts
The application contains many prompts
Prompts change frequently
Non-developers contribute to prompt behaviour
A bad prompt change can affect customers
The team needs testing, controlled publishing or rollback

A useful first step is to identify the prompts currently controlling production behaviour.

For each one, document:

Where is it stored?
Who can change it?
Which version is live?
How is it tested?
How would the team roll it back?
What happens if its delivery system is unavailable?

If those questions are difficult to answer, the prompt has probably become a production asset without a production workflow.

Final thought

Prompts may look like text, but in an AI product they often function as application logic.

Once a prompt can affect customers, revenue, safety or operational decisions, it deserves more than a copied string and a hopeful deployment.

It deserves versioning, testing, controlled publishing and a reliable rollback path.

We are actively developing this workflow in PromptOT, and I would be interested to hear how other teams currently manage production prompts.

The Prompt Versioning Nightmare (And How I Finally Fixed It With PromptOT)

PromptOT — Sat, 08 Aug 2026 08:50:28 +0000

If you've shipped anything serious with LLMs, you already know the feeling.

You tweak a prompt. It works better. You commit it. Two weeks later, something breaks in production. You have no idea which version of the prompt is actually running, who changed what, or how to roll back without rewriting three files.

Welcome to the prompt versioning problem.

The Real Problem Nobody Talks About

Prompts are code. They control model behavior the same way a function controls program behavior. But we treat them like magic strings buried inside:

Python files as multi-line f-strings
YAML configs that nobody remembers editing
Notion pages that drift from reality within a week
Slack messages ("hey, use this new system prompt")
A prompts/ folder with 47 versions and zero context

Here's what breaks when prompts live like this:

1. No version history that actually means anything

git blame tells you who changed a prompt, but not why it was changed, whether it was tested, or whether the change made outputs better or worse.

2. No safe rollback

Prod breaks at 2 AM. Which prompt was live yesterday? Was it the one on main, the hotfix branch, or the one that got hardcoded during last week's demo? Good luck.

3. Fragmented reusability

You end up copy-pasting the same "tone of voice" instructions across 12 prompts. Update one, forget the other 11.

4. No environment separation

The prompt in staging is subtly different from prod. You only find out when a customer screenshots the output.

5. Testing is theater

You "tested it" by running it once in a notebook. There's no regression suite, no diff between versions, no way to know if v7 is actually better than v6.

6. Non-engineers are locked out

Your PM knows the prompt is wrong but can't fix a typo without opening a PR and pinging you on Slack.

Sound familiar? Yeah. Same.

Enter PromptOT

I started using PromptOT after getting fed up with maintaining prompts across three services. The pitch is simple: treat prompts like first-class versioned artifacts, with the tooling engineers already expect for code.

Here's what actually clicked for me.

Prompts as versioned entities

Every prompt gets:

A stable ID
A version history (draft to published to rollback-able)
A diff view between any two versions
A published version that's what your app actually pulls at runtime

No more "which one is live?" You publish a version explicitly. That's the one running. Full stop.

v1 (published) --> v2 (draft) --> v3 (published, live)
                                  ^
                                  rollback here if v3 misbehaves

Blocks: prompts you can compose

This was the game-changer for me. Instead of copy-pasting shared instructions across prompts, you define blocks — reusable prompt fragments — and compose them into full prompts.

Change the "tone of voice" block once. Every prompt that references it picks up the update on the next publish.

It's basically DRY, but for prompts.

Variables

Prompts almost always have dynamic parts: user name, product catalog, current date, whatever. PromptOT lets you declare variables explicitly, so the prompt template is clean and the runtime substitution is auditable.

No more string-concatenation spaghetti.

Test cases attached to the prompt

You can attach test cases directly to a prompt. Each test case has inputs and an expected shape of output. Before publishing v7, you run the suite. If v7 regresses on cases v6 passed, you know before your users do.

This is the part I wish I'd had two years ago.

Draft versions

You can save a draft, iterate on it, share the link with a teammate, and only publish when it's actually ready. Draft is not live. Only explicit publish flips the switch.

Compiled prompt endpoint

Your app doesn't care about blocks and variables at runtime — it just wants the final string. PromptOT exposes a "compiled prompt" endpoint that gives you the fully-assembled prompt for the currently published version, with variables filled in.

Your app code goes from:

system_prompt = f"""
You are a helpful assistant for {company_name}.
Your tone should be {tone}.
{fifty_more_lines_of_instructions}
Today's date is {date}.
"""

To:

system_prompt = promptot.get_compiled_prompt(
    prompt_id="customer-support-agent",
    variables={"company_name": company, "tone": tone, "date": today}
)

Prompt logic lives in PromptOT. App code just calls it. Clean.

The Workflow That Finally Works

Here's what my day-to-day looks like now:

PM spots a wording issue. They open the prompt in PromptOT and save a draft. No PR needed.
I review the draft. I see a diff against the published version. I know exactly what changed.
I run the test cases. If they pass, I publish. If they regress, we iterate on the draft.
Published version goes live. App picks it up on the next call — no redeploy.
Something goes wrong? One-click rollback to the previous published version. Prod is stable while we investigate.

That's it. No merge conflicts on prompts. No 2 AM confusion about what's running. No "hey can you push the new prompt for me."

Why This Matters More Every Month

LLMs aren't getting less central to what we build. Every product I've shipped in the last year has 5-20 prompts running behind the scenes. Some have more.

At that scale, treating prompts as loose strings in code isn't sustainable. You need the same primitives you have for code: versions, diffs, rollbacks, tests, reusability.

PromptOT gives you exactly that. It's the piece I didn't know I needed until I had it, and now I can't imagine going back.

Getting Started

If any of this hit close to home, try it:

Sign up at promptot.ai
Create your first prompt
Break it into blocks and variables
Publish v1, then iterate

The mental shift from "prompts are strings" to "prompts are versioned artifacts" takes about a day. The productivity gain lasts forever.

If you've got your own war stories about prompt versioning going sideways, drop them in the comments — I want to hear how everyone else has been suffering through this.

Who Owns the Production Prompt?

PromptOT — Thu, 06 Aug 2026 08:57:45 +0000

A production prompt rarely belongs to one person for long.

An engineer writes the first version. Product changes the tone. Support adds escalation rules. Legal adds restrictions. Another engineer updates the output schema. Six weeks later, everyone has edited the prompt, but nobody truly owns it.

The result is usually one enormous string that looks something like this:

const systemPrompt = `
You are a helpful support assistant...

Follow these product rules...

Never make these claims...

Escalate when...

Return JSON in this exact format...
`;

Technically, it works. Organizationally, it is a mess.

The problem is not only where the prompt is stored. The bigger problem is that several teams own different parts of its behaviour, but the prompt provides no boundaries between them.

One prompt, several owners

Consider a customer-support assistant.

Different parts of its prompt naturally belong to different people:

Role: Product defines the assistant's purpose and personality.
Context: Support or operations provides policies and domain knowledge.
Instructions: Product and engineering define the workflow.
Guardrails: Legal, security, and support define what must never happen.
Output format: Engineering owns the contract consumed by the application.

When all of this lives inside one text field, every edit becomes risky.

A marketing teammate changing the tone can accidentally modify a formatting instruction. An engineer updating JSON fields can remove a policy sentence. Legal cannot easily review only the restrictions that matter to them.

The prompt is shared, but its ownership is invisible.

Stop treating the prompt as one document

A more maintainable approach is to compose a prompt from typed blocks.

role:
  You are a customer-support assistant for Acme.

context:
  Refunds are available within 30 days of purchase.

instructions:
  Answer the customer's question and suggest the next action.

guardrails:
  Never promise a refund before verifying the purchase date.
  Escalate threats, chargebacks, and legal complaints.

output_format:
  Return JSON containing message, category, and needs_escalation.

The compiled prompt sent to the model may still be plain text. The important difference is how the team authors and manages it.

Each block now has a clear purpose. Reviews become more focused, changes are easier to understand, and ownership can follow the structure of the prompt.

Use ownership boundaries, not editing restrictions

The goal is not to prevent non-engineers from touching prompts.

Domain experts often understand the desired behaviour better than the engineer implementing the application. Support knows which questions cause trouble. Legal knows which claims introduce risk. Product knows how the assistant should communicate.

The goal is to let each person contribute without making every change an uncontrolled production change.

A lightweight ownership model can look like this:

Prompt area	Primary owner	Typical reviewer
Role and tone	Product	Marketing or support
Business context	Domain expert	Product
Instructions	Product and engineering	Domain expert
Guardrails	Legal, security, or support	Engineering
Output format	Engineering	API consumer

This does not need to become a complicated approval matrix. Even documenting the primary owner of each area removes a surprising amount of confusion.

Separate personal experiments from shared assets

Teams also need a simple way to decide which prompts are official.

We have found it useful to think in three levels:

1. Personal drafts

These are experiments. People should be able to try new instructions, tones, and examples without asking for approval.

2. Team or project prompts

These prompts are shared within a product or department. They have an owner, version history, and saved test cases.

3. Organization-approved templates

These are reusable starting points for common workflows such as summarization, support, extraction, content review, or code review.

They should be curated. A shared template without an owner eventually becomes another abandoned document that nobody trusts.

This model keeps experimentation fast while making official prompts easy to discover.

Version the decision, not only the text

A useful version history should explain more than which words changed.

For every published prompt version, a team should be able to answer:

Who made the change?
Why was it changed?
Which blocks changed?
Which test cases were run?
What was approved for production?
Which version should we restore if behaviour regresses?

Git can still manage the application code and tool implementations. But a commit diff alone rarely explains why a domain expert changed an escalation rule or whether the updated prompt still behaves correctly.

That context belongs with the prompt version.

Publishing should be an explicit action

Saving a draft and publishing to production should not be the same action.

A safer workflow looks like this:

Edit a block
    ↓
Review the focused diff
    ↓
Run saved test cases
    ↓
Approve the candidate
    ↓
Publish an immutable version

Production continues using the previous published version while the team edits and tests the draft.

This is what allows collaboration without making collaboration dangerous.

Test responsibilities, not just examples

The ownership model should also influence the test suite.

Engineering may add tests that validate the output schema. Support may add common customer scenarios. Legal may contribute cases that verify prohibited claims. Product may test tone and helpfulness.

For example:

{
  "name": "Refund outside the allowed window",
  "input": "I bought this 60 days ago. Can you refund it?",
  "expected_behaviour": [
    "Does not promise a refund",
    "Explains the 30-day policy",
    "Offers an escalation path",
    "Returns the required JSON fields"
  ]
}

Now the test suite represents the expectations of the whole team, not only the person who originally wrote the prompt.

What we are building with PromptOT

This collaboration problem is a major reason we are building PromptOT.

PromptOT treats prompts as structured, shared production assets instead of opaque text fields. Teams can:

Compose prompts from typed blocks
Start from reusable templates
Work with variables instead of duplicated prompt copies
Keep draft and published states separate
Compare version history
Attach reusable test cases
Run evaluations before publishing
Roll back to a previous version
Deliver compiled prompts through an API
Manage prompts from supported AI tools through MCP

The application still owns its code. PromptOT owns the prompt lifecycle.

That boundary is intentional. Prompt management should complement Git, not attempt to replace it.

Start with a simple ownership exercise

You do not need new infrastructure to improve prompt ownership today.

Take one important production prompt and divide it into five sections:

Role
Context
Instructions
Guardrails
Output format

Then assign a primary owner to each section and create one test case for every important responsibility.

You will quickly discover where requirements conflict, which instructions are duplicated, and which parts of the prompt nobody understands well enough to own.

That exercise is valuable even if the prompt remains in a file for now.

Prompts are collaborative interfaces

The best production prompts are not written once by a single prompt engineer.

They evolve through input from engineering, product, support, operations, security, and domain experts. The tooling should make those contributions safer and easier to review.

When prompt ownership is clear, teams can move faster without losing control of production behaviour.

The question is no longer simply, "Where should we store the prompt?"

The better question is:

How can everyone responsible for the AI's behaviour contribute without accidentally breaking someone else's contract?

That is the workflow prompt-management tools need to solve.

PromptOT is a structured prompt-management platform for teams building production LLM applications. Learn more at promptot.com.

# We Added MCP to PromptOT: Manage Production Prompts from Claude, Cursor, and Codex

PromptOT — Mon, 03 Aug 2026 08:46:34 +0000

Developers increasingly use Claude, Cursor and Codex to write, review and improve application code.

But when those applications depend on production LLM prompts, there is usually a disconnect.

Your AI coding assistant can modify the application, but it cannot safely:

Find the production prompt
Understand its current version
Update a specific prompt section
Create a draft
Compare versions
Add test cases
Publish an approved version

The developer must leave the AI tool, open a separate dashboard, locate the prompt and repeat the change manually.

We wanted to remove that context switch.

That is why we added a Model Context Protocol server to PromptOT.

PromptOT MCP lets compatible AI assistants work directly with your PromptOT workspace through structured tools and scoped permissions.

What is PromptOT?

PromptOT is a prompt management platform for production LLM applications.

Instead of keeping system prompts as hardcoded strings, PromptOT lets teams manage them as structured assets.

A prompt can contain separate blocks for:

Role
Context
Instructions
Examples
Guardrails
Output format

Teams can version these prompts, create test cases, run evaluations and publish approved versions.

Applications retrieve the compiled prompt through an API, allowing prompts to be updated without redeploying the application.

The dashboard remains useful for visual editing and review. But developers increasingly work inside AI-assisted tools, so we wanted PromptOT to be accessible there as well.

Why MCP?

The Model Context Protocol gives AI clients a standard way to communicate with external tools and data sources.

Without MCP, connecting an assistant to PromptOT would require a custom integration for every client.

We would need one integration for Claude, another for Cursor, another for Codex and potentially another for every future AI tool.

With MCP, PromptOT exposes one structured tool catalog.

Any compatible client can discover those tools, understand their input schemas and call them when the user makes a natural-language request.

The flow looks like this:

Developer
   ↓
Claude, Cursor or Codex
   ↓
PromptOT MCP server
   ↓
Authenticated PromptOT API
   ↓
Prompt workspace

The AI assistant does not receive unrestricted database access. It can only call the PromptOT operations exposed through its authorized MCP connection.

What can PromptOT MCP do?

The PromptOT MCP server currently exposes 23 tools across five areas.

Prompt management

The assistant can:

List prompts
Get a prompt and its current state
Retrieve the compiled prompt
Create a prompt
Update prompt metadata
Delete a prompt with explicit confirmation

Example request:

List all prompts in my PromptOT workspace related to customer support.

Block management

The assistant can work with the structured sections inside a prompt:

List blocks
Create a block
Update a block
Delete a block
Reorder blocks

For example:

Open the customer-support prompt and add a guardrail that
prevents the assistant from requesting passwords or complete
payment information.

The AI client can find the prompt, inspect its current blocks and make the appropriate structured change.

Variable management

PromptOT supports runtime variables such as:

{{user_name}}
{{plan}}
{{tone}}

Through MCP, an assistant can:

List variables
Add or update variables
Delete variables

Example:

Add a tone variable to the onboarding-assistant prompt with
“friendly” as its default value.

Version management

Prompt changes should not silently replace production behaviour.

PromptOT MCP includes tools to:

List versions
Save a draft version
Publish a version
Roll back to an earlier version
Compare two versions

A developer can ask:

Save the current customer-support prompt as a new draft version.
Use “Added billing escalation guardrail” as the changelog note.

Or:

Compare the current draft with the published version and
summarize the behavioural differences.

Test-case management

AI assistants can also manage PromptOT test cases.

Available operations include:

List test cases
Create a test case
Update a test case
Delete a test case

For example:

Inspect the support-agent prompt and create three test cases:

1. A normal product question
2. A billing escalation
3. An off-topic request

Check the existing test cases first and do not create duplicates.

The cases are saved to the same PromptOT prompt and become available to the rest of the team.

A real workflow from Claude

Suppose we have a prompt named support-agent.

It contains a Role block and an Instructions block, but it does not have a strong guardrail for billing disputes.

Inside Claude, we can ask:

Using PromptOT, inspect the support-agent prompt.

Add a guardrail requiring refund requests and duplicate-charge
reports to be escalated to a human. Do not change any other
prompt blocks.

Save the result as a new draft version with a clear changelog note.

Claude can use PromptOT MCP to:

Find the prompt
Read its blocks
Create or update the guardrail block
Save a new draft version
Return the result to the user

The same workflow can be performed from Cursor or Codex.

The prompt remains inside PromptOT, with its structure and history preserved.

Installing PromptOT MCP

PromptOT supports local and hosted MCP connections.

Claude Desktop

The easiest Claude Desktop installation is the PromptOT Desktop Extension.

Download it here:

Download PromptOT for Claude Desktop

Open the downloaded file, and Claude Desktop will guide you through the installation.

A manual configuration is also available:

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

Cursor

Add PromptOT to your Cursor MCP configuration:

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

Codex CLI

Add PromptOT to the Codex configuration:

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

The MCP package can also be launched directly:

npx -y @prompt-ot/mcp

Browser-based clients can use PromptOT’s hosted MCP endpoint with OAuth:

https://mcp.promptot.com/mcp

Complete installation instructions are available in the PromptOT MCP documentation.

Designing MCP access safely

Giving an AI assistant access to production prompt management requires clear boundaries.

We designed PromptOT MCP around several safety principles.

Scoped keys

MCP keys can be limited to the permissions they need.

A read-only assistant does not need permission to modify or publish prompts.

Conservative defaults

New MCP keys use development-oriented defaults. Publishing access must be granted intentionally.

Explicit destructive actions

Delete operations are marked as destructive and require explicit confirmation.

Audit history

MCP-originated changes include client information, allowing teams to understand where each mutation came from.

Immediate revocation

An MCP key can be revoked from PromptOT. Future requests using that key will be rejected.

Structured tool schemas

Every MCP tool has a defined input schema.

The assistant cannot send arbitrary database operations or execute unrestricted code through the PromptOT MCP server.

These boundaries are important because MCP should make development faster without removing control from the user.

MCP does not replace the PromptOT API

PromptOT supports two complementary paths.

The API is for applications

A production application retrieves its compiled prompt at runtime:

import { PromptOT } from "@prompt-ot/sdk";

const promptot = new PromptOT({
  apiKey: process.env.PROMPTOT_API_KEY,
});

const { prompt, version } = await promptot.prompts.get(
  "support-agent",
  {
    variables: {
      user_name: "Alex",
      plan: "Pro",
      tone: "friendly"
    }
  }
);

The application can send the resulting prompt to its selected model provider:

const response = await openai.chat.completions.create({
  model: "gpt-4o",
  messages: [
    {
      role: "system",
      content: prompt
    },
    {
      role: "user",
      content: userMessage
    }
  ]
});

PromptOT returns a compiled string, so the application is not locked into one model provider.

MCP is for AI-assisted development workflows

Claude, Cursor or Codex uses MCP to help developers manage prompt resources through natural language.

The API serves the application.

MCP serves the developer’s AI tools.

Both operate on the same PromptOT source of truth.

What we learned while building the MCP server

Building an MCP server is not only about wrapping REST endpoints.

A useful MCP implementation also needs careful tool and permission design.

Clear tool boundaries

A small, predictable tool is easier for an AI assistant to use correctly than one large operation with many unrelated behaviours.

For example, PromptOT provides separate tools for:

Updating a block
Reordering blocks
Saving a draft version
Publishing a version

This makes the assistant’s intended action easier to understand and audit.

Human-readable descriptions

The model relies on tool descriptions to decide which operation it should call.

Tool descriptions are therefore part of the product interface, not merely internal documentation.

Safe defaults

Read operations, mutations and destructive operations should be clearly distinguished.

An AI client should understand whether a tool only retrieves information or permanently changes a resource.

Controlled payload sizes

Compiled prompts can become large.

An MCP server must return enough context for the assistant to complete its task without flooding the model context window with unnecessary data.

PromptOT supports prompt truncation controls when retrieving large compiled prompts.

Consistent transports

Local clients such as Claude Desktop, Cursor and Codex work well with a standard input/output MCP transport.

Browser-based clients require a hosted HTTP transport with authentication.

Both transports should expose the same tool catalog so the assistant receives consistent PromptOT capabilities regardless of where it is running.

One prompt workspace across every tool

PromptOT MCP creates a workflow where the dashboard, application and AI development tools operate on the same prompt resources.

A prompt edited from Claude appears in PromptOT’s history.

A test case created from Cursor becomes available to the team.

A version prepared from Codex can still be reviewed before it is published.

The goal is not to move prompt management into one specific AI client.

The goal is to maintain one source of truth while allowing developers to work from the tools they already use.

Example MCP workflows

After connecting PromptOT, start with something simple:

List my PromptOT prompts and explain the purpose of each one.

Then inspect a specific prompt:

Open the customer-support prompt and summarize its role,
instructions, variables and guardrails.

Create a safe change:

Add a guardrail that prevents the assistant from requesting
passwords. Do not change any other blocks.

Save a version:

Save the current prompt as a new draft version with the
changelog note “Added password safety guardrail.”

Finally, create test cases:

Check the existing test cases for the customer-support prompt.

Create only the missing cases for:

1. A normal product question
2. A billing escalation
3. A prompt-injection attempt

These requests allow an AI assistant to work with structured prompt resources instead of copying untracked prompt text between conversations.

Try PromptOT MCP

If you already use Claude, Cursor, Codex or another MCP-compatible client, you can connect it to PromptOT and start managing prompts from your existing workflow.

Explore PromptOT:

https://www.promptot.com

Read the MCP documentation:

https://www.promptot.com/docs/mcp

Download the Claude Desktop extension:

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

Production prompts should not be scattered across source files, documents and AI conversations.

With PromptOT MCP, your dashboard, application and AI development tools can finally work from the same structured and versioned prompt workspace.

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.