Manage translation projects, phrases and locales with secure organization-scoped tools and views.
Add a new locale to a project and generate translations for every key currently missing in that locale. Uses the default-locale value as the source for each translation.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Translation model to use. Defaults to gpt-5.6-luna. | |
| locale | Yes | New locale code to add (for example, it) | |
| context | No | Optional context applied while translating the missing phrases. | |
| project | Yes | Project name (slug) to localize |
| 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 already indicate a destructive, non-read-only operation, and the description adds meaningful behavioral context: it generates translations for missing keys and uses the default-locale value as the translation source. This reveals side effects beyond the raw annotation flags without contradicting them.
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 tight sentences communicate the core action, the scope ('every key currently missing'), and the source behavior. There is no filler or 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?
The description, combined with full schema coverage, annotations, and an output schema, is nearly complete. A brief note about prerequisites (e.g., the project must have a default locale) would make it fully comprehensive, but no essential calling behavior 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 input schema covers all four parameters with descriptions, so the baseline is 3. The description adds general context about translation sourcing but does not add per-parameter semantic detail beyond what the schema already provides.
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 identifies the verb ('Add') and specific resource ('a new locale'), then expands on what the operation does: generate translations for all currently missing keys using the default-locale value as source. This distinguishes add_locale from siblings like add_project, add_phrase, and even find_missing_translations.
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 makes the use context clear: add a locale and fill in missing translations. It does not explicitly name alternatives or state when not to use it, but the context is unambiguous enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new key in a project’s default locale and generate translations for every other configured locale. Omit value to use the key as its source value. Refuses to overwrite an existing key.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | New exact phrase key | |
| model | No | Translation model to use. Defaults to gpt-5.6-luna. | |
| value | No | Source value in the default locale. Omit to use the key itself. | |
| context | No | Optional context that helps translators disambiguate the phrase. | |
| project | Yes | Project name (slug) to add the key to |
| 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?
The description usefully discloses creation behavior, auto-translation, the omit-value fallback, and overwrite refusal. However, the annotations declare destructiveHint=true, while the description states the tool refuses to overwrite an existing key and only creates new keys. This is a direct contradiction, so the behavior score must be 1.
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 with no filler. The primary action is front-loaded, optional value behavior is next, and the overwrite refusal closes with an important boundary. 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?
For a 5-parameter tool, the description covers the core behavior, the value fallback, the translation side effect, and the existing-key refusal. The output schema and full parameter schema cover the remaining details. The only notable gap is that it doesn't explicitly route existing-key edits to update_phrase, and the conflicting destructiveHint muddies the safety picture.
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 is already documented in the input schema. The description repeats the omit-value behavior but does not add parameter-level semantics beyond that. 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?
The description uses a specific verb ('Create') and names the exact resource ('a new key in a project’s default locale') and outcome ('generate translations for every other configured locale'). It also states a defining constraint ('Refuses to overwrite an existing key') that clearly separates it from update_phrase and other 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?
The context is clear: use this tool for adding a new key with generated translations, not for modifying an existing key. The overwrite refusal implies the alternative, but it never explicitly names update_phrase or states when to prefer a different sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a MultiLocale project with a default locale and optional additional locales. Refuses to create a duplicate project name in the authenticated organization.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | New project name (prefer a URL-safe slug) | |
| locales | No | Initial locale codes. The default locale is added automatically when omitted. | |
| defaultLocale | Yes | Default locale code for the project (for example, en) |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| project | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only and is destructive; the description adds useful behavioral context by stating that duplicate project names are refused and that the operation is scoped to the authenticated organization. This is adequate for a create operation, though error behavior is not detailed.
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 contain the core purpose and a key constraint with no redundant wording. The action is front-loaded and 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?
For a simple create tool with full schema coverage, an output schema, and annotations, the description plus structured data covers required parameters, key behavior, and organizational scope. Nothing essential is missing for an agent to call this tool 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?
The input schema has 100% description coverage, so all three parameters are already documented structurally. The description only adds a high-level restatement that additional locales are optional and the default locale is included automatically, which is helpful but not essential.
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 uses a specific verb ('Create') with a concrete resource ('a MultiLocale project') and adds meaningful detail about default and additional locales. This clearly separates it from siblings like add_locale, add_phrase, and update_project.
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 clearly frames this as the tool for creating a new project and notes the duplicate-name refusal, so an agent can identify the right invocation context. It does not explicitly name alternatives or exclusions, but the verb and resource make the intended use apparent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete every locale translation for one key in a project. If a phrase is shared with other projects, this deletes the shared row for those projects too, rather than only detaching the project.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Exact key whose complete locale group should be deleted | |
| project | Yes | Project id or name that contains the key to delete |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| status | Yes | |
| project | Yes | |
| sharedProjects | Yes | |
| deletedTranslationCount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true and readOnlyHint=false. The description adds valuable nuance beyond this: the deletion is permanent, applies to every locale translation, and removes the shared row for other projects rather than merely detaching the project. No contradiction with annotations.
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 primary action and scope, and the shared-row caveat is placed second. No filler or repetition.
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 two-parameter destructive tool with a complete schema, clear annotations, and an output schema, the description covers the permanent scope and the shared-phrase edge case. Nothing essential is missing for an agent 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?
Input schema covers both required parameters with clear descriptions at 100% coverage, so the description carries little parameter burden. It reinforces that 'key' and 'project' identify the complete locale group, but adds no new parameter-level meaning.
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?
Description begins with a specific verb and object: 'Permanently delete every locale translation for one key in a project.' It also clarifies the scope and permanence, and the distinction from siblings like get_phrase, update_phrase, or share_phrase is clear 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?
The description makes the use case clear: use when a key and all its translations should be removed, including shared rows. It does not explicitly name alternatives or state 'do not use this to edit translations,' but the permanent destructive scope is unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export one locale of a MultiLocale project as bounded, sorted key/value entries. Results are API-paginated with a maximum of 50 entries per call and each value is capped at 500 characters.
| Name | Required | Description | Default |
|---|---|---|---|
| skip | No | Number of keys to skip, sorted alphabetically. Defaults to 0 and is capped at 10000. | |
| limit | No | Maximum number of keys to return. Defaults to 25, capped at 50. | |
| project | Yes | Project name (slug) to export | |
| language | Yes | Language code to export (for example, en) |
| Name | Required | Description |
|---|---|---|
| skip | Yes | |
| status | Yes | |
| entries | Yes | |
| hasMore | Yes | |
| project | Yes | |
| language | Yes | |
| nextSkip | Yes | |
| returnedCount | Yes | |
| valuesTruncated | Yes | |
| offsetCapReached | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description only needs to add context. It discloses API pagination with a 50-entry maximum and a 500-character value cap, which are meaningful behavioral constraints beyond the structured annotations. It does not contradict any annotation.
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 no filler: the purpose is front-loaded, and the second sentence adds two consequential behavioral constraints. Every clause contributes actionable 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?
For a read-only export tool with a complete input schema and an output schema, the description is complete. It states the scope, sorted/bounded nature, pagination behavior, and value size limit, so an agent can call it correctly without missing key constraints.
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%; every parameter (project, language, skip, limit) already has a clear schema description including defaults and bounds. The tool description reinforces the pagination cap but adds no parameter-specific meaning beyond what the schema provides.
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 uses a clear verb and resource: 'Export one locale of a MultiLocale project as bounded, sorted key/value entries.' It specifies the scope (one locale) and output shape (key/value), but it never contrasts itself with similar siblings like list_phrases or search_phrases, so it lacks explicit sibling differentiation.
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?
There is no guidance on when to use this tool instead of alternatives such as list_phrases or search_phrases. The description states what it does but no conditions, exclusions, or hints for routing an agent to a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find keys in a bounded scan of one MultiLocale project whose default-locale translations have the same value. The result explicitly reports when the scan or output preview is truncated.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project id or name whose default-locale copy should be checked | |
| scanLimit | No | Maximum default-locale phrases to scan. Defaults to 1000, capped at 2000. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| project | Yes | |
| scanLimit | Yes | |
| duplicates | Yes | |
| 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 establish read-only, idempotent, non-destructive behavior. The description adds meaningful non-obvious context: the scan is bounded, and the result explicitly reports truncation of either the scan or the output preview. This helps the agent anticipate partial results.
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 concise sentences: the first states the tool's purpose and scope, the second adds an important truncation behavior. There is no filler or repetition of schema or annotation details.
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 description is sufficiently complete for a read-only discovery tool with an output schema and 100% parameter schema coverage. It covers scope, boundedness, and truncation behavior; the output schema handles return-value details.
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 parameters are already well documented. The description's 'bounded scan' phrasing loosely aligns with scanLimit, but it does not add material detail beyond what the schema provides. 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?
The description states a specific verb ('Find keys'), a precise resource ('one MultiLocale project'), and the exact condition ('default-locale translations have the same value'). This clearly distinguishes it from siblings like find_missing_translations and search_phrases.
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 implies usage context through 'bounded scan of one MultiLocale project' and 'default-locale copy,' but it does not explicitly state when to choose this tool over alternatives or when not to use it. No sibling is named as a competing option.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report missing keys in a bounded scan of one locale or up to 10 configured locales, compared with the project default locale. The result explicitly reports partial locale or phrase scans and never creates translations.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | Project id or name whose translation coverage should be checked | |
| language | No | Locale code to check. Omit to report coverage for every configured locale. | |
| scanLimit | No | Maximum phrases to scan per locale. Defaults to 1000, capped at 2000. | |
| localeLimit | No | Maximum configured locales to check when language is omitted. Defaults to 10. |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| locales | Yes | |
| 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 mark this as read-only and idempotent, but the description adds valuable behavior: scans are bounded, partial scans are explicitly reported, and it never creates translations. This goes beyond the structured annotations and helps an agent trust the tool's side-effect profile.
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 no filler. The first sentence front-loads the core purpose and scope; the second adds the critical boundary conditions about partial reports and non-mutation. Every clause 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?
For a read-only reporting tool with a rich output schema and annotations covering idempotence and safety, the description covers scope, limits, and result semantics. Nothing essential is missing for an agent to select and 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 description coverage is 100%, so the baseline is 3. The description adds conceptual meaning by tying 'one locale or up to 10 configured locales' to language and localeLimit, and 'bounded scan' to scanLimit, which helps an agent reason about parameter behavior beyond the raw 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?
Description states a specific action ('Report missing keys') and the resource scope ('bounded scan of one locale or up to 10 configured locales'), and it clarifies the comparison basis ('project default locale'). It distinguishes itself from siblings like find_duplicate_phrase_values or export_locale_dictionary by focusing on missing keys rather than duplicates or exports.
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 clearly establishes when this tool is useful: when you need missing translation keys relative to the default locale. It stops short of naming alternative tools or giving explicit when-not-to-use guidance, but the context is strong enough for an agent to infer the intended use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch translations for one exact phrase key in a MultiLocale project. Returns a bounded Markdown and structured preview across locales, or a single locale when language is provided.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Exact phrase key to look up | |
| project | Yes | Project name (slug) the phrase belongs to | |
| language | No | Language code to fetch (e.g. en, it). Omit to fetch all languages for the key. |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| status | Yes | |
| project | Yes | |
| translations | Yes | |
| translationCount | Yes | |
| translationsTruncated | 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 the safety profile is covered. The description adds a small amount of behavioral context by noting the return preview is Markdown and structured, and that locale scope depends on whether language is supplied. It does not contradict annotations.
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 two sentences, front-loaded with the primary action and resource, and does not waste words. The only slightly vague phrase is 'bounded Markdown', but overall the definition is appropriately compact.
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 read-only lookup tool with 100% schema coverage, an output schema, and strong annotations, the description is nearly complete. It accurately captures the exact-key semantics and optional language narrowing. It would be more complete if it explicitly directed agents away from search_phrases or list_phrases, but the wording already implies that boundary.
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 key, project, and language in detail. The description mostly restates the language behavior ('single locale when language is provided') that the schema already covers, adding little semantic value beyond what structured fields provide.
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 a specific verb ('Fetch') and a concrete resource ('translations for one exact phrase key in a MultiLocale project'). It also differentiates from siblings by emphasizing 'one exact phrase key', which excludes list_phrases and search_phrases without needing to open their definitions.
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 conveys the intended use case: retrieving translations for a specific exact key, optionally narrowed to one locale. It does not explicitly name alternatives or say when not to use it, but the context is clear enough for an agent to select it over list/search variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single MultiLocale project by id or name. Returns bounded Markdown and structured project metadata, including name, configured locales, and timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
| projectIdOrName | Yes | Project id or project name (slug) |
| 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, covering the safety profile. The description adds useful behavioral context beyond that: it returns 'bounded Markdown' and 'structured project metadata' including name, locales, and timestamps. No contradiction with annotations exists.
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 concise sentences, with the core action and resource in the first sentence and valuable output detail in the second. No filler or redundant phrasing.
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 single-parameter read-only getter with an output schema and full annotation coverage, the description is complete. It clarifies the lookup scope, the output type, and key metadata fields. The existence of the output schema means return values need not be exhaustively listed.
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%, with projectIdOrName already described as 'Project id or project name (slug)'. The description merely restates 'by id or name' without adding syntax, format, or disambiguation details, so it adds no value beyond the schema baseline.
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 ('Fetch'), a clear resource ('a single MultiLocale project'), and the lookup key ('by id or name'). It also distinguishes itself from sibling tools like list_projects and search_phrases by emphasizing it retrieves one project with metadata, not a collection or search result.
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 implies the tool is for retrieving a single project by identifier, which is a clear context. However, it does not explicitly state when to prefer this over alternatives such as list_projects or search_phrases, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List translation phrases for a MultiLocale project. Optionally filter by language or key. Returns a bounded Markdown and structured preview of id, key, language, and value.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | Filter by exact phrase key | |
| project | Yes | Project name (slug) to list phrases for | |
| language | No | Filter by language code (e.g. en, it, es) |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| phrases | Yes | |
| phraseCount | Yes | |
| phrasesTruncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond the annotations by disclosing that results are bounded and that the output is a Markdown and structured preview containing id, key, language, and value. No contradiction with annotations exists.
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 zero filler. The main action and scope lead, optional filters follow, and the return behavior closes the statement—each clause 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 rich output schema and comprehensive annotations, the description covers the essential usage and result shape. It could additionally mention limits on the bounded preview or sorting behavior, but 'bounded' plus the structured preview suffices for an agent to invoke the tool 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 the baseline is 3. The description echoes the filter-by-language-or-key semantics already present in the schema but does not add extra meaning beyond what the property descriptions provide, such as format constraints or interaction effects between filters.
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 identifies the action ('List') and resource ('translation phrases for a MultiLocale project'). It specifies optional filtering by language or key, and distinguishes the list operation from singular 'get_phrase' by nature. However, it does not explicitly name a sibling or contrast with 'search_phrases', which would have secured a 5.
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 statement 'Optionally filter by language or key' implies a typical use case—enumerating phrases with optional narrowing. Yet there is no explicit guidance about when to choose this over the closely related 'search_phrases', 'get_phrase', or 'export_locale_dictionary' tools, leaving the routing decision partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all MultiLocale projects the authenticated user has access to. Returns a bounded Markdown and structured preview of project ids, names, locales, and timestamps.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| projects | Yes | |
| projectCount | Yes | |
| projectsTruncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds useful behavioral context: it returns a bounded Markdown and structured preview, and it scopes results by authenticated access. No contradiction with the annotations exists.
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 concise sentences with no filler. The first sentence states the action and scope, and the second sentence describes the return format, making the description easy to scan and immediately actionable.
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 no-parameter, read-only list tool with an output schema and safety annotations, this description is complete. It tells an agent what scope applies, what fields will be present, and that the result is bounded, leaving no essential gap.
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 input schema has zero parameters and schema description coverage is 100%, so there is no parameter semantics to clarify. The description usefully focuses on what the response contains instead of parameter documentation, matching the baseline for a zero-parameter tool.
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 the specific verb 'List' and the resource 'all MultiLocale projects', clearly identifying what the tool does. It also defines the scope as projects the authenticated user has access to, which differentiates it from single-project tools like get_project and creation tools like add_project.
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 clearly communicates that this is the enumeration tool for projects the user can access, with no parameters or complex preconditions. It does not explicitly name alternatives or exclusion criteria, so it falls short of a perfect 5, but the intended usage is obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List a bounded roster for the authenticated MultiLocale organization. Returns only each member's display name and role. Email addresses, member IDs, role IDs, phone, country, and signup device details are excluded.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| members | Yes | |
| memberCount | Yes | |
| membersTruncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond that, including the organization scope, bounded nature of the roster, and the precise fields suppressed from the response.
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 no filler; the main action and scope are front-loaded, and the exclusion list adds useful detail without bloating the definition. 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?
For a zero-parameter read-only list tool with an output schema and annotations already covering safety and idempotency, the description is complete. It tells the agent what will be returned, what is excluded, and the organizational scope, leaving no critical gap.
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 description coverage is 100%, so there are no parameter semantics for the description to clarify. The description still reinforces the implicit operation scope by stating it acts on the authenticated organization's team roster.
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: 'List a bounded roster' for team members. It clarifies exactly what is returned (display name and role) and what is excluded (emails, IDs, phone, country, signup device), making the tool's scope unmistakable.
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 clearly frames the tool as a bounded roster listing for the authenticated organization, which conveys when it is appropriate. It also signals what this tool is not for by listing excluded fields, though it does not name an alternative tool for richer member data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search translation phrases for a MultiLocale project by matching a query string against phrase keys and values. Returns a bounded Markdown and structured preview of matching ids, keys, languages, and values.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search text to match against phrase keys and values | |
| project | Yes | Project name (slug) to search phrases in | |
| language | No | Restrict search to a specific language code (e.g. en, it) |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| phrases | Yes | |
| phraseCount | Yes | |
| phrasesTruncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description need not repeat safety. It adds value by disclosing the output form ('bounded Markdown and structured preview') and the scope of returned data ('ids, keys, languages, and values'), which goes beyond the annotations.
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 deliver the core action, the matching mechanism, and the result format with no filler. The primary operation is front-loaded, and every phrase 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?
Given the simple three-parameter shape, high schema coverage, and existing output schema, the description conveys enough to correctly select the tool and understand its return nature. Minor gaps like pagination or case-sensitivity are acceptable because 'bounded' already signals a limited preview.
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 the schema already explains the query and project parameters. The description reinforces that query matches both keys and values, but it does not meaningfully clarify the optional language parameter beyond the schema. Baseline 3 is appropriate because the structured schema carries the semantic weight.
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 identifies the operation ('Search translation phrases'), the targeted resource ('for a MultiLocale project'), and the matching mechanism ('query string against phrase keys and values'). It also distinguishes itself from siblings like list_phrases by emphasizing query-based matching and the returned preview content.
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 implies this tool is for query-based search within a project, which contrasts with list_phrases or get_phrase, but it never explicitly states when to use this tool over those alternatives or when not to use it. Usage context is inferable but not made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render a bounded overview for a known MultiLocale project. Use this after listing projects or when the user provides a project id or name. It shows safe project metadata and up to 24 configured locales without downloading the project phrase dictionary.
| Name | Required | Description | Default |
|---|---|---|---|
| projectIdOrName | Yes | MultiLocale project id or name (slug) to render |
| Name | Required | Description |
|---|---|---|
| project | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, non-destructive, and closed-world; the description adds useful behavioral context beyond annotations: the overview is bounded, the metadata is safe, it returns at most 24 locales, and it does not download the phrase dictionary. No contradiction exists.
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 what the tool does and when to use it, followed by a concise boundary ('without downloading the project phrase dictionary'). 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?
For a one-paramerer tool with a full input schema, a declared output schema, and rich annotations, the description is complete enough: it gives the precondition, the resource, and the main limitations. Nothing needed for a correct invocation 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% with a clear description of projectIdOrName, so the schema already carries the parameter meaning. The description reinforces that it accepts an id or name and that the project must be known, but adds no new parameter-level syntax or format 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?
The description uses a specific verb ('Render') and resource ('bounded overview for a known MultiLocale project') and clarifies the scope with 'safe project metadata and up to 24 configured locales.' The 'without downloading the project phrase dictionary' clause differentiates it from content-export/list-style siblings, so an agent can tell it apart.
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 states explicit invocation context: 'Use this after listing projects or when the user provides a project id or name.' This makes the precondition clear, but it does not list exclusions or name alternative tools such as get_project or export_locale_dictionary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the translation value for a specific phrase key and language in a MultiLocale project. Phrases may be shared across projects — updating affects all projects that share the key. Clears machine-translation flags since the value is now human-edited.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Exact phrase key to update | |
| value | Yes | New translation value for the given language | |
| project | Yes | Project name (slug) the phrase belongs to | |
| language | Yes | Language code of the translation to update (e.g. en, it, es) |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| value | Yes | |
| status | Yes | |
| project | Yes | |
| language | Yes | |
| previousValue | Yes | |
| sharedProjects | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already flag destructive behavior and idempotency, but the description adds meaningful behavioral detail: updates propagate across all projects sharing the key, and machine-translation flags are cleared because the value becomes human-edited. This is valuable context beyond the annotations and helps an agent anticipate side effects.
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, each earning its place: the first states the core operation, the second warns of cross-project side effects, and the third explains flag clearing. The most important action is front-loaded, and there is no redundant or promotional wording.
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 moderately simple 4-parameter update tool with a full output schema and clear annotations, the description covers the operation, shared-key side effects, and flag behavior. Nothing an agent needs to invoke 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 description coverage is 100%, so all four parameters are already documented structurally. The description adds little new parameter-level meaning beyond reinforcing that key and language identify the specific translation and that value is the new human-edited string. This matches the baseline for fully schema-covered parameters.
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 names the exact action ('update the translation value'), the target resource ('phrase key and language'), and the container ('MultiLocale project'). It also distinguishes itself clearly from sibling tools like add_phrase, delete_phrase, and update_project by stating precisely which object and attribute it modifies.
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 clear context: this is for updating an existing translation identified by key and language within a project. It does not explicitly mention alternatives or exclusion conditions, such as 'use add_phrase for new keys' or 'use delete_phrase to remove', so it stops short of the top score but still gives enough situational clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a MultiLocale project’s default locale, complete locale list, or translation context. Project names are intentionally not changed because phrases reference the project name.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Optional translation context for the project. Use an empty string to clear it. | |
| locales | No | Complete replacement list of locale codes. Include the default locale. | |
| defaultLocale | No | New default locale code. It must be one of the project locales. | |
| projectIdOrName | Yes | Project id or project name (slug) |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| project | Yes | |
| changedFields | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as destructive and idempotent, so the description does not need to restate that. It adds beyond the annotations by explaining a non-obvious design invariant: project names cannot be changed because phrases reference the project name. It also signals that the locale list replacement is complete, not additive, which is important destructive context.
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 no filler. The primary action is stated first, and the critical project-name invariants is placed second. Every word 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 description plus the 100% schema coverage and annotations provide most of what an agent needs: what can be updated, the fact that project name stays fixed, and the destructive/idempotent nature. The only notable gap is the lack of explicit guidance about using add_locale versus update_project for locale changes, but the schema's 'complete replacement list' language mitigates this.
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 description is not required to carry param details. It does name the high-level update targets (default locale, complete locale list, translation context), which maps to defaultLocale, locales, and context. But it adds no semantics beyond the schema, such as the requirement that defaultLocale be in the locales list or that the locales param is a complete replacement.
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 names a specific verb (Update), a specific resource (MultiLocale project), and exactly which aspects can be changed: default locale, complete locale list, and translation context. It also distinguishes itself by explicitly stating that project names are intentionally not changed, which separates it from any project-naming operation and from sibling tools like add_project.
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 states what the tool can do and gives an explicit when-not: project names are intentionally not changed because phrases reference the project name. This is a clear exclusion. However, it does not explicitly contrast with add_locale or other sibling tools, so an agent must infer that add_locale is the better choice for adding a single locale rather than replacing the complete locale list.
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. Dates show when Glama detected each change.
add_localeadd_phraseadd_projectdelete_phraseexport_locale_dictionaryfind_duplicate_phrase_valuesfind_missing_translationsget_phraseget_projectlist_phraseslist_projectslist_team_memberssearch_phrasesshare_phraseshow_project_overviewupdate_phraseupdate_projectClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Locize TMS: 26 tools for translations, TM/glossary/styleguide/screenshot context, versions. OAuth.
Accurate, brand-controlled translation for text, code, images, and documents with terminology.
Localization for AI agents: projects, languages, glossaries and translations from your agent
Manage WeInc AI website builder orgs: projects, publishing, custom domains, and previews.
Add one secure layer between your agents and this server.
The tool set separates resources (project, phrase, locale, team member) with clear action prefixes. Some read tools overlap: get_project vs show_project_overview, and list_phrases vs search_phrases, but descriptions clarify exact scope and parameters. No two tools appear to perform the same operation.
All 17 tools follow a consistent lowercase_snake_case verb_noun pattern, e.g. add_project, list_phrases, update_phrase, export_locale_dictionary. There are no mixed conventions, vague verbs, or inconsistent abbreviation styles. This is exemplary.
At 17 tools, the set is on the heavy side for a localization server and above the typical 3-15 well-scoped range. While each tool has a distinct purpose, show_project_overview and the find_* diagnostics add surface area and could be trimmed without losing core functionality. Still, the count is not excessive for the broad domain.
Phrases have full CRUD plus search/share, and projects have create/read/update/list, but delete_project is absent, leaving an obvious lifecycle gap. Team member operations are list-only, and locale removal is only possible indirectly via update_project. Core translation workflows work, but these gaps will block some common tasks.
