Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-lokalise-server create a translation key 'home_title' with English and Spanish translations"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for managing Lokalise translations.
✅ Create translation keys with multiple language translations
✅ Get specific translation key details by name
✅ Delete translation keys
Related MCP server: i18n-mcp
npm installThe server can be used with any MCP-compatible client. It provides three main tools:
Create a new translation key with translations:
{
"key_name": "my_new_key",
"translations": {
"en": "Hello World",
"de": "Hallo Welt"
}
}Get details for a specific translation key by name:
{ "key_name": "my_key" }Delete a translation key by ID:
{ "key_id": "123456789" }Create your API token here: https://app.lokalise.com/profile#apitokens
The server uses environment variables for configuration:
LOKALISE_PROJECT_ID - Your Lokalise project ID
LOKALISE_API_TOKEN - Your Lokalise API token
LOKALISE_PLATFORMS - Comma-separated platforms (default: web)
Add to your MCP client configuration:
{
"mcpServers": {
"lokalise": {
"command": "node",
"args": ["/path/to/mcp-lokalise-server/index.js"],
"env": {
"LOKALISE_PROJECT_ID": "your-project-id",
"LOKALISE_API_TOKEN": "your-api-token",
"LOKALISE_PLATFORMS": "web"
}
}
}
}Create a new translation key in Lokalise with translations
| Name | Required | Description | Default |
|---|---|---|---|
| key_name | Yes | The name/identifier for the translation key | |
| translations | Yes | Translation values by language code (e.g., {"en": "Hello", "de": "Hallo"}) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says 'Create a new translation key' but does not disclose behaviors like idempotency, error handling, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) and to the point. No wasted words, though it could benefit from slight restructuring for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 params, no output schema), the description is adequate but lacks details about return values, creation confirmation, or error conditions. It is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described in the schema. The description adds minimal value beyond the schema, only hinting at the 'translations' parameter. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create' and resource 'translation key in Lokalise', and it distinguishes from sibling tools (delete_lokalise_key, get_lokalise_key) by indicating a creation operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It merely states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a translation key from Lokalise
| Name | Required | Description | Default |
|---|---|---|---|
| key_id | Yes | The ID of the key to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry all behavioral information. It only says 'delete' without mentioning that it is destructive, irreversible, or requires permissions. Significant transparency gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, clear and front-loaded. Efficient but could be expanded slightly to include behavior without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool with no output schema, the description is minimal but functionally complete. However, lack of behavioral context (e.g., irreversibility, permissions) reduces completeness for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and describes key_id. The description adds no meaning beyond what the schema provides. Baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'delete' and the resource 'translation key from Lokalise', with a specific verb and resource that distinguishes it from sibling tools like create and get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or context provided. The description simply states what it does without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific translation key from Lokalise by name
| Name | Required | Description | Default |
|---|---|---|---|
| key_name | Yes | The name of the key to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description is minimal, not disclosing authorization, error handling, or behavior for missing keys. Adequate for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single focused sentence, no fluff, front-loaded information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one param, no output schema. Description does not specify return structure or error cases, which would aid completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description adds no extra meaning beyond 'the name of the key to retrieve'. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Get', resource 'translation key', source 'from Lokalise', and retrieval method 'by name'. Distinct from sibling tools create and delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when needing a specific key by name, but no explicit when-to-use or when-not-to-use guidance. Sibling tools listed but no alternative differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The three tools are clearly distinct: create, delete, and get are non-overlapping operations on translation keys.
All tools follow the exact pattern 'verb_lokalise_key' with consistent snake_case naming.
With only 3 tools, the server is very focused but borderline thin for a typical scope; however, it fits a minimal key management surface.
Missing essential operations like updating or listing keys, which creates significant gaps for common workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Crowdin — projects, files, strings, translation progress, tasks, and members.
MCP server for Translation Services
Lingo.dev MCP Server - World-class i18n implementation with ICU MessageFormat.
Translate MCP — wraps LibreTranslate API (https://libretranslate.com/)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mert574/mcp-lokalise-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
