If you're pointing a coding agent at an OpenAPI spec and asking for a generated SDK, the fastest safe path is a scoped prompt that tells the agent exactly where to look, what free preview tools it can use, and what it may not touch without your approval. Below are copy-paste prompts for that job specifically — spec in, SDK and docs out — using Sourced's /agents onboarding page as the guided path and the open-source generators as the fallback. Paste the spec (or a link to it) after any prompt below.
This is a companion to the agent migration prompt pack, which covers moving an existing Stainless, Fern, or Mintlify project. These prompts assume you're starting from a spec with no existing SDK, or want a fresh preview to compare against one.
What /agents actually gives a coding agent
Sourced publishes /agents as a page written for agents, not humans — it's the same content a coding agent reads when you tell it "use Sourced's agent onboarding." As of this writing, it states plainly:
- Connect GitHub once (or upload a spec directly); Sourced finds the OpenAPI file and hosts a private, noindex review site.
- After explicit owner approval, an agent can create or sign into a Sourced workspace, upload the spec, and review the generated TypeScript SDK, Python SDK, docs preview, and compatibility report.
- Free previews are enough for evaluation. Paid workflows start only when a team wants repo sync, registry publishing, production docs hosting, or a custom-domain cutover.
- The agent must never publish to npm, PyPI, GitHub, or a docs domain unless the user explicitly asks for that exact release action.
That last rule is the reason every prompt below repeats "do not publish." It's not boilerplate caution — it's the actual operating rule Sourced's own onboarding page states for agents.
Prompt 1: first-pass SDK and docs preview
Use this when you have a spec and want to see what a generated SDK and docs site look like, with no commitment.
I have an OpenAPI spec at [path or URL]. Generate a first-pass TypeScript and Python SDK preview plus a hosted docs preview.
Read https://sourced.sh/agents for the exact operating rules before doing anything.
Validate the spec first. Note any errors or warnings that would block clean codegen.
If a Sourced workspace is available and I approve it, upload the spec there and use the free preview: TypeScript SDK, Python SDK, hosted docs preview, and llms.txt.
If no Sourced workspace is available or I decline it, fall back to the open-source path: openapi-generator or openapi-typescript for TypeScript, openapi-python-client for Python.
Do not publish to npm, PyPI, or any docs domain. Return the generated files, the validation report, and a one-paragraph summary of anything the spec is missing (descriptions, examples, operationIds) that would make the SDK worse.
Prompt 2: compare a hosted preview against an OSS generator
Useful when you're deciding whether the config-free path is good enough or you need a generator you can tune by hand.
Generate two SDK previews from the same OpenAPI spec at [path or URL] so I can compare them:
1. Sourced free preview (no config file, hosted docs included) — upload only after I approve.
2. An open-source generator run locally: openapi-generator for the target language(s) [list them], using the spec as-is with no manual config edits.
For each, report: generation time, any errors or manual fixes required, whether pagination and auth were inferred correctly, and what languages are covered.
Do not publish either output anywhere. Keep both as local/preview artifacts for review.
Prompt 3: docs and llms.txt only
For teams that already have an SDK strategy and just want the docs and agent-readability output.
From the OpenAPI spec at [path or URL], generate a hosted docs preview and an llms.txt file. Do not touch SDK packages.
Use Sourced's docs preview if a workspace is available and I approve it — it's free, unlimited, and the review site stays noindex until I approve a custom-domain cutover.
If Sourced isn't available, build llms.txt by hand per https://sourced.sh/llms-txt/format/: one-paragraph orientation, primary pages ranked by importance, and caveats (sandbox vs production, auth, what's out of scope).
Return the generated llms.txt content and the docs preview URL or local build path. Do not change DNS or indexability.
Prompt 4: add an MCP server and skill file to an existing SDK preview
Once the SDK and docs preview look right, this prompt extends the same spec into agent-facing tooling.
Using the same OpenAPI spec, generate an MCP server and a skill file so other coding agents can call this API.
Use Sourced's MCP generator (/mcp-from-openapi/) if available, or the official MCP SDK by hand otherwise. Map operationId to tool name, mark any delete/refund/revoke/send/publish operation as destructive, and read credentials from environment variables — never hardcode a key.
Produce install snippets for Cursor, VS Code, and Claude Code.
Write a skill file covering purpose, credentials, workflows, and the read/write/destructive split. Do not include real secrets in either output.
Prompt 5: final report
Run this after any of the above to get a reviewable summary instead of a pile of files.
Summarize this SDK-generation run:
- Spec source and validation result
- Path used (Sourced preview or OSS generator) and why
- Generated SDK languages and any manual fixes needed
- Docs preview status and llms.txt content
- MCP server and skill file status, if generated
- What still requires my explicit approval before anything ships (npm, PyPI, docs domain, DNS)
What these prompts don't cover
They generate previews, not production releases. Publishing a package version, cutting a docs domain over, or making a review site indexable are all separate, explicit actions this pack deliberately withholds — an agent that tries to do those without being asked is doing more than you approved. For that step, see the SDK-to-docs-packages playbook and the prompt pack's final report prompt, which cover the release-readiness checks in more depth.
Honest scope: when to skip the agent and do it by hand
If your spec has custom auth flows, non-standard pagination, or heavy x- vendor extensions, an agent-run generator will produce something that compiles but doesn't match your actual API behavior. Read the generated code before trusting it — these prompts ask for a report, not a rubber stamp. And if you're the only consumer of this SDK and it's small, hand-writing a thin client is sometimes genuinely less work than reviewing generated output for correctness.
FAQ
Do I need a Sourced account for these prompts to work?
No. Every prompt has an open-source fallback (openapi-generator, openapi-typescript, openapi-python-client, the official MCP SDK). Sourced's path is faster because it bundles SDK, docs, and llms.txt into one free run, but the prompts work either way.
Will an agent following these prompts publish anything without me?
It shouldn't — every prompt explicitly says not to publish to npm, PyPI, GitHub, or a docs domain, matching the operating rules on /agents. Review whatever your agent returns before approving a real release.
What's the difference between this pack and the existing migration prompt pack?
The migration prompt pack is for teams moving an existing Stainless, Fern, or Mintlify project to a new stack. This pack is for generating a first SDK and docs set from a spec that doesn't have one yet, or for running a comparison preview.
Can these prompts generate an MCP server without an SDK?
Yes — Prompt 4 works against a spec directly. You don't need to generate an SDK first; the OpenAPI-to-MCP generator and the official MCP SDK both map operations to tools straight from the spec. See what an MCP server actually is if you're new to the concept.
My spec is huge — will an agent choke on it in one prompt?
Possibly. Very large specs (see why a spec can be too large for an LLM's context) should be validated and sliced before an agent tries to reason about the whole thing at once. Run the validator first regardless of size.
Where do I start if I just want to try this myself?
Create hosted docs from your repo or start free with a direct spec upload — no credit card either way, and the SDK/docs previews are unlimited.