Upscrape gives AI clients and applications one live catalog of structured platform capabilities. Connect the MCP server when an AI client should discover and call tools. Use REST when your application owns the execution flow.

> **For AI agents.** Start with [`llms.txt`](/llms.txt) for discovery, fetch [`llms-full.txt`](/llms-full.txt) for the complete implemented documentation, or request any documentation URL with `Accept: text/markdown`.

> **Start with the contract.** Every public platform page publishes its capability IDs, input schemas, example requests, credit cost, and, when safe, a real redacted sample response.

## Two ways to connect

Use **MCP** for AI clients and agents. The client searches the live catalog, reads the selected capability's exact schema, executes it, and retrieves a pending result when needed. Start with the [MCP overview](/docs/mcp/overview).

Use **REST** when your application owns control flow, retries, persistence, and scheduling. Start with the [five-minute quickstart](/docs/quickstart).

## The execution model

Every REST capability uses `POST /execute`. A request identifies a capability and supplies input matching that capability's JSON Schema. Upscrape validates the request, resolves account and network policy, runs the registered worker, and returns structured JSON.

Fast work can complete in the initial response when you request a bounded wait. Otherwise, Upscrape returns a job ID that you poll until it completes or fails.

MCP uses the same catalog and execution system as REST. Authentication, visibility, credit accounting, idempotency, and capability behavior stay consistent across both integrations.

## Authoritative references

- [Browse platforms and capabilities](/scrapers)
- [Copy the complete capability catalog as Markdown](/scrapers/llm.md)
- [Understand REST authentication](/docs/api/authentication)
- [Connect an MCP client with OAuth](/docs/mcp/oauth)
- [Review result provenance and trust boundaries](/docs/reference/provenance)

## What is not available yet

Planned documentation pages are visible in the navigation and marked **Planned**. They describe the intended boundary without pretending that the feature exists. The implementation work is tracked in the repository's `asap-todo.md`.