Manage translation projects, phrases, locales, dictionaries, and team data with secure, organization-scoped tools and interactive translation views.
Scored across 17 tools
Most tools have clearly distinct resource+action purposes, but get_project and show_project_overview overlap substantially—both return a project's default locale, configured locales, and timestamps, making selection hard. The phrase readers (list_phrases, search_phrases, export_locale_dictionary, get_phrase) overlap but descriptions successfully differentiate them.
All 17 tools follow a consistent snake_case verb_noun pattern (add_locale, delete_phrase, list_projects, update_phrase, find_missing_translations, show_project_overview). No mixed conventions or ambiguous verbs appear.
17 tools for a full localization management domain (projects, locales, phrases, sharing, QA) is reasonable and each earns a place, though it edges toward heavy. Nothing feels redundant except the project overview/get pair.
Phrase lifecycle is well covered (add, get, list, update, delete, search, share), but projects lack a delete operation and team support is read-only with no invite/remove, an explicit gap noted in the description. Delete coverage for projects/locales is a notable missing operation.
Use this when someone asks to add a new language to a project and translate their strings into it. Returns the updated language list and how many strings were machine-translated, one per key, all before anything is saved, so a very large project can time out. Not for a language the project already has.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Translation model id; defaults to gpt-6-luna | |
| locale | Yes | Locale code to add, such as it or pt-BR | |
| context | No | Note applied to every translation in this run, up to 600 characters | |
| project | Yes | Project id or name |
| Name | Required | Description |
|---|---|---|
| locale | Yes | |
| status | Yes | |
| locales | Yes | |
| project | Yes | |
| translationCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds critical behavioral context beyond annotations: it specifies the return payload (language list and translation count), notes that translations occur before saving, and warns that large projects can time out. However, it doesn't elaborate on the destructive nature (e.g., what data is overwritten or affected).
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?
Three tightly packed sentences that are front-loaded with purpose and usage, then behavioral details. No wasted words; every sentence adds value.
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 complexity (dual add+translate operation), the description covers what the tool does, when to use it, what it returns, and key caveats (timeout risk). With an output schema present, it doesn't need to detail return values. Annotations cover safety aspects. Nothing critical is missing for an agent to decide and invoke correctly.
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%, so all parameter descriptions are in the schema. The description adds no parameter-level details beyond what the schema provides. It mentions 'language' and 'strings' generically but doesn't map to specific parameters like locale, model, or context.
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?
States a specific verb (add) and resource (language/locale), with the implied translation action. Distinguishes from siblings clearly - no other tool handles adding a locale. The description makes the dual nature (add + translate) explicit.
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?
Explicitly states when to use ('when someone asks to add a new language...') and provides a clear exclusion ('Not for a language the project already has'). This prevents the agent from attempting to add an existing locale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks to add a new string or key to their app's translations. Returns the created key with one machine translation per configured locale, made from the source text in the default locale. A key that already exists returns already-exists and is left unchanged. Not for changing an existing translation.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | New key, 1 to 256 characters | |
| model | No | Translation model id; defaults to gpt-6-luna | |
| value | No | Source text in the default locale, up to 2,000 characters; defaults to the key itself | |
| context | No | Note for the translator that disambiguates the string, up to 600 characters | |
| project | Yes | Project id or name |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| status | Yes | |
| locales | Yes | |
| project | Yes | |
| defaultLocale | Yes | |
| translationCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and idempotentHint=false, and the description adds genuinely non-obvious behavior: the collision case returns already-exists and leaves the key unchanged, and creation auto-generates one translation per configured locale from the default-locale source text. It does not explain why the operation is flagged destructive or whether generated translations overwrite anything, leaving a small gap.
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?
Three tight sentences: trigger, behavior/return, and exclusion. The most decision-relevant information (when to use it and what it returns) is front-loaded with no filler.
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?
Return values are covered by an output schema and the safety profile by annotations, so the description's remaining job is trigger conditions and edge behavior — both supplied via the already-exists no-op rule. An agent has everything needed to call this correctly.
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 description coverage is 100%, so every parameter (key length, model default, value default, context, project) is already documented in the schema. The description restates the value/model semantics at a high level ("source text in the default locale") without adding syntax or format detail, so the 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?
States a specific verb+resource (add a string/key to translations) and summarizes the return payload: the created key plus one machine translation per configured locale. It is clearly distinguishable from update_phrase and delete_phrase, and the sibling set confirms this is the creation path.
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?
"Use this when someone asks to add a new string or key" gives a clear trigger condition, and "Not for changing an existing translation" supplies an explicit exclusion. It stops short of naming update_phrase as the alternative for that case, so the routing is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks to create a new localization project with a given name and languages. Returns the new project with its default locale and locales; if the name is taken it returns already-exists and creates nothing. Not for adding a language to an existing project.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the new project, 1 to 128 characters; a URL-safe slug such as my-app is easiest to reference later | |
| locales | No | Other locale codes to start with, such as it or de; the default locale is added automatically | |
| defaultLocale | Yes | Locale code of the source language, such as en |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| project | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, openWorldHint=false, and idempotentHint=false, so the safety profile is covered. Beyond that, the description adds real behavioral context absent from the annotations: the duplicate-name case returns 'already-exists' and creates nothing, and the success case returns the project with its default locale and locales.
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?
Three sentences, front-loaded with the trigger condition, followed by return/error behavior and the exclusion. No sentence is redundant and nothing is buried.
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?
An output schema exists so return values need no further explanation, yet the description still summarizes the meaningful returns and the failure mode. With full parameter coverage and annotations carrying the safety profile, nothing needed to call this tool correctly is missing.
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 description coverage is 100%, so the schema already documents name, locales, and defaultLocale fully, including format and the fact that the default locale is added automatically. The description adds no syntax or format detail beyond that, so the baseline of 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?
The description states a specific verb and resource ('create a new localization project') and scopes it with the inputs that matter (name and languages). It also carves out the adjacent operation, so an agent can distinguish it from add_locale without opening either schema.
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?
It gives an explicit trigger ('Use this when someone asks to create a new localization project') and a clear exclusion ('Not for adding a language to an existing project'). The exclusion implies add_locale but never names it, so routing is clear but not maximally explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks to remove a key from their translations. Returns how many language rows were deleted and which other projects shared them; a shared string is deleted permanently for those projects too. Not for removing only one language's translation.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Exact key to delete in every language | |
| project | Yes | Project id or name that has the key |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| status | Yes | |
| project | Yes | |
| sharedProjects | Yes | Other projects the deleted string was also removed from |
| deletedTranslationCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so safety is covered. The description adds genuinely new context beyond them: the cross-project blast radius ('a shared string is deleted permanently for those projects too') and the deletion count returned. It does not explain the non-idempotent behavior, which the annotations flag.
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?
Three tight sentences with the usage trigger front-loaded, then the side-effect warning, then the exclusion. Every sentence carries information and none is wasted.
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?
With an output schema present (return values needn't be described) and annotations covering the safety profile, the description supplies the remaining critical piece an agent needs: the permanent, multi-project consequence of deleting a shared string. Nothing essential is missing.
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 description coverage is 100%, so both parameters (key, project) are fully documented in the schema. The description reinforces that the key is deleted 'in every language' but adds no syntax, format, or lookup guidance beyond what is already there. Baseline 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?
States a specific verb (delete/remove) and resource (a key/string in translations) with the critical scope qualifier 'in every language', which distinguishes it from the many sibling phrase tools like update_phrase or add_phrase. An agent can identify the operation without opening the schema.
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?
'Use this when someone asks to remove a key from their translations' gives clear positive context, and 'Not for removing only one language's translation' gives an explicit exclusion. It stops short of naming the sibling tool that handles single-language removal, but the boundary is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants the key and value pairs of one language, for example to review or copy a translation file. Returns up to 50 entries per call (25 by default) sorted by key, values cut to 500 characters, with nextSkip for the next page. Not for a complete file download, which the MultiLocale CLI provides.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | Keys to skip in alphabetical order, for paging: pass the previous nextSkip; defaults to 0, at most 10000 | |
| limit | No | Entries to return, from 1 to 50; defaults to 25 | |
| project | Yes | Project name; an id matches nothing | |
| language | Yes | Locale code to export, such as en |
| Name | Required | Description |
|---|---|---|
| skip | Yes | |
| status | Yes | |
| entries | Yes | Key and value pairs sorted by key, values cut to 500 characters |
| hasMore | Yes | |
| project | Yes | |
| language | Yes | |
| nextSkip | Yes | Pass as skip to get the next page; null on the last page |
| returnedCount | Yes | |
| valuesTruncated | Yes | |
| offsetCapReached | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite annotations already covering readOnly/idempotent/non-destructive, the description adds substantial behavior: page size (25 default, 50 max), alphabetical sort by key, 500-character value truncation, and the nextSkip paging contract. This is exactly the operational detail an agent needs to page correctly.
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?
Two sentences, front-loaded with the use case followed by the behavioral/paging contract and the exclusion. No filler and every clause carries 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?
With annotations covering safety and a full output schema plus 100% parameter coverage, the description only needs to add operational context – and it does, via paging, sorting, and truncation limits, plus a pointer away from the CLI for full downloads.
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%, so all four parameters are already documented with defaults and bounds. The description's mention of 50/25 and nextSkip largely restates the schema, adding paging semantics but no new parameter-level meaning; 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?
The description states a specific verb and resource: returning key/value pairs for a single language, tagged by intent ("to review or copy a translation file"). It explicitly rules out a complete file download, though it does not distinguish itself from sibling tools like list_phrases or search_phrases, which also surface phrase data.
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?
It gives both a positive trigger (reviewing or copying a translation file) and an explicit exclusion (complete file download belongs to the MultiLocale CLI). The exclusion points at a non-MCP alternative rather than a sibling tool, so the routing guidance is clear but not fully connected to the tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants to clean up a project by finding keys that repeat the same default-language text. Returns up to 25 repeated values with the keys that share them, scanning 1,000 default-locale strings by default and at most 2,000. Not for untranslated strings.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project id or name | |
| scanLimit | No | Default-locale strings to scan, from 1 to 2000; defaults to 1000 |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| project | Yes | |
| scanLimit | Yes | |
| duplicates | Yes | Up to 25 default-locale values used by more than one key, with up to 10 keys each and the other projects sharing them |
| defaultLocale | Yes | |
| scanTruncated | Yes | |
| duplicateCount | Yes | |
| phrasesScanned | Yes | |
| duplicatesTruncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, idempotent, read-only, closed-world operation, so the safety profile is covered. The description adds non-obvious behavioral detail the annotations lack: the 25-result cap, the 1,000 default scan and 2,000 hard ceiling. It does not explain truncation semantics or ordering, keeping it from a 5.
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?
Three sentences, zero filler: the usage trigger is front-loaded, the output shape follows, and the exclusion closes it out. Every sentence earns its place.
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?
The tool is a simple, read-only two-parameter query. Although an output schema exists and return values need not be explained, the description still usefully summarizes the return shape (repeated values plus the keys sharing them). Nothing needed to call it correctly is missing.
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%, so both parameters are already documented, including scanLimit's range and 1000 default. The description restates the same default and ceiling rather than adding syntax or meaning beyond the schema; 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?
States a specific verb and resource ('finding keys that repeat the same default-language text') and the goal (clean up a project). This clearly distinguishes it from sibling diagnostics like find_missing_translations even without naming them.
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?
Gives a concrete when-to-use trigger ('when someone wants to clean up a project by finding keys that repeat...') and an explicit exclusion ('Not for untranslated strings') that routes the agent toward find_missing_translations. It stops short of naming that alternative sibling directly, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks which strings are not translated yet, or how complete each language is. Returns completion percentages and up to 25 missing keys per locale, for one locale or up to 10, compared with the default locale. Nothing is translated or written. Not for filling in the missing translations.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project id or name | |
| language | No | One locale code to check; omit to check the configured locales | |
| scanLimit | No | Strings to scan per locale, from 1 to 2000; defaults to 1000 | |
| localeLimit | No | How many configured locales to check when language is omitted, from 1 to 10; defaults to 10 |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| locales | Yes | One row per checked locale with its completion and up to 25 missing keys; status partial means a scan cap was reached |
| project | Yes | |
| scanLimit | Yes | |
| defaultLocale | Yes | |
| localesTruncated | Yes | |
| sourceScanTruncated | Yes | |
| sourcePhrasesScanned | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotent/destructiveHint=false, and the description reinforces this with 'Nothing is translated or written.' It also adds concrete behavioral caps not in the annotations: up to 25 missing keys per locale, 1 or up to 10 locales, and comparison against the default locale.
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?
Three sentences, zero filler: the trigger comes first, the return shape second, the scope and exclusion last. Every sentence earns its place.
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?
With a full schema, annotations covering the safety profile, and an output schema present, the description supplies everything else an agent needs: trigger, return granularity, locale bounds, and the read-only guarantee.
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 its parameter descriptions already explain language, scanLimit, and localeLimit including the 1-10 range and default. The description's 'for one locale or up to 10' largely restates the localeLimit schema text rather than adding new meaning, so 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?
States a specific verb and resource ('which strings are not translated yet', completion completeness) and explicitly bounds scope against the fill-in sibling: 'Not for filling in the missing translations.' An agent can tell this apart from update_phrase/add_phrase without opening either schema.
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?
Gives an explicit trigger ('Use this when someone asks which strings are not translated yet, or how complete each language is') plus an explicit exclusion ('Not for filling in the missing translations'), which is exactly the when/when-not framing needed next to mutation siblings like add_phrase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks how one exact key is translated, in every language or in one. Returns that key's text per locale, up to 24 locales and 2,000 characters each, with machine-translation flags and the projects sharing it, and renders a phrase card. Not for searching keys by text.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Exact key, matched case-sensitively | |
| project | Yes | Project name; an id matches nothing | |
| language | No | One locale code such as en or it; every language when absent |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| status | Yes | |
| project | Yes | |
| translations | Yes | One row per locale, up to 24, values cut to 2,000 characters; projects lists every project sharing the row |
| translationCount | Yes | |
| translationsTruncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context: per-locale cap of 24 locales, 2,000 characters each, machine-translation flags, and that it renders a phrase card. It does not discuss errors when a key is absent, which keeps it from a 5.
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?
Two tightly packed sentences with zero filler; the usage trigger and the sibling exclusion are front-loaded, and the limits and rendered output are packed into the same second sentence.
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?
With an output schema present, return values need not be spelled out, yet the description still usefully sketches them (per-locale text, MT flags, sharing projects, phrase card). Combined with annotations covering safety and 100% schema coverage, an agent has everything needed to call this correctly.
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 description coverage is 100%, so all three parameters are already documented including the case-sensitive exact match and the 'every language when absent' default. The description mirrors this at a summary level ('one exact key', 'every language or in one') without adding new semantics, so the 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?
States a specific verb and resource ('how one exact key is translated, in every language or in one') and explicitly distinguishes itself from search_phrases with 'Not for searching keys by text.' An agent can route between get_phrase and search_phrases without opening either schema.
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?
Gives an explicit trigger ('Use this when someone asks how one exact key is translated'), a scope condition (every language vs one), and an exclusion ('Not for searching keys by text') that names the competing sibling capability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks about one localization project, such as which languages it has or its default locale. Returns the project's id, name, default locale, configured locales and creation and edit times. Not for how complete its translations are.
| Name | Required | Description | Default |
|---|---|---|---|
| projectIdOrName | Yes | Project id or name |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| project | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds the useful scope signal that this is a single-project lookup and enumerates returned fields, but says nothing about behavior on a missing/ambiguous project name — relevant since the parameter accepts a name as well as an id.
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?
Three tight sentences with the usage trigger front-loaded, followed by return contents and the exclusion. No filler, nothing to cut.
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?
With an output schema present, the description need not explain return values in depth, and annotations cover the safety profile. The description still names the returned fields and the scope limit, leaving nothing an agent needs in order to call it correctly.
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 description coverage is 100% and the single parameter is documented in the schema as 'Project id or name'. The description adds only the notion that it refers to one project and offers no format, ambiguity, or resolution guidance beyond that, so 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?
States a specific verb+resource ('get one localization project') and explicitly delimits what it is not ('Not for how complete its translations are'), which routes the agent away from the overview/statistics sibling. An agent can distinguish this from show_project_overview without opening either schema.
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?
Gives a concrete triggering condition ('when someone asks about one localization project, such as which languages it has or its default locale') and an exclusion. It doesn't name the alternative tool to use for completeness questions, so it stops just short of a full when/when-not/alternative statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks to see the translation strings in a project, optionally in one language or for one key. Returns up to 100 phrases with id, key, language and value, plus the total count. Not for finding strings by the words they contain.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Only this exact key | |
| project | Yes | Project name; an id matches nothing | |
| language | No | Only strings in this locale code, such as en, it or pt-BR |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| phrases | Yes | Up to 100 phrases, one row per key and language, values cut to 2,000 characters; phraseCount has the total |
| phraseCount | Yes | |
| phrasesTruncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description usefully adds behavioral context the annotations do not: a 100-item cap, the returned fields (id, key, language, value), and the total count.
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?
Three short sentences, front-loaded with the usage trigger followed by return shape and the negative boundary. No filler and nothing redundant.
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?
A read-only list tool with full schema coverage and an output schema; the description covers when to use it, what it returns and its exclusion, which is everything an agent needs to invoke it correctly.
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%, so the schema already documents project, language and key with formats. The description only restates the optional language/key narrowing and adds no syntax or semantics beyond what's structured, so the 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?
States a specific verb (list) and resource (translation strings/phrases) with scope (a project), and names the distinguishing constraint that it is not a content search. An agent can distinguish it from search_phrases and get_phrase without opening a schema.
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?
Gives a clear triggering condition ('when someone asks to see the translation strings in a project') and an explicit exclusion ('Not for finding strings by the words they contain'). It stops short of naming search_phrases as the alternative, so the routing is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks which localization projects they have in MultiLocale. Returns each project's id, name, default locale, languages and timestamps, up to 100 projects. Not for listing the strings inside a project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| projects | Yes | Up to 100 projects; projectCount has the total |
| projectCount | Yes | |
| projectsTruncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered structurally. The description adds genuinely new operational context beyond that: a hard result cap of 100 projects, which tells the agent to consider pagination or narrowing. It does not discuss auth scoping or ordering, but the annotations carry most of the behavioral burden.
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?
Two sentences with the use case front-loaded, then the exclusion. Every clause earns its place and nothing is repeated from the title or annotations.
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?
An output schema exists, so return-value shape is already machine-documented, and the description still adds the useful 100-project bound. For a zero-parameter, read-only list tool, an agent has everything needed to call it correctly and know its limits.
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?
The tool takes zero parameters and the schema has no properties, so there is nothing for the description to disambiguate. Baseline for a no-parameter tool is 4; the description adds no parameter guidance because none is needed.
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?
States a specific verb+resource ('List your localization projects') scoped to the caller's own projects, and enumerates the returned fields (id, name, default locale, languages, timestamps). The closing clause explicitly distinguishes it from the string-listing siblings, so an agent can separate it from list_phrases without opening either schema.
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?
'Use this when someone asks which localization projects they have' gives an explicit triggering condition, and 'Not for listing the strings inside a project' gives a clear exclusion. It stops short of naming the alternative tool (e.g., list_phrases) directly, leaving the agent to map the exclusion to a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks who is on their MultiLocale team or what role each person has. Returns each member's display name and role, up to 100 members (no emails, ids or contact details). Not for inviting or removing people.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| members | Yes | Display name and role only. Email addresses, member ids, role ids, phone, country and signup device details are never returned. |
| memberCount | Yes | |
| membersTruncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive. The description adds genuinely new behavioral context: a 100-member cap and explicit exclusion of emails, ids, and contact details in the response, which is meaningful privacy/scope information.
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?
Three tight sentences, front-loaded with the trigger condition, then return shape, then exclusion. Every sentence earns its place with no redundancy.
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 zero-parameter read tool with annotations covering the safety profile and an output schema covering returns, the description supplies the trigger, scope limits, and return summary. Nothing an agent needs is missing.
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?
The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to compensate for, and it correctly avoids inventing parameter-like details.
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?
States a specific verb+resource (list team members) with the exact return content (display name and role). It also explicitly excludes the invite/remove operations, making it distinguishable from write-oriented siblings.
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?
Names the trigger condition ('when someone asks who is on their MultiLocale team or what role each person has') and explicitly states what it is not for ('Not for inviting or removing people'). Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks to find translation strings that contain a word or phrase, in their keys or text. Returns up to 100 matches with id, key, language and value from a case-insensitive match within one project. Not for one exact key.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Text to find in keys or values, case-insensitive, 1 to 200 characters | |
| project | Yes | Project name; an id matches nothing | |
| language | No | Only search this locale code; every language when absent |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| phrases | Yes | Up to 100 matching phrases, values cut to 2,000 characters; phraseCount has the total |
| phraseCount | Yes | |
| phrasesTruncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuinely useful behavior beyond that: a hard cap of 100 matches and the fact that matching is case-insensitive and confined to one project.
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?
Two sentences, no wasted words, and the trigger plus scope are front-loaded ahead of the exclusion. Every clause carries information an agent needs.
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?
With an output schema present, return-value detail is optional, yet the description still conveys the match cap and project scoping. Nothing an agent needs in order to call this correctly is missing.
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%, so query, project and language semantics (case-insensitive, locale restriction, id does not match) are already fully documented in the schema. The description adds no syntax or format detail beyond it, so the 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?
States a specific verb (find/search) and resource (translation strings by key or text content) and carves out its scope with 'Not for one exact key', which separates it from get_phrase. An agent can select this without opening the schema.
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?
Gives an explicit trigger ('Use this when someone asks to find translation strings that contain a word or phrase') and an exclusion ('Not for one exact key'). The alternative tool (get_phrase) is implied rather than named, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants a quick overview of one of their localization projects. Returns an overview card with the project's default locale, up to 24 configured locales and timestamps. Not for translation completeness.
| Name | Required | Description | Default |
|---|---|---|---|
| projectIdOrName | Yes | Project id or name |
| Name | Required | Description |
|---|---|---|
| project | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the capped 24-locale limit and the inclusion of timestamps, which tell the agent what the card will and won't contain.
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?
Three short sentences, trigger first, return shape second, exclusion last. No filler and nothing repeated from the name or schema.
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?
A read-only single-param lookup with an output schema and full annotation coverage needs little else. The description supplies the trigger and the one behavioral quirk (24-locale cap), which is sufficient for correct invocation.
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 description coverage is 100% for the single projectIdOrName parameter, so the schema already carries its semantics. The description adds no format, lookup, or ambiguity guidance (e.g. id vs. name precedence), so the 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?
States a specific verb (show), resource (project overview), and the shape of what comes back (an overview card with default locale, configured locales, timestamps). It also carves out a boundary against the translation-completeness siblings, though it does not name get_project or find_missing_translations directly.
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?
Gives a clear trigger (someone wants a quick overview of one of their localization projects) and an explicit exclusion (not for translation completeness). It stops short of naming the alternative tool an agent should use for completeness queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks to fix or change the text of one key in one language. Returns the previous and new text and the projects sharing that string; the change applies in all of them and marks the text as human-edited. Not for adding a new key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Exact existing key | |
| value | Yes | New text for that language, 1 to 2,000 characters | |
| project | Yes | Project name; an id matches nothing | |
| language | Yes | Locale code of the translation to change, such as en or it |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| value | Yes | |
| status | Yes | |
| project | Yes | |
| language | Yes | |
| previousValue | Yes | |
| sharedProjects | Yes | Every project using this string; the change applies to all of them |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the mutation profile; the description adds non-obvious behavior: the change propagates to every project sharing the string, marks the text human-edited, and returns previous plus new values. The cross-project propagation is exactly the kind of blast-radius detail annotations cannot convey.
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?
Three short sentences: trigger, effects/return, exclusion. Front-loaded with the use case and free of repetition of schema or annotation content.
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?
Despite an output schema already existing, the description goes further by naming what is returned and the shared-project side effect. Prerequisites and scope are fully covered for a four-parameter mutation tool.
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 each parameter is documented in-schema (exact existing key, locale code, new text length bound), so the description carries no additional parameter detail. Baseline 3 applies when the schema does all the work.
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?
States a specific verb and resource ('fix or change the text of one key in one language') and immediately scopes it against the sibling add_phrase with 'Not for adding a new key.' An agent can distinguish this from add_phrase/delete_phrase without opening a schema.
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?
Gives a clear triggering situation ('when someone asks to fix or change the text') and an explicit exclusion ('Not for adding a new key'). It stops short of naming add_phrase as the alternative tool by name, but the when/when-not framing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks to change a project's default locale, replace its list of languages, or set its translation context. Returns which fields changed. The language list is replaced as a whole, no strings are translated or deleted, and the project name stays fixed. Not for adding a language with its translations.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Translation context for the whole project, up to 600 characters; an empty string clears it | |
| locales | No | Complete replacement list of locale codes, including the default locale | |
| defaultLocale | No | New default locale code; it has to be one of the project's locales | |
| projectIdOrName | Yes | Project id or name |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| project | Yes | |
| changedFields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With destructiveHint=true and idempotentHint=true already declared, the description usefully bounds what 'destructive' means here: the locale list is replaced wholesale, no strings are translated or deleted, and the name is immutable. It also states the return shape ('which fields changed'). It stops short of mentioning permission or auth requirements, so it is very good but not exhaustive.
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?
Three sentences, front-loaded with the usage trigger, then the behavioral constraints, then the exclusion. Every sentence carries distinct information with no repetition of the title or schema.
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?
Output schema covers the return value, annotations cover safety and idempotency, and the schema fully documents all four parameters. The only thing an agent additionally needs — when not to call it — is explicitly provided.
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 description coverage is 100% and each parameter is well documented there (including the 'one of the project's locales' constraint and the empty-string-clears-context rule), so the baseline of 3 applies. The description reinforces replacement semantics but adds no syntax or format detail beyond the schema.
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?
Names the concrete operations: change default locale, replace the language list, set translation context. The verb 'change/update' plus a clearly scoped resource distinguishes it from siblings like add_locale and update_phrase without needing the schema.
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?
Opens with an explicit trigger ('Use this when someone asks to...') and closes with a hard exclusion ('Not for adding a language with its translations'), implicitly routing that case to add_locale. Both when-to-use and when-not-to-use are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
add_locale4 fields changedInput schema / properties / context / descriptionPrevious value: -"Optional context applied while translating the missing phrases."New value: +"Note applied to every translation in this run, up to 600 characters"Input schema / properties / locale / descriptionPrevious value: -"New locale code to add (for example, it)"New value: +"Locale code to add, such as it or pt-BR"Input schema / properties / model / descriptionPrevious value: -"Translation model to use. Defaults to gpt-6-luna."New value: +"Translation model id; defaults to gpt-6-luna"Input schema / properties / project / descriptionPrevious value: -"Project name (slug) to localize"New value: +"Project id or name"add_phrase5 fields changedInput schema / properties / context / descriptionPrevious value: -"Optional context that helps translators disambiguate the phrase."New value: +"Note for the translator that disambiguates the string, up to 600 characters"Input schema / properties / key / descriptionPrevious value: -"New exact phrase key"New value: +"New key, 1 to 256 characters"Input schema / properties / model / descriptionPrevious value: -"Translation model to use. Defaults to gpt-6-luna."New value: +"Translation model id; defaults to gpt-6-luna"Input schema / properties / project / descriptionPrevious value: -"Project name (slug) to add the key to"New value: +"Project id or name"Input schema / properties / value / descriptionPrevious value: -"Source value in the default locale. Omit to use the key itself."New value: +"Source text in the default locale, up to 2,000 characters; defaults to the key itself"add_project3 fields changedInput schema / properties / defaultLocale / descriptionPrevious value: -"Default locale code for the project (for example, en)"New value: +"Locale code of the source language, such as en"Input schema / properties / locales / descriptionPrevious value: -"Initial locale codes. The default locale is added automatically when omitted."New value: +"Other locale codes to start with, such as it or de; the default locale is added automatically"Input schema / properties / name / descriptionPrevious value: -"New project name (prefer a URL-safe slug)"New value: +"Name of the new project, 1 to 128 characters; a URL-safe slug such as my-app is easiest to reference later"delete_phrase3 fields changedInput schema / properties / key / descriptionPrevious value: -"Exact key whose complete locale group should be deleted"New value: +"Exact key to delete in every language"Input schema / properties / project / descriptionPrevious value: -"Project id or name that contains the key to delete"New value: +"Project id or name that has the key"Output schema / properties / sharedProjects / descriptionAdded value: +"Other projects the deleted string was also removed from"export_locale_dictionary6 fields changedInput schema / properties / language / descriptionPrevious value: -"Language code to export (for example, en)"New value: +"Locale code to export, such as en"Input schema / properties / limit / descriptionPrevious value: -"Maximum number of keys to return. Defaults to 25, capped at 50."New value: +"Entries to return, from 1 to 50; defaults to 25"Input schema / properties / project / descriptionPrevious value: -"Project name (slug) to export"New value: +"Project name; an id matches nothing"Input schema / properties / skip / descriptionPrevious value: -"Number of keys to skip, sorted alphabetically. Defaults to 0 and is capped at 10000."New value: +"Keys to skip in alphabetical order, for paging: pass the previous nextSkip; defaults to 0, at most 10000"Output schema / properties / entries / descriptionAdded value: +"Key and value pairs sorted by key, values cut to 500 characters"Output schema / properties / nextSkip / descriptionAdded value: +"Pass as skip to get the next page; null on the last page"find_duplicate_phrase_values3 fields changedInput schema / properties / project / descriptionPrevious value: -"Project id or name whose default-locale copy should be checked"New value: +"Project id or name"Input schema / properties / scanLimit / descriptionPrevious value: -"Maximum default-locale phrases to scan. Defaults to 1000, capped at 2000."New value: +"Default-locale strings to scan, from 1 to 2000; defaults to 1000"Output schema / properties / duplicates / descriptionAdded value: +"Up to 25 default-locale values used by more than one key, with up to 10 keys each and the other projects sharing them"find_missing_translations5 fields changedInput schema / properties / language / descriptionPrevious value: -"Locale code to check. Omit to report coverage for every configured locale."New value: +"One locale code to check; omit to check the configured locales"Input schema / properties / localeLimit / descriptionPrevious value: -"Maximum configured locales to check when language is omitted. Defaults to 10."New value: +"How many configured locales to check when language is omitted, from 1 to 10; defaults to 10"Input schema / properties / project / descriptionPrevious value: -"Project id or name whose translation coverage should be checked"New value: +"Project id or name"Input schema / properties / scanLimit / descriptionPrevious value: -"Maximum phrases to scan per locale. Defaults to 1000, capped at 2000."New value: +"Strings to scan per locale, from 1 to 2000; defaults to 1000"Output schema / properties / locales / descriptionAdded value: +"One row per checked locale with its completion and up to 25 missing keys; status partial means a scan cap was reached"get_phrase4 fields changedInput schema / properties / key / descriptionPrevious value: -"Exact phrase key to look up"New value: +"Exact key, matched case-sensitively"Input schema / properties / language / descriptionPrevious value: -"Language code to fetch (e.g. en, it). Omit to fetch all languages for the key."New value: +"One locale code such as en or it; every language when absent"Input schema / properties / project / descriptionPrevious value: -"Project name (slug) the phrase belongs to"New value: +"Project name; an id matches nothing"Output schema / properties / translations / descriptionAdded value: +"One row per locale, up to 24, values cut to 2,000 characters; projects lists every project sharing the row"get_project1 field changedInput schema / properties / projectIdOrName / descriptionPrevious value: -"Project id or project name (slug)"New value: +"Project id or name"list_phrases4 fields changedInput schema / properties / key / descriptionPrevious value: -"Filter by exact phrase key"New value: +"Only this exact key"Input schema / properties / language / descriptionPrevious value: -"Filter by language code (e.g. en, it, es)"New value: +"Only strings in this locale code, such as en, it or pt-BR"Input schema / properties / project / descriptionPrevious value: -"Project name (slug) to list phrases for"New value: +"Project name; an id matches nothing"Output schema / properties / phrases / descriptionAdded value: +"Up to 100 phrases, one row per key and language, values cut to 2,000 characters; phraseCount has the total"list_projects1 field changedOutput schema / properties / projects / descriptionAdded value: +"Up to 100 projects; projectCount has the total"list_team_members1 field changedOutput schema / properties / members / descriptionAdded value: +"Display name and role only. Email addresses, member ids, role ids, phone, country and signup device details are never returned."search_phrases4 fields changedInput schema / properties / language / descriptionPrevious value: -"Restrict search to a specific language code (e.g. en, it)"New value: +"Only search this locale code; every language when absent"Input schema / properties / project / descriptionPrevious value: -"Project name (slug) to search phrases in"New value: +"Project name; an id matches nothing"Input schema / properties / query / descriptionPrevious value: -"Search text to match against phrase keys and values"New value: +"Text to find in keys or values, case-insensitive, 1 to 200 characters"Output schema / properties / phrases / descriptionAdded value: +"Up to 100 matching phrases, values cut to 2,000 characters; phraseCount has the total"share_phrase3 fields changedInput schema / properties / key / descriptionPrevious value: -"Exact key to share across every locale"New value: +"Exact key to share, with all of its languages"Input schema / properties / project / descriptionPrevious value: -"Source project id or name that already contains the key"New value: +"Project id or name that already has the key"Input schema / properties / targetProjects / descriptionPrevious value: -"One or more target project ids or names to attach to the key"New value: +"1 to 25 project ids or names to attach the key to"show_project_overview1 field changedInput schema / properties / projectIdOrName / descriptionPrevious value: -"MultiLocale project id or name (slug) to render"New value: +"Project id or name"update_phrase5 fields changedInput schema / properties / key / descriptionPrevious value: -"Exact phrase key to update"New value: +"Exact existing key"Input schema / properties / language / descriptionPrevious value: -"Language code of the translation to update (e.g. en, it, es)"New value: +"Locale code of the translation to change, such as en or it"Input schema / properties / project / descriptionPrevious value: -"Project name (slug) the phrase belongs to"New value: +"Project name; an id matches nothing"Input schema / properties / value / descriptionPrevious value: -"New translation value for the given language"New value: +"New text for that language, 1 to 2,000 characters"Output schema / properties / sharedProjects / descriptionAdded value: +"Every project using this string; the change applies to all of them"update_project4 fields changedInput schema / properties / context / descriptionPrevious value: -"Optional translation context for the project. Use an empty string to clear it."New value: +"Translation context for the whole project, up to 600 characters; an empty string clears it"Input schema / properties / defaultLocale / descriptionPrevious value: -"New default locale code. It must be one of the project locales."New value: +"New default locale code; it has to be one of the project's locales"Input schema / properties / locales / descriptionPrevious value: -"Complete replacement list of locale codes. Include the default locale."New value: +"Complete replacement list of locale codes, including the default locale"Input schema / properties / projectIdOrName / descriptionPrevious value: -"Project id or project name (slug)"New value: +"Project id or name"add_locale1 field changedInput schema / properties / model / descriptionPrevious value: -"Translation model to use. Defaults to gpt-5.6-luna."New value: +"Translation model to use. Defaults to gpt-6-luna."add_phrase1 field changedInput schema / properties / model / descriptionPrevious value: -"Translation model to use. Defaults to gpt-5.6-luna."New value: +"Translation model to use. Defaults to gpt-6-luna."list_projects1 field changedInput schema / additionalPropertiesAdded value: +falselist_team_members1 field changedInput schema / additionalPropertiesAdded value: +falseshow_project_overview4 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseOutput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / properties / project / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "creationTime": {
- "anyOf": [
- {
- "maxLength": 32,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "defaultLocale": {
- "anyOf": [
- {
- "maxLength": 35,
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "id": {
- "anyOf": [
- {
- "pattern": "^[0-9a-f]{24}$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "lastEditTime": {
- "$ref": "#/properties/project/anyOf/0/properties/creationTime"
- },
- "localeCount": {
- "minimum": 0,
- "type": "integer"
- },
- "locales": {
- "items": {
- "$ref": "#/properties/project/anyOf/0/properties/defaultLocale/anyOf/0"
- },
- "maxItems": 24,
- "type": "array"
- },
- "localesTruncated": {
- "type": "boolean"
- },
- "name": {
- "maxLength": 128,
- "type": "string"
- }
- },
- "required": [
- "id",
- "name",
- "defaultLocale",
- "localeCount",
- "localesTruncated",
- "locales",
- "creationTime",
- "lastEditTime"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "creationTime": {
+ "anyOf": [
+ {
+ "maxLength": 32,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "defaultLocale": {
+ "anyOf": [
+ {
+ "maxLength": 35,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "anyOf": [
+ {
+ "pattern": "^[0-9a-f]{24}$",
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "lastEditTime": {
+ "anyOf": [
+ {
+ "maxLength": 32,
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "localeCount": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "locales": {
+ "items": {
+ "maxLength": 35,
+ "type": "string"
+ },
+ "maxItems": 24,
+ "type": "array"
+ },
+ "localesTruncated": {
+ "type": "boolean"
+ },
+ "name": {
+ "maxLength": 128,
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "defaultLocale",
+ "localeCount",
+ "localesTruncated",
+ "locales",
+ "creationTime",
+ "lastEditTime"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]add_localeadd_phraseadd_projectdelete_phraseexport_locale_dictionaryfind_duplicate_phrase_valuesfind_missing_translationsget_phraseget_projectlist_phraseslist_projectslist_team_memberssearch_phrasesshare_phraseshow_project_overviewupdate_phraseupdate_project
Add one secure layer between your agents and this server.