Your agent needs to read and act on Smartling. Maybe it triages translation issues before a release, pushes new UI strings into a job, or gives product teams on-brand machine translation inside their workflow. Smartling ships a hosted MCP server and a large REST API. They overlap, but they are not the same object: different capability coverage, different identity models, different failure modes in production. Here is how to pick.
Both paths hit the same Smartling account. What differs is who the agent acts as, and how much of the platform it can reach.
Smartling launched its Model Context Protocol (MCP) server on August 19, 2025. It is a remote server built and maintained by Smartling, reachable from any MCP client over Streamable HTTP. Smartling routes MCP translation requests through its MT API, using the MT profile configured under AI Hub, Instant MT, MT API in the Smartling dashboard.
Auth changed recently. As of August 3, 2026, new connections must use an OAuth 2.1 login in the browser; older token-based connections keep working. Smartling's help center also notes that using every tool requires the Account Owner role. Other users can authenticate and call only the tools their permissions allow.
Official reference: the Smartling Help Center article "Smartling MCP Server: Connect Your AI Chat Tools to Smartling".
The REST API spans translation (Files, Jobs, Job Batches, Strings, Context, MT), translation management (Issues, Tags, Reports, Estimates, Attachments, quality checks), and account management (projects, locales, people). GraphQL APIs cover content search and translation memory. Smartling describes the API as a paid resource, priced through your Customer Success Manager.
Auth starts from an API token: a user identifier and user secret scoped to an account or a single project. Your code exchanges them for a bearer access token.
Official reference: the Smartling API reference site and the Help Center "Overview of the API" article.
The MCP surface is strong for job, string, and issue operations. The gaps show up around files, job lifecycle end states, and event subscriptions.
The biggest gap is files. Smartling's help center is explicit: the MCP server does not upload files into a project with string parsing and translation workflows. Translation through MCP is instant MT or LLM output with no human in the loop, and nothing is written to translation memory. Smartling points file-based project workflows to its separate CLI MCP, a Docker image that wraps smartling-cli and authenticates with API credentials.
The string path is more complete than it looks. An agent can call smartlingmcp_smartling_create_strings, attach them with smartlingmcp_smartling_add_strings_to_job, then smartlingmcp_smartling_authorize_job. That is a real workflow submission. What it cannot do is cancel, close, or delete the job afterwards.
If your agent must react when a job completes, the MCP tools only help at creation time: smartlingmcp_smartling_create_job accepts a callback_url. Webhook subscriptions, which cover recurring events across a project, are managed only through the dashboard or the API. Smartling signs webhook deliveries with HMAC-SHA256, may deliver out of order or twice, and disables a subscription after 96 hours without a successful delivery.
The 53 Smartling tool descriptions on Scalekit's connector page run to roughly 73,000 characters. At about four characters per token, that is on the order of 18,000 tokens before your agent does any work. Several descriptions also carry instructions such as "Must ask user if not provided" for target_locale, which stall a headless run.
Loading the full server into every context window is an accuracy problem and a cost problem. The fix is not better prompting. It is surface reduction, which the Scalekit section below shows in code. For a broader discussion of why MCP can be significantly more expensive than CLI approaches, that tradeoff is worth understanding before you commit to a tool surface.
This is where the two paths diverge most for B2B agents. MCP gives you user identity. The API gives you integration credentials.
The MCP host opens a browser, the user logs in to Smartling, and authorizes access. The resulting token acts as that user, with that user's roles. The full tool set, including account-level tools such as smartlingmcp_smartling_find_account_issues, needs the Account Owner role; other users get what their permissions allow. What the user can't do, the agent can't do.
The consent step needs a person at a browser once. After that, a background agent can keep acting for that user, as long as someone stores and refreshes the token.
The API has no documented third-party OAuth flow. Your code posts the user identifier and secret to /auth-api/v2/authenticate and receives an access token (expiresIn of 480 seconds) plus a refresh token (refreshExpiresIn of 3,660 seconds). Every token pair belongs to one session with a maximum lifespan of 12 hours, no matter how often you refresh.
Near the end of a session, refreshed tokens come back with shrinking lifetimes, then requests fail with 401. Smartling's guidance is to watch refreshExpiresIn shrink and re-authenticate with the identifier and secret. A long-running agent must implement that state machine correctly, per credential.
An API token represents an integration scoped to an account or project, not an individual end user. The tokens themselves don't expire, so each customer hands you a long-lived secret to vault, and every action through it carries the integration's permissions.
Both paths require per-user credential isolation in a multi-tenant B2B agent. MCP's OAuth flow gives you a token per user. Direct API calls give you a credential per customer or project. In neither case does the path itself solve storage, rotation, or revocation. Those are infrastructure problems regardless of which path you choose. For a deeper look at who holds the token across different agent tool-calling patterns, it is worth reviewing how credential ownership maps to your architecture.
The split is predictable: Smartling owns more of the tool layer on MCP, and you own nearly everything on the API.
Smartling maintains the tool schemas and maps them onto its APIs. When Smartling adds tools, your agent can pick them up without a code change. The flip side is that MCP tool schemas are not versioned the way REST endpoints are, so descriptions and parameters can shift under you.
You still own token storage, refresh, revocation when a user disconnects, and tenant isolation. You also own tool selection, since exposing all 53 tools to every run is expensive and error-prone.
You own everything: endpoint selection, request construction, the credential exchange and 12-hour session logic, 429 MAX_OPERATIONS_LIMIT_EXCEEDED backoff (limits vary by endpoint and count per user, project, or account), 202 ACCEPTED polling for long-running uploads, and webhook signature verification.
That is more surface area and more control. You get the Files API, job lifecycle endpoints, and webhook subscriptions the MCP server does not expose. Every tool schema your agent needs is one your team writes, tests, and maintains.
Both lists below are specific to Smartling workloads. Many production localization agents end up using both.
Pick either path and you still hold N credentials for N users or customers. The token type differs. The infrastructure required is the same.
On MCP, each user's OAuth token must be encrypted at rest, isolated per tenant, refreshed before expiry, and revoked when the user leaves or disconnects. On the API, each customer's identifier and secret must be vaulted, and your runtime must manage 480-second access tokens and 12-hour sessions without two workers refreshing the same session at once.
Neither Smartling path gives you a token vault, refresh coordination, or a signal when a user's authorization breaks. Your agent learns about it from a 401 in the middle of a job. Understanding how to handle token refresh for AI agents is foundational before building either integration in production.
Scalekit's Smartling connector handles the OAuth 2.1 flow, token storage, and refresh for the MCP path per user, so credentials never touch the agent runtime. The next section shows the code.
Recommended reading: How to handle token refresh for AI agents and Token vault for AI agent workflows.
The Scalekit Smartling MCP connector routes tool calls to Smartling's own MCP server. Each user signs in to Smartling once; Scalekit stores and refreshes their tokens. The examples below use Python and LangChain.
Create a Smartling MCP connection in the Scalekit dashboard under AgentKit, Connections. The connection name in your code must match the dashboard name exactly; mismatched connection names are the most common integration error. The examples assume smartlingmcp, plus slack for the multi-tool example.
Each end user gets a connected account keyed by your own identifier. If the account is not active, send the user an authorization link; Scalekit completes the OAuth exchange and marks the account ACTIVE. Smartling expects agents to resolve the account UID first, so the first call does exactly that.
In production, switch the connection's user verification mode from None to a custom verifier, so the person who completes the Smartling login is the user your app intended to connect.
The agent should not load a flat connector catalog. actions.langchain.get_tools calls list_scoped_tools under the hood: it returns only tools bound to this user's connected account, and the tool_names filter narrows those to what this job needs. Six tools instead of 53 keeps selection accurate and context small. Scalekit returns native LangChain StructuredTool objects, so no schema reshaping is needed. For more on how LangChain tool calling works and where it stops, the pattern here extends directly from those fundamentals.
With the scoped tools bound, execution is a standard tool-calling loop. Every tool invocation runs through Scalekit with this user's Smartling token.
For a full LangChain walkthrough, see the Scalekit LangChain example in the docs.
Localization agents rarely touch Smartling alone. A release agent reads Smartling issues and posts to Slack; a string-sync agent reads a GitHub diff and creates Smartling strings. A Virtual MCP server gives each agent role one scoped endpoint across several connectors.
The server declares which connections and which tools the agent can see. You get a static mcp_server_url reused for every user. Omit tools on a mapping only if you truly want every tool from that connection.
The endpoint is static; the identity is not. Before each run, confirm the user's Smartling and Slack accounts are active, then mint a short-lived session token bound to that user. The default expiry is about an hour, and create_session_token is also how you remint. Never share a session token across users.
The authorization links returned by list_mcp_connected_accounts are short-lived, so surface them to the user immediately rather than storing them.
One server definition serves every customer. Each run carries only one user's Smartling and Slack credentials, so an agent working for tenant A cannot reach tenant B's projects. The Smartling surface drops from 53 tools to four, which cuts context overhead and removes destructive tools such as smartlingmcp_smartling_delete_issue_comment from reach entirely.
There is no MCP server for you to deploy, host, or maintain. Configure the connections, map the tools, mint a token per run.
Recommended reading: Virtual MCP servers for scoped, per-user agent access and Access control for multi-tenant AI agents.
When a localization agent authorizes the wrong job, the first question is who did it, with which credential, and when. Scalekit answers that at the auth and tool-call layer.
Every execute_tool response carries an execution_id, and the AgentKit Connected Accounts view in the dashboard shows each account's status, token refresh history, and tool execution logs. Each call is tied to the acting user's identifier, not a shared service credential.
For proactive handling, subscribe to the connected_account.status_updated and connected_account.token_refresh_failed webhooks. A user loses Smartling access? Pause the agent, prompt re-authorization, and stop before the job fails halfway. More on this in agent tool observability.
Scalekit's catalog covers Smartling through the MCP connector. Smartling's REST auth is a credential exchange with short-lived tokens and 12-hour sessions, not a static key, so it does not map cleanly onto a static BEARER or API_KEY custom connector. If your agent needs Files API or webhook coverage alongside MCP, talk to the Scalekit team about the right setup.
If your agent works at the string, job, and issue level, especially for interactive assistants or multi-tool release agents, Smartling MCP is the faster path. You get per-user identity, maintained tool schemas, and instant MT with your glossaries.
If your agent moves resource files through Smartling projects, reacts to webhooks, or needs job cancellation and translation memory writes, use the REST API. The MCP server's instant-MT-only translation and missing Files API are product boundaries, not configuration options.
Most production localization agents run both: MCP for user-facing triage and string submission, the API for file-based pipelines. Either way, the credential problem is the same, and that needs production-grade infrastructure. The common production problems, patterns, and anti-patterns for tool-calling agent auth are worth reviewing before you finalize your architecture.
Building a Smartling agent for many users or customers? Talk to the Scalekit team for immediate help with connection setup, Virtual MCP design, and multi-tenant rollout.
