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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered; the description's 'adds or replaces' is consistent with the idempotent/replace semantics. It adds the monodirectional vs multidirectional capability, which annotations do not convey, but does not explain what a replace destroys or any auth/rate-limit constraints.

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 with the core action front-loaded and the glossary-type nuance second; every clause earns its place with no filler.

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

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

An output schema exists and the input schema is rich, so return values and parameter details need not be repeated. For a destructive, idempotent mutation the description is adequate, though it could have noted that the target glossary must exist and that replacement overwrites existing term data.

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 id format, guid usage, and the terms array structure including the source/target ordering for monodirectional glossaries. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb pair (adds or replaces) and a specific resource (an entry in a glossary in your Lara Translate account). The 'adds or replaces' framing implicitly separates it from the sibling delete_glossary_entry, but no sibling is named explicitly.

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 'adds or replaces' phrasing and the mention of monodirectional vs multidirectional glossaries imply when the tool applies, but there is no explicit when-to-use guidance, no statement of prerequisites (e.g. glossary must exist), and no routing to alternatives such as update_glossary or delete_glossary_entry.

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 carry the behavioral profile (readOnlyHint=false, destructiveHint=true, idempotentHint=false, openWorldHint=false), and the description adds nothing on top: no note about duplicates, reversibility, auth/permission requirements, or what destruction means. With annotations present the bar is lower, but the description still contributes no extra behavioral context.

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

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

A single front-loaded sentence with no wasted words. It is appropriately sized, though its brevity is partly under-specification rather than disciplined conciseness.

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

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

With an output schema present, return values need not be explained, and the input schema is fully documented with no gaps. However, for a destructive, non-idempotent write tool, the description does not state preconditions (memory must exist, duplicate handling) that the structured fields leave open.

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

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

Schema description coverage is 100%, and the schema itself is rich (field semantics, the mem_xyz123 format, and the list_languages cross-reference for language codes). The description adds no parameter-level meaning, so the baseline 3 for full schema coverage is appropriate.

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

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

States a specific verb and resource: adding a translation to a translation memory in the Lara Translate account. It clearly identifies the object of the operation, but it does not differentiate from related siblings such as import_tmx (bulk add) or delete_translation, so an agent must infer the boundary.

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 when-to-use guidance, no exclusions, and no mention of alternatives. The sibling set includes import_tmx and delete_translation, which are natural companions/alternatives, but the description gives no routing signal for choosing between them.

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/non-destructive/closed-world, so the safety profile is covered. The description adds the non-obvious operational trait that this is a polling endpoint to be called repeatedly until completion, which is genuine context beyond the annotations, though it says nothing about rate limits or what a terminal state looks like.

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 the purpose and followed immediately by the actionable polling instruction. Nothing wasted.

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

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

For a single-parameter polling tool with an output schema and full annotation coverage, everything an agent needs is present: what it does, when to call it, and how to drive the poll loop. Return-value details are appropriately left to the output schema.

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 baseline is 3. The description adds provenance the schema lacks — the id comes from import_glossary_csv — which helps the agent source the value, though it calls it 'import_id' while the schema names it 'id', a minor mismatch.

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?

Specific verb ('checks the status') plus resource ('glossary CSV import job'), and it names the originating sibling tool import_glossary_csv, which distinguishes it from the TMX-oriented check_import_status sibling.

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

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

Explicitly states when to call it (after import_glossary_csv) and how (poll with the returned import_id until complete). It does not, however, explicitly rule out or contrast with the sibling check_import_status, leaving that routing 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: this is a polling endpoint, the ID originates from import_tmx's response, and progress is the field to watch for completion.

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

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

Three short sentences, front-loaded with the purpose and followed by the polling instruction and completion signal. The progress-field sentence is somewhat redundant with the existing output schema, but overall there is little waste.

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 rich annotations, a fully described single-param schema, and an output schema carrying the return values, the description needs only to explain pairing and polling — which it does. The only missing piece is explicit disambiguation from check_glossary_import_status.

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

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

Schema coverage is 100% with a single parameter, so the baseline would be 3. The description earns an extra point by disclosing provenance — the id is the value returned by import_tmx — which the schema's generic "The ID of the import job" does not convey; a minor naming drift ("import_id" vs schema's "id") is the only friction.

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 ("Checks the status of a TMX import job") and names the tool that creates the job (import_tmx), which implicitly separates it from the look-alike sibling check_glossary_import_status. It is clear and scoped, though it never explicitly rules out the glossary-status sibling.

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

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

Gives concrete operational guidance: poll this tool with the import_id returned from import_tmx until the import is complete. That is a clear when-to-use trigger and an exit condition. It stops short of naming the alternative (check_glossary_import_status) for non-TMX imports.

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 this is a non-read-only, non-destructive, non-idempotent creation, so the safety profile is covered. The description adds the conceptual role of glossaries but says nothing about required account/permissions, whether duplicate names are allowed, or naming constraints beyond what the schema already states.

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, action front-loaded in the first clause, and the second sentence earns its place by explaining the resource's purpose. No filler or repetition.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. However, for a mutation tool in a 21-sibling family, the description omits any guidance on when this creator is the right choice versus the related create/import tools.

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?

With a single parameter and 100% schema description coverage, the schema already carries the naming guidance ('short and descriptive, like brand_terms'). The description's phrase 'with a custom name' adds no semantics beyond that, so the 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 states a specific verb+resource ('Create a glossary') and adds a one-line definition of what a glossary does. It is clearly distinguishable by resource from siblings like create_memory or create_record, though it does not contrast itself with the other glossary-creation paths (import_glossary_csv, add_glossary_entry).

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?

Usage is only implied: the note that glossaries 'enforce specific terminology during translation' hints at why you would create one, but there is no statement of when to create a new glossary versus importing an existing CSV or adding entries to an existing one. No prerequisites or exclusions are given.

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 safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the mutating, non-idempotent nature is covered. The description adds that the memory lives in the user's account and stores source/target segment pairs, which is modest extra context but says nothing about duplicate-name handling, limits, or auth requirements.

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

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

Two sentences, front-loaded with the action and resource, with no repetition of the title. The second sentence is explanatory rather than operational but is short and does orient an agent unfamiliar with translation memory concepts.

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 full schema coverage, a present output schema, and annotations covering safety, the description only needs to convey purpose and domain, which it does. It stops short of describing what the created memory returns or how external_id import interacts with creation, but nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100%: the name parameter already documents its purpose and gives examples ('catch_phrases', 'brand_names'), and external_id documents the MyMemory import format. The description only echoes the 'custom name' concept, adding nothing beyond the schema, 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 specific verb and resource ('Create a translation memory') and names the account scope, so it is immediately distinguishable from list_memories, update_memory, and delete_memory in the sibling set. It never explicitly contrasts itself with those siblings, but the verb alone carries the distinction.

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 statement of when to invoke this tool versus alternatives (import_tmx, create_glossary, add_translation), nor any prerequisites or exclusions. The second sentence explains what a memory is for, which only weakly implies a use case.

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, idempotentHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond them — it does not say the deletion is irreversible, whether glossary entries are cascaded away, or whether the caller needs elevated permissions, which is what a destructive tool's prose should supply.

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 short, front-loaded sentence with the verb first and no wasted clauses. The trailing 'from your Lara Translate account' is mild filler rather than useful information, but nothing is buried.

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

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

An output schema exists, so return values need not be explained, but for a destructive, irreversible operation the definition is thin: no cascade behavior, no confirmation or precondition notes, and no routing to the entry-level deletion sibling. An agent can call it, but not safely or confidently.

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

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

Schema description coverage is 100% and the single 'id' parameter is fully documented with its gls_* pattern and example, so the baseline of 3 applies. The description contributes no additional meaning about the identifier.

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 ('Deletes a glossary'), so the action is unambiguous. It does not, however, differentiate itself from the sibling delete_glossary_entry, nor state whether the whole glossary and its entries go away together — the agent must infer that from the name alone.

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 when-to-use guidance, no prerequisite (e.g., glossary must exist, required permissions), and no pointer to alternatives such as delete_glossary_entry for removing single terms. The agent gets only the bare statement of the operation.

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, idempotentHint=true and readOnlyHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that — it never states the deletion is permanent, whether the entry can be recovered, or what happens on a missing id.

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

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

Two short sentences, purpose front-loaded and the parameter routing second. 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?

With annotations covering destructiveness/idempotency, an output schema covering returns, and a fully documented schema, the definition is nearly self-sufficient. It only omits any note on irreversibility or error behavior for the destructive path.

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 itself already labels guid for multidirectional and term for monodirectional glossaries, so the description largely restates structured data. It adds no format, validation, or mutual-exclusivity 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?

States a specific verb and resource: 'Deletes an entry from a glossary.' The noun 'entry' distinguishes it from the sibling delete_glossary, but no sibling is named explicitly and the account scope is the only additional qualifier.

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

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

Gives explicit conditional routing: use term for monodirectional glossaries, guid for multidirectional glossaries. That is clear when-to-use-which guidance, but it does not address when to prefer this tool over alternatives or any preconditions.

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, idempotentHint=true, and readOnlyHint=false, so the agent knows this is a permanent, idempotent write. The description adds nothing beyond that — no note that deletion is irreversible or what happens to translations referencing the memory, which is the kind of context a destructive tool should supply.

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 efficient sentence with the verb and resource front-loaded; nothing is wasted, though it is minimal rather than information-dense.

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

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

An output schema exists and annotations cover the safety profile, so the core is covered. Still, for a destructive operation the description should at minimum signal irreversibility or required permissions, which it omits.

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?

With one parameter at 100% schema description coverage, the schema already documents the id format (mem_xyz123). The description adds no parameter meaning of its own, so the baseline of 3 applies.

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

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

States a specific verb (deletes) and resource (translation memory) scoped to the Lara Translate account, which cleanly separates it from siblings like delete_translation and delete_glossary. It does not, however, explicitly contrast itself with those siblings.

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

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

The description offers no guidance on when to use this tool versus update_memory, list_memories, or other deletion tools, and gives no prerequisites or confirmation requirements. Usage is only implied by the verb.

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, idempotentHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is covered elsewhere. The description adds nothing beyond confirming the resource: it does not say the deletion is permanent, what happens when the id array holds several memories, or whether the unit can be restored. Also, it describes deleting 'a translation' singular while the schema's id parameter is an array.

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 sentence, front-loaded with the verb and resource, with no filler or repetition of the name. Nothing could be trimmed without losing meaning.

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 output schema exists, so return values need not be explained, and annotations cover the destructive/idempotent profile. However, for a destructive delete requiring 5 of 8 parameters and supporting optional context fields (sentence_before/sentence_after), the description supplies no matching or scoping guidance, leaving it barely adequate.

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% across all 8 parameters, so the schema carries the full burden of parameter meaning (id format mem_xyz123, tuid, language codes, sentence context fields). The description contributes no additional param semantics, which is the baseline-3 case when the schema is this rich.

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 (deletes) plus resource (a translation from a translation memory in the Lara Translate account), which is enough to separate it from delete_memory, delete_glossary and delete_glossary_entry. It is slightly ambiguous whether the unit being removed is the 'translation' field or the whole translation unit, a distinction the annotation title supplies but the description does not.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as update_memory or delete_memory. The agent gets no signal about when this destructive call is appropriate versus other memory-mutating siblings.

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=true, idempotentHint=true and destructiveHint=false, so safety is covered structurally. The description adds the input-size ceiling (128 elements) and the multi-step orchestration behavior with translate, which the annotations do not convey. It does not disclose anything about latency or cost for large batches, so it falls short of a 5.

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

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

The purpose and output shape are front-loaded in the first two sentences, and the usage rule follows. The final sentence is dense with nested parentheticals, and part of the translate guidance is arguably over-explained for a detection tool, but nothing is wasted enough to obscure the core instruction.

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

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

With an output schema present, the description need not detail return values, and it covers input shape, limits, and workflow positioning. It leaves the optional 'hint'/'passlist' controls unexplained, which is the main remaining gap for a 3-parameter tool.

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

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

Schema description coverage is 100%, so baseline is 3. The description restates the string-or-array shape and 128-element limit already documented in the schema, and says nothing about the 'hint' or 'passlist' parameters, which are the ones most likely to be misused.

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 first sentence states a specific verb+resource ('Detects the language of the provided text'), and the second sentence names the outputs. It is trivially distinguishable from siblings like translate and list_languages, which do different jobs.

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

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

It gives an explicit when-to-use rule ('whenever the user asks to know or confirm what language a text is written in'), covers the compound case with translation, and specifies call ordering plus what to report back. No inference is required about when this tool is the right choice.

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 the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description's burden is lighter. It adds the unidirectional/multidirectional format dimension but does not state whether export triggers file generation, where output goes, or any size limits.

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, purpose front-loaded before the format detail, with no filler. Every clause carries information.

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

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

The tool is simple, an output schema exists so return values need no explanation, and annotations carry the safety semantics. The one minor gap is that the conditional 'source required for csv/table-uni' rule is only in the schema, not the description, but that is adequately covered elsewhere.

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 id, source, and the content_type enum plus the conditional source requirement. The description's mention of uni/multidirectional formats merely restates the enum, adding no syntax or behavioral 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?

States a clear verb+resource ('exports a glossary') plus the output format ('as CSV') and account scope, which distinguishes it from get_glossary/list_glossaries. It does not name or contrast with those siblings explicitly, so it stops short of a 5.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no alternatives such as get_glossary or list_glossaries. The only hint is that two export formats exist, which is format information rather than usage direction.

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, non-destructive, closed-world behavior, so the safety profile is covered. The description adds a genuinely useful behavior not in the annotations: it returns null when the glossary is not found, telling the agent how to detect a miss rather than assuming an error.

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, zero waste, with the core action front-loaded and the not-found behavior appended. Nothing is redundant or padded.

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

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

With a 100%-documented single parameter, rich annotations, and an output schema covering return values, the description only needs to convey purpose and the not-found edge case, which it does. It stops just short of routing the agent among the many glossary siblings.

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

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

Schema description coverage is 100%, and the single id parameter's format (gls_* pattern, example) is fully documented in the schema. The description adds no parameter detail beyond referencing "by ID", so the schema 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?

States a specific verb (Retrieves) and resource (a specific glossary by ID) plus the account scope. It clearly distinguishes a single-item fetch from a collection listing, though it does not name sibling tools like list_glossaries or get_glossary_counts.

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 "by ID" phrasing implies usage when the caller already has an identifier, but no explicit when-to-use/when-not or alternative routing is given (e.g., use list_glossaries to discover IDs first). Guidance is implied rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered by structured data. The description adds no behavioral context beyond the annotations — no error handling for an unknown/invalid glossary ID, no note on auth requirements, and no indication of what units the counts use.

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, no filler, and the resource scope is front-loaded. It is appropriately sized for a simple single-parameter read tool, though it is too terse to convey any usage or behavioral nuance.

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

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

An output schema exists, so return values need no explanation, and the annotations plus the fully documented single parameter cover the rest. For a one-parameter read-only tool this is nearly complete; only error behavior for an invalid ID is left unspecified.

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%: the single id parameter is documented with its gls_* pattern and example, and the description adds no format, constraint, or semantics beyond that. Baseline 3 applies when the schema already does the heavy lifting.

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

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

The description gives a specific verb ("Retrieves") and a precise resource ("term and language counts for a glossary"), which clearly separates it from the broader get_glossary sibling that returns glossary details. It does not name a sibling explicitly, so it stops short of a 5.

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

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

Usage is only implied: an agent can infer you call this when you need counts rather than full glossary data, but the description never states when to prefer it over get_glossary (which may already surface counts) or after operations like add_glossary_entry. No prerequisites or exclusions are given.

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 declare destructiveHint=true and idempotentHint=true, yet the description adds genuinely non-derivable workflow context: the operation is asynchronous, returns a job object with an import_id, and must be polled to completion. It omits any warning about what the destructive import overwrites in the target glossary, which is the one notable gap.

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

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

Three tight sentences: purpose, format scope, then the async/polling contract, each front-loaded with no filler. Every sentence carries distinct 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?

An output schema exists, so return values need no explanation, and the description still covers the async lifecycle end-to-end including the sibling tool to poll with. For a destructive, annotated import tool, nothing needed to invoke and complete the workflow 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 id/content_type/csv_content/gzip are already fully documented in the schema. The description restates the unidirectional vs multidirectional distinction that the content_type enum already encodes, adding no new syntax or format detail.

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 ('Imports a CSV file into a glossary') and names the supported formats, which distinguishes it from the sibling import_tmx (TMX vs CSV). An agent can identify the tool 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?

Explicitly tells the agent the call is async and routes the follow-up to check_glossary_import_status with the returned import_id — a clear when/how-to-continue instruction. It does not, however, compare against import_tmx or state when CSV import is preferred over other ingestion paths.

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, readOnlyHint=false and non-idempotent, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the operation is asynchronous and returns an import job with an import_id that must be polled. It does not explain what 'destructive' means here (e.g., whether existing translation units are merged or overwritten), leaving a small gap.

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

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

Three short sentences, front-loaded with what the tool does, then the async contract, then the follow-up action. Every sentence carries information the agent needs; nothing is redundant.

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

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

An output schema exists, so the return shape needn't be explained, yet the description still highlights the import_id field that drives the polling loop. For a 2-param destructive async tool, the description covers the operation, its async nature, and the required next step — nothing material 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% — both 'id' (with mem_xyz123 format) and 'tmx_content' are documented in the schema itself. The description adds no parameter-level detail beyond what the schema provides, so the 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?

States a specific verb+resource ('Imports a TMX file into a translation memory') and names the exact file format, which cleanly separates it from the sibling import_glossary_csv. An agent can identify the operation without opening the schema.

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

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

Explicitly tells the agent this is async and to poll with check_import_status using the returned import_id, which is the key usage context for a sibling that exists in the tool list. It does not state when-not to use it or how it differs from other memory-writing tools like add_translation, so it stops short of full when/alternative guidance.

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, non-destructive and closed-world, so the safety profile is covered. The description adds domain context (what a glossary is) but says nothing about pagination, result size, or ordering behavior an agent might need for a full listing.

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 front-loaded sentences with no filler; the purpose leads. The second sentence is definitional background rather than invocation guidance, but it is short and plausibly useful to an agent unfamiliar with the terminology domain.

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 full output schema, and annotations covering the safety profile, almost nothing is left for the description to carry. It is appropriately complete, with only return-shape/pagination behavior unaddressed.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond what the schema already states. Baseline for 0 params applies.

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

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

States a specific verb and resource ('Lists all glossaries') and scopes it to the account. The plural/'all' framing implicitly contrasts with the singular get_glossary sibling, but the description never names a sibling to make the distinction explicit.

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

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

Usage is only implied: an agent infers this is the discovery tool to call before get_glossary/update_glossary/delete_glossary, but no when-to-use or when-not-to-use guidance is given, and alternatives are not named.

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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only the account-scoping detail and nothing about result size or ordering; for a parameterless read this is adequate but not enriching.

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 front-loaded sentence with no wasted words. The verb and scope lead, and no filler or redundant restatement of the title is present.

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

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

With an output schema present, return values need not be explained, and there are no parameters or complex behaviors to document. The description is sufficient for this simple enumeration tool, though it omits whether the list is paginated or sorted.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies since no parameter semantics are required.

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 (Lists) and resource (all supported languages), plus the scoping context 'in your Lara Translate account'. It is clear enough on its own, though it does not explicitly differentiate itself from the nearby detect_language or translate 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?

There is no when-to-use guidance, no mention of alternatives, and no conditions or prerequisites stated. An agent must infer that this is a lookup helper to call before translate or detect_language.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds only the account-scope detail ('in your Lara Translate account'), which is mildly useful but not rich behavioral context.

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

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

A single, front-loaded sentence with no filler or repetition. It is efficient, though it carries no extra information beyond the name and title.

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 full output schema for return values, and annotations covering the safety profile, little more is required. The remaining gap is usage context relative to sibling list tools, which does not affect 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 tool takes zero parameters, so the baseline is 4. The description correctly implies a no-argument, unfiltered listing, consistent with the empty 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?

States a specific verb (Lists) and resource (translation memories) scoped to 'your Lara Translate account'. However, it offers no differentiation from sibling list tools such as list_glossaries or list_languages, which an agent must disambiguate by name alone.

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 call this versus other listing tools, nor any prerequisites or follow-up actions. The agent must infer usage purely from the name.

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 only declare the generic profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description must carry the operational burden. It does disclose non-obvious call-pattern behavior: one language per call requiring repeated invocations, and a mandatory ID-resolution step before glossary use. It does not discuss tracing/storage implications (no_trace lives only in the schema) or that repeated identical calls create new translations.

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?

Front-loaded with the core purpose, then two clearly flagged IMPORTANT blocks for the highest-risk failure modes. Every sentence carries guidance, though the target-language constraint is duplicated nearly verbatim from the schema description, adding a little length without new 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 14-parameter tool with 100% schema coverage and an output schema, the description only needs to cover routing and workflow pitfalls, which it does (multi-language fan-out, glossary ID resolution, instructions discipline). Remaining parameters (style, priority, reasoning, timeout, no_trace, content_type) are fully documented in the schema and need no repetition.

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% (baseline 3), and the description adds real meaning on top: it explains when to use 'instructions' and that they must not be contradictory, and it explains the 'gls_*' ID requirement plus the list_glossaries resolution workflow for 'glossaries'. The 'target' single-code rule is restated from the schema, which is mildly redundant but harmless.

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

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

States a specific verb+resource ('Translate text between languages using Lara Translate') and immediately scopes the capabilities (detection, context-aware translation, memories, glossaries). It is unmistakably distinct from siblings like detect_language, list_glossaries, or add_translation.

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

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

Gives explicit when-to-use and when-not-to-use rules: only supply 'instructions' when tone/formality/terminology adjustments are needed, call once per target language for multi-language requests, and call list_glossaries first when the user names a glossary. It even specifies the fallback (tell the user rather than guess an ID).

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=false, destructiveHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered elsewhere. The description adds nothing beyond that — it doesn't explain that the existing name is replaced, whether the glossary must pre-exist, or any auth/rate-limit context.

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

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

A single, well-formed sentence with the action and target front-loaded and no filler. It is efficient, though extremely terse for a mutation tool.

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

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

An output schema exists, so return values need not be described, and annotations carry the behavioral profile. For a two-parameter rename tool this is minimally adequate, but it omits any note about preconditions or side effects of replacing the name.

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 both id and name fully documented in the schema, so the baseline is 3. The description reinforces that only the name is the mutated field, but adds no format or edge-case 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 names a specific verb and resource ('Updates the name of a glossary'), making the narrow scope clear — it renames rather than mutating entries or settings. It does not explicitly distinguish itself from neighboring glossary tools, but the stated scope is unambiguous.

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 versus alternatives such as create_glossary, delete_glossary, or the entry-level tools. Usage is only inferable from the word 'Updates', with no exclusions, prerequisites, or routing hints.

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=false, idempotentHint=true, and destructHint=true, so the safety profile is covered. The description adds nothing beyond that—no mention of what is affected, permission requirements, or reversibility—so it contributes no behavioral context of its own.

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, front-loaded sentence with no redundancy. It is efficient, though the phrase 'in your Lara Translate account' is mild filler that could be trimmed to make room for actual usage or behavioral detail.

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

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

With an output schema present, return-value explanation is unnecessary, and both parameters are fully covered by the schema. The description is technically sufficient to invoke the tool but omits the rename semantics and any usage framing, leaving a modest gap given the rich structured data available.

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 both id (format mem_xyz123) and name fully documented in the schema. The description adds no meaning beyond that, so the baseline of 3 applies.

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

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

States a verb ('Updates') and a resource ('a translation memory'), so the operation is identifiable. However, 'updates' is generic and does not convey that this operation specifically renames the memory (which the annotation title and the id+name schema reveal), and it does not distinguish this from siblings like create_memory or delete_memory.

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 offers no when-to-use guidance, no prerequisites, and no mention of alternative tools such as create_memory or delete_memory. An agent must infer entirely from the name and schema that this is the correct tool for changing a memory's name.

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