Choosing an integration

Which way to connect DeepSieve — MCP, skill, SDK, or raw REST

There are four ways to connect DeepSieve, and they are not competing options — they answer different questions. Most people end up using two.

If you don't want to think about it: paste the setup prompt into your agent and it picks for you.

You want to…	Use	Auth
Give your coding assistant live access to your data	MCP server	Browser login
Teach your assistant to drive the API well	Agent Skill	— (knowledge only)
Work from a terminal, or script it in a shell	CLI	Browser login
Have your own application call DeepSieve	SDK or REST	API key
Run it in CI, a container, or a cron job	CLI, MCP (stdio), or REST	API key

MCP server — live access from your editor

The MCP server puts DeepSieve tools directly in your coding assistant: it can list your runs, read your cited dataset, start a research run, and ask the research agent questions — without you writing any integration code.

Two transports, same tools:

Remote (HTTP) — https://deepsieve.ai/mcp, authenticated by browser login. No API key exists to leak. This is the default and what the setup prompt uses.
stdio — a local process (uvx deepsieve-mcp) authenticated with an API key. For CI, containers, and headless environments where nobody can click a consent screen.

The server is a schema-bound translator: your assistant sees typed tools, not raw HTTP, and never handles your credentials directly.

Reach for it when you're working in an editor or terminal assistant and want your data at hand. Don't build a production data pipeline on it — use the SDK or REST, which have stable contracts and webhooks.

Agent Skill — knowing how to use it

The skill is procedural knowledge, not access. It teaches an assistant the things that make the difference between a working integration and a plausible-looking broken one: discover the schema instead of guessing column names, test with dry_run before spending credits, read a citation's verdict before repeating a value as fact.

bash

npx skills add https://deepsieve.ai

Reach for it alongside either MCP or REST — it's additive. The setup prompt installs it and also saves a short rules file, so the hazards stay loaded in every session while the detailed procedures load on demand.

CLI — the operator's tool

The deepsieve CLI is what you reach for when you're already in a terminal: check a run, pull today's rows into a file, wire something into a cron job. It signs in through your browser (device flow) and stores a scoped, revocable key.

bash

uv tool install deepsieve-cli
deepsieve data get companies --receipts --json | jq '.data[0]'

It's also the pragmatic choice for a terminal-resident agent: --json on every command, stable exit codes, and shell pipelines it can compose. Where MCP gives an agent typed tools, the CLI gives it a shell it already knows.

Reach for it when you're at a prompt or writing a script. Don't build an application on it — shelling out from code is worse than the SDK in every way that matters (types, errors, retries).

SDK — your application calling DeepSieve

The Python SDK is generated from our OpenAPI contract, so it carries typed models, retries, and pagination helpers — and CI fails any change that leaves it out of step with the contract.

The honest caveat: that guard keeps the SDK matching the contract, not automatically the implementation. When the two differ, the API is the truth — tell us, because that's a bug on our side.

bash

pip install deepsieve

Reach for it when you are writing software that talks to DeepSieve — a backend service, a scheduled sync, a data pipeline. Don't use it to give an assistant ad-hoc access; that's MCP's job.

REST — everything else

The HTTP API is the substrate all of the above sit on. It's versioned, and becomes additive-only at GA — until then breaking changes are announced in the changelog. See Versioning & stability. For the whole surface at a glance — one link per component — see The API; every endpoint is in /openapi.json, and every docs page has a markdown mirror for agents (append .md to any URL).

Reach for it when you're in a language we don't ship an SDK for, or you want zero dependencies.

How the pieces fit

/llms.txt tells an agent this API exists and how to find its way around.
MCP tool schemas tell it which operations are available and what they take.
The skill and rules file tell it how to combine those operations without wasting your money or overstating a finding.

Access, vocabulary, and judgment — you generally want all three.