Your agent needs to work inside Lokalise: find untranslated keys, open translation tasks, pull files before a release. Lokalise now runs an official MCP server next to the REST API it has maintained for years. Both are official, and both hit the same backend and the same rate limits. They still put your agent on different capability surfaces, different auth paths, and different maintenance obligations. The gap widens once the agent runs headless, for many users, across many tenants. Here's the decision framework.
Both paths share a backend and a permission model. The difference is who designs each call: Lokalise, or your team.
Lokalise hosts the MCP server itself, and it is still in beta. It ships as two toolkits on separate endpoints: Project Management (PM) at /mcp/project-management for projects, tasks, contributors, languages, files, keys, and glossary, and Software Development (SD) at /mcp/software-development for projects, tasks, keys, and screenshots. Any team on a plan with API access can use it, though Lokalise documents it for Lokalise Expert and not Lokalise Vantage.
Clients authenticate with OAuth 2, which Lokalise recommends, or with a personal API token in an apikey header. Either way, the agent inherits the permissions of the user behind the token.
The REST API (APIv2) is the full platform surface: projects, keys, translations, files, tasks, contributors, glossary, screenshots, webhooks, snapshots, orders, and team administration, plus branch-aware endpoints, an over-the-air (OTA) API, and audit logs.
It authenticates two ways. A personal API token, read-only or read/write, goes in the X-Api-Token header. To act on behalf of other users, Lokalise supports the OAuth 2 Authorization Code flow, with access tokens that usually expire after an hour and a refresh-token grant to renew them.
Four dimensions decide the choice: capability coverage, the auth path, what you own in production, and where each path wins.
The MCP toolkits cover the everyday developer and localization-manager loop. The gaps appear when an agent needs to react, clean up, or work at scale.
The MCP surface is almost entirely additive. The only delete among its documented actions removes a screenshot. That suits IDE agents and blocks cleanup or migration agents. Event-driven work is API-only as well: there are no webhook tools, and the documented actions include no way to check an upload's queued process.
Exports are the ambiguous case. Lokalise's product page and launch post describe file downloads in the SD toolkit, but the Help Center's action table leaves them out. Call tools/list on that endpoint before your agent depends on it. Lokalise's own guidance is explicit that MCP does not expose every REST operation.
The MCP server prefers OAuth 2. In Claude Code, you add each toolkit endpoint, restart, and accept the authentication prompt; the client holds the resulting token. The alternative is a personal API token in the apikey header. A read-only token covers listing keys and checking progress, and anything that creates, updates, or uploads needs a read/write token.
In both modes, permissions follow the user who authorized the connection. If that user has no access to a project, neither does the agent. What the user can't do, the agent can't do.
Personal API tokens are self-serve and fit headless jobs: no redirect, no refresh cycle. The cost is scope. A token carries its creator's project permissions, narrowed only by its read-only or read/write type, so least privilege depends on who issued it.
OAuth 2 is the per-user delegation path, and it has friction for agent builders. There is no self-serve app registration; you contact Lokalise support with your app details and the scopes you need. Only the Authorization Code grant is supported, and access tokens expire after about an hour.
Both paths require per-user credential isolation in a multi-tenant B2B agent. MCP's OAuth flow gives you a token per user. The API gives you a credential per user. In neither case does the path itself solve storage, rotation, or revocation; those are infrastructure problems regardless of which path you choose. The failure modes are covered in access control for multi-tenant AI agents.
Lokalise owns hosting, tool definitions, and schema updates, and new tools arrive without a redeploy on your side. You still own the credential the client holds and the rate budget, because MCP calls count against the same limits as your REST integrations.
You also own change management. The server is in beta, and Lokalise plans to add toolkits, including translator-focused ones, so the tool list your agent sees will shift. Audit coverage has a plan boundary too: Lokalise's Audit Log records MCP actions on Enterprise plans, and elsewhere your trail depends on Lokalise's activity records plus whatever your client keeps.
Everything. Pagination metadata arrives in response headers, including the X-Pagination-Next-Cursor value that cursor pagination on keys and translations depends on. Uploads return a queued process you poll until it finishes. Synchronous downloads stop at 10,000 key-language pairs, so larger projects need the async endpoint and another poll.
Webhooks are unsigned: Lokalise sends a shared secret in X-Secret, expects a 2xx within 8 seconds, and disables the handler after 24 hours of failed retries. Then there are the 429s, at 6 requests per second per token or 10 concurrent requests per project, and the retry logic they demand.
Choose either path and the credential count comes out the same: one Lokalise credential per user, per tenant.
Take a localization agent serving 40 customer workspaces with 5 users each. That's 200 Lokalise credentials, whether they came from MCP OAuth or personal API tokens. Each one must be encrypted at rest, isolated per tenant, kept out of prompts and logs, and revoked when its owner leaves. OAuth tokens add a refresh cycle; Lokalise's REST access tokens last about an hour. API tokens skip refresh, but they are static secrets someone has to rotate and revoke by hand. Neither MCP nor the API gives you a vault, a rotation policy, or a revocation flow.
Scalekit's Lokalise connector moves that work into the infrastructure layer. Each user adds their Lokalise API token once through a Scalekit-hosted page. Scalekit stores it in its token vault as a connected account and injects it into every call, so credentials never touch the agent runtime. The MCP vs API decision no longer changes your auth infrastructure. For the tradeoffs between the two credential types, read OAuth vs API keys for AI agents.
Every path below follows the same shape: create the connection once, connect each user once, then call tools through execute_tool, a framework adapter, or a Virtual MCP server. Create the Lokalise connection under AgentKit > Connections using the Lokalise connector docs, then set SCALEKIT_ENVIRONMENT_URL, SCALEKIT_CLIENT_ID, and SCALEKIT_CLIENT_SECRET. The connection_name in code must match the connection name in the dashboard exactly; a mismatch is the most common integration error.
Before the agent acts for a user, confirm their connected account is ACTIVE. If it isn't, send them the authorization link. For an API-key connector like Lokalise, that link opens a hosted form that collects their token, so your code never handles it.
Not every Lokalise workflow needs a model in the loop. A nightly job that finds untranslated keys and queues an AI translation task is a fixed sequence, so it calls execute_tool directly. It pages with offsets on purpose: Lokalise returns the next cursor in a response header, and tool results carry the response body, not headers.
Node.js teams make the same call with executeTool, passing the connection name as connector. Save the file with an .mts extension so top-level await works.
actions.langchain.get_tools doesn't hand the model a flat connector catalog. It retrieves the tools this user's connected account is authorized to call and returns them as native LangChain tools. Scope matters here because the connector ships 109 tools. At the roughly 200 tokens per tool Scalekit uses as a rule of thumb, that's over 20,000 tokens before the agent does any work, and Lokalise schemas run large: the async export tool alone takes 27 parameters. Filter with tool_names. Paging is a trap; a page_size of 100 silently drops 9 tools.
A Virtual MCP server gives you the MCP interface with no MCP server to deploy, host, or maintain. You define it once per agent role and choose which connections and tools it exposes. Everything else in the Lokalise catalog, including lokalise_delete_project, lokalise_create_order, and lokalise_create_payment_card, doesn't exist for that agent. This server pairs three Lokalise tools with Slack's slack_send_message for a release agent.
Before each run, confirm the user's connections are active and mint a short-lived session token. The URL stays static; the identity rides on the token. The agent loop is the LangChain loop from above, now running over MCP.
The 109 tools skip branch management, the OTA API, and audit logs, and they can't finish cursor pagination. For those, actions.request proxies a raw call to the Lokalise API through the same connected account. You pass the path, Scalekit resolves the base URL and injects the user's token, and you get the full HTTP response back: a requests.Response in Python, an Axios response in Node.js. That makes X-Pagination-Next-Cursor readable. Proxy access is on by default, and the custom tools guide covers the pattern.
Getting a first call working is the easy part. These properties decide whether a Lokalise agent survives production.
Every execute_tool call returns an execution_id, and the AgentKit dashboard shows each connected account's status and tool execution logs. When Lokalise rejects a call, the SDK raises a ScalekitTool* exception carrying the provider's error code, message, and that execution ID, so a failed nightly run traces to one user, one tool, and one call. Rate limits stay legible too: Scalekit tags its own 429s RATE_LIMITED and upstream ones TOOL_ERROR. Lokalise's own Audit Log for MCP actions needs an Enterprise plan. For the compliance angle, see audit trails for agent auth.
A release agent rarely touches Lokalise alone. It reads keys, opens a task, posts to Slack, and maybe checks a pull request in GitHub. A Virtual MCP server turns that surface into one endpoint per agent role. One server definition serves every tenant, and each run gets a short-lived session token bound to one user's connected accounts, so there is no credential sharing between users and no per-user server configuration. Set up once per agent role; mint a token before each run. The endpoint is static; the identity is not.
Lokalise's API can spend money and destroy data, and the connector mirrors it. lokalise_empty_project deletes every key in a project, lokalise_create_order places a paid translation order, and lokalise_create_payment_card adds a billing card. A progress-reporting agent needs none of them. Scoping the catalog to 5 to 10 tools cuts tool-definition tokens by more than 90% and takes those actions out of the blast radius. The fix is not better prompting. It is surface reduction. For a deeper look at tool calling auth patterns and anti-patterns, that post covers the design principles behind catalog scoping.
Users rotate Lokalise tokens and leave companies. Scalekit's connected_account.status_updated webhook fires on every status transition with the old and new status, so an agent can pause and prompt the user instead of failing mid-run. If a token is revoked inside Lokalise, the next call raises ScalekitToolUnauthorizedException; send the user back through get_authorization_link to add a fresh token. For patterns around secure token management for AI agents at scale, the full lifecycle is covered there.
Lokalise's own guidance draws the line in the same place: MCP for interactive, conversational work, the REST API for production automation. If your agent works alongside a person, such as a developer adding keys from Cursor or a manager assigning tasks from Claude, start with the MCP server. If it runs headless, reacts to webhooks, manages branches, or moves thousands of keys, build on the API, because it is the only complete surface.
Scalekit narrows the gap from both sides: its Lokalise tools call the REST API, and a Virtual MCP server delivers a scoped slice of them over MCP. Either way, the credential problem is identical, and that is the part that needs production-grade infrastructure.
If you're building Lokalise agents for many users and want a second pair of eyes on the auth design, talk to us for immediate help. To start on your own, the Lokalise connector docs list all 109 tools and their parameters, the connector catalog shows the other tools your agent can reach on the same auth plumbing, and pricing lays out the plans. For multi-tool patterns, start from the auto release notes agent or DevOps assistant agent templates. Other posts in this series compare GitHub MCP vs API and Slack MCP vs API.
