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

With no annotations provided, the description must carry the burden of behavioral disclosure, but it only says tasks are 'aggregated'. It does not explain whether excluded tasks are hidden by default, how aggregation is computed, or whether this is a read-only 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?

The phrase is concise and front-loaded, with no wasted words. However, it is more of a fragment than a complete specification, and its brevity contributes to ambiguity rather than clarity.

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?

Despite having an output schema and only one optional parameter, the description omits parameter behavior and any usage context. An agent can infer the basic purpose but not enough information to confidently invoke the tool correctly in all situations.

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 description does not mention include_excluded at all. The schema's title and default value offer some self-explanation, but the description fails to add meaning beyond the schema.

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

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

The description 'Toutes les taches agregees du vault' communicates that the tool returns all aggregated tasks in the vault, but it is a noun phrase without an explicit verb such as 'list' or 'get'. It does not clearly distinguish this tool from the sibling 'tasks_for' or other task-related 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?

There is no guidance about when to use this tool versus alternatives like 'tasks_for' or search tools. It also does not mention the include_excluded parameter or any context that would help an agent decide to call this tool.

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 alone carries the burden. It mentions appending text but does not clarify side effects (e.g., whether the note must already exist, if it modifies in place, or if it is non-destructive).

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 sentence that directly conveys the tool's purpose without unnecessary verbosity.

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 lacks information about return values, error handling, or prerequisites. It is minimal and leaves out context that an agent might need to use the tool effectively.

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 has no descriptions for 'path' or 'text', and the description does not elaborate on their meaning. The parameter names are self-explanatory, but the description provides no additional context, so coverage is minimal.

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 action: appending text to the end of a note. It is specific to the tool's name and distinguishes it from prepend or write operations.

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 does not explicitly state when to use this tool versus alternatives like prepend_to_note or write_note. The intent is implied by the verb 'append' but not made explicit.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It indicates an action ('applies') but does not explain side effects, irreversibility, permissions, or whether applying a workflow permanently mutates 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?

The description is a single efficient sentence with the main action front-loaded and clarifying examples appended. It is concise with no filler, though it is sparse enough to leave important context uncovered.

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 tool with no annotations and a free-form nested input object, the description is too minimal. It does not specify the structure of prepared_run beyond loose examples, nor does it clarify execution semantics or side effects. An agent would struggle to call this tool correctly with confidence.

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 0% description coverage and prepared_run is an additionalProperties object, so the description's examples ('workflowId, ops, changes...') provide useful hints about expected keys. However, it does not define these fields' types, meanings, or whether they 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?

The description states a clear action ('applies') and a resource ('a prepared workflow run'), with examples of relevant fields in parentheses. It does not explicitly distinguish this from sibling workflow tools such as write_workflow or undo_workflow_run, but the meaning is not vague or tautological.

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 apply_workflow versus alternatives, nor are prerequisites or exclusions mentioned. The phrase 'prepared workflow' implies a prior preparation step, but this is left implicit.

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 explaining behavior. 'Archive une note' implies a state change but does not disclose whether archiving is reversible, whether it removes the note from active views, or what side effects it may have.

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 short, but this is under-specification rather than effective conciseness. It does not earn its place beyond restating the information already present in 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 mutating tool with no annotations and no usage guidance, the description is incomplete. Although an output schema exists, the description still omits key context about the meaning of archiving, how it differs from deleting, and when it should be chosen over sibling 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?

The input schema has 0% description coverage and the only parameter, 'path', is not explained in the description. The agent must rely on the parameter name alone; the description adds no meaning beyond the schema.

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

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

The description states a specific verb and resource: 'Archive une note' clearly identifies the operation and target. However, it does not differentiate this action from closely related siblings like trash_note or delete_note.

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 archive_note versus alternatives such as unarchive_note, trash_note, restore_note, or delete_note. The description only states the action, leaving the agent to infer appropriate usage 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?

The description implies a read-only existence check with no side effects, which is transparent enough for such a simple tool. However, it does not explicitly state that it does not modify anything or describe any edge cases, and no annotations are available to carry this burden.

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 one short, front-loaded sentence with no filler. It is appropriately sized for a zero-parameter existence check, though it could be slightly more explicit about the return value.

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

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

Given the tool's simplicity, zero parameters, and the presence of an output schema, the description provides sufficient context for an agent to understand what the tool does. It lacks only a small amount of operational detail, but nothing critical is missing.

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

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

The tool has zero parameters, so the schema covers everything. The description adds no parameter information, which is acceptable because there are no parameters to document.

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 'Dit si le dossier assets existe' clearly specifies the action (checking existence) and the resource (the assets folder). It is distinct enough from listing tools like list_assets, though it does not explicitly mention that it returns a boolean result.

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. It does not mention suitable scenarios, exclusions, or sibling tools such as browse_directories or list_assets, leaving usage entirely implicit.

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 disclosing side effects and constraints. The verb 'explore' suggests a non-mutating browse operation, but the description does not explicitly say it is read-only, whether subdirectories are recursed, or whether authentication or special access is required. This is minimal behavioral disclosure.

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 French sentence with no redundant clauses. Every word contributes to identifying the action and target. It is appropriately sized for such a simple tool, even though it sacrifices some detail for brevity.

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 reduces the need to describe return values, and the tool itself is simple with only one optional parameter. However, the missing path semantics and the lack of guidance against similar sibling tools leave an agent to infer important invocation details. The 'vault picker' hint provides orientation, so the description is minimally complete but not fully self-sufficient.

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 has one parameter, 'path', with no description and 0% schema coverage. The tool description at least implies that the path refers to a server-side directory, but it does not clarify the expected format, whether an empty string means the root or current directory, or how traversal should be expressed. The compensation is minimal.

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 ('explore') and a clear resource ('server-side folders'), with a parenthetical purpose hint ('vault picker'). It is not a tautology and is understandable, but it does not explicitly differentiate itself from the sibling tool 'list_folders', which appears to serve a similar listing role.

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 'vault picker' implies a usage context: browsing server-side folders while choosing a vault location. However, the description does not state when to prefer this tool over alternatives, nor does it provide any exclusions or prerequisites. The guidance is implied rather than explicit.

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 behavioral burden. It discloses the create-then-write sequence and the conditional body behavior ('si fourni'), but it does not cover edge behavior such as folder handling or what happens on duplicate titles. Still, the core creation behavior is clear.

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 efficient sentence with a clear sequence and no filler. It could be slightly more structured to cover folder behavior, but as written it is compact and front-loaded.

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

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

Given the simple 3-parameter shape and the existence of an output schema, the description covers the basic invocation path. It is incomplete for an agent choosing among many note-writing siblings and for understanding the folder default, but it is adequate for a straightforward capture call.

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 clarifies the body parameter is only written when provided, but it gives no explanation of the folder parameter or its 'quick' default, leaving two of three parameters semantically under-documented.

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: 'cree une note puis y ecrit le body' (creates a note then writes the body), so an agent knows the core purpose. It is specific about the resource (note) and the write behavior, but it does not explicitly differentiate itself from sibling create_note/write_note.

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 over create_note, write_note, or append_to_note. 'Capture rapide' only suggests speed; it does not state conditions or alternatives.

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

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

With no annotations, the description carries the full burden of explaining side effects and requirements, but it only says a drawing is created. It does not mention overwrite behavior, required permissions, file system effects, or any other behavioral consequences.

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 short and free of filler, which is positive. However, it is under-specified rather than efficiently informative, omitting context that would make the single sentence genuinely useful.

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?

A create operation with three optional parameters, no annotations, and no parameter documentation needs more context to be complete. The output schema may describe return values, but the description still leaves the agent guessing about folder and subpath semantics and about when this tool is appropriate.

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 description does not mention the title, folder, or subpath parameters at all. The agent gets no help understanding what these parameters mean or how they affect the created drawing.

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 action and resource: 'Cree un dessin Excalidraw' (create an Excalidraw drawing). This identifies the tool's purpose and distinguishes it from siblings like create_note or create_folder. However, it is very close to a restatement of the tool name and provides no further detail.

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

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

The description gives no guidance about when to choose this tool over alternatives such as create_note, upload_asset, or other creation tools. There is no context, prerequisite, or exclusion information.

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 completely absent, so the description carries the full burden of behavioral disclosure. It only indicates that a folder is created and constrains the folder parameter values; it does not state whether the operation is idempotent, whether existing folders are overwritten, whether nested paths are created, or what happens on conflict.

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 second sentence about folder values is useful, but the first sentence merely restates the tool's name ('create folder') in French and adds no new information. The description is short but not efficiently informative, bordering on under-specification rather than 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 no annotations and no parameter descriptions in the schema, the description should explain the role of subpath and the intended folder creation semantics, but it does not. The tool may be invoked incorrectly because key input behavior is missing, even though an output schema exists to describe return values.

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 has 0% parameter description coverage, so the description must compensate. It adds critical meaning for 'folder' by listing inbox|quick|archive|trash, which the schema does not provide as an enum. However, 'subpath' remains completely unexplained, so compensation is only partial.

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

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

The description states the action ('Cree un dossier' = create a folder) and defines the allowed values for the required 'folder' parameter, which distinguishes it from sibling tools like rename_folder, delete_folder, and duplicate_folder. However, it does not clarify what differentiates a folder from a note or the role of subpath, leaving some ambiguity about the exact resource being created.

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 alternatives such as create_note or write_note. The description does not mention prerequisites, whether the folder must already exist, or how subpath influences the target location, so the agent is left without clear decision 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'create a note' and lists folder values, but does not disclose what happens with title/subpath, default behavior, response content, or whether creation overwrites anything. This is minimal for 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?

The description is very short and front-loaded, with no wasted words. The folder constraint is presented first. However, the brevity comes at the cost of missing important guidance.

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 has an output schema and only three optional parameters, so the baseline complexity is moderate. But the description fails to explain the role of title/subpath, the distinction from sibling write tools, or any behavioral details. It is not complete enough for an agent to invoke correctly in all intended 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 description coverage is 0%, so the description must compensate. It adds meaning only for the folder parameter by listing allowed values. The title and subpath parameters are completely undocumented in both schema and description.

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

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

The description states a specific action on a resource: 'Cree une note' (Create a note). However, it does not distinguish this tool from closely related siblings such as write_note or capture_note, so the clarity is good but not fully differentiating.

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 like write_note, capture_note, or append_to_note. It only lists allowed folder values, which is a constraint, not usage 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the key behavior that the asset is moved to trash and can be restored, which is essential for a delete operation. It does not mention permissions, failure behavior, or whether the path must be an existing asset, so the disclosure is only partial.

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 states the action first and adds the crucial qualifier about trash/restorability in a parenthetical. There is no filler, and the structure is immediately scannable.

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 tool with an output schema, the description conveys the main action and its key consequence. It is nonetheless incomplete in that it does not define path semantics or explicitly point to related restore/purge operations, though sibling tool names partially fill that gap.

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

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

Schema description coverage is 0%, and the description does not explain the 'path' parameter beyond the parameter name and title. It does not clarify whether path refers to a file path, folder path, ID, or URL, nor does it give format examples. The description therefore does not compensate for the schema's lack of parameter 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?

The description uses a specific verb 'Supprime' and identifies the resource 'asset', while the parenthetical 'corbeille assets, restaurable' clarifies that this is a soft-delete operation. This clearly distinguishes delete_asset from permanent deletion siblings such as purge_deleted_asset or empty_deleted_assets.

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 that deletion is non-destructive and restorable, which hints at when to use this tool rather than a permanent delete tool. However, it does not explicitly name alternatives or state conditions for when not to use it, leaving the routing partly 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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only says a folder is deleted. It does not disclose whether deletion is permanent or reversible, whether non-empty folders are deleted recursively, or what effects occur beyond the folder itself.

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 definition is short and without filler, but this is under-specification rather than disciplined conciseness. A single sentence that merely restates the tool name does not earn high structure credit.

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 destructive operation with no annotations, 0% schema coverage, and two parameters, the description is far from complete. An agent cannot determine what 'folder' and 'subpath' mean, whether deletion is permanent, or what safety checks are needed. The presence of an output schema does not compensate for these input and safety 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%, so the description must explain the parameters, but it does not. The word 'dossier' loosely maps to the required 'folder' parameter, while the optional 'subpath' parameter is completely unexplained and receives no semantic context.

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 'Supprime un dossier.' is a direct restatement of the tool name 'delete_folder' and adds no new information. It does identify the resource and action, but only by repeating what the name already communicates.

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 delete_note, delete_asset, or trash_note. It does not mention prerequisites, exclusions, or any conditions that would make delete_folder 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 carries the behavioral disclosure burden. It does disclose the critical trait that deletion is irreversible, but it says nothing about permissions, side effects on links or attachments, or behavior when the path does not exist.

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 one compact sentence with no filler. The action verb is front-loaded and the critical non-restorable warning is included parenthetically with minimal overhead.

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 destructive tool with an output schema, this is nearly complete: it gives the operation and its irreversibility. The main gap is that path semantics are undocumented, which an agent needs to invoke the tool correctly.

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

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

The schema has one required string parameter 'path' with 0% description coverage, and the tool description does not explain what kind of path is expected (absolute vs relative, note name, extension, etc.). The description adds no meaning beyond the parameter name.

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

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

The description states a specific action ('Supprime définitivement une note') with a clear resource and an explicit irreversibility qualifier ('non restaurable'). This distinguishes delete_note from sibling trash_note/restore_note, which imply a recovery path.

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 permanent/non-restorable qualifier gives clear context for when this tool should be selected: when the note must be permanently removed. It does not explicitly name alternatives like trash_note or state when not to use it, so it falls just short of a full routing explanation.

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 behavioral burden. It only states that a template is deleted, without disclosing irreversibility, permissions, side effects, or what happens to the template data.

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 very short, but this is under-specification rather than effective conciseness. It omits critical context for a destructive operation and does not earn its place as a complete tool explanation.

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?

Even though an output schema exists and the tool has only one parameter, the description lacks essential behavioral and parameter context. For a deletion tool with no annotations, this is not enough for an agent to invoke it safely.

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 description does not explain what source_path means, what path format is expected, or how it identifies the template. The single parameter is left to be inferred from its name and title.

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 ('Supprime' / delete) and a clear resource ('template'), so an agent can tell this is the deletion tool for templates. It is distinguishable from siblings like read_template, write_template, and list_templates by the action it names.

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, no mention of preconditions, and no indication of whether deletion is permanent or recoverable. The one-sentence description leaves the selection context entirely implicit.

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 only says the workflow is deleted and does not mention irreversibility, cascading effects on runs, permissions, or whether deletion can be undone. This is thin for a destructive 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?

The description is a single concise sentence with no filler and the core action is front-loaded. However, it is so terse that it crosses into under-specification, preventing a higher score.

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?

Despite low complexity and a single parameter, the description omits usage guidance, parameter semantics, and behavioral consequences. The output schema exists, so return values need not be described, but the deletion semantics and distinction from delete_workflow_runs are not addressed.

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 description does not explain source_path at all. The parameter name is somewhat self-explanatory, but the description adds no meaning about what source_path should reference or how it should be formatted.

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

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

The description states a specific action ('Supprime un workflow' = 'Deletes a workflow') with a clear verb and resource. It does not explicitly differentiate from the sibling tool delete_workflow_runs, but 'workflow' reads as the workflow definition versus runs, so it is mostly clear.

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 tool instead of alternatives such as delete_workflow_runs, undo_workflow_run, or trash_note. The description provides no contextual or exclusionary information.

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

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

The description indicates a destructive action, but without annotations it does not disclose whether the deletion is permanent, whether it affects the workflow definition, or whether confirmation is required. Behavior beyond the basic 'delete' verb is not explained.

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 sentence with no redundant content. It directly conveys the essential purpose without unnecessary 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 tool is simple, but the description lacks important contextual details such as effects, irreversibility, and how it differs from closely related tools like undo_workflow_run or delete_workflow. With no annotations or output details, the description alone is not fully self-sufficient.

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 single parameter workflow_id is mentioned in the description via 'd'un workflow', but the schema provides no per-parameter description. The meaning is mostly inferable from the parameter name and tool description, but no additional detail such as format or constraints is provided.

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 action: deleting the run history of a workflow. It also implicitly distinguishes itself from delete_workflow and undo_workflow_run by targeting the run history rather than the workflow itself.

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 provided about when to use this tool versus related tools such as delete_workflow, undo_workflow_run, or list_workflow_runs. The description offers no context, preconditions, or use-case clarification.

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 implies a write or setup action inside the vault, but it does not say whether it modifies existing content, is reversible, requires permissions, or is idempotent.

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 short sentence with no filler, and the action verb is front-loaded. It is well-sized for a no-parameter tool, though the unexplained term 'demo visit' keeps it from being fully self-sufficient.

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 calling complexity is low because there are no parameters and an output schema exists, so return-value documentation is not the description's responsibility. However, the description leaves 'demo visit' undefined and does not disclose vault side effects, making it only minimally complete for selecting and invoking the 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 has zero parameters and schema description coverage is effectively complete for an empty schema, so there is nothing extra the description must explain. The zero-parameter baseline of 4 applies.

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

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

The description states a concrete action ('Génère') and identifies the resource ('la visite demo') and location ('dans le vault'), so an agent can tell this is a demo-generation tool. It does not explicitly compare itself with siblings like demo_remove, which prevents a top score.

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 demo_generate, what conditions call for it, or how it relates to demo_remove or other demo-related tools. Any usage inference comes only from the tool name and the generic phrase.

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 behavioral burden, but it only states that something is removed. It does not disclose whether the removal is permanent, whether it affects user data, or what side effects occur, which is especially important for a destructive zero-parameter 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?

The description is a single short sentence with no filler; the action is stated up front. For such a simple zero-argument tool, this level of conciseness is appropriate despite the semantic ambiguity.

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

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

Given the low complexity, one sentence might seem sufficient, but the absence of any context about when to run this cleanup, whether it is safe, and what happens to the vault means an agent cannot confidently select and invoke it. The output schema exists, so return values are not the gap; usage and side-effect context are.

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 100% coverage, so no parameter documentation is needed. The description's reference to removing the demo visit implies the operation requires no user input, matching the empty schema; baseline for zero parameters 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 says 'Retire la visite demo du vault' (removes the demo visit from the vault), giving a verb and a resource, so it is not a tautology. However, 'visite demo' is ambiguous and the definition does not clarify what a demo visit is or how it differs from other removal tools such as delete_note or empty_trash.

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 call this tool versus alternatives. A sibling tool named demo_generate strongly suggests a counterpart, but the description never says 'use after demo_generate' or 'use to clean up demo data', so the agent is left to infer usage.

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 present, the description carries the full burden of explaining side effects. It implies a read-like operation (downloading an asset) but does not clarify whether it modifies the asset on the server, overwrites local files, or has other side effects. The behavior is minimally transparent but lacks depth.

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 sentence that communicates the core functionality without any unnecessary words. It is well-structured and 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?

The description is minimal and does not cover essential context such as expected output, error conditions, or prerequisites. Given the ambiguity in parameter meanings and the lack of guidance on distinguishing from similar tools, the description is not complete enough for fully correct usage.

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 provides no descriptions for 'path' or 'local_path', and the tool description does not explain either parameter. Although the names suggest 'path' might be the asset's source and 'local_path' the destination, this is not explicitly stated, leaving room for misinterpretation.

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 action (download) and the object (asset) with a destination (local path). It distinguishes from sibling tools like upload_asset, move_asset, and delete_asset, making the tool's specific purpose 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?

The description does not provide explicit guidance on when to use this tool versus alternatives. It only states what the tool does, leaving the agent to infer appropriate usage from the context. No conditions or exclusions are mentioned.

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 explaining behavior. It only says 'Duplicates an asset' and does not disclose whether the duplicate is created in the same directory, how the new filename is generated, whether overwriting can occur, or any other side effects.

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 with no filler or unnecessary detail. It is front-loaded and easy to parse, which is appropriate for a simple, single-purpose 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?

The presence of an output schema covers return values, but behavioral and contextual expectations are largely missing. With no annotations and no guidance on duplicate naming, destination, or failure conditions, the description is not complete enough for an agent to confidently invoke the tool 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?

The schema has 0% description coverage, and the description does not mention the 'path' parameter at all. Although 'path' is a single, fairly obvious parameter, the description adds no semantic meaning beyond what the schema's type and title already provide.

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 ('Duplique') and resource ('asset'), making it clear that the tool duplicates an asset. It does not explicitly distinguish itself from sibling tools like duplicate_note or duplicate_folder, but the asset resource is enough to avoid major ambiguity.

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 tool versus alternatives such as duplicate_note or duplicate_folder. The description does not mention prerequisites, whether the asset must exist, or what distinguishes this duplication operation from other asset-related tools.

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 of behavioral disclosure, but it only restates the operation. It does not clarify whether contents are copied recursively, where the duplicate is placed, what happens on naming conflicts, or whether the operation is reversible.

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 extremely short and front-loaded, but it is under-specified rather than appropriately concise. It lacks the substance needed to serve as a complete tool definition.

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 mutation tool with two parameters and no annotations, the description is missing critical details about subpath semantics and the resulting duplicate location. The presence of an output schema does not compensate for the invocation ambiguity.

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 explain both the folder and subpath parameters. It does not mention subpath at all and adds no meaning beyond the parameter names and default 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 specific verb ('dupliquer') and resource ('un dossier'), clearly distinguishing this tool from siblings like duplicate_note and duplicate_asset. It tells the agent exactly what operation the tool performs.

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 duplicate_folder versus create_folder, rename_folder, or delete_folder, nor about prerequisites. The usage context is only implied by the tool name and the minimal one-line description.

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 responsibility for disclosing behavioral traits. It merely states 'duplicate' without explaining side effects such as whether the copy is placed in the same folder, whether metadata is preserved, or if attachments are included. No behavioral details are given.

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, clear, and concise sentence. It is well-structured and easy to read, with no unnecessary words. However, the extreme brevity, while structurally efficient, leaves out essential information, so it receives a slightly lower score than a perfect 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?

Given the simplicity of the operation, the description is far from complete. It lacks context about the tool's place within the note management workflow, potential side effects, permissions required, or interaction with existing note properties. The user is left with only the bare action statement.

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 has one required parameter 'path' but provides no description. The tool description does not clarify what 'path' refers to (e.g., full path, relative path, or ID) or any constraints. Since schema coverage is 0%, the description must compensate, but it adds no semantic value for the parameter.

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 action 'duplicate' and the object 'note', which is a direct and identifiable purpose. It is sufficiently distinct from sibling tools that target folders or assets, though it does not elaborate on the exact nature of the duplication.

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. No mention of scenarios, limitations, or why one would choose duplicate_note over other note-related operations like copy, move, or create. The description offers no contextual usage instructions.

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 the full burden. 'Vide la corbeille' conveys a destructive emptying operation but does not state that all trashed assets are permanently removed or that the action is irreversible; no auth or side-effect context is provided. This is a minimal indication of behavior rather than a transparent disclosure.

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 short sentence with no filler. It is compact and front-loads the action and object, which is appropriate for a zero-parameter 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?

The operation is simple and has no parameters, and an output schema exists, so the description need not explain return values. However, for a destructive no-annotation tool it still omits the irreversible/all-items nature and any caution about side effects, so it is only minimally complete.

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

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

The tool has zero parameters and the schema documents 100% of them, so there is no semantic burden on the description. Baseline of 4 applies; no parameter explanations are needed.

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 French description 'Vide la corbeille des assets' names the exact action (empty) and the target (assets trash), and its plural/trash-level scope distinguishes it from sibling purge_deleted_asset and empty_trash. This is a clear, specific purpose statement.

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

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

The description gives no guidance on when to call this tool versus restore_deleted_asset, purge_deleted_asset, or empty_trash. There are no conditions, prerequisites, or alternatives, so the agent must infer usage entirely from the tool 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?

With no annotations provided, the description carries the full burden of disclosing behavior, but it only says 'empty the trash.' It does not state irreversibility, that objects may be permanently removed, whether confirmation is required, or any authorization 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 short, direct sentence with no filler. It is efficiently front-loaded and easy to parse, though its brevity causes incompleteness in other dimensions.

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 destructive operation with no annotations, this description is too thin. It fails to clarify scope, permanence, or behavior when the trash is already empty, and the ambiguity against sibling empty_deleted_assets is material. The output schema exists, so return format is not the gap, but the operational effects are.

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 has zero parameters and schema description coverage is 100%, so there are no parameter semantics for the description to add. A baseline of 4 is appropriate because there is nothing to explain.

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 French phrase 'Vide la corbeille' clearly states a specific action (empty) and object (trash), so an agent can infer the operation. However, it does not differentiate from sibling tools like empty_deleted_assets, purge_deleted_asset, or restore_note, and it does not specify whether it applies to notes, assets, or the whole vault.

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 trash_note, restore_note, purge_deleted_asset, or empty_deleted_assets. The description provides no preconditions, exclusions, or context for choosing it.

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 conveys that the tool returns a server-announced capability list, which implies a safe read-only introspection operation, but it does not describe return organization, error behavior, or scope. The presence of an output schema mitigates some of this 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?

A single front-loaded sentence with zero wasted words and useful parenthetical examples. Slightly cryptic due to the French wording and trailing ellipsis, but appropriately efficient for the tool's trivial scope.

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?

Adequate for a zero-parameter introspection tool, especially with an output schema documenting the return shape. However, the description leaves unclear how this relates to get_search_capabilities and when an agent should prefer one over the other, which is a meaningful gap given the large sibling set.

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 has zero parameters, so the baseline of 4 applies. Schema description coverage is vacuously 100% and there is nothing for the description to clarify.

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

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

The description states the resource clearly ('capacités annoncées par le serveur' — capabilities announced by the server) with illustrative examples (watch, templates, workflows) that help an agent anticipate what to expect. The verb+resource mapping is specific, and the examples implicitly differentiate it from the narrower sibling get_search_capabilities, though the sibling is not named.

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 on when to call this tool versus alternatives such as get_search_capabilities, nor on typical use cases like checking feature availability before invoking template or workflow tools. The discovery purpose is implied by the name and examples but never made explicit.

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 only offers a noun phrase and never explicitly states that this is a read-only operation, what it returns, or whether any side effects exist.

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 extremely short and contains no filler, which fits a parameterless getter. However, it is a terse noun phrase rather than a complete sentence, so it is efficient but not especially instructive.

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 an output schema present, the description does not need to document arguments or return values. Still, the meaning of 'platform' is somewhat ambiguous, and the absence of annotations or usage context leaves the agent with limited guidance.

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 has zero parameters, so there is nothing for the description to add beyond the schema. The baseline of 4 is appropriate because parameter semantics are essentially irrelevant here.

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 that the tool concerns the server's host platform, and combined with the verb 'get' in the name, the purpose is reasonably clear. It does not explicitly contrast with siblings like get_version or get_capabilities, but the resource is identifiable.

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 tool rather than alternatives such as get_version, get_capabilities, or health_check. The agent must infer the appropriate context from the tool name alone.

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 behavioral burden. It only adds that the search engine is either ripgrep or fzf, but it does not explicitly say whether the tool returns the active engine, performs no side effects, or what the response contains. The output schema exists but is not referenced to clarify 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?

The description is extremely short and contains no filler or repetition. It is front-loaded and appropriately sized for a zero-parameter introspection tool, though it reads more like a fragment than a complete explanatory sentence.

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, has zero parameters, and has an output schema, so the definition does not need to enumerate return values. However, it lacks explicit usage context and behavioral clarity, and the overlapping get_capabilities sibling leaves room for misinterpretation.

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 has zero parameters and schema description coverage is 100%, so the baseline of 4 applies. The description adds no parameter details, but none are needed.

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 the resource ('moteur de recherche') and the candidate values ('ripgrep / fzf'), which clearly points at the tool's subject and differentiates it from generic siblings like get_capabilities. However, it is a noun phrase rather than an explicit 'returns/reports' statement, 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?

There is no guidance on when to call this tool versus alternatives such as get_capabilities or search_text. The description never states a condition like 'use this to check the active search backend'; an agent must infer usage entirely from the tool name and sibling list.

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 behavioral disclosure. The verb 'Lit' clearly signals a read-only operation and the parenthetical lists what settings are covered, but there is no mention of authentication, side effects, errors, or limitations. This is minimal but acceptable for a simple getter.

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 sentence that front-loads the action and resource, with a short parenthetical giving concrete examples. There is no redundant or filler content.

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

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

For a zero-parameter, read-only tool with an output schema, this description is nearly complete: it states the resource and gives representative categories of settings. It could be slightly stronger by clarifying the relationship to set_vault_settings, but nothing essential for 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?

The input schema has zero properties, so there are no parameter semantics to explain. The description's examples describe the content returned rather than parameters, and the baseline of 4 applies for a parameterless tool.

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

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

The description gives a specific verb ('Lit') and resource ('reglages du vault') with clarifying examples such as system folders, daily notes, and tasks. It is clearly a read operation versus set_vault_settings, though it does not explicitly name or differentiate itself from sibling tools like vault_info.

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 explicit guidance about when to use this tool or when to prefer an alternative. The usage is only implied by the verb 'Lit', with no mention of set_vault_settings or other related tools, so the agent receives no routing information.

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 only lists the returned data and does not state whether the call is read-only, requires authentication, or has side effects. The 'get' prefix hints at safety, but the description itself offers no explicit 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?

The description is extremely concise at four words, efficiently conveying the core output without wasted text. It is a fragment rather than a full sentence, but for a zero-parameter getter this is acceptable and appropriately sized.

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 covers the essential return content, and an output schema exists so return-value details are available elsewhere. However, it omits authentication/session expectations and does not differentiate itself from other info endpoints, so an agent must infer whether this tool is callable without a session or how it compares to health_check.

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 has zero parameters, so there is no parameter information for the description to complement. The schema already fully covers everything (vacuously 100%), and the baseline for 0 parameters is 4.

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

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

The description clearly states the tool returns the server version and Go runtime, which is a specific output resource and distinguishes it from sibling tools like get_platform and get_capabilities. However, it is a noun phrase rather than an explicit verb-led explanation, so it relies on the tool name 'get' to imply the retrieval action.

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. It does not mention equivalent info tools like get_platform, get_capabilities, or health_check, nor does it give any context for which tool should be selected in a given situation.

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 itself discloses the HTTP method (GET), the exact endpoint, and that no authentication is required. This gives an agent sufficient behavioral understanding for a simple, side-effect-free health probe, even if it does not discuss response shape or rate 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?

The description is two short sentences with no filler. The core purpose and endpoint are front-loaded, and the auth requirement is stated as a useful addendum. 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 no-parameter, simple health-check endpoint, the description provides the essential invocation details: HTTP method, path, and auth requirement. The presence of an output schema means return-value documentation is not required here, so the description is complete for an agent to select and call the tool correctly.

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

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

The tool has zero parameters, so the semantic burden on the description is minimal. The baseline of 4 applies, and no parameter documentation is needed beyond confirming that the call takes no arguments, which the empty schema already makes clear.

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

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

Description states a specific action ('Ping le serveur') with the exact endpoint and HTTP method (GET /api/healthz), making its purpose immediately clear. It is readily distinguishable from sibling tools like get_version or get_capabilities, which target different resources.

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 use as a server liveness/health check via 'ping' and the /healthz endpoint, but it does not explicitly state when to choose this over alternatives or provide any exclusion criteria. There are no sibling health-check tools, so the intended context is clear enough, but explicit guidance is minimal.

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 only says 'list attachments' and does not state whether deleted assets are included, whether this is read-only, or any other behavioral 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?

The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a zero-parameter tool, though it could include slightly more contextual detail without becoming verbose.

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 zero-argument tool, the description is minimally adequate, and the output schema can cover return value details. However, it lacks clarity about whether this lists only active assets versus deleted assets, and it does not position the tool among its many asset-related 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?

There are zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the empty schema fully covers the argument structure.

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 'Liste les pieces jointes' clearly states the verb 'list' and the resource 'attachments/assets', so the basic purpose is understandable. However, it does not differentiate this tool from sibling tools like list_deleted_assets or assets_exists.

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 tool versus alternatives, no exclusions, and no mention of related tools such as list_deleted_assets. The agent must infer usage solely from the tool name and 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?

With no annotations, the description carries the full burden, but it only notes that the assets are restorable. It does not disclose pagination, ordering, whether this is a read-only listing, or what distinguishes deleted from purged assets.

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 text is extremely short and has no filler, but it is a sentence fragment that lacks a verb and clear structure. It is concise at the cost of being under-specified.

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, has no parameters, and an output schema exists, so the description does not need to explain return values. However, it does not connect to sibling tools like list_assets or restore_deleted_asset, and it leaves behavioral expectations (e.g., scope of 'deleted') implicit.

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 has zero parameters and schema description coverage is 100%, so there is no parameter semantics gap. Per the baseline rule for 0-parameter tools, the description need not add parameter details.

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 identifies the resource as deleted/restorable assets, which aligns with the tool name, but it is a noun phrase ('Deleted assets (restorable)') rather than a statement of what the tool does. It does not explicitly say it lists or returns these assets, and it is in French while the tool name is English.

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 rather than list_assets or restore_deleted_asset. The description does not mention alternatives, exclusions, or context such as trash/restoration workflows.

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 supplied, so the description carries the full burden of behavioral disclosure. It merely restates the action and does not clarify whether the listing is flat or recursive, whether hidden folders are included, or whether the operation is read-only.

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 with no filler, and the action is front-loaded. It is efficient and readable, though the brevity leaves little room for additional context.

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

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

For a parameterless read tool with an output schema, the description provides the core operation an agent needs. However, it is only minimally complete because it does not disambiguate from browse_directories or describe the shape of the folder listing beyond what the output schema might already cover.

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 has zero parameters and an empty input schema, so there is nothing for the description to explain. The baseline score of 4 applies because parameter semantics are trivially satisfied.

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 ('Liste') and resource ('les dossiers du vault'), so an agent knows it lists folders in the vault. It is clear, but it does not explicitly differentiate from the similarly named sibling browse_directories, which could also relate to folder/directory listings.

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 choose list_folders over alternatives such as browse_directories or list_notes. The intended use case is only implied by the verb and resource; there are no explicit conditions, alternatives, 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 are present, so the description carries the full burden of behavioral disclosure, but it only restates the listing action. It does not mention pagination, ordering, size limits, read-only safety, or scope (vault-wide vs workspace), all relevant for a tool claiming to list 'toutes' notes.

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. The parenthetical adds meaningful scope without redundancy, making it as concise as the tool's simplicity allows.

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

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

Given the empty input schema and presence of an output schema, the basic call contract is covered. However, the description does not clarify what 'toutes les notes' means operationally, such as whether the result is paginated or scoped to a vault, and no usage guidance compensates for the missing behavioral 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 has zero parameters and schema coverage is 100%, so there is no parameter information for the description to add. The baseline for this dimension is appropriately high, and the description correctly implies that no arguments 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?

The description states a clear action ('Liste') and resource ('toutes les notes'), with the parenthetical '(metadonnees)' clarifying that it returns metadata rather than note content. This distinguishes it from content-reading siblings like read_note, though it does not explicitly name 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?

The description provides no explicit when-to-use guidance or mention of alternatives. The word 'metadonnees' implies the tool is for metadata rather than content, but with dozens of sibling tools an agent is left to infer when list_notes should be selected over read_note, search_text, or list_folders.

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 what is listed (custom templates) and where they live (.zennotes/templates), which is adequate for a simple read operation, but doesn't mention return shape, auth needs, or behavior when no templates exist. It does not contradict structured data.

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 that delivers the core purpose and scope with no filler words or redundant elaboration.

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, simple list operation with an output schema present, the description is sufficiently complete. It names the resource and location; return details are covered by the existing 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?

There are zero parameters, so the schema is fully covered. The description adds no parameter detail, but none is needed; the baseline for a zero-parameter tool is 4.

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 ('Liste les templates custom') with an explicit location, distinguishing it from read_template, write_template, and delete_template. The verb 'list' immediately signals a read-only enumeration.

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 on when to use this tool versus siblings like read_template or list_notes. The usage is implied by the list verb, but with many sibling tools, explicit exclusions or alternatives would help disambiguation.

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 full behavioral disclosure burden. It only states 'history of workflow runs' and does not explicitly disclose read-only behavior, ordering, scope, pagination, or any side effects. The list semantics are implied by the name but not clarified in the description.

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, short sentence with no filler or redundancy. It is appropriately sized for a zero-parameter tool and is front-loaded with the core resource and operation.

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 and has an output schema, so return-value documentation is not required. However, with no annotations and no usage guidance, the description leaves some context gaps around what exactly constitutes a 'run', whether undone runs are included, and how this differs from related workflow run 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?

The tool has zero parameters with 100% schema coverage, so no parameter documentation is required. The description adds no parameter details, but none are needed for this tool.

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

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

The description 'Historique des runs de workflows' clearly identifies the resource (workflow runs) and implies a listing/history operation. It distinguishes itself from list_workflows by focusing on runs rather than workflow definitions, though it does not explicitly name the sibling it differs from.

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 list_workflows, apply_workflow, undo_workflow_run, or delete_workflow_runs. The description provides no context for selection or exclusions, leaving the agent to infer usage from the name alone.

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, and the description does not mention side effects, read-only nature, permissions, or any behavioral aspects. The description alone gives no transparency into potential outcomes.

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, clear sentence with no extraneous content. It is highly concise and well-structured for its simple purpose.

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

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

For a simple list operation with no parameters, the description adequately conveys the tool's purpose. It does not detail the output format, but the presence of an output schema and the simplicity of the operation make it sufficiently complete.

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

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

The tool has no parameters, so schema coverage is effectively 100%. The baseline of 3 applies, and the description adds no parameter information, but none is needed.

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

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

The description clearly states the tool's function with a verb and resource: it lists workflows. Despite being brief, it is unambiguous and distinguishes itself from other workflow-related tools.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or context for invocation. It is a bare functional statement.

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, but it only repeats the operation implied by the name. It does not disclose effects like whether the source is removed, whether target_dir must exist, or what happens on conflict.

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 short clause with no wasted words, but it is under-specified to the point of being a restatement of the tool name. It lacks the structure needed to convey any additional context.

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?

Although the tool is simple and an output schema exists, the description does not explain parameter roles, prerequisites, or behavioral consequences. Given no annotations and no schema descriptions, this is insufficient for confident 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?

Schema description coverage is 0%, and the description adds nothing about the required 'path' and 'target_dir' parameters. The agent must infer that path is the asset to move and target_dir is the destination; no meaning is supplied beyond the property titles.

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

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

Description 'Deplace un asset' states a specific verb (move) and resource (asset), which distinguishes it from sibling tools like move_note, rename_asset, and delete_asset. It does not add details like destination semantics, but the core purpose is clear.

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 provided about when to use this tool instead of alternatives such as move_note, duplicate_asset, or rename_asset. The description only states the action, leaving selection entirely 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that a note is moved, without saying whether the move overwrites existing files, updates references, requires special permissions, or is reversible. The description is too sparse to set accurate agent expectations.

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. It is concise and easy to parse, though it sacrifices detail for brevity.

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?

This is a mutating operation with no annotations and only a minimal description. The description does not cover conflict behavior, path formatting, target_subpath semantics, or return expectations. The output schema exists but does not absolve the description from explaining the tool's context and side effects.

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 by explaining parameters. It loosely implies target_folder as the destination folder, but it does not explain path or, more importantly, target_subpath and its default empty-string behavior. This leaves significant ambiguity for an agent choosing values.

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 action ('move'), the resource ('a note'), and the destination ('to another folder'). This distinguishes it from related operations like move_asset and rename_note, making the tool's purpose immediately clear.

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

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

The description gives no guidance on when to use this tool versus alternatives such as rename_note, duplicate_note, or move_asset. It does not mention prerequisites, limitations, or cases where this tool should not be used.

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 of behavioral disclosure, but it only restates the action. It does not specify whether the note must already exist, whether the operation modifies the note in place, what happens if the note is missing, or any side effects. 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 concise sentence with no filler. The key information (adding text to the beginning) is front-loaded and immediately actionable. It earns its place with zero 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?

Despite having an output schema and only 2 simple parameters, the description lacks essential behavioral context for a mutating operation. It does not state whether the note must already exist, whether it creates a note if missing, or how errors are handled. Given no annotations, the description is not complete enough for reliable 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?

Schema description coverage is 0%, so the description must compensate. It does relate 'texte' to the text parameter and 'une note' to the path parameter, but it adds no detail about the path format or how the note is identified. The parameter names are intuitive, but the description only minimally clarifies their meaning.

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

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

The description 'Ajoute du texte au debut d'une note' clearly specifies the action (add text), the resource (note), and the location (beginning), which distinguishes it from the sibling tool append_to_note that adds text at the end. The verb and resource are specific and 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?

The implied usage is to prepend text to a note, but the description provides no explicit guidance on when to use this tool versus alternatives like append_to_note, write_note, or create_note. It does not mention conditions, prerequisites, or exclusions, leaving the agent to infer the appropriate 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?

With no annotations, the description must carry behavioral disclosure; it does state that the action is definitive/permanent and targets a deleted asset. However, it does not explain why an undo_token is required, what preconditions apply, or any side effects beyond the obvious purge, so the transparency is only partial.

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 with no filler, and the core action is stated directly. It could not be more compact while remaining grammatical.

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?

Although the tool is simple and has an output schema, the only parameter is semantically opaque and the description offers no source or format for undo_token. Combined with no alternative routing, this is not complete enough for an agent to safely invoke a destructive tool without external knowledge.

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 0% description coverage and only the title 'Undo Token' for the single required parameter. The tool description adds no explanation of what undo_token is, where it comes from, or how to obtain it, so the agent has no semantic basis to fill the parameter correctly.

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 ('purge') and a specific resource ('un asset supprime'), clearly indicating permanent removal of an already-deleted asset. This distinguishes it from sibling operations such as delete_asset, restore_deleted_asset, and empty_deleted_assets.

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 'asset supprime' makes it clear the tool is for assets that have already been deleted, which gives a usable when-to-use condition. It does not explicitly name alternatives or exclusion cases, but the context alone is clear enough for basic routing.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the action and resource, without mentioning whether the operation is non-destructive, how errors are handled, whether authentication is required, or what the output shape is. The read-only nature is implied by the verb 'read' but not explicitly disclosed.

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, front-loaded sentence that conveys the essential purpose without unnecessary words. Every word contributes to understanding the tool's function.

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 one-parameter read operation with an output schema, the description provides a minimal viable understanding of what the tool does. However, it lacks usage context, parameter semantics, and behavioral notes, so it is not fully complete for an agent deciding when and how to invoke it.

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 0% description coverage, and the description does not explain the meaning, format, or expected values of the required 'path' parameter. It only implies that the path identifies a note, leaving the agent to infer what kind of path is expected.

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

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

The description states a specific action ('Lit les commentaires') applied to a specific resource ('d'une note'), which clearly identifies what the tool does. It also effectively distinguishes itself from the sibling tool write_comments by focusing on reading rather than writing.

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 provided about when to use this tool versus alternatives such as read_note, list_notes, or write_comments. The read/write contrast with write_comments is implied but not stated, and there is no mention of prerequisites or context for using the tool.

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

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

The description communicates a read-only action and indicates the returned content type (body markdown and frontmatter). However, it does not mention potential errors, handling of missing or deleted notes, or any side effects, and there are no annotations to supplement.

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 sentence with an example, making it easy to scan and understand.

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?

It covers the core purpose and return contents, but lacks parameter details and usage context. The frontmatter/body mention helps, but the description does not fully specify the response format.

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 only parameter 'path' has no schema description and the description only gives an example filename. It does not explain whether the path is vault-relative, absolute, or how to reference folders.

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

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

The description clearly states the tool reads a note and specifies content includes body markdown and frontmatter, with an example path. This distinguishes it from list or write operations among 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?

No guidance is provided for when to use this tool versus alternatives like list_notes or search_text, aside from an example filename. It does not mention prerequisites or 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?

With no annotations provided, the description carries the disclosure burden. It clearly describes a read-only action, but does not mention path constraints, error behavior, or whether the raw template content is returned. The output schema helps with return value expectations, but behavioral details remain minimal.

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 plus an illustrative example. It is appropriately short and front-loaded, with no filler or redundant 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 simple one-parameter read tool with an output schema, the description plus example is nearly sufficient. The main gap is not indicating where valid template paths originate, such as from list_templates, and not explicitly distinguishing this from read_note.

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 for the single 'path' parameter. The example '.zennotes/templates/adr.md' adds useful meaning about expected path format and location, but it does not clarify whether the path is vault-relative, whether extensions are required, or whether other template locations are allowed.

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

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

The description states the specific action 'Lit un template' (reads a template) and gives an example path, clearly identifying both the verb and the resource. This distinguishes it from sibling tools like list_templates, write_template, and delete_template.

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 on when to use read_template versus alternatives such as list_templates or read_note. The example path provides some context, but there are no explicit usage conditions, exclusions, or references to sibling tools.

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 of behavioral disclosure, but it only states that an asset is renamed. It does not mention whether the path must exist, whether the operation overwrites, what side effects occur, whether permissions are required, or how failures are reported.

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 French sentence with no filler or redundant content. It delivers the core purpose immediately, though it is terse and omits supporting details that would improve usability.

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?

Even though the tool has only two parameters and an output schema, the description lacks parameter semantics, usage guidance, and behavioral caveats for a mutating operation. An agent would need to rely on convention and inference to invoke this tool reliably.

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 has 0% description coverage, and the description does not explicitly explain that 'path' identifies the current asset and 'name' is the new name. These meanings are inferable from the parameter names and the rename action, but the description adds no direct clarification 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?

The description clearly states the action ('Renomme' = rename) and the resource ('asset'), which is a distinct resource type among the sibling tools. It differentiates at the resource level from rename_note and rename_folder, though it does not explicitly contrast with related asset operations like move_asset or duplicate_asset.

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 tool instead of alternatives such as move_asset, duplicate_asset, or delete_asset. No conditions, prerequisites, or exclusions are mentioned, so the agent must infer usage entirely from the tool name and sibling 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 only states the action, without explaining side effects, path semantics, conflict handling, or return behavior. This is minimal and leaves too much to inference.

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 one short sentence with no filler, making it concise and front-loaded. However, it is so brief that it sacrifices informational value, so it is not fully 'appropriately sized' for a tool with three required parameters.

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 three required parameters, no annotations, and zero schema descriptions, the description is far too sparse. It does not explain subfolder semantics, how the tool differs from related operations, or any constraints, leaving critical information for correct invocation 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 0% and the description does not clarify the meaning or relationship of folder, old_subpath, or new_subpath. The agent is left to guess whether these are paths, names, IDs, or something else.

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 verb ('Renomme') and resource ('un sous-dossier'), so the primary function is understandable. It implicitly distinguishes from rename_note by targeting folders, but does not explicitly contrast with other folder operations like move_folder or duplicate_folder.

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 rename_note, move_folder, or duplicate_folder. No context about prerequisites, exclusions, or selection criteria is provided.

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?

There are no annotations, so the description carries the behavioral disclosure burden. It usefully reveals that [[wikilinks]] follow automatically, which is a key side-effect. However, it does not mention permissions, reversibility, or what happens to the note's path beyond the rename.

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 compact sentence with no filler, and the important side-effect is presented in a clear parenthetical. Every word contributes 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?

For a two-parameter tool, the description is serviceable and an output schema exists. However, without annotations or parameter documentation, the agent must rely on inference for parameter meaning and invocation context, making it only minimally complete.

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

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

Schema description coverage is 0% and the description does not explain the two required parameters. 'path' and 'title' are somewhat inferable, but the description does not explicitly state that path identifies the note to rename and title is the new title.

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 ('Renomme') and a clear resource ('une note'), so an agent can tell it is a rename operation. It does not explicitly differentiate itself from nearby siblings like move_note or duplicate_note, but the core purpose 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?

No when-to-use guidance or alternative routing is provided. The description only states what the tool does, leaving the agent to infer when rename_note is appropriate relative to other note-manipulation 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 only says the tool restores an asset and tells the caller to pass the deleted object as-is. It does not disclose side effects, whether the asset becomes immediately visible, permission requirements, error behavior, or reversibility.

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 one short sentence with no filler. It front-loads the action and parameter handling in a compact, efficient way.

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 has a single parameter and an output schema, so the description does not need to explain return values. However, it omits the source of the deleted object and any preconditions (e.g., the asset must currently be in deleted assets), making it only minimally sufficient for reliable use.

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

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

The input schema provides no description and marks the 'deleted' parameter as an opaque object with additionalProperties true. The description adds some meaning by saying to pass the deleted object exactly as-is, which hints that the agent should reuse an existing deleted-asset object rather than construct one, but it does not specify required fields or the object's source.

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 a specific action and resource: 'Restaure un asset supprime' (restores a deleted asset). It is distinguishable from sibling tools like restore_note because it says 'asset', though it does not explicitly name 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?

The instruction 'passer l'objet deleted tel quel' implies the caller should reuse a deleted asset object, likely from list_deleted_assets, but the description never names that source or states when to use this tool instead of purge_deleted_asset or restore_note. Usage context is only implied, not explicit.

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 full responsibility for behavioral disclosure. It merely restates the core action and does not explain side effects, error behavior, or what happens if a note already exists at the restored path.

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 one short, direct sentence with no wasted words. It is appropriately concise, though it sacrifices semantic detail that is needed elsewhere.

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 tool with no annotations, this description is minimal but incomplete: the parameter meaning is entirely absent, and the output schema does not compensate for the missing guidance on how to call the tool correctly.

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

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

The required 'path' parameter has zero schema description coverage, and the tool description does not explain what path refers to (trash location vs. original location). The agent cannot determine correct input semantics from available information.

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 ('Restaure'), a clear resource ('une note'), and a clear source ('la corbeille'), which distinguishes it from related operations like trash_note, delete_note, and even restore_deleted_asset.

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

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

The intended use is implied: use this to restore a trashed note. However, there is no explicit guidance about when not to use it or how it differs from alternatives, leaving the agent to infer the appropriate 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?

There are no annotations, so the description carries the behavioral burden. It does disclose a key trait: results are line-level matches rather than whole documents. But it does not clarify matching semantics such as case sensitivity, query operators, whitespace handling, or whether filenames are also searched, leaving notable gaps for an unannotationed tool.

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 dense sentence with the primary action front-loaded and a parenthetical that adds meaningful behavioral detail without 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?

For a one-parameter search tool, the core selection and invocation intent are present. However, query syntax and search scope remain underspecified, and no constraints or limits are mentioned; adequate for simple use but not fully complete.

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

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

The schema only defines a required 'query' string with zero description coverage. The tool description adds no syntax, formatting, or interpretation guidance beyond the generic word 'full-text,' so the agent must guess at valid query semantics.

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

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

States a specific action ('Recherche plein-texte') and resource ('dans le vault'), with the parenthetical adding result granularity. No sibling tool performs content search, so it is clearly distinct from listing/browse 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 intended use is implied: an agent should use this when it needs full-text content lookup inside the vault. However, there is no explicit when-to-use, when-not-to-use, or comparison against alternatives such as list_notes or get_search_capabilities.

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 the transparency burden. It does state that the tool opens a session, which implies a state-changing operation. However, it does not disclose potential side effects (e.g., overwriting an existing session) or any required permissions. This partial transparency warrants a mid-range 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?

The description is a single, concise sentence that directly states the tool's purpose and key parameter. It has no unnecessary words or redundant 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?

Given the simplicity of the tool (one parameter, no output schema), the description is largely complete. It explains the action and the token's purpose. However, it omits any mention of success/failure behavior or return value, which would make it fully comprehensive.

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 provides only the type and required status for the 'token' parameter. The description adds crucial semantic context by specifying it is a 'bootstrap token,' which clarifies the token's role and distinguishes it from other token types. This goes beyond the schema's minimal information.

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

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

The description clearly states the tool's function: it opens a browser session using the bootstrap token. This is a specific verb-object structure that distinguishes it from sibling tools like session_status or session_logout.

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 does not provide any explicit guidance on when to use this tool versus alternatives. It does not mention conditions for use, such as 'use this when you need to start a new session' or 'do not use if a session already exists.'

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

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

The description discloses the primary side effect (closing the session) but omits further details such as whether it invalidates tokens, requires authentication, or has any irreversible consequences. Since no annotations are provided, the description carries the full burden but is minimal.

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, clear sentence with no extraneous information. It is appropriately sized for its simple purpose.

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

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

Given the simplicity of the action and the presence of sibling session tools, the description is sufficient. It does not explain the return value or error cases, but these are not critical for a logout operation in this 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 has no parameters, so there is nothing to explain. The empty schema is fully covered and no ambiguity exists.

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

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

The description clearly states the tool's function: closing the current session. It is specific and distinguishes itself from sibling session tools like session_login, session_status, and session_rotate_token.

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 provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as being authenticated, or scenarios where logout might be inappropriate.

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 of behavioral disclosure. It clearly flags the most important destructive side effect: the previous token is invalidated. Minor gaps remain around whether an existing session must already be active and whether invalidation is immediate, but the critical behavior is well covered.

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 one short, front-loaded sentence with the essential warning in parentheses. There is no filler, repetition, or redundant 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 zero-parameter action with a low complexity and an existing output schema, the description is nearly complete: it names what the tool does and the key side effect. Only minor questions about session prerequisites and exact invalidation timing remain.

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 has zero parameters, so schema description coverage is trivially 100%. The baseline for 0-parameter tools is 4, and no parameter-level explanation is needed because there is nothing for the agent to configure.

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

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

The description states a specific action (regenerate) applied to a specific resource (auth token). The warning 'invalide l'ancien' clarifies that this is a rotation, not a simple login or logout, so an agent can distinguish it from sibling session 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?

Usage is implied from the name and action: use this to refresh or replace the auth token while invalidating the old one. However, it does not explicitly say when to prefer rotate over session_login or session_status, nor does it state prerequisites such as requiring an existing authenticated session.

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 bears the full burden of describing behavior. It only says the tool reports session state, but it does not explicitly state that the call is read-only, whether authentication is required to call it, or what side effects it might have. This is a meaningful gap for a session-related tool.

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 one short, front-loaded sentence with no wasted words. It is concise, though slightly too terse to fully support an agent's decision-making.

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

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

For a parameterless status tool with an output schema, the description is mostly adequate. However, it omits usage context relative to the session sibling tools and does not clarify whether calling session_status itself requires authentication or is safe to call before login.

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 has zero parameters and 100% schema description coverage, so there is nothing for the description to add about parameters. The baseline score of 4 for a parameterless tool 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 that the tool reports session state and specifically whether authentication is required. This adds a meaningful detail beyond the tool name, although it is a noun phrase rather than an imperative verb and does not explicitly distinguish itself from the sibling session 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?

There is no guidance on when to use this tool versus session_login, session_logout, or session_rotate_token. An agent can infer that status is checked before deciding to authenticate, but the description does not say this or give any usage 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a write operation and hints that a complete settings object is expected, implying possible overwrite behavior, but it does not explain whether settings are merged or replaced, whether the operation is destructive, or what side effects or permissions are involved.

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 sentence with the main verb and resource front-loaded and no filler words. It is efficiently written, though it omits some important contextual 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 mutation tool with no annotations and an open-ended settings object, the description is too sparse for an agent to invoke it confidently. It does not clarify what a 'complete settings object' should contain, whether the operation replaces or merges existing settings, or what the response will be, even though an output schema exists.

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 schema only defines 'settings' as an object with additionalProperties true. The description adds the requirement to pass the complete settings object, giving some semantic meaning beyond the schema, but it does not elaborate on the object's fields or structure.

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

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

The description states a specific action with a verb and resource: 'Ecrit les reglages du vault' (writes the vault settings). This clearly conveys the tool's purpose and distinguishes it from the read-oriented sibling get_vault_settings, though it does not explicitly name the alternative.

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 alternatives such as get_vault_settings or vault_info. The parenthetical 'passer l'objet settings complet' is a parameter-level instruction, not situational usage 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 disclosure burden. It does not state whether the operation is read-only, whether permissions are required, what happens with excluded tasks, or any side effects or edge cases. The name suggests retrieval, but the description offers little concrete behavioral detail.

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

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

The description is extremely short, which is concise, but it is under-specified to the point of being a noun fragment rather than a complete functional statement. There is no useful structure, and the brevity sacrifices essential 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?

Although an output schema exists, the description is incomplete for an agent to call the tool correctly. Missing context includes the meaning of include_excluded, how 'path' should be specified, and how this tool relates to all_tasks. The description does not sufficiently cover the tool's usage 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?

With 0% schema description coverage, the description must compensate for undocumented parameters. It weakly maps 'path' to 'note', but does not explain that path is the note's path, nor does it clarify the meaning of include_excluded or its default behavior. The description adds minimal meaning beyond the raw parameter names.

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 'Taches d'une note donnee' identifies the resource as tasks belonging to a specific note, which gives some scope and distinguishes it from all_tasks. However, it lacks an explicit verb like 'list' or 'get', and does not clarify whether it returns tasks directly or performs some other action.

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

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

There is no guidance on when to use this tool instead of alternatives such as all_tasks or search_text. The phrase 'd'une note donnee' implies a per-note scope, but no explicit conditions, exclusions, or references to sibling tools are provided.

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 states the primary behavior (moving a note to trash) and adds that it is 'restaurable' (restorable), which implies non-permanence and that a restore_note tool exists. It does not detail side effects (e.g., what happens to links or attachments) but for a simple trash action, the description is reasonably transparent. No contradiction with annotations since none exist.

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 sentence in French: 'Met une note a la corbeille (restaurable).' It is front-loaded with the verb and resource, contains no unnecessary words, and directly conveys the action. Perfectly concise and well-structured.

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

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

Given the simplicity of the operation (trash a note), the description is largely complete. It states the action and reversibility, and the sibling tools (restore_note, delete_note) provide context. It does not mention preconditions (e.g., note must not already be trashed) or output details, but these are not critical for a basic trash action. Overall, adequate for the complexity.

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 single parameter 'path' has no description in the schema (schema coverage is 0%). The tool description does not clarify what 'path' refers to (e.g., note ID, file path, folder path). Since the description provides no additional meaning, the parameter is ambiguous and relies on implicit knowledge from other tools. This is a significant gap.

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 action: 'Met une note a la corbeille' (puts a note in the trash). It identifies the resource (note) and the destination (trash), and adds '(restaurable)' to indicate the operation is reversible. This distinguishes it from permanent deletion (delete_note) and aligns with the restore_note 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 gives no explicit guidance on when to choose this tool over alternatives like delete_note or archive_note. It only hints at reversibility with '(restaurable)', but does not explicitly compare to other operations or state scenarios where trashing is preferred. The user must infer usage from the sibling tool names.

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 discloses only the basic action and omits where the note is placed after unarchiving, whether authentication or ownership is required, whether the action is reversible, and what edge cases apply (e.g., note not currently archived). It adds no behavioral context beyond what the tool name implies.

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 one lean sentence with zero wasted words; every token earns its place. It is appropriately front-loaded with the action verb and object. It loses one point only because the brevity comes at the cost of omitted operational detail, but judged purely as a concise structure, it is efficient.

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 mutation tool with no annotations, a compact sentence could still carry substantial operational detail, but this one only restates the action. Missing are path semantics, post-unarchive destination, and any disambiguation from restore_note/archive_note. Even though an output schema exists, the input/behavior side is under-specified enough that an agent cannot confidently invoke it.

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 description does not compensate at all. The only parameter, path, is left undefined: does it refer to the archived note's current path, the pre-archive location, or the destination? The description needed to explain path semantics because the schema only declares type: string, and it failed to do so.

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 ('Sort' = remove/take out) and a specific resource (a note from the archive), so the core action is unambiguous. It implicitly differentiates from trash-related siblings by specifying 'archive', but does not explicitly name alternatives, leaving restore_note vs unarchive_note contrast to inference.

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

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

The description gives no guidance on when to use this tool versus alternatives. Notably, sibling restore_note performs a user-facing action very similar to unarchiving ('restore' both from archive and trash), and without explicit context on when the archive-specific unarchive is appropriate, an agent could easily pick the wrong tool.

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