Connect your AI

Add the server, then sign in. No key to copy or store:

claude mcp add --transport http ensemblai https://mcp.ensemblai.com/mcp

In Claude Code, run /mcp, choose ensemblai and sign in. Your browser opens the EnsemblAI sign-in and a one-click consent page, and the connection then runs as your account. From a terminal, claude mcp login ensemblai does the same.

Settings → Connectors → Add custom connector, with URL https://mcp.ensemblai.com/mcp, then Connect and sign in with your EnsemblAI account (OAuth, one click). If you skip that step the trial tools still work, and Claude asks you to connect when it needs your account.

Pro account: all 32 tools at your plan’s limits, weekly data and full history.

Free or Standard account: the free trial, counted for your account alone: 10 calls a day on five read tools (search, package details, top downloads, compare, 6-month monthly charts). The other tools answer that they need Pro, and an upgrade reaches the open connection within a minute.

Not signed in: the same trial, but the 10 calls a day are shared by everyone on your network address, which in a hosted client such as Claude.ai can mean its other users too. When they run out, Claude asks you to sign in.

Where nobody can open a browser (CI, scheduled jobs, remote agents), send a Pro API key instead of signing in:

claude mcp add --transport http ensemblai https://mcp.ensemblai.com/mcp \
  --header "Authorization: Bearer ek_live_YOUR_KEY"

Bundles the connection with a skill that teaches Claude when to use the data and how to read it correctly. It signs in like any other connection: after installing, run /mcp and choose the EnsemblAI plugin server, or from a terminal run claude mcp login plugin:ensemblai:ensemblai. Without signing in it runs as the free trial. The plugin no longer takes an API key; if you set one in an earlier version, update the plugin and sign in once.

/plugin marketplace add EnsemblAI/claude-plugin
/plugin install ensemblai@ensemblai

Add to ~/.codex/config.toml (or a project-scoped .codex/config.toml):

[mcp_servers.ensemblai]
url = "https://mcp.ensemblai.com/mcp"
http_headers = { "Authorization" = "Bearer ek_live_YOUR_KEY" }

To keep the key out of the config file, export it and reference the variable instead:

[mcp_servers.ensemblai]
url = "https://mcp.ensemblai.com/mcp"
bearer_token_env_var = "ENSEMBLAI_API_KEY"

Cursor reads .cursor/mcp.json in the project, or ~/.cursor/mcp.json globally. Most other MCP clients take the same shape.

{
  "mcpServers": {
    "ensemblai": {
      "url": "https://mcp.ensemblai.com/mcp",
      "headers": { "Authorization": "Bearer ek_live_YOUR_KEY" }
    }
  }
}

curl -s https://api.ensemblai.com/v1/packages/numpy \
  -H "Authorization: Bearer ek_live_YOUR_KEY"

Full surface: OpenAPI schema · /llms-full.txt (generated from the live schema) · /llms.txt. Breaking changes are announced in the changelog.

Because the questions worth asking are not lookups. Registry download endpoints answer one package at a time over a capped recent window: no rankings, no growth math, no ownership, no dependencies, no categories, no cross-ecosystem view. Registry search ranks by text relevance, so you can look a package up by name — but you cannot rank by downloads or growth, segment by industry, or see a trend.

The public download logs that do carry history are raw event tables — PyPI-only, no npm, no classification, no ownership, no aggregates. Getting from there to an answer means running the scans yourself and then building the analytics layer on top.

What that takes to rebuild. Putting the pre- and post-2026 eras on a single comparable basis means re-processing three years of PyPI download logs at petabyte scale — and then continuing to re-process them every week to stay current. That is before npm mirroring, classification, ownership attribution, dependency extraction, or any of the aggregate layer. The segment-level series are the expensive part and the part nobody publishes.

And it is fast. Measured warm against production, three consecutive passes each: package detail, leaderboards, company stats, dependency lookups, ecosystem maps and multi-package series all return in 100–200 ms; the heaviest whole-segment aggregate, 24 months across an entire industry domain, takes about 1.3 s. For an agent that is one call instead of a dozen sequential fetches that still cannot answer the question.

The queries that only exist here. Totals, growth and leaders for an entire industry domain or technology category as one pre-computed series. What 2,800+ companies and 42,312 GitHub orgs actually publish. Ranked discovery that surfaces packages you did not know to ask about. Dependency structure, cohorts, and which packages travel together. All of it with identical field names for PyPI and npm, so a cross-ecosystem comparison is a filter rather than an integration project.

Comparable history, which is the part that matters most right now. A download should mean somebody fetched a package. From mid-July 2023 PyPI also logged metadata-sidecar fetches, which are not downloads, and their share of logged rows grew from under 0.03% to roughly 40% by 2026. On 2026-08-24 it stopped logging them. So anyone counting raw log rows is inflated across 2023 to 2026 and then drops ~35% overnight for no real-world reason, which silently breaks year-over-year growth, rankings and trend math. EnsemblAI counts distribution files only, for all time: history from July 2023 was re-derived on that basis and nothing earlier needed changing, so there is one basis end to end and no step at any date. Where a raw-row source reads higher for 2023 to 2026, that is its overcount, not our undercount. Details in How we count downloads.

CI is separated, and geography is a control, not a footnote. Every PyPI series is stored as ci_downloads and non_ci_downloads; ci_percentage is a sort field on the package listing and the split is returned by the per-package metrics endpoint, so "growing because people install it" versus "growing because pipelines re-install it" is a query rather than a guess. The headline total_downloads includes CI on purpose, so it stays comparable to what the registry publishes. country_grouping=ALL | US | ALL_EX_US applies to metrics, time series, growth and leaderboards, and /v1/analytics/geography breaks a package out per country. Not separated: mirrors and Docker-layer rebuilds are not flagged as such (ex-US and the CI split are the available proxies), and there is no per-installer endpoint yet.

When a number here will not match a registry endpoint. These figures are reconciled against the registries on a schedule (npm every Monday against api.npmjs.org, to the download), and a month is published as complete only once a sample of it matches. A point-in-time comparison can still differ, for these reasons and only these: windows (ours are calendar months and Monday–Sunday weeks; a registry “last month” is a rolling window ending today); completeness lag (the most recent ~6 weeks are subject to the registry’s own late backfill); the PyPI normalization above; registry outages mirrored faithfully (npm’s own statistics show zero for major packages on some days, and we report what the registry reports); and corrections (when a gap in our mirror is found, history is fixed rather than left wrong). A difference not explained by one of those is a bug — report it to support@ensemblai.com and it will be reconciled.

Every call is scoped to your account: tier limits, rate limits, and row-level security apply identically to MCP, REST, and the dashboard.

Monthly billing, no annual lock-in, and a soft overage cap on paid plans so a runaway job cannot produce a surprise bill.

Why Pro, if you are connecting a tool. It is the only plan with programmatic access, so the comparison is not Standard versus Pro but Pro versus not connecting. It is also where the comparable history becomes usable: Standard stops at 36 months at monthly resolution, and year-over-year work across the 2026 change needs the full series at weekly resolution, which surfaces a trend turn within a week or two instead of at month close.

Against building it. Keeping only the PyPI download side current means re-scanning the full log history every week, indefinitely — and that buys none of the npm coverage, classification, ownership attribution, dependency graph or pre-computed aggregates, nor the engineering time to build and run them.

Need more than Pro? sales@ensemblai.com.