Short answer: A hand-written MCP entry in Cursor's config is plumbing you maintain; a generated server is derived from the contract. Both expose tools to the agent, but only the generated one stays correct when the API changes and shows where each tool came from. The config is the connection; the spec is the source of truth.
What a hand-written entry gives you
You can point Cursor at any MCP server, including one you write yourself. That is flexible, and it is the right path for a capability that has no contract. The downside is that the server is now another artifact: its tools, parameters, and descriptions are maintained by hand and drift the moment the API changes.
What a generated server gives you
| Property | Hand-written | Generated from OpenAPI |
|---|---|---|
| Tool source | You | Operations and schemas |
| Provenance | Implicit | Visible per tool |
| On contract change | Manual edit | Regenerates on save |
| Weak / skipped tools | Silent | Surfaced |
The failure that generated servers avoid
The most common hand-written failure is a stale tool description: the endpoint moved, the parameter changed type, and the server still advertises the old shape. The agent trusts it and fails at runtime. A generated server cannot advertise a shape the contract does not declare.
They compose
You are not choosing one forever. Generate the server for the API you own, and keep hand-written entries for capabilities that genuinely have no spec.
This is part of the Powerduck vs Cursor comparison. Next, read why agents hallucinate API calls.
Comments
Join the discussionNo comments yet. Be the first to comment.