Developer tools

IDE access

Connect coding agents to the OAuth-protected platform MCP server.

Platform MCP endpoint

Configure this Streamable HTTP URL in your MCP client. The client opens a browser for local platform sign-in and approval; no runtime API key is used.

/platform/mcp

Durable mutations preview by default. Your last project_selectchoice is restored when the IDE reconnects.

Access tokens refresh automatically. IDE authorization remains valid for 90 days unless you revoke it here.

Authorized clients

Client setup

Connect a coding agent or ChatGPT app to the platform MCP endpoint.

Run this once. Codex detects OAuth and opens the browser approval flow.

Terminal
codex mcp add mcp-ops-studio --url /platform/mcp

Alternatively add [mcp_servers.mcp-ops-studio] with this URL to ~/.codex/config.toml, then run codex mcp login mcp-ops-studio.

Reusable agent skill

Copy this SKILL.md so an agent knows when and how to operate the platform safely. The same content follows the Agent Skills format supported by Codex and Claude Code.

Project skill

Codex: .agents/skills/mcp-ops-studio/SKILL.md

Claude: .claude/skills/mcp-ops-studio/SKILL.md

Personal skill

Codex: ~/.agents/skills/mcp-ops-studio/SKILL.md

Claude: ~/.claude/skills/mcp-ops-studio/SKILL.md

Create the directory, save the copied text as SKILL.md, and restart the client only if it does not detect the new top-level skill directory. For a ChatGPT app, put these operating rules in its workspace or agent instructions; ChatGPT does not read local skill folders.

SKILL.md
---
name: mcp-ops-studio
description: Operate MCP Ops Studio projects through its platform MCP server. Use for Functions, endpoints and bindings, Secrets and grants, authentication and network policies, testing, deployments, and runtime diagnostics.
---

# MCP Ops Studio

Use the MCP Ops Studio platform tools to configure and operate the selected project safely.

## Operating procedure

1. Start with `projects_list`, then call `project_select` before project-scoped work. The last selection is restored after reconnecting.
2. Inspect the current Function, endpoint, binding, Secret grants, and policies before changing them.
3. Use dry-run or preview modes for durable mutations when the tool provides one. Review the proposed change before applying it.
4. Create and rotate Secret values only with `secret_set_value`. Never repeat Secret values in chat, source, logs, execution input, or summaries.
5. Before enabling a binding or deploying an endpoint, assign an authentication policy and verify endpoint access and Function permissions.
6. Keep outbound network policies minimal: allow only the required hosts, methods, and ports. Do not enable private-network access unless the user explicitly requires and approves it.
   Disable TLS certificate verification only when the request requires it and the exact host is explicitly approved by the endpoint's `allowInsecureTlsHosts` policy. Prefer a trusted CA.
7. Validate or test the affected Function, then deploy the complete immutable Development snapshot. Inspect deployment status and failures before reporting success.
8. Ask for explicit confirmation before deleting resources, rotating an in-use Secret, releasing to Production, or rolling back.
9. Never claim a mutation or deployment succeeded when a tool returned an error, was cancelled, or has not completed.

## Safety

- Never request or expose encrypted or plaintext Secret values through list/get tools.
- Prefer logical names over hidden IDs when a tool supports them.
- Preserve project scoping and do not create tenant or project-membership layers.
- Functions are the executable unit; MCP tools and HTTP routes are bindings, not separate implementations.
- Draft source is not live until an immutable deployment snapshot becomes active.
Agent Skills format