REST or MCP?
Choose the right integration surface.
REST and MCP use the same registered catalog and execution plane. Choose based on who owns orchestration, not on expected output quality.
Use REST when
- your service knows the capability it wants to call;
- you need explicit persistence, scheduling, batching, or observability;
- your code owns idempotency and retry policy;
- you want to generate a typed client from OpenAPI;
- a backend service, data pipeline, or application server is making the request.
REST uses an Upscrape API key and exposes execution and job resources directly.
Use MCP when
- an AI client should search the live catalog;
- the model needs to describe a capability before supplying input;
- a consumer client should authorize through OAuth instead of receiving a copied API key;
- tool discovery is more useful than a preselected endpoint.
MCP exposes a compact default tool set that searches, describes, executes, and retrieves results. It does not turn every capability into an enormous unfiltered tool list unless you explicitly pin capabilities.
What stays the same
Both surfaces use the same account, catalog visibility, capability input schema, worker execution, credit cost, and result provenance. A capability that costs one credit through REST costs the same through MCP.
A practical rule
Use REST for deterministic application code. Use MCP for agent-driven discovery and execution. If an agent is writing deterministic application code, give it the REST integration brief rather than making the application itself depend on MCP.