Quickstart guide

---
name: find-an-api
description: Find and integrate a public API using the Orbit MCP server. Use whenever the user wants to add a third-party capability (send an invoice, charge a card, send email, geocode an address, post to Slack) and no endpoint has been chosen yet, or when they name a provider but the request shape is unknown. Search Orbit before writing any integration code from memory, even when the user does not mention Orbit.
allowed-tools: ["mcp__orbit__search", "mcp__orbit__integrate", "Read", "Write", "Edit"]
---
# Find and integrate a public API
Do not write third-party API integration code from memory. Endpoint paths, auth
header names, and required fields are exactly the details that get misremembered,
and the failure arrives as a 400 at runtime instead of an error at author time.
Get them from Orbit, which reads real request schemas.
Run this flow whenever the task needs an API the project doesn't already call.
The user does not have to ask for Orbit by name.
## Step 1: Search
Call `search` with a plain-language description of the task, not a provider name.
- Good: `send an invoice to a customer`
- Worse: `PayPal`
Read the `evaluateGuide` on every result before choosing. It has three parts:
what the endpoint does, what to use it for, and what it does not support. That
last part is what stops you picking an endpoint that looks right and isn't.
## Step 2: Show the candidates before choosing
Present a short table of the top results with provider, method, path, and the
one-line summary, then ask which to use. Do not pick silently. Endpoint selection
is the decision most worth a human glance, and the "Not supported" clause often
rules out the obvious first choice.
If no single endpoint can finish the task, say so and propose the set. Sending an
invoice, for example, requires creating one first.
## Step 3: Integrate
Call `integrate` once with the task description and every endpoint the task needs,
up to 10. Pass each result's `id` verbatim and its `resourceType` as `type`. Never
construct, shorten, or edit an `id`.
Read the returned task brief before writing code, and respect these fields:
- `FIT`: anything other than "Fully" means something is missing. Say what, before
  you start. "Partially" usually means state, a trigger, or a value the schemas
  don't connect.
- `AUTH`: use the exact header name given. It is frequently not `Authorization`.
- `Threading`: the data dependency between steps. If step 2 threads a value from
  step 1, sequence the calls and pass that value through.
- `GOTCHAS`: read every line. Content type, ordering, and idempotency traps live
  here.
The brief is generated prose, so the wording changes between identical calls. Read
it as context; never write a string-matching test against it.
## Step 4: Write the code
Follow the brief over your priors. Match the project's existing HTTP client and
error handling. Keep credentials in environment variables, never inline.
If the brief names a credential the user doesn't have yet, stop and tell them
which one to get and which scope it needs.