Manage translation projects, phrases and locales with secure organization-scoped tools and views.
Scored across 17 tools
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.
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 states 'Refuses to overwrite an existing key,' which indicates a non-destructive create-and-translate operation, while annotations set destructiveHint=true. This is a direct annotation contradiction and seriously misleads an agent about side effects. The additional translation-generation and value-fallback details are helpful, but the conflict dominates.
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 carry purpose, fallback behavior, and overwrite protection with no filler. The most important behavioral facts are front-loaded.
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 exists and parameters are well documented, and the description covers the core create-and-translate behavior. However, the destructiveHint contradiction leaves the safety model ambiguous, and the description does not clarify failure behavior or what happens when translation generation encounters issues, so it is not fully complete.
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 already has a clear type and semantic description. The description reinforces the value-omission behavior, but that is also present in the value property's schema, so it adds no significant 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?
The description states a concrete action: 'Create a new key in a project's default locale and generate translations for every other configured locale.' This distinguishes add_phrase from sibling tools like update_phrase, delete_phrase, and read-only phrase lookup tools.
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 the creation path for new keys and warns 'Refuses to overwrite an existing key,' implying agents should not attempt edits here. It does not explicitly name update_phrase as the alternative for existing keys, so it stops short of a full 5.
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 declare destructiveHint=true and readOnlyHint=false, but the description goes beyond that by stating the deletion is permanent, affects every locale, and cascades to other projects that share the phrase. This gives the agent a clear understanding of the full destructive impact.
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 and the most important side-effect without filler. The destructive action is front-loaded, and the shared-phrase caveat is placed exactly where it 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?
For a simple two-parameter destructive tool with a full input schema and an output schema, the description is complete. It explains scope, permanence, and the surprising shared-phrase side effect, so an agent has enough context 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% and both parameters already have meaningful descriptions. The description reinforces that the key refers to one key's locale group but does not add parameter-level detail 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 specific verb phrase, 'Permanently delete every locale translation for one key in a project,' and clearly identifies the resource and scope of the operation. It also distinguishes itself from less destructive phrase operations by explaining the shared-phrase cascade behavior.
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 implies this is for permanently removing a key's translations, but it never explicitly names an alternative tool or states when not to use it. The phrase 'rather than only detaching the project' hints at a non-destructive alternative, but the agent is left to infer which sibling tool provides that behavior.
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 cover read-only, idempotent, non-destructive behavior. The description adds useful context beyond annotations: the bounded result format (Markdown and structured preview) and the locale behavior (all locales or a single locale when language is provided). 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?
A single, well-structured sentence that front-loads the core behavior and then adds return-format details. There is no wasted or redundant 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?
Given the high schema coverage, strong annotations, and presence of an output schema, the description is complete enough for safe and correct invocation. It covers the lookup scope and the language behavior without over-explaining details already available in structured fields.
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 does not need to compensate for missing parameter docs. The description adds little meaning beyond the schema, though it reinforces the exact key and locale-optionality concepts.
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 ('Fetch') with a clear resource ('translations for one exact phrase key') and scope ('MultiLocale project'). This precisely distinguishes it from sibling search/list tools without needing to name 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 implies usage by emphasizing 'exact phrase key,' which suggests this is not for broad search or listing. However, it does not explicitly say when to prefer this over search_phrases or list_phrases, nor does it state exclusions.
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 readOnly, idempotent, and non-destructive, so no side-effect disclosure is needed. Description adds output specifics ('bounded Markdown', fields), which is mild context, but no auth or rate-limit behavior is addressed.
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, front-loaded with action and identifier, no fluff.
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 tool with a full schema and rich annotations, the description covers what it does and what it returns; nothing needed to invoke it 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 covers 100% of the one parameter, including meaning (id or slug) and maxLength. Description merely repeats 'by id or name', adding no extra semantics.
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 (Fetch) and resource (single MultiLocale project) with id or name. The word 'single' distinguishes it from list_projects, though it doesn't name show_project_overview, so it doesn't fully separate it from all 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?
Implies use when you need one project identified by id or name, but gives no explicit when-not or alternative guidance such as show_project_overview or list_projects. The context is inferable but not stated.
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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by noting the response is a bounded Markdown and structured preview with specific fields, going beyond what annotations alone provide.
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 concise and well-structured: it leads with the action and resource, notes optional filters, and closes with the return format. Every sentence earns its place with no extra fluff.
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 list operation with only three documented parameters, a required project field, and an output schema, the description is complete enough for an agent to invoke the tool correctly. It covers purpose, filters, and response shape without over-explaining.
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 each parameter is already documented in the schema. The description only adds that filtering by language or key is optional, which is mild semantic value beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists translation phrases for a MultiLocale project using a specific verb and resource, and it notes optional filters and the returned fields. However, it does not explicitly differentiate this from the sibling search_phrases or get_phrase tools, so it falls just short of full purpose 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?
The description provides clear context: use this tool to list phrases in a project, with optional filtering by language or key. It does not explicitly state when to choose this over search_phrases or get_phrase, and it does not mention exclusions, but the listing and filtering intent is clear enough for basic routing.
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 convey readOnly, idempotent, and non-destructive. The description adds concrete behavioral bounds: safe project metadata, at most 24 configured locales, and no phrase dictionary download, which goes beyond what the annotations cover.
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 states the purpose, and the second supplies usage context and behavioral limits; every clause carries useful 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 one-parameter, read-only, idempotent tool with an output schema available, the description fully orients an agent: when to call it, what it returns at a high level, and what it deliberately avoids doing.
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 schema fully describes the sole parameter with its type, length constraints, and the phrase 'id or name (slug) to render.' The tool description echoes this without adding new format, resolution, or fallback details, 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?
The description opens with a clear verb and resource: 'Render a bounded overview for a known MultiLocale project.' It distinguishes from siblings like list_projects and get_project by noting the bounded view, the up-to-24-locale limit, and the absence of the phrase dictionary download.
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 explicitly says when to use: 'Use this after listing projects or when the user provides a project id or name.' It gives clear context but does not name alternative tools such as get_project or state when to prefer them instead.
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 description adds significant behavioral context beyond the annotations: it warns that updates propagate across all projects sharing the key and that machine-translation flags are cleared because the value is now human-edited. This is exactly the kind of side-effect disclosure an agent needs. No contradiction with the annotations found.
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 focused sentences with no filler. It front-loads the primary purpose, then adds the two most important side effects. Every sentence contributes useful information for invoking the tool correctly.
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 four-parameter update operation, the description covers the target, the shared-key propagation risk, and the flag-clearing behavior. The schema covers required parameters and an output schema exists, so return-value details are not needed. Nothing critical 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 already documents all four parameters with descriptions, and coverage is 100%. The tool description adds little parameter-level meaning beyond restating that the value is a translation and identifying key/language/project as selectors. This meets the baseline for full schema coverage.
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 action ('update the translation value') targeting a specific resource ('a specific phrase key and language in a MultiLocale project'). It clearly separates this from sibling tools like add_phrase, delete_phrase, or update_project, and the unique scope is obvious.
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 gives clear context for when to use the tool: when changing a translation value. It also surfaces an important caveat that phrases may be shared and the update affects all projects sharing the key. It does not explicitly name alternatives or when-not-to-use conditions, but the intended use is clear.
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 provide destructiveHint=true and idempotentHint=true, covering the mutation safety profile. The description adds useful context by explaining that project names are intentionally unchanged because phrases reference the name. However, it does not itself disclose that replacing the locale list can remove omitted locales; the schema handles that detail.
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 packs the full purpose, and the second adds a valuable constraint with rationale. It 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?
With an output schema, 100% parametr coverage, and annotations for destructive/idempotent behavior, the description is largely sufficient. The only implicit aspect is how optional parametrs interact when omitted, but the schema's 'complete replacement list' and defaultLocale requirements reduce the risk. Slightly more explicit note about partial updates could make it fully complete.
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 parametr already has detailed descriptions, e.g., 'Complete replacement list of locale codes' and 'New default locale code. It must be one of the project locales.' The description summarizes the three updatable areas but does not add new meaning beyond the schema, so 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 clearly states the verb 'Update', the resource 'MultiLocale project', and the exact editable fields: default locale, complete locale list, and translation context. It also explicitly names a non-goal (project names are intentionally not changed) and distinguishes itself from sibling tools like update_phrase and add_locale.
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 clear context about when to use this tool: when updating locale settings or translation context. The explicit statement that project names are not changed is a clear exclusion, and 'complete locale list' implies replacement semantics rather than single-locale addition. It does not explicitly name sibling alternatives like add_locale, so it stops short of a perfect score.
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.
