Google Keep

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

The description fully discloses behavior: it can either return a login link or accept a token to establish a session, and clarifies the difference between permanent (config) and session-only (pasted) setups. Annotations (idempotentHint true) align with this behavior, with no contradictions.

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 slightly verbose but each sentence adds value. It is front-loaded with the core action and then explains the two methods clearly. Minor redundancy but acceptable.

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 schema with one optional parameter and no output schema, the description covers all necessary context: how to authenticate (two methods), the meaning of the token parameter, and the behavior of calling with no args. It is complete for an AI agent to decide and invoke 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 a single 'token' parameter with no description, but the tool description explains its purpose (a JWT to paste for session login) and that it can be omitted to get a link. This fully compensates for the schema's lack of 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 clearly states this tool authenticates by either providing a browser login link (no args) or accepting a pasted JWT token. It distinguishes itself from sibling tools (all note-related) by focusing on authentication and configuration.

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 explains when to use each mode: adding token to config for permanent access, or pasting token for session-only, or no args to get the link. This provides clear context for selecting the tool over alternatives like 'connect'.

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

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

Annotations already indicate readOnly and idempotent safe behavior. The description adds valuable behavioral detail about conditional returns: when all providers are connected it returns authenticated:true and empty pending[], otherwise returns connect_url and per-install URLs. This goes beyond annotations and clarifies expected responses.

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 concise sentences, no redundant phrasing. Front-loaded with the core action and immediately explains the two possible outcomes.

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 (no params, no output schema) and the annotations, the description is nearly complete. It explains both return scenarios but could specify what 'pending[]' represents or mention provider names, but that is minor. Adequate for a status-check 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?

Tool has zero parameters, so baseline is 4. Description does not need to explain parameters. It adequately conveys that no inputs 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 clearly states the tool's purpose: 'Returns connection status and URLs.' This is a specific verb-resource combination that distinguishes it from siblings like 'authenticate' (which establishes auth) and 'show_version' (which returns version 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?

Implied usage: use to check connection status. It describes two return states, but does not explicitly mention when to prefer this over 'authenticate' or other alternatives. Lacks explicit 'when not to use' 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?

The description adds 'criada se não existir' (created if doesn't exist), a side effect beyond what annotations disclose. Annotations state readOnlyHint false (mutation) and destructiveHint false, which are consistent. However, it does not mention potential errors, permission requirements, or effects on existing labels. It adds some context (bulk support) but not enough to be higher.

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 exceptionally concise: two short sentences, with the primary action front-loaded and bulk support mentioned second. No filler words or redundancy.

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

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

Given the tool has 5 parameters, no output schema, and annotations that are all false hints, the description should provide more context. It only covers label and note_ids, omitting unsafe and account. No mention of return values or error handling. For a tool with multiple knobs, this is incomplete.

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 coverage, the description must explain parameters. It does clarify 'label' is by name and 'note_ids' enables bulk, but it does not explain 'unsafe' or 'account', and 'note_id' is not explicitly described beyond being required. The incomplete parameter coverage leaves significant gaps for a 5-parameter 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 clearly states the action: 'Anexa uma label... a uma nota' (adds a label to a note), including that the label is created if it does not exist. This verb-resource pair is specific and distinguishes it from siblings like keep_create_label (creates label standalone) and keep_remove_label_from_note (removes label).

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

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

The description implies usage (adding labels to notes) and mentions bulk support with note_ids, but does not explicitly state when to use this over alternatives. It does not provide exclusions or context like 'use if you need to add a label, use keep_create_label if you only need to create it.' The bulk mention gives a hint but no explicit when/why.

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 adds only the bulk execution behavior beyond the annotations. It does not disclose any potential side effects, failure modes, or permission requirements. Since annotations already indicate a mutating operation, the description adds little extra transparency.

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 with two sentences, and the main purpose is front-loaded. Every word is useful and it does not waste space, but it may be too terse given the missing parameter information.

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

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

The tool has six parameters, no output schema, and zero schema description coverage. The description only covers the overall function and one parameter's purpose. It lacks details on required vs optional fields, return value, and usage conditions, making it incomplete for an agent to use 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 description only mentions note_ids for bulk support. The other five parameters (text, unsafe, account, checked, note_id) are not explained at all, and since the schema itself has no descriptions, the description fails to compensate. This is a major gap for a tool with six 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 adds an item to a checklist, using a specific verb and resource. It also mentions bulk support, which helps differentiate it from single-item operations. However, it does not elaborate on what constitutes an 'item' or the checklist context, so it is clear but not excessively detailed.

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 a hint about bulk usage with note_ids, but it does not explicitly state when to use this tool versus alternatives like keep_update_list_item or keep_create_list. There is no guidance on prerequisites or exclusions, leaving the agent to infer usage from the tool name and siblings.

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

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

Annotations already indicate a non-read-only, non-destructive operation. The description adds that batch execution is supported via note_ids, which is useful behavioral context. It does not disclose potential side effects, permission requirements, or behavior when sharing an already-shared note.

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 crisp sentences: first states the core action, second adds the bulk capability. Every word contributes 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?

The description covers the primary purpose and bulk behavior, but it does not fully explain all five parameters or the interaction between note_id and note_ids. Since there is no output schema, return behavior remains unspecified.

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

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

Schema description coverage is 0%, and the description only clarifies email and note_ids (bulk). It leaves note_id, unsafe, and account without added meaning, making some parameters ambiguous.

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 what the tool does: 'Compartilha uma nota com um colaborador (por email)' (shares a note with a collaborator by email). This distinguishes it from sibling tools like keep_remove_note_collaborator and keep_list_note_collaborators.

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

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

The description implies usage through the 'Bulk support: accepts note_ids for batched execution' note, which indicates when to use note_ids. However, it does not explicitly mention when not to use the tool or name alternatives such as keep_remove_note_collaborator.

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 adds useful behavioral context beyond the basic annotations by stating the default `archived=true` and confirming bulk support. However, it does not clarify the meaning or consequences of the `unsafe` parameter, and the annotations already indicate mutation, so the description provides only moderate transparency.

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 compact sentences with no filler. It front-loads the core purpose and immediately adds the default behavior and bulk capability, making it easy to parse quickly.

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 core use case and batch capability are present, the tool has five parameters, no output schema, and minimal annotations. Omitting semantics for `unsafe` and `account` means the description is not complete enough for an agent to confidently handle all valid invocations or understand 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?

With 0% schema description coverage, the description carries the full burden for parameter semantics. It adds meaning for `archived`'s default and `note_ids`' bulk behavior, but it leaves `unsafe`, `account`, and the exact relationship between `note_id` and `note_ids` unexplained, which is a substantial gap for a 5-parameter 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 opens with a specific action: 'Arquiva ou desarquiva uma nota', naming both the operation and the target resource. It also clarifies the default (`archived=true`) and distinguishes this from sibling tools like keep_trash_note and keep_restore_note, since archiving is a distinct 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 clearly conveys when to use the tool: to archive or unarchive notes. It also signals batch usage via note_ids, which helps the agent decide between single and bulk invocation, though it does not explicitly contrast this with trash/restore or provide exclusion criteria.

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 adds no behavioral context beyond what annotations already signal. Annotations indicate readOnlyHint=false and destructiveHint=false, which align with creating a label, but the description does not disclose duplicate behavior, account requirements, or any consequences of creation.

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 redundant wording. While it is minimal, it is appropriately concise for a simple create operation, though it sacrifices necessary detail.

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

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

For a tool with 2 parameters and no output schema, the description is too thin. It does not explain the optional 'account' parameter, potential duplicate behavior, or how this differs from creating lists or notes, leaving the agent with incomplete operational understanding.

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. It says nothing about the required 'name' parameter or the optional 'account' parameter, leaving the agent without information on what values are expected or how they affect label creation.

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 ('Criar' = create) and the resource ('label'), distinguishing it from sibling tools like keep_delete_label and keep_list_labels. However, it lacks any scope qualifier or differentiation beyond the obvious verb-resource pairing.

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 such as keep_create_list or keep_add_label_to_note. The context implies creation of a label, but there is no explicit usage context 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 discloses the automatic label 'keep-mcp' as a behavioral trait not covered by annotations. It does not mention return values or error handling, but for a simple create operation this is acceptable.

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, consisting of two short sentences, and conveys the essential information without any fluff.

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, the description covers the main action and a key side effect (labeling). It omits return details, but that may be acceptable for a create operation. It is mostly complete for the 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 schema has 3 parameters (items, title, account) with no descriptions. The description explains only 'items' and its structure, leaving 'title' and especially 'account' unclear. This is incomplete coverage.

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 it creates a checklist in Google Keep, uses the verb 'Cria' (creates), and specifies the resource. It distinguishes from sibling tools like keep_create_note by mentioning 'checklist'.

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?

While not explicit, the description implies usage for creating checklists, and the sibling list shows keep_create_note for regular notes. The mention of automatic labeling suggests a side effect but does not explicitly contrast with 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?

Annotations already declare readOnlyHint=false and destructiveHint=false. The description adds the side effect of auto-adding the 'keep-mcp' label, which is useful beyond annotations. However, it doesn't disclose authentication needs or return 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?

Two short, front-loaded sentences with zero filler. The primary purpose is stated first, followed by the label behavior, achieving maximum efficiency.

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 main purpose and an important side effect, but lacks parameter explanations and any guidance on when not to use it. Given the simplicity of the tool and presence of annotations, it's minimally viable but not 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?

Schema coverage is 0% for text, title, and account. The description only mentions 'text note' without explaining the role of each parameter, leaving agents to infer the meaning of 'account' or whether 'title' is 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 explicitly states the action (create) and resource (text note in Google Keep), and distinguishes from siblings like keep_create_list by specifying it's a text note. The mention of the automatic label further clarifies the tool's unique behavior.

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?

Implies usage for creating a text note, but does not explicitly contrast with alternatives like keep_create_list or keep_update_note. No exclusions or prerequisites are mentioned, leaving the 'when not to use' 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?

Annotations include destructiveHint: false, but the description says 'Apaga' (deletes), which implies destruction. This is a potential contradiction: the annotation suggests it's not destructive, but the description clearly indicates deletion. No additional behavioral context is provided, such as whether deletion is permanent or if it affects notes using the label.

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 Portuguese. It is front-loaded with the action and resource. However, it is under-specified, which is not a conciseness issue but a completeness issue.

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 has 2 parameters, no output schema, and minimal annotations, the description is insufficient. It doesn't explain the account parameter, the effect of deletion, or any error conditions. The description is too brief for a deletion operation.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'pelo nome' (by name), which aligns with the 'name' parameter, but it doesn't explain the 'account' parameter at all. The description adds minimal value 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 'Apaga uma label pelo nome' clearly states the action (delete) and the resource (label) with the method (by name). It distinguishes from siblings like keep_create_label and keep_list_labels, though it doesn't 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?

No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites like authentication or whether the label must exist. The description is minimal and doesn't provide context for selection.

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 says the tool removes/deletes a checklist item, which is inherently destructive. Yet the annotations state destructiveHint: false, creating a direct contradiction. No other behavioral context is provided.

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, front-loaded with the primary purpose, and the bulk-support note is placed as a separate useful sentence. There is no wasted wording.

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

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

For a tool with no output schema and no behavioral annotations beyond a contradictory destructiveHint, the description is minimal. It covers the core action and batch capability but omits important context like the meaning of 'unsafe'/'account', expected result, or any 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?

The description adds meaning for item_id and item_ids, noting that item_ids enables batch execution. Since the schema has 0% parameter descriptions, this helps somewhat, but the 'unsafe' and 'account' parameters remain completely unexplained.

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—'Remove um item de checklist por item_id'—and identifies the resource as a checklist item. This distinguishes it from sibling tools like keep_delete_note or keep_update_list_item because it targets a specific checklist item by ID.

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 conditional usage guidance via 'Bulk support: accepts item_ids for batched execution,' indicating when to use the array form. However, it does not explicitly contrast with sibling tools or state when this tool should be avoided.

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 explicitly states the deletion is permanent and irreversible, which is critical behavioral information. It also discloses bulk execution, so it is transparent about the tool's 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 concise and to the point, leading with the main action and adding bulk support in a second sentence without unnecessary detail.

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

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

While the core purpose and bulk behavior are covered, the lack of explanation for the unsafe and account parameters leaves the description incomplete for fully informed 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 description clarifies the note_ids parameter for batch operations, but does not explain the unsafe or account parameters, leaving their semantics unclear.

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 permanently deletes a note, distinguishing it from trash or soft-delete operations. It also mentions bulk support, which further clarifies its purpose.

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 mentions bulk support but does not explicitly contrast with alternative tools like trash or update, leaving the specific use-case context somewhat open.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds the default value for trashed (false), but does not disclose other behavioral aspects like pagination, return format, or side effects. It adds minimal context beyond what annotations provide.

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 purpose and lists filters efficiently. No unnecessary words; it 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 search tool with 8 parameters and no output schema, the description covers the main filters and their defaults. However, it does not mention the limit or account parameters, nor does it clarify what the output looks like (e.g., metadata only vs full content). Given that annotations provide safety context, it is adequate but not 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%, so the description must compensate. It lists most parameters (query, labels, colors, pinned, archived, trashed) and clarifies that query searches title/text. It also notes the default for trashed. However, it omits limit and account, and does not explain the exact semantics of colors/labels beyond being filters. It provides partial but not complete compensation.

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 searches notes in Google Keep (Busca notas no Google Keep). It lists optional filters, distinguishing it from sibling tools like keep_get_note (which likely retrieves a single note) and mutation tools. The verb 'Busca' (search) and resource 'notas' provide specific purpose.

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

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

The description implies usage for searching notes but does not explicitly discuss when to use this tool versus alternatives like keep_get_note or other filter-specific tools. No exclusions or alternative recommendations are provided, leaving the agent without clear guidance on when to prefer this tool over siblings.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds bulk-execution behavior beyond annotations, but does not describe return format, missing-ID handling, or account selection. This adds value but not rich behavioral context.

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

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

The description is two short sentences, front-loaded with the core purpose, and contains no filler. The bulk-support sentence is informative and earns its place.

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

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

For a simple read tool with good annotations, the description covers the main action and bulk behavior. However, the lack of output schema, 0% parameter coverage, and ambiguity around note_id/note_ids/account leave notable gaps for full autonomous 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 explains note_id and note_ids ('Bulk support'), but it does not describe the 'account' parameter or clarify whether note_ids is an alternative to or a supplement for the required note_id.

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

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

The description clearly states the tool returns a Google Keep note/list by ID, which is a specific verb+resource+scope. The 'pelo id' wording differentiates it from search-oriented siblings like keep_find and from mutation 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 bulk support note ('accepts note_ids for batched execution') gives some usage context, and the purpose implies when to use the tool. However, it does not explicitly contrast with alternatives like keep_find or mention when not to use 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds that accounts are linked to the install and what fields are returned, but it does not explain whether the optional 'account' parameter affects the result or how the listing behaves beyond that. This is useful but minimal additional 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?

Two sentences, front-loaded with the primary purpose and followed by a practical use case. No filler or redundancy; every word contributes to understanding what the tool does and why to use it.

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 read-only, and the description states its output fields (id/email, label) and a usage trigger. However, the absence of any parameter semantics for the optional 'account' field and the lack of an output schema leave a gap: an agent cannot be fully sure whether to pass anything or what might change in the listing. The description is good but not complete enough for full autonomous 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 for the single optional 'account' parameter is 0% and the description only references `account` as a value to discover, not as a parameter of this tool. It does not clarify what the parameter does, its format, or whether it filters the list. With such low schema coverage, the description needed to compensate but only partially does.

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 ('Lista' / lists) and a clear resource ('contas Google Keep vinculadas a este install') with the output details (id/email, label). It distinguishes itself from sibling tools like keep_list_labels and keep_find by focusing on account discovery.

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 explicitly states when to use the tool: 'Use pra descobrir o `account` quando há várias.' This provides clear context but does not mention when not to use it or explicitly name alternatives, so it stops short of a 5.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds no extra behavioral details (e.g., whether results are sorted, paginated, or account-scoped). It simply restates what the operation does without enriching the annotation 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 a single, clear sentence that efficiently conveys the core function. It is front-loaded and free of 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?

Given the tool's simplicity (one optional parameter, no output schema), the description is minimal but leaves gaps: what does 'account' refer to? Is it required? Are there any assumptions about the account context? The lack of any explanation about the parameter or response structure reduces completeness.

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 one optional parameter 'account' with no description. The tool description says 'from the account' but does not explain what the account parameter is, its format, or its optionality. With 0% schema description coverage, the description fails to compensate for the lack of parameter clarity.

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 is in Portuguese: 'Lista todas as labels da conta.' which translates to 'Lists all labels from the account.' It clearly states the action (lists) and the resource (labels), and distinguishes this from sibling tools like keep_create_label and keep_delete_label.

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 this tool versus alternatives. It does not mention when it is appropriate to call this tool, nor does it provide exclusions or contrast with related listing tools. The purpose is implied but not explicitly framed.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the bulk support behavior and that it returns emails, but doesn't detail response format or edge cases. No contradiction with annotations.

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 concise with two sentences, front-loading the main purpose. The bulk support note is useful and placed second. No wasted 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?

Given 0% schema coverage, no output schema, and 3 parameters, the description is incomplete. It doesn't explain the account parameter, the relationship between note_id and note_ids, or what the output looks like. For a read-only tool with annotations, it's adequate but leaves key usage details unclear.

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 mentions note_ids for bulk support but doesn't explain the relationship between note_id and note_ids (e.g., mutually exclusive or note_id required even with note_ids). The account parameter is not mentioned at all. 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 tool lists collaborators (emails) with whom a note is shared, using a specific verb and resource. It distinguishes from siblings like keep_add_note_collaborator and keep_remove_note_collaborator, though it doesn't explicitly name them.

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

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

The description implies usage for listing collaborators on a note, and mentions bulk support via note_ids. However, it doesn't provide explicit when-to-use vs alternatives or exclusions, though the purpose is clear enough for basic selection.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety profile is covered. The description adds the bulk execution behavior (accepts note_ids) and that it returns links, which is useful. However, it doesn't describe pagination, output format details, or whether the account parameter is needed for bulk. Given annotations cover safety, a 3 is appropriate.

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: the first states the purpose, the second notes bulk support. Both sentences earn their place. No fluff, front-loaded with the main 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?

The tool is relatively simple with 3 params (one required) and useful annotations. The description covers the core purpose and one important behavior (bulk). It lacks detail on return structure or account parameter, but given the simplicity and annotations, it's mostly complete. Slight gap on account parameter meaning and output 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?

Schema description coverage is 0%, so the description must compensate. It mentions note_ids for bulk support and note_id implicitly as the primary single note. The 'account' parameter is not mentioned, which is a gap. The description adds some meaning (links, media types) but doesn't fully clarify each parameter's role, especially account. Baseline is 3 given no schema coverage, but it partially compensates.

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 lists media blobs (images/audio/drawings) from a note with links. It distinguishes from sibling tools like keep_get_note (full note) or keep_find (search). Slight deduction because it doesn't explicitly name alternatives, but the verb+resource is specific.

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

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

The description clearly implies the primary use case: listing media from a specific note. It mentions bulk support with note_ids, which is a clear usage context. It doesn't explicitly say when not to use it, but the sibling list shows alternatives like keep_get_note for full note retrieval, and the context is reasonably clear.

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

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

Annotations already indicate this is a mutating operation (readOnlyHint=false) and not destructive, and the description's language is consistent. It adds useful context about the default pinned value and bulk support, but it does not disclose the effect of the 'unsafe' parameter or account selection.

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

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

The description is two short, front-loaded sentences with no filler. The first sentence states the core action and default behavior; the second adds batch capability. 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?

The description covers the primary behavior and bulk execution, which is adequate for a simple mutation tool. However, with no output schema and zero schema-level descriptions, the unexplained 'account' and 'unsafe' parameters leave gaps in fully understanding how 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?

With schema description coverage at 0%, the description must compensate. It explains the 'pinned' default and that 'note_ids' enables batched execution, but it leaves 'note_id', 'account', and 'unsafe' without meaningful semantic explanation.

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 ('Fixa ou desafixa') and a clear resource ('uma nota'), making the tool's purpose immediately obvious. It also clarifies the default pinned state and is distinct from sibling tools like archive, trash, and restore.

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: pin or unpin a note, with optional bulk support via note_ids. However, there is no explicit guidance about when to use this tool versus alternatives such as keep_archive_note or keep_trash_note.

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 annotations already show readOnlyHint=false and destructiveHint=false, so the important read/write and safety traits are given. The description adds essentially only 'bulk support', but it does not disclose behavior around unsafe, account, what happens when the label is absent, or how the note association may be affected.

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 contains only two short sentences, both useful and front-loaded. The action, target, label semantics, and bulk support are communicated without filler, so every sentence 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 the simplest invocation, the description is sufficient: a note_id and a label by name can be supplied to remove the label. It is less complete for batch and edge cases, especially because unsafe and account are unexplained and there are no output shapes or error/behavioral expectations disclosed.

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 compensates only partly: it clarifies that label is matched by name and that note_ids enables bulk execution. It leaves unsafe and account undefined, and the relationship between required note_id and optional note_ids is ambiguous from the provided text.

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 and target: "Remove uma label (por nome) de uma nota" clearly states that it removes a label by name from a note. The bulk note about note_ids adds scope and distinguishes it from singular add/delete label operations, and the action is clearly differentiated from sibling tools like keep_add_label_to_note and keep_delete_label.

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 a clear use context for removing labels from notes and adds a useful batch-use hint with note_ids. However, it does not explicitly say when not to use it, does not mention alternatives, and does not state any prerequisites or constraints such as account requirements.

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 show readOnlyHint=false, destructiveHint=false, idempotentHint=false, which are sparse aid. Description adds bulk support but doesn't clarify whether operation is reversible, permission requirements, or effects on note sharing. It does not contradict annotations, but adds minimal 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?

Description is brief and front-loaded: one line for main purpose, one line for bulk support. No waste, but could include more details without losing 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?

Tool has moderate complexity with 5 parameters and no output schema. Description is minimal, leaving unspecified parameters unexplained. Without annotations providing detail, the description is incomplete for effective invocation, especially in bulk mode.

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 description must compensate. Description only explains email and note_id implicitly, but does not explain unsafe, account, or note_ids. This is insufficient given 5 parameters, many of which are undefined in the schema.

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

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

Description specifies verb 'remove' and resource 'colaborador (por email) de uma nota', with the note that it removes a collaborator by email from a note. It distinguishes from sibling keep_add_note_collaborator, but could be more specific about the type of collaborator (e.g., editor vs viewer) and the effect on permissions, so not a 5.

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

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

No guidance on when to use this tool versus alternatives. It does not mention cases like removing yourself, handling non-existent collaborators, or that bulk mode might have specific use cases. The bulk support note is a hint but not explicit enough.

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

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

Annotations already indicate this is not read-only and not destructive. The description adds the bulk execution capability, but does not disclose side effects, error behavior, or what happens when restoring notes with dependent items. No contradiction with annotations.

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 concise: two short sentences that immediately convey the core action and the bulk capability. No filler or redundant phrasing.

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 four parameters with no schema descriptions and no output schema, the description is too thin. It omits important context about 'unsafe', 'account', and the exact behavior or limitations of batch restores, leaving significant gaps for 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?

Schema description coverage is 0%, so the description must explain parameters. It only mentions note_ids for bulk support and implicitly note_id, leaving 'unsafe' and 'account' completely unexplained. The agent cannot infer their meaning or requirements from the 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 clearly specifies the operation: restoring a note from the trash. It also distinguishes the tool from siblings like keep_trash_note by mentioning trash-specific behavior and bulk support.

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 'Restaura uma nota da lixeira' establishes the clear context: use this tool when restoring trashed notes. Bulk support adds guidance for batched use, though it does not explicitly mention when not to use it or compare 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?

Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false. The description adds that it supports bulk execution via note_ids, which is a behavioral detail not in annotations. However, it does not disclose other side effects (e.g., whether it overwrites existing color, permission requirements, or error behavior). Since annotations set the baseline, this is a moderate addition, so a 3 is appropriate.

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 concise: two short sentences. It front-loads the primary purpose and then adds a key capability (bulk support). No fluff or redundancy. Ideal length for a simple 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?

Given that the tool has 5 parameters (note_id, color, unsafe, account, note_ids) and no schema descriptions, the description should compensate for missing parameter meaning. It only elaborates on color (which is already an enum) and the bulk capability. It leaves 'unsafe' and 'account' unexplained, and does not specify behavior regarding invalid inputs, return values, or potential side effects. For a mutation tool, more context is needed.

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 'color' parameter by listing valid values (though these are also in the schema enum) and explains that 'note_ids' enables batch operations. However, it leaves 'unsafe' and 'account' completely unexplained, and does not clarify the relationship between 'note_id' and 'note_ids' (e.g., exclusivity). This is insufficient given the low schema coverage.

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: 'Define a cor de uma nota' (set the color of a note), and lists the accepted color values. It is specific about the resource (note) and the action (set color). However, it does not explicitly distinguish itself from sibling tools like keep_add_label_to_note or keep_update_note, though the name itself is fairly clear. Slightly deducting for lack of explicit 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 provides no guidance on when to use this tool versus alternatives or any prerequisites. It only mentions bulk support but does not explain scenarios where this tool is preferred. There is no mention of exclusions, limitations, or conditions under which one might use a different note-related 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 annotations already provide readOnlyHint=false, destructiveHint=false, and idempotentHint=false, which are contradictory and unhelpful. The description does not clarify the actual behavior (e.g., if trash is reversible, if it archives instead of deletes, any permission requirements). It only adds bulk support information, which is useful but insufficient for a mutating operation with such ambiguous annotations.

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 brief and front-loaded with the core action, followed by a clear note on bulk support. No unnecessary words, but the brevity contributes to the lack of detail in other dimensions. It's concise, though the second sentence could be more informative.

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 there is no output schema, the description must compensate for explaining returns and side effects, but it doesn't. It doesn't specify whether the trash operation is reversible, what happens to the note, or any permission requirements. The tool is relatively complex (4 parameters, bulk support, mutation), but the description only covers the bulk aspect, leaving major 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?

With schema coverage at 0%, the description must explain all parameters, but it only mentions note_ids for bulk execution and not the other three parameters (unsafe, account, note_id). The description fails to clarify the difference between note_id and note_ids, or the purpose of unsafe and account, leaving the agent guessing.

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 clear verb + resource ('Move uma nota pra lixeira') and explicitly mentions bulk support via note_ids, which differentiates it from siblings like keep_archive_note or keep_delete_note. However, it does not explicitly contrast with these alternatives, so it's clear but lacks direct sibling 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 indicates when to use it (to trash a note and for bulk operations) but provides no explicit guidance on when not to use it or alternatives. The mention of bulk support implies a use case, but there is no explicit exclusion or comparison to related tools like keep_archive_note or keep_delete_note.

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

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

Annotations already indicate this is a write operation (readOnlyHint: false) and not idempotent/destructive. The description adds value by disclosing bulk execution capability, which is a behavioral trait not captured in annotations. It does not elaborate on error handling, partial failures, or side effects, but the annotation coverage lowers the burden; a 3 is appropriate for the additional bulk 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 comprises two very concise sentences: the first states the purpose, the second adds bulk support. There is no fluff, every word contributes. It is front-loaded with the primary action, making it easy to parse quickly.

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 complexity (6 parameters, no output schema, minimal annotations), the description is too sparse. It omits meaning for 'unsafe' and 'account', does not discuss error behavior, atomicity of bulk operations, or any prerequisites (like authentication). For a mutation tool, this level of completeness is inadequate for an agent to use reliably without additional investigation.

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 schema description coverage at 0%, the description must compensate. It explains 'texto' (text) and 'checked' parameters, and mentions item_id and item_ids for bulk. However, it leaves 'unsafe' and 'account' completely unexplained, and does not clarify relationships between parameters (e.g., whether item_ids replaces item_id). This is insufficient for a tool with 6 parameters, even if the core ones are touched.

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 it updates text and/or checked status of a checklist item, using the Portuguese verb 'Atualiza' (updates) and specifies the resource as 'item de checklist'. It distinguishes from siblings like add/delete by focusing on update functionality and mentions bulk support via item_ids, which is unique among sibling 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 clear context for when to use the tool: to update text/checked status. It explicitly mentions bulk support ('Bulk support: accepts item_ids for batched execution'), which guides usage for multiple items. However, it does not explicitly state exclusions or alternative tools, so it lacks a strong when-not-to-use directive.

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

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

Annotations already indicate readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds the list-item distinction and bulk support, but does not clarify update semantics (e.g., partial updates, unsafe flag behavior, consequences of omitting fields). It fails to explain the 'unsafe' parameter or the account parameter, leaving significant behavioral ambiguity.

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

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

The description is two sentences: first states the core functionality, second gives a usage guideline for lists and mentions bulk support. Concise and front-loaded with the key 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?

The description provides the core use case but lacks details on edge cases (e.g., unsafe parameter, behavior when fields omitted, return values). The tool has 6 parameters with zero schema descriptionsaint, so the description only partially compensates. The list-item exclusion is helpful, but the bulk feature is only briefly mentioned without specifics.

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 has 0% parameter descriptions. The description explains that title and/or text can be updated)Skip because it mentions 'título e/ou texto' but doesn't mention unsafe or note_ids parameters explicitly (only implicitly via bulk). It does mention bulk via note_ids but doesn't explain how it affects behavior. account is unexplained. So it adds some meaning but not comprehensive.

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 'Atualiza título e/ou texto de uma nota' (Updates title and/or text of a note), clearly specifying the verb and resource. It also distinguishes from list item tools by directing users to use list item tools for list editing, and mentions bulk support via note_ids. This clearly defines the tool's purpose and differentiates it from siblings.

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

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

The description provides a clear exclusion for list items: 'Pra listas, edite os itens com os tools de list item' (For lists, edit items with list item tools). It also mentions bulk support via note_ids. However, it doesn't explicitly state when to use this tool over other note update variants (e.g., when to use keep_set_note_color vs this), though that is implied by focusing on title/text.

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 numerous behavioral traits beyond annotations: invoke works even if the MCP is not installed, returns connect/checkout links for auth/payment, writes require owner/admin, and the one-off install behind invoke doesn't add to toolkit. This is highly transparent and aligns with annotations (readOnlyHint=false, openWorldHint=true).

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 long but well-organized into a coherent narrative. It front-loads the core flow and then explains ancillary actions. While it could be trimmed, the length is justified given the tool's complexity (23 parameters, multiple action categories). No repetitive sentences, and each sentence adds meaningful 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 tool this complex, the description covers all major domains: the MCP discovery/execution flow, auth/payment handling, permissions for writes, and the separate prompt library. It does not detail every parameter (like cancel_reason or limit), but given the absence of output schema and annotations, it provides sufficient operational context for an agent to act correctly. There are minor gaps but overall completeness is high.

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

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

Schema coverage is 0%, so the description must compensate. It does explain the action enum implicitly (search, describe, invariant actions) and mentions 'arguments' for invoke, prompt_body for publishing, etc. However, many parameters (limit, immediate, tier_slug, cancel_reason, etc.) are not individually addressed, and the description never maps parameter names to actions explicitly. It provides high-level context but not per-parameter 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?

The description clearly states the tool is the official mcp.ai marketplace, covering catalog discovery, running tools, and prompt library. It uses specific verbs (search, describe, invoke, install) and distinguishes itself from sibling tools (which are mostly note-taking utilities). The resource is well-defined as 'the in-platform catalog of every MCP/tool, AND the way to run them.'

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 outlines the core flow (search → describe → invoke) and provides when-to-use guidance: prefer invoke for one-off use, install for permanent toolkit addition, and lists subordinate actions (list_tools, subscribe, etc.). It also explains the prompt library usage separately, making it clear when to use those actions.

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 says 'Report a bug, missing feature, or send feedback,' which implies a side-effecting submission action. However, the annotations declare idempotentHint=true, suggesting repeated identical calls are safe and produce no additional effect. This is a contradiction: submitting the same bug report multiple times would plausibly create duplicate reports. The description also fails to disclose post-submission behavior or side effects beyond the schema.

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

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

The description is two concise sentences. The first sentence front-loads the purpose, and the second provides a concrete usage instruction. Every word 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 simple tool with no output schema and no nested objects, the description covers the basic action and one parameter, but it is incomplete: it omits the meaning of the required message parameter, does not explain context, and its behavior contradicts the idempotentHint annotation. The combination of incomplete parameter guidance and the annotation conflict makes the description insufficient for reliable agent 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?

With 0% schema description coverage, the description needed to explain all three parameters. It only addresses the 'conversation' parameter, noting it should contain recent messages for reproduction. The required 'message' parameter and the 'context' parameter are not explained at all, leaving significant semantic gaps.

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 purpose with a specific verb and resource: 'Report a bug, missing feature, or send feedback.' It is immediately distinguishable from all sibling tools, which are primarily Google Keep operations and authentication utilities.

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 makes the intended use context clear: use this tool when encountering a bug, missing feature, or when wanting to send feedback. It does not explicitly mention when not to use it or name alternatives, but no alternative feedback tool exists among siblings, so the guidance is sufficient.

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 aligns with the readOnly and idempotent annotations, and 'Show' clearly indicates no side effects. However, it does not add extra context beyond what annotations already convey, such as specific output format or potential edge cases.

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 function without any unnecessary 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?

Given the simplicity of the tool (no parameters, no output schema), the description sufficiently conveys what it does and what it returns (the versions). It is complete for this trivial use case.

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 no parameters in the schema, so the description has nothing to explain. This dimension is 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 clearly states the action ('Show') and the resource ('MCP platform and adapter versions'), making it specific and distinguishable from sibling tools that perform actions like authenticate, connect, or CRUD operations on notes.

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 tool's purpose is obvious and unique, but the description does not explicitly state when to use it or mention alternatives. It implies usage for checking versions, but lacks explicit context about scenarios or prerequisites.

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 goes beyond the annotations (readOnly, idempotent, non-destructive) by detailing the exact pieces of information returned (installed MCPs, connection status, accounts, catalog tool counts). This adds valuable behavioral context, ensuring the agent knows what to expect without needing to invoke the 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 that efficiently lists the return content without unnecessary detail. It is well-structured and directly to the point.

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?

There is no output schema, but the description fully describes what the return value includes, making the tool's purpose and results clear. It is complete for a simple informational tool without needing additional explanation.

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, and the schema coverage is complete (100%). Since there are no parameters to describe, the description cannot add value in this dimension. Per the rubric, the baseline for high coverage is 3, so this score 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 clearly states the tool returns the current toolkit state with specific details (installed MCPs, connection status, accounts, catalog tool counts), using a specific verb 'Returns' and a distinct resource. It distinguishes itself from sibling tools by focusing on toolkit-level information rather than individual note 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 implies usage for retrieving overall toolkit status, which is self-explanatory. It does not explicitly mention alternatives, but given the nature of the tool as a status/info aggregator, alternatives are not obvious. Lacks explicit when-to-use guidance, but it's adequate.

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