Jotform MCP vs Jotform API for AI Agents

TL;DR

• Jotform MCP exposes a small, form-centric toolset (list, create, edit forms; create and list submissions).
• The Jotform REST API exposes the full account surface: webhooks, user and sub-user management, reports, folders, form properties, and field-level operations. The gap is real and matters for event-driven or operational agents.
• The auth models are inverted from the usual MCP-vs-API story. The MCP server is OAuth 2.0 only and gives you a per-user delegated identity. The REST API is API-key only, with no OAuth path at all; the key is account-scoped and static.
• For headless agents, the API key is the only non-interactive option; the MCP server requires a browser OAuth flow per user and can only be installed by a workspace admin.
• For multi-tenant B2B agents, the MCP path gives you one OAuth credential per user, and the API path gives you one account-level key per tenant. Neither path stores, rotates, or revokes those credentials for you.
• Scalekit's Jotform connector wraps the MCP path: it handles the OAuth flow, token storage, and per-user isolation, so the path decision doesn't change your auth infrastructure.

Your agent needs to read and write Jotform forms. Jotform now ships a hosted MCP server at mcp.jotform.com and a long-standing REST API at api.jotform.com. They are not the same object: different capability coverage, different auth models, different operational surface in production.

The choice between Jotform MCP vs Jotform API for agent development also isn't obvious, because Jotform inverts the pattern most tool vendors set. Here is the decision framework for which one your production agent should build against.

What's Jotform MCP

• The Jotform MCP server is a hosted, Jotform-maintained endpoint at https://mcp.jotform.com, built on the open Model Context Protocol so any MCP-compatible client can connect.
• Authentication is OAuth 2.0 only; the client opens a consent screen, and the user authorizes the connection once. Bearer-token access is explicitly not supported, and only a workspace admin can install the Jotform MCP app.
• A separate interactive variant, the MCP-App at https://mcp.jotform.com/mcp-app, layers a sandboxed UI on top of the same tools for clients like Claude and ChatGPT.

What's Jotform API

• The Jotform REST API at https://api.jotform.com is the decade-old interface that powers integrations like Zapier.
• It exposes the full account surface: forms, submissions, webhooks, users and sub-users, reports, folders and labels, and form properties.
• Authentication is API-key only; you pass the key as a query parameter or an APIKEY HTTP header.
• There is no OAuth path.
• Regional endpoints exist for EU (^{eu-api.jotform.com}) and HIPAA (^{hipaa-api.jotform.com}).

Comparing them where it matters for agents

What your agent can actually do

The MCP server is built for form-centric, natural-language interactions: listing forms, creating and editing forms, and creating or listing submissions. The base server ships five tools. The REST API covers everything operational that sits around forms, and that is where the gap opens up.

The base MCP toolset is deliberately small. The interactive MCP-App adds search, fetch, assign, and submission analysis, but it does not add the operational surface.

Where the MCP ceiling is

The most consequential gap is webhooks. If your agent needs to react when a form is submitted, that event stream lives only in the REST API; the MCP server has no event-subscription surface. The second gap is governance: user, sub-user, and per-form permission management are API-only, which matters the moment your agent operates across a team rather than a single account.

One API caveat worth flagging early: submissions created through the API do not trigger Jotform's own email notifications or downstream integrations. If your workflow depends on those firing, you handle the notification yourself or register a webhook.

The auth path each one puts you on

Here Jotform inverts the pattern most vendors set, so read this section carefully even if you have built against other MCP servers.

The MCP path: OAuth, per user. The MCP server is OAuth 2.0 only. Every user who connects completes a browser-based consent flow, and the resulting token is scoped to that user's Jotform permissions. There is no API-key option on the MCP path, and only a workspace admin can install the MCP app in the first place. This is the path that gives you a genuine per-user delegated identity.

The API path: key only, account-scoped. The REST API is the opposite. It supports only an API key, passed as a query parameter or HTTP header. There is no OAuth flow, no client credentials, no token exchange. The key is tied to the account, and the only scoping available is the sub-user model, where a sub-user is granted full or read-only access per form. The JavaScript SDK's login flow does not change this; it simply retrieves the user's existing API key for you to store.

What this means for multi-tenant agents

In a multi-tenant B2B agent,

• The MCP path gives you one OAuth credential per user, which is the correct isolation model but requires the interactive consent flow and admin install.
• The API path gives you one account-level key per tenant, which is static and headless-friendly but coarse: the key can do anything the account can do, and you lean on the sub-user model for any narrowing.

Neither path manages storage, rotation, or revocation for you. That remains your infrastructure problem regardless of which path you pick. This is the same credential ownership challenge that surfaces across every tool-calling pattern.

What you own in production

The MCP server manages tool schemas, endpoint normalization, and response shaping. Jotform updates the tools when it ships server changes, so your agent picks up new capabilities without a redeploy. What you still own on the MCP path: OAuth token storage per user, refresh and revocation handling, and the workspace-admin install dependency that gates onboarding.

On the API path you own the full stack: endpoint selection, request construction, pagination, retries, and the API-key lifecycle. The maintenance surface is larger, but the contract is more stable and entirely under your control.

Rate limits and versioning as production constraints

API limits are plan-based: 1,000 calls per day on the starter tier, scaling to 100,000 on gold, with Jotform Enterprise removing the daily cap. The MCP server inherits your plan's limits, and Enterprise raises MCP throughput to 600 requests per minute. Agentic workflows issue several sequential calls per user action, so the math moves faster than a traditional integration; monitor consumption from day one on either path.

MCP tool schemas are unversioned and can shift when Jotform updates the hosted server. The REST API surface has been stable for years. For deterministic pipelines where an unexpected schema change is an incident, the API is the more predictable dependency. Understanding how MCP and APIs differ at the protocol level helps frame this tradeoff.

When to use MCP, when to use the API

Use Jotform MCP when:

• Your agent is interactive and user-facing: a form-building or submission-querying assistant inside Claude, Cursor, or a similar client where the user is present for OAuth consent
• The job is creating, editing, and reading forms and submissions in natural language, not reacting to events or managing the account
• You want a per-user delegated identity by default, and a workspace admin can perform the one-time install
• You want Jotform to maintain the tool schemas rather than building API adapters

Use the Jotform API directly when:

• Your agent runs headless: scheduled syncs, background processors, or event-driven pipelines with no user present, where the static API key is the only viable credential
• Your agent must react to submissions via webhooks, which the MCP server does not expose
• You need user, sub-user, report, folder, or field-level operations that live only in the API
• You need account-wide submission retrieval at volume, or you require schema stability over automatic tool updates

The credential problem that exists on both paths

Both paths leave you holding a credential per principal. The MCP OAuth flow gives you a token per user; the API key gives you a key per account. In neither case does the path provide a vault, rotation logic, or a revocation flow.

The N-credential problem

In a multi-tenant agent, which is the B2B norm, that is N credentials to store encrypted, isolate per tenant, refresh or rotate, and revoke when a user or customer leaves. The MCP token can be revoked by the user inside Jotform's Connected Apps panel at any time, and your agent has no built-in way to detect that until a call fails. The API key persists until someone rotates it, which is its own offboarding hazard.

The problem is structurally identical whether you chose MCP or the API; only the credential type differs. This is the same token vault challenge that every multi-tenant agent faces. Scalekit's Jotform connector handles the OAuth flow, token storage, and per-user isolation for the MCP path, so the path decision doesn't change what you build for auth.

Building on Jotform with Scalekit

The token vault value for a Jotform agent

Scalekit's Jotform connector is built on the MCP path and uses OAuth 2.1 with dynamic client registration. The credential the user authorizes lives in Scalekit's token vault, encrypted at rest and isolated per tenant, and is resolved on each tool call. Credentials never touch the agent runtime or the model's context. What the user can't do in Jotform, the agent can't do either; scope is a function of the user's authorization, not a shared key.

Connecting with the Scalekit SDK

Authentication runs in three steps: generate an authorization link for the user, let them authorize once, then call tools by name. The example below uses the Python SDK. The connection_name value must match the connection configured in your Scalekit dashboard exactly; a mismatch here is the most common integration error.

The tools the connector exposes

The Scalekit Jotform connector exposes a scoped, named toolset your agent calls with execute_tool. The current tools, drawn from the connector documentation, are:

• ^{jotformmcp_search}: search Jotform assets by query, with optional filters and ordering
• ^{jotformmcp_fetch}: fetch metadata for a form by ID or URL
• ^{jotformmcp_create_form}: create a form from a natural-language description
• ^{jotformmcp_edit_form}: edit a form from a natural-language instruction
• ^{jotformmcp_get_submissions}: list submission IDs for a form, with optional filters
• ^{jotformmcp_assign_form}: assign a form to a user by email
• ^{jotformmcp_analyze_submissions}: run AI-powered analysis across one or more forms' submissions

Scoped surfaces and audit logs for multi-tenant agents

Before the agent runs, you retrieve the tools authorized for the current connected account rather than loading a flat catalog, so each user's agent sees only the surface their authorization allows. That scoping is what keeps tool selection accurate and tenant boundaries intact as you add more users.

Every authorization, token event, and tool call is recorded in Scalekit's auth logs, giving you an audit trail tied to the user who authorized the action; the observability that multi-tool, multi-tenant agents need before a security review, not after.

Least privilege with Virtual MCP Servers

If you would rather expose Jotform to your agent as an MCP endpoint, Scalekit's Virtual MCP Server gives you one server definition with per-user credential isolation and least-privilege tool access. You declare which connections and which tools the server exposes once per agent role; the agent sees only the tools you allow, not everything the connector surfaces.

Before each run, a short-lived session token is minted scoped to that specific user's connected account, so one static endpoint serves all users while the identity stays per-user. A Scalekit Virtual MCP server URL looks like https://companyName.scalekit.com/mcp/v3/servers/<server-id>. There is no MCP server for you to deploy, host, or maintain.

Setup references. Get started with the setup in the vMCP quickstart, the configure and connect guide, and an end-to-end Claude managed agent example.

When the tool you need isn't there yet

Scalekit's Jotform connector follows the MCP path, so the webhook-driven and account-management operations that live only in the REST API are not exposed today. If you need a Jotform tool that isn't available yet, request it through the Scalekit Slack community or talk to the team.

Which one to build against

• If your agent is interactive and its job is building, editing, and reading forms and submissions in natural language, the MCP server is the faster path, and it gives you a per-user identity for free.
• If your agent runs headless, reacts to submissions through webhooks, or manages users, reports, and account configuration, build against the REST API with its account-scoped key.

Most production Jotform agents will end up using both: the interactive assistant on MCP, the background processor on the API. Either way, the credential management problem is the same, and that is what needs production-grade infrastructure.

Browse the Scalekit Jotform connector.