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

With no annotations, the description carries the full burden, but it does disclose one meaningful trait: the complete JSON is written into `destination` when that argument is supplied. It says nothing about permissions, what happens when `destination` is omitted, or whether the operation mutates local state.

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 no padding, and the resource is front-loaded ahead of the conditional write behavior. It is efficient, though brevity here edges toward under-specification rather than tightness.

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 the definition still omits the tool's core action and when it applies. For a two-parameter tool with zero annotation coverage, an agent cannot confidently decide to call this over fiche or detail_cours.

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 0% for two parameters. The description clarifies `destination` functionally (full JSON written there when provided) but says nothing about `cours`, the required parameter — for example whether it is a course identifier, slug, or path.

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 resource ('cartes de révision du cours local') but leaves the verb ambiguous — it is unclear whether it retrieves, generates, or formats flashcards. It does not distinguish itself from siblings like detail_cours, fiche, or lancer_generation.

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 prerequisites, and no mention of which sibling to pick for a related task. The only context given is a conditional about writing output, which is behavioral rather than usage-oriented.

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, so the description carries the full burden. It hints that a local working folder is created (a filesystem side effect) but says nothing about idempotency, what happens on duplicate titles, required permissions, or error behavior for what is clearly a mutating operation.

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; the action and input come first. Slightly terse for a creation tool but structurally clean.

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. However, for a creation tool with no annotations and no usage or behavioral detail, the description leaves the agent short of what it needs to call it confidently in edge cases.

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 0% and only one parameter exists. The phrase 'à partir d'un titre' confirms the parameter is a title, but that merely restates the field name 'titre' with no format, length, or uniqueness constraints. It only marginally compensates for the missing schema documentation.

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 (Crée) and resource (un cours local / dossier de travail) and clarifies it is derived from a title. It does not differentiate itself from siblings like detail_cours or liste_cours, so an agent gets the action but not the routing logic.

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 context, no prerequisites, and no mention of alternatives. The agent is not told when creating a new course is appropriate versus listing or viewing existing ones.

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 full behavioral burden. It usefully lists accepted file types (m4a/mp3/wav, PDF slides), but omits overwrite behavior, permissions/auth needs, mutation side effects on existing course sources, and error handling.

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 front-loaded sentence with no filler. The action, accepted file types, and destination are immediately clear.

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 no annotations, a bare input schema, and only a one-sentence description, the definition is incomplete for correct invocation. It does not cover course identifier format, path handling, file-size/type limits beyond examples, overwrite behavior, or relation to sibling tools, though the presence of an output schema means return values need not be described.

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 0%, and neither parameter has a description. The description only indirectly maps 'chemin' to a local file path and 'cours' to course sources, without defining expected formats (course ID vs name, absolute vs relative path) or constraints.

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 ('Copie') and resource/destination ('un fichier local ... dans les sources du cours'), including accepted file types. It does not differentiate from sibling tools such as telecharger_fichier, so it falls 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?

No explicit when-to-use, prerequisites, or alternatives are given. The description only implies it is for adding local files to course sources; it never mentions when to choose it over telecharger_fichier or other 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool reads local course state and returns produced artifacts, sources, and the tail of a generation log, which implies a safe read. It does not state what happens if the course is missing, permission needs, or whether it triggers any work.

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 compact sentence with the operation front-loaded and no filler. It is slightly dense but appropriately sized for a simple read 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 repeated, yet the description still enumerates them. For a one-parameter read tool it is adequate, but the absence of usage context and parameter format leaves gaps an agent must fill from 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 coverage is 0% and the single 'cours' parameter has no description in the schema. The description never clarifies whether 'cours' is a name, slug, or path, so the parameter's expected format must be inferred from siblings.

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 resource and scope: it exposes the state of a local course (artifacts, sources, generation log tail). The verb 'État' clearly signals a read/inspection operation, but the description never distinguishes it from siblings like 'liste_cours' or 'fiche', leaving the agent to 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 mention of alternatives, and no condition that selects this tool over 'liste_cours' or 'fiche'. The sentence only describes output content, not invocation context.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says the tool builds a deck from local course cards but omits prerequisites, side effects, where the generated file goes, whether the course must already exist, or any authentication 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?

The description is a single front-loaded sentence with no wasted words. However, it is extremely sparse for a tool that requires prerequisites and parameter context, making it feel under-specified rather than optimally concise.

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 needn't be explained, but with no annotations and zero schema coverage the description must carry more weight. It does not explain prerequisites, the meaning of 'cours', or when calling the tool is appropriate, leaving the agent with significant 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?

Schema description coverage is 0%, and the single parameter 'cours' has no schema-level description. The description adds only that it refers to a 'cours local' (local course), but does not clarify the expected value, format, or whether it must match an existing course 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 ('Construit') and resource ('le deck Anki (.apkg)') plus the source ('à partir des cartes du cours local'). It distinguishes itself from siblings like 'telecharger_fichier' or 'cartes' by naming the Anki format, though it doesn't explicitly contrast with alternatives.

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 or when-not-to-use guidance is provided. The description implies the tool is for exporting Anki decks but does not mention prerequisites or alternatives among the sibling tools such as 'telecharger_fichier' or 'cartes'.

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, and it does disclose two real behavioral traits: output is markdown and is truncated to a 6000-character preview unless complet=True. It does not say whether the read is safe/idempotent, what an invalid or missing course does, or what happens for large courses beyond the flag.

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; every clause carries information (format, truncation, override flag). It is terse to the point of being cryptic in places, which keeps it just below a 5.

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 low-complexity read shape (2 params) is mostly covered. What is missing is any routing information relative to the many sibling tools that also expose course content.

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 0% with two parameters, so the description must compensate. It fully explains 'complet' (complet=True pour tout) but leaves 'cours' as an unstated identifier, only inferable from 'du cours local'.

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?

Names the concrete resource and output format ('Fiche markdown du cours local') and the scope condition ('aperçu 6000 caractères'), so an agent knows it retrieves a course's markdown summary rather than a listing or generation. No verb and no explicit differentiation from siblings like detail_cours or cartes, 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: 'cours local' hints at local (already-generated) course content, and the 6000-character preview plus the complet flag suggest when to ask for the full version. It never states when to prefer this over detail_cours, cartes, or deposer_fichier, and gives no prerequisites or exclusions.

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

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

No annotations, so the description carries the full burden and largely does: it discloses async/background execution, the run.log location under <cours>/work/, a progress-tracking mechanism, and a timing estimate (~1 min per 10 min audio). It omits failure/overwrite behavior and permission requirements, but the key operational traits are present.

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 core action is front-loaded in the first line, followed by parameter, logging, and timing notes. Reasonably sized with little waste, though parameter details could be organized more tightly against the schema.

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

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

An output schema exists, so return values need no explanation. For a heavyweight no-annotation generation pipeline the description is adequate on behavior (async, log, timing) but incomplete on parameters and on prerequisites such as required inputs.

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 0%, so the description must compensate, yet it only explains `langue` (translation target, defaulting to course language, transcription authoritative). The other three parameters — date, cours, sujet — receive no semantics at all, leaving most of the schema undocumented.

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 ('Lance') and the exact pipeline resource ('chaîne transcription → plan → fiche/questions/cartes en arrière-plan'). An agent can immediately distinguish this generation trigger from siblings like detail_cours (progress) or fiche/cartes (artifact retrieval).

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 (background run, follow progress via detail_cours) but never states when to prefer this over alternatives or any preconditions (e.g., must the course/fichier exist first?). Progress-tracking pointer is useful but not explicit when-to-use/when-not 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the data source (local working directory) and the fields returned, which is useful, but says nothing about read-only safety, pagination, ordering, or whether the listing can be empty.

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 that states resource, scope, and fields with no filler. It is appropriately sized for a trivial zero-parameter list 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?

With no parameters and a dedicated output schema, the description needn't explain return values; it just identifies what is listed and from where. The remaining gap is the absence of any read-only or ordering context.

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 schema has nothing to document and the baseline is 4. The parenthetical list of returned fields adds mild value without overstepping into the output schema's territory.

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 (Liste) and resource (les cours), plus the scope (dossier de travail local) and the returned fields (id, titre, état). This clearly separates it from detail_cours, which fetches a single course, though 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?

There is no when-to-use guidance, no prerequisites, and no routing to alternatives such as detail_cours for a single course. Usage is only implied by the verb 'Liste'.

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 exist, so the description carries the full behavioral burden. It says it copies to `destination` but never states whether an existing file is overwritten, whether the destination directory must exist, what permissions are needed, or what happens on failure – all material for a filesystem write.

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 that front-loads the action and the artifact set. Nothing wasted, though the naming/semantic ambiguity slightly reduces its utility.

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, but for a three-parameter copy operation with zero annotation coverage and zero schema descriptions, the description is too thin – notably it omits what `cours` does and any destination/overwrite semantics.

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 0%, so the description must compensate. It explains what values `nom` can take via the artifact list and names `destination`, but leaves `cours` completely undefined and never clarifies whether `destination` is a directory, full path, or filename.

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 ('Copie') and resource ('artefact local') and even enumerates the concrete artifacts involved (fiche.md, questions.json, cards.json, transcript.md, plan.json, export.apkg), so an agent knows exactly what the tool moves. It does not, however, differentiate itself from siblings like deposer_fichier or exporter_anki, and the name ('telecharger') is looser than the actual copy semantics described.

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 about when to use this instead of deposer_fichier, exporter_anki, or the other artifact-producing tools. The agent must infer the use case purely from the verb and the file list.

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