Your agent needs to read, write, and reason over content in Box. Box ships a hosted MCP server at mcp.box.com and a REST API that has been production-grade for years. They are not two views of the same surface: the capability gap is wide, the auth models diverge at exactly the point where background agents live, and the MCP tool list is not the same in every tenant you deploy into. Here is how to pick.
Both paths terminate at the same Box authorization server and both spend the same API quota. What differs is the shape of what your agent sees and who has to approve it.
The remote Box MCP server is Box-hosted at the endpoint mcp.box.com. It exposes existing Box API functionality as a defined tool set rather than adding new capability. Connecting requires an endpoint URL, a client ID and secret, an MCP name of box-remote-mcp, and a bearer authorization token.
Auth runs against Box's own OAuth endpoints: /api/oauth2/authorize on account.box.com and /oauth2/token on api.box.com. The scopes Box documents for the server are root_readwrite, ai.readwrite, and docgen.readwrite, with docgen.readwrite requiring an Enterprise Advanced license.
One prerequisite repeats on every client integration guide Box publishes: a Box enterprise account with the MCP server enabled by an admin. The server is available on all Box plans; the gate is the admin toggle, not the plan tier. Full details are in Box's remote MCP server documentation.
The Box REST API is versioned by year through the box-version header, with 2024.0, 2025.0, and 2026.0 in circulation. Requests without the header default to 2024.0. Some newer resources reject calls that omit it: Hubs endpoints return a 400 unless you send box-version: 2025.0.
The resource surface spans files, folders, search, metadata templates and taxonomies, collaborations, shared links, comments, tasks, Box AI, Box Sign, Doc Gen, Hubs, webhooks, events, retention policies, legal holds, Shield information barriers, storage policies, users, groups, and trash. Auth supports OAuth 2.0, JWT, Client Credentials Grant, and App Token. The reference lives in Box's API documentation.
Run a single agent through both paths and the differences stop being abstract. Take a contract operations agent: find this quarter's signed agreements, pull the counterparty and renewal date out of each one, tag the files, share a summary folder with legal, and route the unsigned ones for signature.
"Off by default" below means the tool exists on Box's server but is unavailable to agents until a Box admin turns it on for the enterprise. "Not exposed" means there is no MCP tool at all.
On the MCP path, finding and extracting work on defaults. Search is on, get_file_content is on, and the Box AI extraction tools are on. Then the agent reaches tagging, which needs metadata writes, and those are off. Sharing the folder needs shared links, also off. Routing for signature needs Box Sign, which does not exist as a tool.
The agent gets most of the way through the job and stalls on every step that changes something. That is the shape of the MCP gap for Box: reading and reasoning are well covered, and mutation is either gated or absent.
Sixteen of the documented tools ship off and need an admin to enable them. Box AI tools depend on the tenant having Box AI turned on. Doc Gen depends on an Enterprise Advanced license. Box also states that new tools appear automatically for enterprises with the MCP server enabled.
Put those together and tools/list returns a different answer in tenant A than in tenant B, and a different answer in tenant A next month. For a single-tenant internal agent that is a configuration step. For a multi-tenant product it is a per-customer onboarding dependency you cannot resolve from your own dashboard.
Text uploads work on the MCP path through upload_file. Binaries do not. Box routes them through get_upload_url and get_download_url, both off by default, and both of which hand your agent a temporary URL it must call itself.
Box is explicit that this only works in code-executing environments, because declarative agents cannot make the outbound request. Several Box hosts also need upload.box.com and dl.boxcloud.com allowlisted before the transfer succeeds. If your agent moves PDFs rather than notes, this is a real integration task, not a checkbox.
The MCP server is OAuth-only and always acts as the user who authorized it. There is no service-account variant. Box documents two ways to supply client credentials for it: Integration Credentials generated inside each enterprise's Admin Console, or your own OAuth application from the Developer Console. Scalekit's Box MCP connector uses the second.
The REST API supports four auth types. OAuth 2.0 for user-delegated access, JWT and Client Credentials Grant for server-to-server with no user in the loop, and App Token for Limited Access Apps. JWT and CCG both authenticate as a Service Account by default and can act as a managed user when configured with enterprise access.
A nightly job that reclassifies last week's contracts has no browser and no user session. On the REST API path, JWT or CCG gives you a token without an interactive redirect. On the MCP path, there is no equivalent; every credential originates from a user consenting in a browser.
Neither path is admin-free. JWT and CCG apps must be authorized by a Box admin on enterprise accounts. OAuth 2.0 user-auth apps do not need enablement by default, but do if the enterprise has turned on app enablement controls. The difference is that the MCP path adds an admin gate on top of whichever one you already had.
Box owns the MCP server: hosting, tool schemas, and updates. That is a genuine reduction in surface area, and for an interactive assistant it is the right trade. What you still own is token storage per user, refresh handling, revocation, and the per-tenant configuration drift described above.
On the REST path you own request construction, pagination, error handling, retries, and the full token lifecycle. In exchange you get a version pin. You send box-version: 2026.0 and the contract holds; Box supports each stable version for at least 12 months and declares end of life 24 months ahead. The MCP tool surface has no equivalent handshake.
Box publishes 1,000 API requests per minute per user and 240 upload requests per minute per user. Search is the constraint a content agent actually hits: 6 searches per second per user, 60 searches per minute per user, and 12 searches per second per enterprise.
That enterprise-wide search ceiling is shared across every application in the tenant, not just yours. Box also meters API calls against a per-enterprise monthly allocation tied to the customer's plan. MCP tool calls are Box API calls; they count. Both paths return 429 with a retry-after header, and both need exponential backoff.
Pick either path and Box hands you the same object: an OAuth credential belonging to one user. What it does not hand you is anywhere to put it.
Box access tokens expire after 60 minutes. Refresh tokens are valid for 60 days or one use, whichever comes first, and every refresh returns a new pair that you must persist immediately. Authorization codes expire after 30 seconds.
Miss a write and the user is disconnected until they reauthorize. Two agent threads refreshing the same connection at the same time is exactly the race condition this model produces. Box handles some concurrent-refresh cases, but the burden of persisting the rotated pair is yours. The mechanics of getting this right are covered in how to handle token refresh for AI agents.
In a multi-tenant B2B agent, every user who connects Box is a separate rotating credential with its own expiry, its own revocation event, and its own tenant boundary. The path you chose changes the token profile. It does not change the count.
Tokens have to be encrypted at rest, isolated per tenant, never logged, and never placed in LLM context. When a customer churns or an employee leaves, you need to find and invalidate every credential tied to that identity. Neither Box MCP nor the Box REST API does any of this for you. The broader challenge of secure token management for AI agents at scale applies equally to both paths.
Scalekit's Box connector and Box MCP connector handle the OAuth flow, vaulted token storage, and automatic refresh for both paths. Credentials resolve server-side at call time and never touch the agent runtime. The MCP versus API decision stops being an auth architecture decision.
Both connectors sit behind the same SDK and the same three calls: authorize the user, retrieve the tools that user is authorized to call, execute. The connector name is the only thing that differs.
Register a Box OAuth application once, add the Scalekit redirect URI to it, and store the client credentials in the dashboard. Enable at least root_readonly and root_readwrite in Box; add manage_webhook, manage_groups, or manage_enterprise_properties only for the tools you actually call.
Each user who connects Box becomes a connected account keyed by an identifier you control. The connection_name string must match the connection name configured in your Scalekit dashboard exactly; this is the most common integration error.
The Box connector exposes 102 tools. Handing all of them to a model is the failure mode, not the feature: at roughly 200 tokens per definition, that is somewhere near 20,000 tokens of tool schema before the agent reads a single file, and a decision space no model selects well from.
actions.langchain.get_tools() returns the tools the current user's connected account is authorized to call, and a tool name filter narrows that further to the job at hand.
The tools come back as native StructuredTool objects, so nothing about the loop below is Scalekit-specific. The full walkthrough lives in the LangChain code sample, and the pattern is unpacked further in LangChain tool calling.
Moving the same agent onto Box's MCP server is a connection name change. The tools come back prefixed boxmcp_ instead of box_, and the surface narrows to the 44 tools Scalekit's Box MCP connector currently exposes.
A contract agent rarely stops at Box. It reads the file, checks the CRM record, and posts to Slack. Wiring three separate MCP servers, each with its own auth and its own full tool list, is where multi-tool agents get expensive.
A Virtual MCP server is one endpoint that declares exactly which connections and which tools an agent role can see. You create it once per role, not once per user, and mint a short-lived session token bound to a specific user before each run.
The agent sees four tools instead of Box's full surface plus Slack's. The endpoint is static across every user; the identity attached to it is not.
The connector solves the credential problem. Three things after that are what make a Box agent survive an enterprise security review.
A shared Box service account is the default shortcut, and it destroys attribution. Every file read and every folder search shows up in Box's own audit trail as the bot, with admin-level reach that ignores collaboration scope and folder permissions. That failure is the subject of agent tool observability and the broader discussion in audit trails for agent auth.
Scalekit resolves the authorizing user's token at call time, so Box enforces that user's real permissions and Scalekit records who triggered the call, which tool ran, and what came back. The Box connector page documents 90 days of tool-call history, exportable to a SIEM. That is the difference between answering an auditor and guessing.
Storing a token is table stakes. The production question is whether this agent, calling this tool, for this tenant, in this scope, is permitted. Scalekit checks that before the request reaches Box rather than trusting a prompt to hold the line.
For Box specifically that matters because a root_readwrite token is broad by design. Tool-level scoping is how you narrow a delete-capable credential down to a read-and-tag agent. The reasoning is spelled out in access control for multi-tenant AI agents.
Each customer's Box credentials live in a per-tenant namespace. One Virtual MCP definition serves every user, and the session token minted before each run is what binds the endpoint to an identity. There is no per-user server to configure and no cross-tenant reachability to reason about.
The same pattern carries across connectors, so adding Salesforce or Slack to a Box agent does not mean a second auth implementation. Working examples are in the deal room sync agent and offer letter routing agent templates, and the broader argument in how tool calling auth changes when you move from single-tenant to multi-tenant.
If your Box agent is interactive and read-heavy, users asking questions across their own files and Hubs with Box AI doing the retrieval, the remote MCP server is a legitimate choice. Box maintains it, OAuth handles consent, and the default tool set covers that workload well.
If your agent writes, signs, provisions, or runs on a schedule, build against the REST API. The absence of JWT and Client Credentials Grant on the MCP path is not a gap waiting to be filled; it is what the server is for. So is the absence of Box Sign, webhooks, and governance endpoints.
Does your agent need to act without a user in the browser, or take an action Box has not exposed as a tool? If yes, the REST API is the only production-viable path. If no, MCP is on the table, and the per-tenant admin dependency becomes the thing to plan around rather than the thing that blocks you.
Either way, you end up holding one rotating Box credential per user, and that is infrastructure neither path builds for you.
The same analysis for the content platforms Box usually sits next to: Google Drive MCP vs API, SharePoint MCP vs API, and Dropbox MCP vs API.
Start with the Box connector docs for the REST path or the Box MCP connector docs for the MCP path. The Box connector page has the full tool list, framework snippets, and starter prompts, and the Box MCP connector page covers the MCP variant.
Browse the full connector catalog to add Salesforce, Slack, or Google Drive to the same agent, check the agent templates for working multi-tool patterns, and see AgentKit pricing for volume.
Building on Box and hitting something this article did not cover? Join the Scalekit Slack community or talk to an engineer for help on your specific setup.
