MCP v2 in PolyApiIDE: letting an AI agent run your requests

I build PolyApiIDE, and one thing about MCP v2 gets misread a lot: there is no separate MCP server process running inside the extension. The actual mechanism is simpler and more mundane — an external AI tool can queue exactly one command for the extension and fetch the result later. No persistent connection, no dedicated process, just an ordinary command queue through the server.

What it is

MCP v2 is a channel through which an AI agent — one running inside a code editor, for example — can ask PolyApiIDE to actually execute a saved request, collection, folder, or scenario against a real API and return a real response. Not a simulation, not a model's guess at what the server would return, but an actual HTTP call using your variables, auth, and environment — the same way it would run if you triggered it yourself in the tab.

An important boundary up front: the agent does not get open-ended control of your browser and cannot go off and browse arbitrary sites. It can only run what you have already saved in PolyApiIDE, and only through one of four commands — nothing more.

Why it is useful

A typical case: you or an agent are working on an integration directly in the editor — adjusting client code that calls a third-party API — and the agent needs to check the endpoint's actual behavior, not what the docs claim it does. Before this feature, that meant switching to the extension tab by hand, finding the right request, running it, and copying the response back into the chat with the agent. MCP v2 removes that switch: the agent queues the command itself and fetches the result itself once it is ready.

This is particularly useful for agentic development and testing workflows: an agent can run a scenario or a folder of checks, see the real response codes, and use them for its next step — without you acting as the go-between for two separate tools the whole time.

How the command-to-job_id flow works

There is no magic here, just a few steps:

• the external AI tool authenticates using your extension's client_id — a technical API-client identifier, not an account login or password; full client registration also needs a client_secret, but queuing a command only requires the client_id;
• the tool sends one of four commands to the server: run_request, run_collection, run_folder, or run_scenario, naming what to run;
• the extension periodically polls the server for pending commands addressed to that client_id;
• once it finds one, the extension executes the matching saved object locally — with the same variables, environment, and auth it would use for a manual run;
• the result becomes available by job_id — the AI tool fetches it in a separate request whenever it chooses to.

In other words, the extension never listens for incoming connections — it initiates the poll to the server itself, and the AI tool initiates fetching the result itself. That is exactly why MCP v2 is not an embedded server but a queue with polling on both sides.

Security: treat client_id like a password

This is the part to understand before turning the feature on, and I do not want to bury it in a footnote. In this channel, the client_id alone is enough to queue a command — no secret required. That means the client_id needs the same care as a password: whoever has it can make your extension execute a saved request, collection, folder, or scenario.

The practical takeaway: do not put a client_id in a public repository, a CI log config, a screenshot attached to a support ticket, or a chat that outsiders can read. If you suspect a client_id has leaked, it can be reissued in settings, the same as any other compromised access key.

That said, the channel does not hand over full browser control: the agent cannot open an arbitrary site, read your history, or go beyond the four commands above. That limits the blast radius of a leak, but it does not make a leak safe — take the client_id seriously.

Current limits

• the feature is available on paid plans only (Month, Year, Lifetime) — MCP v2 does not work on Free;
• the queue caps at 20 unprocessed commands per client_id — that is an overflow guard, not a working budget for normal use;
• each queued command and its result record expires after 24 hours — if you do not fetch the result by job_id in time, you will need to run it again;
• the channel itself is rate-limited — a safeguard against overload, not a way to push through thousands of commands a minute.

More detail on these limits, and answers to common client_id questions, is in the FAQ.

How to turn it on

MCP v2 lives where your license lives — the Settings → License tab. Since it is a paid capability, it unlocks automatically once you have an active paid plan, with no separate purchase. That same tab is where you find the client_id to hand to your AI tool — and, as above, treat it like a password.

Setting up the AI tool itself (the editor or agent environment) depends on how it supports MCP-style integrations on its own side — the technical side of the protocol is covered in the MCP docs.

If you already use PolyApiIDE and run an agent in your editor for integration work or debugging, MCP v2 removes one more tool switch from the loop. If you are just getting started, learn requests and collections first through the quick start, and turn MCP on once you hit a concrete case where the agent needs a real API response instead of your retelling of one.