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

With no annotations provided, the description carries the disclosure burden. It adds one meaningful behavioral fact: chapters must be added later via the Motimate interface. However, it does not mention return values, permissions, or duplicate-creation behavior, leaving some behavioral ambiguity.

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, front-loaded sentences: the first states the action and scope, the second lists the affected fields, and the third gives a key limitation. Every sentence earns its place with no redundancy.

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

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

The description plus the fully documented schema provide enough to call the tool correctly for the initial creation step, and the chapter caveat prevents a false expectation. However, with no output schema and no annotations, the description leaves return/confirmation behavior and side-effect details unstated.

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 every parameter. The description's list of settable fields maps to most parameters but adds no new semantic detail beyond the schema; locked_order is not mentioned in prose, though the schema covers it.

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: 'Erstellt eine neue Schulung (Moti) in Motimate.' The word 'neue' clearly separates creation from the sibling motimate_update_moti, and listing the settable fields makes the tool's scope 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?

It is clear from 'Erstellt eine neue Schulung' that this tool is for creating a new Moti, and the closing sentence sets the boundary that chapters cannot be added through this tool. It does not explicitly name alternatives like motimate_update_moti, but the context is strong enough.

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?

No annotations are provided, so the description must carry the burden of behavioral disclosure. It indicates a read-only retrieval operation ('Gibt zurück') and states that the result includes the contained trainings. However, it does not mention behavior for invalid or missing learning_path_id, permissions, pagination, or potential side effects, leaving some transparency gaps.

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 a single, front-loaded sentence that states the main action and the most useful additional detail (that contained trainings are included). There is no filler 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?

For a one-parameter retrieval tool without an output schema, the description is minimally viable: it tells the agent what the tool returns and the schema identifies the required input. It omits response shape, ordering, and error behavior, which are notable gaps but not critical for a simple read operation.

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 fully documents the single parameter learning_path_id with a clear German description. The tool description adds no additional semantic detail about the parameter 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 uses a concrete verb ('Gibt ... zurück' / returns) and a concrete resource ('alle Abschnitte eines Lernpfads' / all sections of a learning path), and adds that contained trainings are included. This clearly distinguishes it from sibling tools like motimate_get_moti_chapters, which targets chapters of a MOTI, and motimate_search_learning_paths, which searches for learning paths.

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

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

The description implies the usage context: call this when you have a learning_path_id and need the sections of that learning path, including their trainings. However, it gives no explicit 'when not to use' guidance and does not contrast with sibling tools, so the agent must infer when this 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?

With no annotations, the description must carry behavioral information. It correctly implies a read-only operation, but it does not disclose that include_content defaults to true and controls whether heavy content blocks are loaded, nor does it provide response or error behavior.

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, focused sentence with no filler. It states the purpose clearly and is easy to parse.

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 2-parameter getter with full schema coverage, the description is minimally sufficient. However, there is no output schema, no mention of the content-block inclusion behavior, and no relationship to sibling tools, so some semantics must be inferred.

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 already documents both parameters fully (100% coverage). The description adds no real parameter-level semantics beyond referencing 'einer bestimmten Schulung' for moti_id.

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 operation: returns all chapters of a specific training. It uses a specific verb and resource, but it does not mention how this differs from sibling tools like motimate_search_moti_content or motimate_get_moti_progress.

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 phrase 'einer bestimmten Schulung' implies the tool is used when a specific training ID is already known and its chapters are needed. There is no explicit guidance on when not to use it or which alternative to choose.

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?

No annotations are provided, so the description carries the behavioral disclosure burden. It conveys read-only behavior through 'Zeigt' and describes filtering behavior, but it does not disclose output shape, pagination, permissions, or what exactly constitutes 'Lernfortschritt'. This is adequate but thin.

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 short, front-loaded sentences with no filler. The first sentence identifies the action and object; the second states the filtering options. Every word earns its place.

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

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

For a simple read tool with two optional parameters, the description provides enough to invoke it. However, since there is no output schema, it does not clarify whether the result is per-user progress, aggregated progress, or a list of records, leaving the agent to infer the return shape.

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 parameters already explained in the schema. The description's mention of filtering by Schulungs-ID or Nutzer-ID adds only a slight rephrasing of the schema semantics, so it provides no meaningful additional value.

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 clear action ('Zeigt' = shows) and a specific resource ('Lernfortschritt von Nutzern in einer Schulung'), and identifies the two relevant filter dimensions. It does not explicitly differentiate from sibling tools, though 'progress' is a distinct concept from the chapter/content/search 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 implies usage contexts: retrieve progress for a specific training or user, or for all via empty IDs. However, it gives no explicit guidance on when to prefer this tool over alternatives like motimate_get_moti_chapters or motimate_search_motis, and no when-not-to-use conditions.

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 no annotations, the description carries the full burden of behavioral disclosure. 'Returns all categories' clearly implies a read-only, unfiltered list operation, and the qualifier 'alle' is useful. However, it does not disclose anything about ordering, output format, localization, or whether authentication or special permissions are required.

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 a single concise German sentence. It front-loads the action and result, and the explanatory clause adds meaningful context about categories without any wasted words or redundancy beyond the natural overlap with the tool name.

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

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

For a zero-parameter list tool, the description is mostly complete: it states what is returned and the domain context. However, since no output schema is provided, a slightly richer description of the return shape or ordering could help an agent understand exactly what to expect, though this is a minor gap given the tool's simplicity.

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

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

The input schema has zero parameters and 100% schema description coverage, so there are no parameter semantics to document. Per the baseline rule for zero-parameter tools, this earns a 4; the description does not need to compensate for anything.

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 ('Gibt zurück'), a resource ('alle Kategorien'), and adds useful context about how categories organize trainings and learning paths. It is clear and distinct from siblings like motimate_list_folders, though it does not explicitly call out why an agent would choose this over a 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?

The description provides no guidance on when to use this tool versus alternatives, such as motimate_list_folders or motimate_search_motis. There are no prerequisites, exclusions, or scenario-based hints beyond the obvious implication that one should call it when categories are needed.

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 no annotations provided, the description carries the burden of behavioral disclosure. The phrase 'Gibt alle Ordner zurück' makes the read-only intent clear, but it does not mention pagination, sorting, authentication, or whether the operation has any side effects. For a simple zero-parameter list tool this is adequate but not rich.

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 a single, front-loaded sentence with no filler. It communicates the core purpose efficiently and wastes no words.

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

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

The description is complete enough for a very simple zero-parameter tool, but since there is no output schema, it does not explain what each folder entry contains or how results are returned. It also omits any mention of ordering or filtering behavior, leaving minor but real gaps.

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

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

The input schema has zero properties and schema description coverage is 100%, so there are no parameters requiring explanation. The description naturally implies that the tool takes no arguments, which is consistent and sufficient.

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 clear action and resource: it returns all folders where trainings are stored. It is specific enough to distinguish itself from search/create/update siblings, though it does not explicitly contrast with motimate_list_categories.

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 guidance is given about when to use this tool versus the sibling tools. There is no mention of prerequisites, alternatives, or situations where a different tool like motimate_search_motis or motimate_list_categories would be more 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?

No annotations are provided, so the description carries the behavioral burden. It clearly indicates a read-style search/list operation and explains the domain concept. However, it does not disclose result output, default behavior when no search term is supplied, or any special handling of draft learning paths.

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 action and target resource. The second sentence adds useful domain context without unnecessary padding or repetition of schema details.

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

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

For a simple tool with two optional parameters, no nested objects, and no output schema, the description plus schema are sufficiently complete for correct invocation. The main gaps are the return shape and exact search semantics, but they are minor for a straightforward search/list 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?

The input schema already provides descriptions for both parameters, with 100% coverage, so the baseline is 3. The description itself adds no parameter-level details; 'search' and 'publish_status' are already adequately explained in 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 states a specific operation ('Sucht und listet') on a specific resource ('Lernpfade in Motimate'), and the second sentence clarifies that learning paths bundle multiple trainings. This makes it clearly distinguishable from siblings like motimate_search_motis, motimate_search_moti_content, and motimate_get_learning_path_sections.

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 when to use the tool: when the agent needs to search or enumerate learning paths rather than individual Motis, content, or sections. It does not explicitly name alternatives or exclusion conditions, so it stops 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?

With no annotations provided, the description carries the full burden. It discloses an important implementation behavior: it loads all chapters with content blocks and then filters for matches, implying a potentially expensive operation. It does not mention read-only guarantees, return format, or failure behavior, but the disclosed loading/filtering behavior is valuable context beyond the schema.

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. The first sentence states the main purpose and scope, and the second explains the operational approach. Every word earns its place.

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

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

For a single-parameter search tool with no output schema, the description is largely sufficient: it states the search scope, the content types involved, and the loading/filtering mechanism. It leaves the exact return structure unspecified, but the tool's purpose implies a list of matching content items, so the gap is minor.

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 parameter description already explains that the search term applies to titles and content. The tool description adds content-type details but does not materially enhance the meaning of the single parameter 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 names a specific action (Durchsucht) and a clear resource (Inhalte aller Schulungen), including concrete content types: Texte, Quizze, Bilder. This distinguishes it from sibling search tools like motimate_search_motis by focusing on content-level search across all trainings.

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

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

The description clearly establishes when to use the tool: when searching inside the text, quiz, and image content of trainings. It does not explicitly compare against sibling tools or state when not to use it, but the context is unambiguous enough for an agent to select it appropriately.

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

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

Annotations are absent, so the description carries the full burden of behavioral disclosure. It does make the read/search nature clear ('Sucht und listet') and enumerates the filter surface, which covers the core behavior of a search tool. However, it discloses nothing about result format, pagination, ordering, or how filters combine, keeping this at a mid score.

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

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

Two sentences with zero waste: the first is front-loaded with the core action and resource, the second efficiently summarizes all filtering dimensions. No filler and no tautological restatement of the tool name.

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 search tool with zero required parameters, a fully documented schema, and no output schema, the description adequately conveys the purpose and filter options. Gaps remain: no disambiguation from motimate_search_moti_content, no mention of result scope or limits, and no statement about whether filters combine. These are non-fatal for a simple search tool but leave room for improvement.

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 five parameters, giving a baseline of 3. The description's filter list ('Titel, Beschreibung, Kategorie, Ordner, Tags oder Status') restates the parameter semantics at a higher level of abstraction and adds no new 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 ('Sucht und listet') with a specific resource ('Schulungen (Motis) in Motimate') and enumerates the filtering dimensions, making the core function clear. However, it does not explicitly distinguish this tool from the closely named sibling motimate_search_moti_content, so differentiation must be inferred from the tool name rather than the description.

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 no guidance on when to use this tool versus alternatives. With siblings like motimate_search_moti_content and motimate_search_learning_paths present, an agent gets no explicit signal for choosing between searching training metadata, searching inside training content, or searching learning paths. The usage context is only weakly implied by 'Sucht und listet Schulungen,' with no exclusions or named 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?

No annotations are provided, so the description carries the full responsibility for behavioral disclosure. It only states that metadata is updated and lists fields; it does not explain whether the update is partial or full, what happens to omitted fields, whether permissions are required, or what response is returned. For a mutation tool, this is a significant 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?

The description is a single sentence that leads with the action and resource, then lists the relevant fields. It contains no filler, repetition, or unnecessary 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?

The description plus the fully documented schema give an agent enough to identify the inputs and the general operation. However, with no annotations and no output schema, important behavior remains unspecified: whether fields are merged or overwritten, whether sending only moti_id is valid, and what the tool returns after updating.

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 each parameter already documented in German, including array examples for tags and category_ids. The description restates the same field names without adding new meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Aktualisiert'), names the exact resource ('Metadaten einer bestehenden Schulung'), and lists the affected fields (Titel, Beschreibung, Tags, Kategorien). This clearly differentiates it from create_moti, search_motis, and content/chapter 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 phrase 'bestehenden Schulung' implies this tool is for modifying an existing training rather than creating or searching, which gives some usage context. However, there is no explicit when-to-use guidance, no mention of alternatives like create_moti, and no exclusions stated.

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