Multilocale

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, and the description adds useful behavioral detail: it only fills keys currently missing and uses the default-locale value as the source. This prevents an agent from assuming existing translations are overwritten. It doesn't enumerate every side effect, but for a creation/generation tool this is reasonably transparent.

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 and the translation-generation behavior are stated first, and the source-locale detail follows in the second sentence. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description, combined with a complete schema and output schema, provides enough for an agent to select and call the tool. A minor gap is lack of guidance on what happens if the locale already exists, but 'add a new locale' covers the main expectation.

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 baseline is 3. The description adds the meaning of 'default-locale' as source and clarifies 'missing translations', but does not explain model or context parameters beyond what the schema already states.

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 ('Add'), a resource ('a new locale to a project'), and a concrete action ('generate translations for every key currently missing'). It clearly distinguishes this from siblings like add_project and 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 intended use case clear: use this tool when adding a new locale and populating it with translations for missing keys. It does not explicitly name alternatives or exclusions, but the scenario is specific enough for an agent to choose correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations already declaring readOnlyHint false and destructiveHint true, the description adds genuinely useful behavior: it operates in the authenticated organization and refuses duplicate project names, which also explains the non-idempotent nature. It does not over-explain beyond what the annotations and schema already convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the core action and followed by the key constraint. Every clause earns its place and there is no redundant restatement of the title or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple creation tool with a 3-parameter schema, full property descriptions, and an output schema, the description covers the essential semantics: what is created, how locales are supplied, duplicate behavior, and organization scope. A minor gap is that it does not mention what happens when the defaultLocale is also listed in locales, but that is not necessary for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides 100% description coverage for name, locales, and defaultLocale, including the automatic addition of the default locale when omitted. The description reinforces the default-plus-optional structure but adds no parameter-specific detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource ('Create a MultiLocale project') and scopes the operation to a default locale plus optional additional locales. This clearly distinguishes it from sibling tools like add_locale 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 intended use is clear: invoke this to create a new project, with a uniqueness guard for duplicate names. It does not explicitly route to alternatives such as update_project or add_locale, but the create semantics and sibling context make the selection unambiguous enough without exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral detail beyond that: results are bounded, sorted, API-paginated with a maximum of 50 entries per call, and each value is capped at 500 characters. This helps an agent anticipate limits and pagination without contradicting 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?

The description is two sentences with no filler. It front-loads the core purpose, then adds the key pagination and size constraints. Every sentence contributes 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 an export tool with a thorough input schema, an output schema, and annotations covering safety and idempotency, the description is complete enough. It covers sorting, pagination, entry limits, value caps, and the one-locale scope. No critical operational 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?

Schema description coverage is 100%, so the schema already documents project, language, skip, and limit. The description adds helpful context that the export is sorted and paiated, which supports the skip/limit semantics, but it does not provide further per-parameter meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Export' with a specific resource ('one locale of a MultiLocale project') and describes the output as 'bounded, sorted key/value entries'. This clearly distinguishes it from listing or searching tools in the sibling set. It also adds the important one-locale scoping detail.

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 that the tool is for exporting a locale dicionary and is API-paginated, so the usage context is implied. However, it does not explicitly state when this should be preferred over siblings such as list_phrases or search_phrases, nor does it mention exclusions or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds real behavioral context beyond the annotations: scans are bounded, and the result explicitly reports truncation of either the scan or output preview. This is exactly the kind of non-obvious behavior an agent needs to know, and it does not contradict the readOnly or idempotent hints.

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, both earning their place. The primary action is stated first, and the important truncation behavior follows without redundancy or 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 simple read-only tool with an output schema, full parameter documentation, and clear annotations, the description is complete. It explains the core operation, the bounded-scan nature, and the truncation reporting, leaving no critical gap for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with project and scanLimit already documented in the schema. The tool description adds no parameter-specific meaning beyond what the schema provides, so the baseline score 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 states a specific verb and resource: it finds keys whose default-locale translations share the same value, within a bounded scan of one MultiLocale project. This clearly distinguishes it from the sibling find_missing_translations without requiring schema inspection.

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 when to use it (to detect duplicate default-locale copy) and gives useful context like bounded scanning, but it does not explicitly state when to use this tool over alternatives such as search_phrases or find_missing_translations. Usage guidance is adequate but left mostly to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds meaningful behavioral context beyond annotations: it is a bounded scan, it explicitly reports partial scans, and it never creates translations. This complements the readOnlyHint and idempotentHint annotations rather than merely repeating 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 tightly written sentences convey purpose, scope, result behavior, and safety guarantee with no filler. The core function is front-loaded, and 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 full schema parameter documentation and an output schema, the description is complete. It covers the scan scope, comparison baseline, partial-scan transparency, and non-destructive behavior, leaving no critical gap for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds extra semantic value by explaining the comparison baseline (project default locale) and the bounded nature of the scan (one locale or up to 10 locales), which enriches the agent's understanding of language and localeLimit 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 uses a specific verb ('Report') and resource ('missing keys... compared with the project default locale'), making the tool's function immediately clear. It also distinguishes itself from sibling tools by emphasizing detection of missing translations rather than export, search, or phrase editing.

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 indicates the tool is for reporting translation coverage gaps across one or multiple locales. It does not explicitly name alternatives or exclusion conditions, but the context is strong enough for an agent to know when this read-only reporting tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that the result is 'bounded' and includes both Markdown and structured previews, which is context 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 with no redundant words. The core action and scope are in the first sentence, and return details in the second. Every part 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 zero parameters, a clear scope, and output schema available, the description is nearly complete. The only minor gap is not detailing pagination or the exact structure of the 'bounded' preview, but the output schema and structured preview reduce the need for that detail.

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?

There are no parameters to document. The description clarifies the return content (project ids, names, locales, timestamps), which is the only meaningful semantic information an agent could need for a parameterless 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?

States a specific verb ('List') and resource ('MultiLocale projects the authenticated user has access to'), and clearly indicates the returned elements (ids, names, locales, timestamps). This clearly differentiates it from sibling tools like add_project or delete_phrase.

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 it lists projects the authenticated user has access to, providing clear context. It does not explicitly mention when not to use it or compare it with alternative tools, but for a parameterless listing operation, this is sufficient context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds meaningful behavioral details: the result is 'bounded', only display name and role are returned, and specific fields are excluded. This goes beyond what annotations 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?

Two concise sentences deliver the core purpose, scope, and exclusions without redundancy. The key behavior is front-loaded, and every phrase 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 parameterless list tool with an output schema and safety-related annotations, the description is complete. It tells the agent what will be returned and what will not, which is all that is needed 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?

There are zero parameters, so the description carries no parameter burden. The baseline for a parameterless tool is 4, and the description appropriately focuses on return scope rather than 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 states a specific verb ('List'), a specific resource ('bounded roster for the authenticated MultiLocale organization'), and the exact data included. It clearly differentiates this from sibling tools focused on phrases, projects, locales, and 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 provides clear context that this is for listing members of the authenticated MultiLocale organization. It does not explicitly name alternatives or exclusions, but no sibling tool overlaps with team member listing, so the usage context is sufficiently clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already disclose readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is known. The description adds useful behavioral context: it returns a bounded Markdown and structured preview, and it matches against both keys and values. It doesn't disclose details like case sensitivity or partial vs. exact matching, but the 'bounded' preview is a valuable behavior disclosure beyond 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?

One sentence with no filler. It front-loads the action and resource, then states the result format. Every clause earns its place, and no redundant schema information is repeated.

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 search tool with a rich output schema and full schema parameter coverage, the description is largely complete. It states the matching target, the result format, and the bounded nature. The only gaps are minor: no mention of case sensitivity, pagination limits, or matching semantics (substring vs. exact), but these are not critical for an agent to select and 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 schema already documents all three parameters (query, project, language). The description adds that matching is against phrase keys and values and that the result is bounded, but it doesn't add much beyond what the schema provides. Baseline 3 is appropriate because the schema carries the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Search'), a specific resource ('translation phrases for a MultiLocale project'), and the matching scope ('against phrase keys and values'). It differentiates from sibling tools like list_phrases by emphasizing query-string matching, and from get_phrase by covering multiple results. The title 'Search phrases' is reinforced, and an agent can distinguish this tool from siblings without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clarifies when to use this tool: search by a query string against phrase keys and values. It doesn't explicitly say when NOT to use it or name alternatives like list_phrases or get_phrase, but the context is clear: this is the search tool for matching text, while list_phrases would be for broad listing and get_phrase for direct retrieval. It misses a direct comparison to list_phrases, so it's not a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description discloses that the call mutates underlying phrase rows into a shared state and that edits thereafter propagate to every attached project — an enduring side effect. This adds specificity about what changes and carries ongoing consequences, and it is consistent with destructiveHint=true, so there is no contradiction.

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 core action and scope, the second delivers the critical behavioral consequence. Nothing is repeated from the schema or annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter mutation tool with full annotation coverage and an output schema, the description covers the core call scenario and its enduring side effect. The main gap is the unhandled edge case of a target project that already contains the same key, which is a plausible call given siblings like add_phrase and update_phrase exist.

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%: project is documented as the source id/name containing the key, key as the exact key across locales, and targetProjects as the attachments. The description's wording mirrors these definitions (source project, target projects, every locale translation) without adding new parameter-level detail, so the coverage baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (Attach) on a concrete resource (every locale translation for one key in a source project) with a clear target (one or more target projects). The shared-row consequence in the second sentence distinguishes this from copy behavior and from siblings like add_phrase or update_phrase, which create or modify phrases rather than link them across projects.

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: attach a key's translations to target projects and keep them in sync, since future edits propagate to all attached projects. It does not name alternatives explicitly or state exclusion conditions (e.g., when a target project already contains the key), which keeps it just short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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.

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.

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.