Your agent needs to ground its answers in the scientific literature, and a citation count is not enough. It needs to know whether later papers supported a finding, contradicted it, or were retracted. Scite ships a hosted MCP server and a REST API that read from the same Smart Citation index. They are not interchangeable: different tool coverage, different credentials, different licensing, different metering. Pick wrong and you either rebuild auth mid-project or discover in production that your self-service key returns redacted snippets. Here's how to pick.
Both surfaces read the same index of papers and Smart Citations. They differ in what they expose and how an agent authenticates.
Scite MCP is a hosted, stateless JSON-RPC server maintained by Scite, part of Research Solutions. It launched on February 26, 2026, is available to all Scite subscribers, and backs Scite's own ChatGPT plugin and Claude connector; Scite describes all three as ways to reach the same tools. All traffic is POST to /mcp; GET returns 405, and there are no server-initiated SSE streams. It exposes 25 tools across literature, evidence datasets, and Collections, plus four prebuilt research prompts. Interactive clients use OAuth 2.1 with PKCE and Dynamic Client Registration (DCR). Programmatic clients send an API key carrying the mcp scope as a bearer token, and Enterprise customers can use issued client credentials. See Scite's official MCP documentation.
The Scite REST API covers papers, Smart Citation tallies, the citation graph, search, evidence datasets, Collections, Reference Check, the Assistant, authors, and journal-level metrics. Papers and Tallies endpoints are public and need no key. Everything else needs one of two credentials: a self-service API key, available on the Pro plan since August 8, 2026, or an Enterprise client_id and client_secret exchanged through client_credentials for an access token that expires after two hours. Keys travel as Authorization: Bearer and carry the scopes you pick in the API Console. Responses expose RateLimit-* headers, and limits vary by endpoint and account. See the Scite API documentation.
Four dimensions decide this for a Scite agent: what it can do, how it authenticates, what you operate in production, and which workloads fit each path.
The MCP server is built for conversational research: find papers, read open-access excerpts, and pull the citation statements that support or contrast them. The REST API is built for systems: batch lookups, graph traversal, document checks, and dashboards.
The ceiling is document-level and portfolio-level work. An agent that checks every reference in a manuscript needs Reference Check. An agent that ranks journals, walks a citation graph several hops out, or refreshes tallies for 5,000 DOIs a night needs REST. The MCP server also returns deliberately slim search results, and its Evidence tools follow a search-then-fetch pattern so the model pulls full records only when it needs them. That is a feature for context budgets and a cost for throughput. One more gap: MCP Collections can only be DOI lists. Saved-search Collections, whose membership comes from a query, are created in the web app or through REST.
Scite gives the two surfaces different credential models, and the difference matters more than the transport.
Interactive clients run the OAuth 2.1 authorization code flow with PKCE (RFC 7636, S256 required), discover endpoints from the Authorization Server Metadata document (RFC 8414), and obtain a client_id through DCR (RFC 7591). Platforms that ship with PKCE or DCR turned off get invalid_request. The grant carries the mcp scope, and the token endpoint accepts grant_type=refresh_token, so a background agent can keep running after one browser consent. Programmatic clients can skip OAuth and send a Pro API key with the mcp scope. That key shares its owner's MCP quota, which makes it a single-account credential, not a multi-tenant one. Users on SAML SSO must sign in through SSO before authorizing.
The REST API documents two credential types and no per-user OAuth grant. A self-service API key requires Pro, is shown once, and can be rotated or revoked in the API Console; for a multi-tenant product, that means asking every user to hold Pro and paste a key. The alternative is Enterprise credentials: your company's client_id and client_secret, exchanged for a two-hour access token. That is clean server-to-server auth for headless pipelines, but it is one identity for every tenant. Scite sees your product, not the researcher, and per-user attribution becomes your problem.
Scite meters and licenses the two surfaces separately. MCP calls draw on the authorizing user's monthly credits, 250 on Basic and 2,500 on Pro, and exhausting them returns -32001 until the calendar month resets. REST limits are enforced separately and vary by endpoint. Basic includes MCP credits but no REST key. A self-service Pro key is for evaluation: Search snippets come back redacted, commercial or research use of Search needs a separate license, and Evidence datasets need dataset-specific scopes. On MCP, an individual Pro account unlocks Evidence tools, while organization licenses need an explicit evidence:<dataset>:mcp entitlement.
Recommended reading: OAuth vs API Keys for AI Agents
Scite hosts both surfaces. The difference is which failure modes land on your team.
Scite maintains the tool schemas, the access resolver that finds a readable copy of each paper, and protocol negotiation across MCP versions 2024-11-05 through 2025-11-25. You own token storage, refresh, revocation handling, and tenant isolation for every connected user. You also own tool-surface hygiene. search_literature alone carries 30 parameters and a multi-paragraph description, and Scite warns that large limit values produce payloads that consume significant model context. Scite annotates delete_collection and remove_dois_from_collection with destructiveHint, which your client should honor with confirmation or exclusion. Scite points clients to tools/list for the live schema, so treat tool contracts as server-controlled.
You own everything above plus the client: endpoint selection, pagination through citation graphs that can exceed 3,000 records, polling loops for Assistant and Reference Check tasks, and retry policy. Scite's guidance is specific: never retry 401, 403, 404, or 422 unchanged; back off with jitter on 429 and transient 5xx; honor Retry-After; and avoid retrying writes without deduplication. You also map field names yourself, because journal-level tallies use totalSupportingCites where DOI-level tallies use supporting. The upside is control. Batch jobs, bulk tallies, and aggregations run deterministically, with no model choosing tools.
Three MCP errors deserve explicit handling. -32001 means the user's monthly allowance is spent. -32003 means a plan, scope, or entitlement is missing; after an upgrade, entitlements can take up to 15 minutes to reach a live session. -32042 returns an upgrade URL as an elicitation, which a headless agent has no one to show. Because access is enforced on tools/call, not tools/list, a Basic user's agent still sees all 17 Evidence tools and fails on each one. Filter the tool surface to what the user's plan can execute.
The split follows workload shape more than preference.
Choosing MCP or REST changes the token type. It does not change the infrastructure you need around it.
On MCP, Scite gives you a per-user OAuth grant with refresh, and every call runs on that researcher's plan and credits. That is the right posture for a research agent: what the user can't do, the agent can't do. On REST, Scite gives you either per-user API keys or one Enterprise credential. Either way, Scite validates the credential it receives. Neither surface documents a way to notify your agent when a user revokes access, downgrades a plan, or rotates a key; you find out on the next failed call.
Take a B2B literature-review product with 60 customer organizations and 1,500 researchers. On MCP, that is 1,500 access and refresh token pairs to encrypt, isolate per tenant, refresh before expiry, and invalidate on revocation, plus plan awareness so each tool surface matches its user's entitlements. On REST with per-user keys, it is 1,500 long-lived secrets that users paste and rotate. With one Enterprise credential, it is a single secret whose compromise exposes every tenant, and an audit trail that cannot name the researcher. The token type differs. The infrastructure required does not.
Recommended reading: How Tool Calling Auth Changes When You Move from Single-Tenant to Multi-Tenant
Scalekit ships one Scite connector, scitemcp, which routes tool calls to Scite's own MCP server; there is no separate Scite REST connector in the catalog. Each user signs in to Scite once, Scalekit stores and refreshes the token, and your agent never handles it. The examples use Python and the Claude SDK, because the Node.js SDK does not mint Virtual MCP session tokens yet.
Create a Scite MCP connection in the Scalekit dashboard under AgentKit, then install the SDKs. The examples use scitemcp, the connection name from Scalekit's quickstart; your code must use the exact connection name shown in your dashboard. The Scite MCP connector docs list all 25 tools with their input schemas.
Authorization happens once per user. get_or_create_connected_account returns the user's connected account; if it is not ACTIVE, the authorization link sends the user through Scite's OAuth 2.1 consent. After that, Scalekit keeps the token fresh and your code passes only the user's identifier.
The agent does not load a flat connector catalog. list_scoped_tools returns the tools this user's connected account is authorized to call, narrowed further by the tool_names you pass. For Scite, that filter carries policy: leave out the two destructive Collection tools, and add Evidence tools only for users whose Scite plan can execute them, since Scite checks entitlements on the call rather than the listing.
execute_tool runs each call as the user, with the credential resolved server-side. Provider-side failures raise ScalekitToolException, which the SDK reserves for errors returned by the upstream service. The loop hands those back to Claude as tool errors instead of crashing the run.
The direct path suits one agent calling one connector. A research product usually runs several agent roles across several tools for many tenants. A Virtual MCP server is defined once per agent role: which connections and which tools. Each run gets a short-lived session token bound to one user's connected accounts, so one static endpoint serves every tenant with no credential sharing. This example pairs three read-only Scite tools with the Slack connector's slack_send_message for an evidence digest agent.
Before each run, confirm the user's connections are active and mint a session token. The default lifetime is about an hour; set expiry above the expected run time, and remint rather than refresh, since there is no refresh endpoint. Anthropic's MCP connector then calls the Virtual MCP server directly, so there is no tool loop to write.
For recommendations, citation-graph traversal, or Reference Check, add Scite's REST API as a custom connector with BEARER auth; each user supplies their own Pro API key, stored in the same vault. Calls go through Tool Proxy with actions.request(), and paths are relative to the connector's proxy_url. Custom connectors and the API proxy are part of the Growth plan on the pricing page.
Three properties matter most once a Scite agent leaves the demo.
AgentKit records every tool call with timestamp, connection, tool name, user identifier, and latency; the detail view adds connection and account IDs, duration, source, and the full error. The overview separates connector errors, where Scite received the call and rejected it, from API errors, where the call failed before leaving Scalekit, such as an expired token or invalid parameters. For a Scite agent, that split is diagnostic: a spike in connector errors on Evidence tools is a signal to check plan entitlements, while API errors point at your own configuration. Authentication events land in auth logs, with SIEM integrations on Enterprise.
Recommended reading: Agent Tool Observability: Your Agent Is Running. Is It Actually Working?
A literature-review agent, a regulatory-watch agent, and a grant-scouting agent each need a different slice of Scite's 25 tools, often alongside Slack, Notion, or web search through Exa. A Virtual MCP server turns each slice into a static endpoint defined once, with a per-run token bound to one user. search_literature alone ships 30 parameters, so scoping a server from 25 tools to five keeps the decision space small. Surface reduction is the lever. Model upgrades help. They are not the lever. Tenant isolation comes from the token, not from per-user server configuration.
Recommended reading: When to Use a Virtual MCP Server
Scite OAuth tokens live in Scalekit's AES-256 vault, namespaced per tenant, resolved at request time, and kept out of prompts, logs, and LLM context. When a user revokes Scite access, their next call fails closed with a clear error while other users in the tenant keep working. Calls run on the authorizing user's Scite entitlement, so usage and rate limits land on the real account, and the audit trail names the researcher whose agent ran the search. See how the model works in the token vault deep dive.
If your agent is an interactive research assistant whose users hold Scite subscriptions, build on MCP: per-user OAuth, Smart Citation statements without an Enterprise agreement, and tool schemas Scite maintains. If your agent runs Reference Check, walks citation graphs, or refreshes tallies in bulk, build on REST, and expect an Enterprise conversation before production Search use. Many Scite products will run both: MCP for the conversational layer, REST for batch jobs. Either way, the credential lifecycle is the same problem, and that is what needs production-grade infrastructure.
Browse the Scite MCP connector, fork a pattern from the agent templates such as the competitive intelligence briefing agent, and review AgentKit pricing; the free tier includes 5,000 tool calls a month and unlimited connected accounts. Building a Scite agent and want a second pair of eyes on the auth design? Talk to us for immediate help.
