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 does disclose meaningful behavior: HTML support, automatic downloading and embedding of media from URLs. However, it does not mention what happens on success or failure, whether a card ID is returned, or any side effects beyond creation. For a mutation tool with no annotations, richer behavioral disclosure would be expected.

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 compact and front-loaded with the core action. It consists of three sentences with no obvious filler. It could be slightly sharper by naming the front/back text fields instead of 'text fields,' but it is generally 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 8 parameters and no output schema, the description is adequate but incomplete for fully informed invocation. The rich schema covers parameter details, but the description does not clarify the expected return value, error behavior, or how this tool differs from the bulk and cloze siblings. That leaves some decision-making burden on the agent.

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

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

The schema already documents all 8 parameters with 100% coverage, so the baseline is 3. The description's mention of HTML and URL-based media roughly mirrors the schema's per-parameter descriptions and adds little new semantic meaning beyond what is already structured.

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 and resource: 'Create a new note in a specified deck.' It also adds useful scope by mentioning HTML formatting and media attachment. It does not explicitly distinguish itself from siblings like create-cloze-card or create-cards-bulk, though the required front/back fields and name imply a standard 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?

The description gives no guidance about when to use this tool versus alternatives such as create-cloze-card, create-cards-bulk, or update-card. There are no usage conditions, exclusions, or prerequisites stated in the description itself; the deck-existence prerequisite appears only in the schema, not in the tool 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?

No annotations are provided, so the description carries the burden. It discloses the batching behavior (one request regardless of batch size) and the media constraint, which is genuinely useful. However, it omits batch failure semantics — whether the whole batch is atomic or partially applied if one note is invalid — which matters for a write 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?

Three sentences, each earning its place: purpose, batching rationale, and limitation with alternative routing. The core purpose is front-loaded and there is zero wasted text.

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 2-parameter tool with 100% schema coverage, the description covers purpose, usage, and exclusions well. Minor gaps remain: no mention of return value/behavior since no output schema exists, and no statement about partial-failure handling in a batch. These are small against the otherwise complete picture.

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

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

Schema description coverage is 100% and the parameter descriptions are rich (tags constraints, deck nesting, prerequisite to create-deck first). The tool description itself adds no parameter-level detail, so the baseline 3 applies — the schema handles the heavy lifting.

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

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

The description states a specific verb-resource pair ('Create multiple basic notes in a single call') and pins down the note type ('basic'), distinguishing it from cloze siblings like create-cloze-cards-bulk. It also differentiates from create-card by explicitly addressing the media limitation.

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

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

Gives an explicit when-to-use directive ('Use this instead of calling create-card repeatedly') with the underlying reason (single request vs many). It also gives an explicit when-not-to-use rule ('Does not support images or audio: use create-card') that routes the agent to the correct alternative.

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 does disclose the key non-obvious behavior: media from URLs is 'automatically downloaded and embedded.' However, this largely repeats what the schema parameter descriptions already state, and it omits other behaviors an agent might need, such as duplicate-creation consequences or deletion of previous 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?

Two sentences with the primary purpose and syntax example front-loaded. The example ({{c1::Paris}} is the capital of France) earns its place, and the media-handling sentence is compact. Slight redundancy with schema param descriptions prevents a 5.

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

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

For an 8-parameter creation tool with no annotations and no output schema, the description covers the core cloze workflow adequately and the schema richly documents every parameter. It is incomplete in that it doesn't address return values, duplicate-creation behavior, or how this differs from the bulk sibling, though schema richness compensates for much of the 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 coverage is 100%, so the baseline is 3. The description adds marginal value by demonstrating the {{c1::text}} syntax pattern for the text parameter, but it adds nothing about deckName, tags, audio, or image parameters beyond what the schema already documents.

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 ('Create a new cloze note in a specified deck') and the cloze-deletion syntax example makes it clearly distinct from the sibling create-card. However, it does not differentiate itself from create-cloze-cards-bulk, so it falls just short of full sibling distinction.

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

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

The description explains HOW to use the tool (cloze syntax, HTML support) but gives no guidance on WHEN to choose it over alternatives like create-card, create-cloze-cards-bulk, or update-cloze-card. The only usage routing (use create-deck first) lives in the schema, not the description, so an agent gets no explicit selection criteria from the description itself.

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

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

With no annotations provided, the description carries the full burden. It discloses a key behavioral trait (sends one request regardless of batch size) and a limitation (no media support). This goes beyond the schema, which only describes parameters. However, it does not mention error handling, idempotency, or return behavior, which would make it more complete. Still, it provides meaningful context that an agent would find useful.

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

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

The description is two sentences with zero fluff. The primary purpose and efficiency benefit are front-loaded in the first sentence, and the limitation with alternative is in the second. Every word earns its place, making it highly 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?

For a bulk creation tool with two parameters and no output schema, the description covers the essential context: what it does, when to use it, and a key limitation. It relies on the schema for deck existence and tag constraints, which is appropriate given 100% schema coverage. It lacks explicit mention of return values or failure modes, but those are not critical for a straightforward creation tool. Overall, it is complete enough for an agent to correctly 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 100%, so the schema already documents all parameters (deckName, cards, and nested fields). The tool description adds no extra parameter-specific meaning beyond the schema. Per calibration, baseline is 3 when schema covers all parameters, and no additional value is added 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 clearly states the tool creates multiple cloze notes in a single call, using specific verbs and resources. It explicitly distinguishes itself from create-cloze-card by stating it is a batch alternative, and even names the sibling for media support. This leaves no ambiguity about its function or its differentiation.

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

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

The description gives explicit guidance: use this instead of calling create-cloze-card repeatedly, and use create-cloze-card when media (images/audio) is needed. It also implies it is the preferred choice for bulk cloze creation without media. This directly addresses when to use the tool versus its alternatives.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'Create' with no mention of side effects, error handling, or what happens on duplicate deck names. The schema does note nested deck behavior, but that is outside the description 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?

A single sentence with zero redundancy. The purpose is front-loaded and every word earns its place.

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

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

For a simple creation tool with one parameter and no output schema, the definition is mostly complete. However, without annotations, the lack of behavioral disclosure (e.g., idempotency, failure modes) leaves some gaps for an agent expecting robust 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?

Schema description coverage is 100% and the 'name' parameter is thoroughly documented, including nested deck syntax and parent auto-creation. The description adds no additional parameter context, so baseline 3 is appropriate.

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

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

The description states a specific verb ('Create') and a specific resource ('a new Anki deck'). It clearly distinguishes from sibling tools that operate on cards, so an agent can identify it without confusion.

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 alternative deck creation tool among siblings, so the intended use is implied. The description could mention when not to use it (e.g., if a deck already exists), but the context makes the primary use obvious.

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 thoroughly warns that deletion is permanent, cannot be undone, has no trash recovery, removes every card generated from the notes, and that deleting a cloze note removes all its generated cards. This is exemplary disclosure 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 appropriately sized for a destructive tool and front-loads the most important fact: permanent deletion. Every sentence adds relevant guidance. It is slightly redundant between 'cannot be undone' and 'notes and every card generated from them are gone,' but the repetition serves to emphasize severity, so it remains effective.

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 two-parameter tool with no annotations and no output schema, the description is fully complete. It covers the safety warning, the prerequisite find-cards workflow, explicit ID requirements, the confirm acknowledgement, and the cloze-note cascade behavior. Nothing an agent needs to invoke it correctly 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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema: it explains that noteIds must come from find-cards, that there is no delete-by-query, and that IDs must be listed explicitly. It also reinforces the confirm parameter's purpose by tying it to user-requested deletion and permanence.

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 begins with a specific verb and resource: 'PERMANENTLY deletes notes.' It clearly distinguishes itself from the create/update/find siblings by focusing exclusively on deletion, and it adds the critical 'permanent' qualifier that defines the tool's scope.

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 explicit when-to-use guidance: only delete notes the user has asked to delete. It also provides a required workflow: use find-cards first to obtain note IDs and confirm the right notes, and states that there is no delete-by-query and IDs must be listed explicitly. This fully routes the agent away from misuse.

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 disclosure burden. It discloses that field content is truncated, results are capped, and the output includes note IDs, note type, tags, and excerpts. It does not mention auth, exact caps, or ordering, but for a read-only search tool the disclosed behavior is substantially transparent.

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

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

The description is four sentences, front-loads the core purpose, then gives the usage context, limitations, and examples. Every sentence earns its place with no redundancy or filler.

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

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

For a tool with a single parameter, no output schema, and no annotations, the description covers the essential information: what it searches, what it returns, how to use the query, and the main limitations. It could add the exact truncation cap or result format, but the existing content is sufficient for correct invocation.

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

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

Schema coverage is 100% and the schema already describes the query parameter, so the baseline is 3. The description adds value by giving concrete Anki query syntax examples and explaining the consequence of overly broad queries, which helps the agent choose an effective parameter 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 opens with a specific verb and resource ('Search for notes using Anki's search syntax') and enumerates the returned fields (note IDs, note type, tags, excerpts). It also explicitly positions the tool as the prerequisite for update-card, update-cloze-card, and delete-card, clearly differentiating it from the sibling create/update/delete 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?

It explicitly states when to use the tool: to obtain the noteId needed by update-card, update-cloze-card, or delete-card. It also warns that results are truncated and capped and instructs the agent to narrow the query if the desired note is not listed, which is actionable 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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states 'update' without revealing whether fields are partially updated or fully replaced, what happens to omitted fields, or any side effects. This is a significant gap for a mutation 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, concise sentence with no wasted words. It's appropriately sized for a simple update operation, though it could benefit from more detail. The brevity is a strength, not a flaw.

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 absence of an output schema and annotations, the description leaves out important operational context. It doesn't explain the effect on fields not provided, whether tags are replaced or merged, or what the response looks like. For a tool with four parameters, this is incomplete and could lead to incorrect 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?

Schema description coverage is 100%, with each parameter already having a clear description in the schema. The tool description adds no additional meaning beyond what the schema provides, so the baseline of 3 applies. The schema itself adequately explains the parameters.

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

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

The description clearly states the tool updates an existing note, giving a specific verb and resource. However, it doesn't differentiate from sibling update-cloze-card, which is a similar operation on a specialized note type. The name 'update-card' vs description 'note' adds minor ambiguity, but it's still understandable.

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 like update-cloze-card. There's no mention of what kinds of notes are appropriate, nor any exclusions or prerequisites. An agent is left to infer usage 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 provided, the description must carry the full burden of behavioral disclosure. It only states the action without mentioning side effects, permission requirements, whether the update is partial or full, or any impact on existing card data. For a mutation tool, this is a significant gap – the agent knows it updates but not how it behaves.

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, essentially restating the tool name. While it is not verbose, it fails to add any value beyond the name – it does not earn its place by providing useful context. It is under-specified rather than concise, similar to a tautology.

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 4 parameters, no annotations, and no output schema, the description is completely inadequate. It does not explain what 'update' means operationally, whether fields are optional or overwrite existing values, or what the expected outcome is. An agent cannot safely invoke this tool based solely on this description.

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

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

Schema description coverage is 100%, so all parameters are already documented in the input schema. The description adds no additional parameter context, but per the rubric, the baseline is 3 when the schema covers everything. The description does not clarify parameter relationships or update semantics 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 clear verb and resource: 'Update an existing cloze note'. It distinguishes from create-cloze-card by using 'update' and specifies 'cloze' to differentiate from generic update-card. However, it does not mention the fields that can be updated or the fact that it operates on a note rather than a card, leaving some 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?

The description provides no guidance on when to use this tool versus the sibling update-card or create-cloze-card. An agent cannot determine whether to use this for cloze notes and update-card for basic notes without additional context. No exclusions or alternatives are mentioned.

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