Using ChatGPT Custom Connectors With a Remote MCP Form Server

A developer connected ChatGPT to FORMLOVA's remote MCP server, enabling ChatGPT to create and operate forms directly via tool calls. The setup uses OAuth authentication and a remote MCP URL, allowing ChatGPT to generate draft forms without manual form-building steps.

ChatGPT can suggest form fields in seconds. That is useful, but it still leaves a gap: Ask ChatGPT for fields Open a form builder Create the form manually Copy labels Configure response emails Preview Fix issues Publish With a remote MCP server, ChatGPT can move one layer deeper. Instead of only describing the form, it can call tools that create and operate the form. This post walks through a narrow version of that setup using FORMLOVA as the remote MCP form server. The goal is not to explain every FORMLOVA feature. The goal is to show the practical connection path: ChatGPT developer mode, a remote MCP URL, OAuth, a first draft form, and the safety boundaries you should keep in place. OpenAI's current help content may call this area "developer mode", "MCP apps", "custom apps", or formerly "custom connectors". The naming can move. The underlying shape is the same: ChatGPT can connect to an external MCP server and call approved tools. Reference: The server URL for FORMLOVA is: https://formlova.com/api/mcp It is a remote MCP server. You do not install a local package, run a process on your laptop, or paste a shared API key into a config file. The connection flow is: php ChatGPT - remote MCP server URL - OAuth - FORMLOVA tools - draft form / preview / review / operations OAuth matters because a form system is not a read-only documentation source. It can create forms, inspect submissions, configure emails, and eventually operate workflows. The server needs to know which FORMLOVA user is acting. You need: | Requirement | Notes | |---|---| | ChatGPT developer mode / MCP app access | Availability depends on plan and workspace settings. | | A FORMLOVA account | The free plan is enough for the first connection test. | | A browser session | OAuth redirects through the browser. | | Remote MCP URL | https://formlova.com/api/mcp | If you are in a workspace plan, an admin may need to allow developer mode or custom apps before you can create an MCP app. In ChatGPT settings, look for the area related to apps, connectors, or developer mode. The labels may differ by account type, but the fields you are looking for are roughly: Name: FORMLOVA Description: Create and operate forms from ChatGPT MCP server URL: https://formlova.com/api/mcp Authentication: OAuth Use the exact domain: https://formlova.com/api/mcp Do not add a random server URL you found in a thread or snippet. MCP apps can expose tools that perform write actions. Treat the server URL like an application you are granting permission to operate. After creating the app, ChatGPT should send you through the FORMLOVA authorization flow. The rough flow is: php ChatGPT settings - create MCP app - FORMLOVA login / consent - return to ChatGPT - app connected If the connection appears successful but tools do not run, check whether the app is enabled in the specific chat. Connecting an MCP app in settings and selecting it in a conversation can be two separate steps. Start with a low-risk draft. Do not begin by publishing or sending emails. Example prompt: Use FORMLOVA to create a draft registration form for an internal engineering meetup. Ask for name, email, team, attendance type, dietary restrictions, and one question for the speaker. Keep it unpublished and return the preview URL. The expected result is: draft form created preview URL returned no public publish action yet This is the right first test because it proves that ChatGPT can call the remote MCP server without immediately creating public side effects. The first prompt can be short, but a realistic prompt should include the workflow after submission. Forms are rarely just fields. They are the beginning of an operational process. Here is a better test prompt: Use FORMLOVA to create a draft contact form for a B2B SaaS website. Required fields: - name - work email - company - inquiry type - message Optional fields: - company size - current tool - expected timeline After submission, the team wants to route pricing inquiries faster, ignore obvious sales pitches, and send a confirmation email that sets a realistic response-time expectation. Keep the form unpublished. Return the preview URL. After creating it, review the form for mobile input friction, unnecessary required fields, and response-management gaps. This prompt gives the model three kinds of information: field requirements operational intent safety boundary The safety boundary matters. "Keep it unpublished" and "return the preview URL" make the first test observable without turning it into a production action. A weak test is: Create a contact form. ChatGPT can answer that without using any tool. It can produce a nice Markdown list of fields and still never touch the remote MCP server. For a real test, verify the artifacts: | Check | Why it matters | |---|---| | Preview URL exists | Proves a draft was created outside the chat | | Form is unpublished | Confirms the write action was bounded | | Fields match the prompt | Confirms the tool call used the requested schema | | Mobile-specific review exists | Confirms the model did more than generate labels | | Follow-up operations are identified | Confirms the form is treated as intake, not a static page | I also like asking the model to summarize what it did: Summarize the FORMLOVA actions you took. Include the preview URL, publish status, and any review findings. That response is not the source of truth by itself. The preview URL and the server-side draft are the evidence. But the summary helps you catch when the model is pretending to operate while only writing advice. Once the draft exists, ask for a review pass: Review this form before publishing. Check whether it is clear on mobile, whether any required fields are unnecessary, and whether the confirmation message sets the right expectation. For form software, this step matters more than the initial generation. AI-generated form fields are usually plausible. The operational mistakes come later: too many required fields, weak confirmation text, unclear response handling, missing status columns, or a form that is painful on mobile. A useful form review should not only say "looks good." It should catch issues like: The phone field is optional, but the follow-up workflow assumes phone calls. The inquiry type is free text, which makes routing harder. The form asks for budget too early, increasing friction. The confirmation message says "we will reply soon" but does not set a response-time expectation. The form is long on mobile and should split contact details from request details. The message field is required but has no guidance about what to include. For a contact form, the review should connect form fields to response operations: | Form decision | Operational consequence | |---|---| | Inquiry type as select | Enables routing and filtering | | Work email required | Reduces low-quality consumer traffic | | Timeline optional | Helps prioritize without blocking submission | | Confirmation message | Sets expectations and reduces duplicate submissions | | Sales-pitch filtering | Keeps real inquiries visible | This is where MCP-backed form software becomes more useful than a static AI answer. The same conversation can move from field creation to response workflow decisions. MCP gives ChatGPT a tool surface. That is powerful, but it should not remove product safety. I would separate early usage into these tiers: | Tier | Examples | Risk | |---|---|---| | Read | list forms, inspect draft, get preview | Low | | Draft write | create unpublished form, edit labels | Medium | | Publish | make a form public, change public copy | Higher | | External effects | send emails, trigger reminders, export data | Highest | For the first session, stay in the first two tiers. Create a draft, preview it, edit it, review it. Publish only after the generated result has been inspected. This is also why a form MCP server should expose domain-level operations rather than one giant "do anything" endpoint. A tool named create draft form is easier to reason about than a generic mutate . If ChatGPT does not call the server, try making the target app explicit: Use the FORMLOVA MCP app to create this draft form. If OAuth loops, check browser blockers, workspace permissions, and whether you are logged into the expected FORMLOVA account. If the app connects but no tools appear, check whether developer mode is enabled for your account or workspace and whether the current chat has the app selected. If the model tries to answer with a static checklist instead of operating the tool, ask for a concrete action: Create the draft in FORMLOVA and return the preview URL. Do not just suggest fields. This setup is not necessary for every form. If you only need a one-off internal poll, a static prompt and a simple form builder may be enough. The remote MCP pattern becomes more valuable when the form has operational weight: responses need triage emails need different wording by answer submissions have statuses follow-up needs timing spam or sales pitches need filtering forms are revised repeatedly multiple people inspect the same intake queue In those cases, ChatGPT is not just generating a form. It is becoming the operating surface for the workflow around the form. That is the real reason to connect a remote MCP form server. This is not a tutorial on building an MCP server from scratch. It is not a full Apps SDK UI guide. It also does not cover Claude, Cursor, or Gemini CLI setup. The narrower point is that ChatGPT can be used as an operating surface for a remote form system when developer mode and MCP apps are available. The full FORMLOVA guide covers the longer path: setup, OAuth, preview, publishing, response management, email operations, workflows, and safety boundaries.