Short answer: Generate an MCP server from your OpenAPI spec, run it locally, and add it to Cursor's MCP configuration. The agent then calls typed tools that trace to real operations, instead of working from endpoint notes you paste into the chat. The whole setup takes minutes and survives contract changes because the server regenerates on save.
Why the MCP route beats pasting notes
Pasting a curl command or a list of endpoints into the chat works for that one session and is forgotten the next. The agent re-derives the same facts, and if the notes are stale, the agent is confidently wrong. An MCP server is a maintained interface: the tools are always present, typed, and gated by the same permission prompt as any other tool.
The steps
- Open the OpenAPI file in the studio and compile it into an MCP server. Each tool maps to an operation and its parameters.
- Run the server over a local stdio or HTTP transport. The studio shows the tool list and a call log.
- Add the server to Cursor's MCP configuration and confirm the tools appear.
- Ask the agent to use the tools; watch the call log to see the exact requests it makes.
What good looks like
When it works, the agent does not invent a path. It selects the tool, supplies the typed arguments, and the call log shows the operation and the returned status. If a tool is missing, the studio tells you why — usually an operation without an operationId — instead of silently producing a weak tool.
Keep it in sync
The server is generated, not hand-written, so changing the spec and saving updates the tools. The discipline is simple: the contract is the source, and the agent always reads the current version.
This is part of the Powerduck vs Cursor comparison. See also Cursor MCP config vs a generated server.
Top comments (0)