# We Added MCP to PromptOT: Manage Production Prompts from Claude, Cursor, and Codex
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.
This is a summary aggregated from Dev.to. Read the complete article on the original site:
Read full article at Dev.to