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

No annotations are provided, so the description carries the full behavioral burden. It confirms a write/add operation but says nothing about persistence, duplicate handling, permissions, or what the add returns. For an unannotated mutation tool this is a real gap.

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

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

The purpose sentence is front-loaded and the Args block is compact, one line per parameter. There is little waste, though the Args duplication of the schema is somewhat redundant.

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 3-param tool with no output schema and no annotations, the description covers the inputs but omits behavioral context an agent would want (persistence, return value, duplicate handling). Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description meaningfully compensates by documenting all three params: content ('text to remember'), source (with its 'manual' default), and metadata ('optional key-value metadata'). The metadata entry is thin (no expected keys or format), so it clarifies the basics but not the details.

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

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

States a specific verb ('add') and resource ('manual memory/note') with the target store ('personal memory store'). It is clear what the tool does, though it does not explicitly distinguish itself from the sibling search_memoreei. The word 'manual' implicitly separates it from the many sync_*/import_* 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 term 'manual' implies this is for user-entered notes as opposed to synced or imported data, giving implied usage context. However, there is no explicit when-to-use/when-not-to-use guidance and no alternative tool is named, leaving the agent to infer the boundary against the sync/import 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 declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds one useful behavioral trait, the ordering ('oldest first'), but the clause 'it has hit: true' is opaque and discloses no clear state. With annotations carrying safety, this is an adequate but not rich addition.

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

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

Two short sentences, front-loaded with what it returns and followed by the usage cue; there is little waste. The 'it has hit: true' fragment is the one piece that does not earn its place, keeping it from a 5.

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

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

An output schema exists, so return values need not be re-explained. The description covers what is returned, the ordering, and the chaining scenario, which is sufficient for a 3-parameter read tool, though naming the sibling search tool would fully close the loop.

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 before/after/memory_id are fully documented in the schema itself, including defaults and the 'exactly as given' note. The description adds no parameter syntax or meaning beyond that, so the baseline of 3 is appropriate.

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

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

It states the resource clearly (the messages around one message, in its chat, oldest first), giving an agent enough to know it returns surrounding context rather than a message itself. The lack of an explicit verb and the cryptic trailing clause 'it has hit: true' slightly muddy it, but the core purpose is unambiguous.

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

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

It says exactly when to reach for it: when a search result is relevant but needs the surrounding exchange (the question it answers, the reply, what 'it' refers to). That is a strong chaining cue after a search. No exclusions or explicit sibling name (e.g. search_memoreei) are given, 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?

No annotations exist, so the description carries the full behavioral burden. It does disclose a meaningful trait beyond the schema — that phone numbers and email addresses get mapped to display names — but says nothing about duplicate handling, whether existing contacts are merged or replaced, or what side effects the import has. That is a notable gap for a mutation tool with zero annotation coverage.

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?

Front-loaded with the one-line purpose, followed by a focused export tip and a short Args block. No redundant restatement of the tool name; the macOS export hint is arguably optional but earns its place as practical input guidance.

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

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

For a simple one-parameter import with no output schema, the description covers purpose, input format, and one behavioral detail (name mapping). It omits what happens to pre-existing contacts and where the data lands, which an agent would want before invoking a write 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 schema documents nothing about the single parameter. The description compensates with an Args block clarifying file_path is a path to the .vcf file, adding format meaning beyond the bare 'string' type. It is minimal but fills the coverage 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?

States a specific verb and resource ('Import contacts') plus the exact input format (vCard/.vcf), which distinguishes it from import_csv_file and import_json_file in the sibling set. It stops short of explicitly naming those alternatives, so 4 rather than 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?

Provides a concrete 'how to produce the input' tip (macOS Contacts export path), which is genuinely useful context. However, it gives no guidance on when to use this versus sync_contacts or the other import_* tools, nor any prerequisites or exclusions.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It mentions auto-detection of delimiter and support for headers, but lacks details on error handling, file size limits, duplicate handling, or side effects. The description provides 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 well-structured with a summary line, followed by additional details and parameter documentation. It is efficient but slightly verbose in listing example sources. Most sentences add value.

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

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

Given 5 parameters (2 required) and no output schema, the description covers parameter usage and general behavior. However, it omits details on return values, success/failure indications, and prerequisites. While adequate, it could be more complete.

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

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

The JSON schema has 0% description coverage, but the description's Args section thoroughly explains each parameter, including required ones like content_column and optional like timestamp_column with auto-detection. It adds significant meaning beyond the schema.

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

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

The description clearly states 'Import messages from any CSV file,' specifying the action (import) and resource (messages from CSV). It also lists supported formats and provides examples like LinkedIn exports, differentiating it from sibling import tools for other formats.

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 CSV files and mentions specific sources, but does not explicitly state when to use alternatives (e.g., import_json_file) or provide conditions for not using this tool. Some guidance on exclusion is missing.

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

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

With no annotations, the description carries the full burden. It explains that all messages from all channels and DMs are imported and that both folder and ZIP formats are accepted, but it does not disclose potential side effects like processing time, size limits, or whether the import overwrites existing data.

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

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

The description is extremely concise—four sentences that get straight to the point. It front-loads the purpose, then provides user guidance, and ends with parameter details. No 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?

For a single-parameter tool with no output schema, the description covers the essentials: what it does, how to get the data, and the parameter format. It does not explicitly state the outcome (e.g., that data is added to memory), but sibling names like add_memory provide implicit 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 input schema has 0% description coverage, so the description must compensate. The Args section adds meaning by stating that 'package_path' can be a path to an extracted folder or a ZIP file, clarifying the acceptable formats beyond the schema's minimalist title.

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

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

The description clearly states the verb 'Import' and the resource 'Discord Data Package (GDPR export)', and distinguishes it from sibling tools like import_csv_file or import_messenger by specifying its Discord-specific origin.

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 provides context on how to obtain the data (Discord Settings > Privacy & Safety > Request All of My Data) and notes that both extracted folders and ZIP files are supported. However, it does not explicitly state when to use this tool over alternatives or when not to use it.

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

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

No annotations; description does not disclose side effects (e.g., overwriting, idempotency), relying only on 'import' as a vague action.

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 plus an args line, no wasted words, efficiently conveys purpose and argument.

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?

Covers source format, acquisition steps, and parameter description; lacks error handling and output behavior, but adequate for a single-parameter import 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?

With 0% schema coverage, the description adds valuable meaning by specifying the data_path as the extracted folder containing 'your_instagram_activity/', beyond just type.

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 imports Instagram DMs from a GDPR export in JSON format, specifying verb and resource uniquely among siblings.

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

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

Provides explicit download instructions and argument format, but lacks explicit when-not-to-use or alternative guidance.

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

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

No annotations are provided, so the description carries the burden. It explains what the tool does and parameter roles, but does not disclose whether import is additive or destructive, what happens on failure, or any file size limits. Core behavior is covered, but side effects and error handling are omitted.

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 brief (four sentences plus list), front-loads the core purpose, and uses a clear structure. Every sentence adds value without repetition or 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 5 parameters, no output schema, and no annotations, the description covers purpose, format support, and parameter details. It lacks mention of return value or side effects (e.g., whether data is appended or replaced). Considering complexity, it is mostly complete but misses output 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?

Schema description coverage is 0%, but the description provides full parameter details in an Args section: purpose, required/optional status, and default values. This adds complete meaning beyond the schema, which only lists names and types.

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 imports messages from JSON files, specifies supported formats (arrays, JSON-lines, wrapped objects), and lists example data sources (Google Chat, Hangouts, LinkedIn). It distinguishes from siblings by focusing on generic JSON import rather than platform-specific formats.

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

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

The description implies use for JSON files, especially those from common services, but does not explicitly exclude other formats like CSV (handled by import_csv_file) or state when not to use this tool. It provides context but lacks explicit alternatives or 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?

No annotations are provided, so the description must carry the full burden. It only states that the tool imports messages, but does not disclose side effects (e.g., whether it overwrites existing data, requires authentication, or has rate limits). With no further behavioral context, the description is insufficient.

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 brief (3 sentences) and front-loaded with the purpose. The second sentence provides actionable download instructions, and the third defines the parameter. No redundant information, though the parameter definition could be integrated more seamlessly.

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 import tool with one parameter and no output schema, the description covers the essential aspects: what, format, how to obtain data, and expected input. It does not describe the return value, but this is less critical for a straightforward import operation.

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

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

The input schema has 0% description coverage, but the description adds meaningful context by explaining that 'data_path' should point to the extracted folder containing 'messages/inbox/'. This compensates well for the schema's lack of detail.

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

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

The description specifies exactly what the tool does: import Facebook Messenger messages from a GDPR export in JSON format. It distinguishes itself from sibling import tools (e.g., import_instagram, import_discord_package) by naming the source platform and format.

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?

Provides clear steps for obtaining the required data (Facebook Settings > Download Your Information) and specifies the expected folder structure (messages/inbox/). However, it does not explicitly state when to use this tool over alternatives, though the tool name and context make the context 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?

No annotations are provided, and the description does not disclose behavioral traits such as whether the import is additive, idempotent, or requires specific permissions. The basic action is stated, but deeper behavior is omitted.

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 sentences plus an Args line. The first sentence front-loads the purpose, and every part is necessary. 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 the tool's simplicity (one parameter, no output schema), the description covers the essentials. However, the lack of behavioral transparency and any usage guidance leaves gaps for an agent to fully understand the tool's implications.

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 adds meaning by explaining what 'file_path' is ('Path to the XML backup file'). However, it lacks details like accepted formats, validation rules, or examples, so it only 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 verb 'Import' and the resource 'SMS/MMS messages' from a specific source format (Android SMS Backup & Restore XML). This distinguishes it from sibling import tools for other formats.

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

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

The description implies the tool should be used when users have an Android SMS Backup & Restore XML file, but it does not explicitly state when not to use it or mention alternatives among the many sibling import tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds that results are ordered by message volume and split across people/groups/platforms, but this is essentially return-content detail also covered by the output schema, so it adds limited behavioral context beyond 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?

Two short sentences with zero waste, and the routing constraint is front-loaded in the second line. Nothing redundant or padded.

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

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

With an output schema present, return values need not be explained, and annotations cover safety. The description supplies purpose and usage context adequately, though the meaning of 'sources' relies partly on the annotation title ('List people and chats').

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 'name' (partial match, like participant) and 'limit' (default 30, max 200) are already fully documented in the schema. The description adds no parameter detail beyond it, so the baseline 3 applies.

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

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

The description defines what list_sources returns: the most-messaged people with their chats, busiest group chats, and platforms. It conveys the resource concretely, though it is phrased as a label ('Who is in the archive') rather than a clean verb+resource, and it doesn't explicitly contrast against other listing-type 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?

It states when the tool is NOT needed ('Not needed before searching') and names the alternative that handles the case instead (search_memoreei finds people by name or number itself). This is explicit routing guidance an agent can act on directly.

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

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

No annotations are provided, so the description carries the full disclosure burden. It states the tool triggers an outward-facing sync but never says whether it blocks, how long it takes, whether it is rate-limited, whether re-running is safe, or whether it can fail on unreachable sources — meaningful gaps for a network-triggering operation.

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

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

A single sentence with the action, scope, and outcome front-loaded in that order. No filler, no restatement of the tool name, nothing that could be cut.

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

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

With no output schema, the description usefully compensates by naming the return value ('new message count'). Combined with zero parameters and a stated scope, an agent has enough to call it, though blocking behavior and failure modes remain undocumented and there are no annotations to cover them.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline is 4. The description correctly avoids inventing parameters and instead spends its words on scope and return 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 names a specific action ('Trigger an immediate sync'), its scope ('all configured sources'), and its return value ('new message count'). It is clear what the tool does, but it offers no differentiation from the heavy cluster of sync siblings such as sync_all and sync, which appear to overlap with the same 'sync everything' semantics.

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

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

There is no guidance on when to prefer this over sync_all, sync, or the per-platform sync_* tools. The agent is left to infer that a tool literally named for a product refresh is distinct from the near-identical 'sync all configured sources' siblings, with no exclusions or alternatives stated.

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 the safety profile (readOnlyHint=true, openWorldHint=false), but the description adds genuine behavioral context: results are ranked best-match-first, filters are applied before ranking, and the failure/empty path surfaces an explanatory 'note'. It stops short of mentioning pagination or result-size behavior, but the filter-then-rank ordering and empty-result semantics are substantive additions.

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, front-loaded with the core capability, and no filler. The final sentence ('If results is empty or note is set, note says why and what to try') is slightly convoluted in phrasing but each sentence carries distinct content.

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

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

An output schema exists, so return-value explanation is not required, and the description still cues the 'results'/'note' structure it returns. For a 7-parameter read-only search with full schema coverage, the definition supplies the retrieval semantics an agent needs; only cross-tool routing guidance is absent.

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 every parameter (after, before, source, participant, participant_scope, limit, query) is already documented in the schema, including examples and the enum semantics. The description only speaks of 'filters' generically and adds no syntax or constraint detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Search the owner's messages') and even names the retrieval mode ('by meaning and by keyword, best match first'). No sibling in the tool list performs search, so the purpose is unambiguous without needing to reference an alternative.

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

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

The description explains result/empty behavior ('If results is empty or note is set, note says why and what to try') but never states when to choose this over other tools or any precondition. Usage is implied by the search framing rather than explicitly guided. With a sibling set consisting only of sync/import/add tools, the lack of explicit alternatives is a smaller gap but still a gap.

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 openWorldHint=false, idempotentHint=true, destructiveHint=false and readOnlyHint=false; the description adds real context by spelling out what it touches (all configured connectors plus changed registered import files) and why it is idempotent (only re-reads files that changed since). It stops short of describing runtime behavior such as blocking/duration or the result of a run.

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 short sentences, the core action front-loaded, and each sentence carries distinct information (what it does, which connectors/files, why it takes no arguments). Nothing is wasted.

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

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

For a no-argument tool with no output schema and strong annotations, the description is nearly sufficient: it defines scope, mechanism, and constraints. It could be better if it named the sync_all alternative or hinted at what a run produces (e.g., new-item counts), but nothing essential 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?

There are zero parameters, so the baseline is 4, and the description usefully confirms 'Takes no arguments' and explains why (it can only refresh server-configured sources). No additional param meaning is needed.

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

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

States a specific verb+resource ('Refresh memory from the sources configured on the server') and explains the mechanism (runs every configured connector, re-reads changed import files). However, it never distinguishes itself from the sibling sync_all, which on its face sounds like the same broad operation, leaving the agent to guess which to pick.

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 implies scope with 'it can only refresh what the server's owner has already set up,' which tells the agent this is a config-driven bulk refresh, but gives no explicit when-to-use versus the many alternatives (sync_all, sync_discord, sync_telegram, etc.). Usage is inferable but not directed.

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

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

No annotations are provided, so the description must fully disclose behavior. It mentions syncing each connector but does not discuss potential side effects, error handling, or whether the operation is idempotent.

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

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

The description is two sentences long, front-loaded with the main purpose, and each sentence adds value without 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 no input schema and no output schema, the description provides essential context: iterates over configured connectors and returns counts. It could mention behavior on failure or ordering, but is fairly complete for a batch sync command.

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

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

The tool has zero parameters, and the input schema is empty. The description adds no parameter information, which is acceptable since none are needed. Baseline for 0 params is 4.

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

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

The description clearly states the action ('sync every configured connector') and output ('return counts per source'), listing specific connector types, which differentiates it from individual sync 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 implies usage when syncing all configured connectors is desired, and the sibling tools provide clear alternatives for individual syncs. However, it does not explicitly state when not to use or any 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the source, target table, name-mapping behavior, and platform-specific empty-result behavior, but it does not say whether existing contacts are overwritten or merged, whether permissions are required, or how repeated syncs behave.

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 action, and structured into purpose, mapping effect, and platform caveat. Every sentence adds useful information without repetition.

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

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

For a parameterless sync tool with no output schema and no annotations, the description covers the source, target, mapping effect, and platform behavior. It leaves some mutation semantics unstated, but it is nearly complete 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?

The tool takes zero parameters, so there are no parameter semantics to clarify. The schema coverage is listed at 100%, and the description correctly adds no unnecessary parameter detail beyond the tool's operation.

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

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

The description names a specific verb (sync), resource (contacts), and source (macOS AddressBook), and states the effect of writing into the contacts table. It is clearly distinguishable from generic sync siblings by its macOS-specific source, though it does not explicitly contrast itself with import_contacts_vcf or other contact-import 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 gives an implied usage context: syncing native macOS AddressBook contacts. It also states a platform constraint (macOS only; empty result elsewhere). However, it never says when to choose this over siblings such as import_contacts_vcf, nor does it describe prerequisites or exclusions beyond the platform 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?

No annotations are provided, so the description must carry full behavioral burden. It only says 'sync' without disclosing traits like read/write nature, rate limits, permissions, or impact on state. Minimal 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 (two lines) and front-loaded with purpose. Every word adds value.

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

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

Given a simple tool with 1 optional param and no output schema, the description covers purpose and parameter usage. However, it omits return value, behavior (does it store or just fetch?), and interaction with the configured channel. Adequate but not fully complete.

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

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

With 0% schema description coverage, the description compensates by explaining that channel_id is a Discord channel ID and can default from an env var. This adds meaning beyond the schema's type and default.

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 syncs recent Discord messages from a configured channel, which is a specific verb and resource. However, among many sync siblings (sync_email, sync_slack, etc.), it does not differentiate beyond the platform name.

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 vs alternatives (e.g., sync_all, import_discord_package). The description does not provide prerequisites, when-not-to-use, or 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?

With no annotations provided, the description carries the full burden. It discloses the per-folder UID checkpoint (indicating incremental sync), required environment variables, and the default folder. It does not hide any side effects.

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

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

The description is divided into a one-sentence summary, a behavioral paragraph, environment variable requirements, and an Args section. Every sentence adds value and there is no redundancy.

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

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

Given the simplicity of the tool (2 parameters, no output schema), the description covers all necessary aspects: purpose, behavior (UID checkpoint), prerequisites (env vars), and parameter details. It leaves no ambiguity.

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

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

The input schema provides only type and default for folder and max_emails. The description adds meaningful context: folder options with examples like '[Gmail]/Sent Mail', and max_emails as a cap per sync. This fully compensates for the missing schema descriptions.

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 starts with 'Sync Gmail messages into memory via IMAP.', clearly stating the verb (sync), resource (Gmail messages), and mechanism (IMAP). It distinguishes itself from sibling sync tools (e.g., sync_slack, sync_discord) by targeting email, specifically Gmail.

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 mentions that it fetches emails from a Gmail folder and stores them for search, and explains that it uses a UID checkpoint to avoid re-ingesting. It does not explicitly state when not to use it, but the context is clear for Gmail email syncing.

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 behavioral burden and does so well: it discloses read-only access, platform restriction ('returns an error dict on other platforms without raising'), the Full Disk Access prerequisite, and the IMESSAGE_DB_PATH override. It omits idempotency/incremental behavior and whether existing synced data is replaced, which for a sync tool would matter.

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?

Front-loaded with the core purpose, then platform/prerequisite details, then the argument. Every sentence carries information, though the Full Disk Access sentence is somewhat long and the parenthetical remediation command is more operational than agent-facing.

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

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

For a single-optional-param tool with no output schema, the definition covers platform, prerequisites, path override, and filter semantics adequately. The return shape is only hinted at ('error dict'), so an agent has a mild gap on what a successful sync produces, but nothing critical is missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: chat_name is explained as an optional filter matching against chat_identifier (with the '+1234567890' example) or display name. This adds real matching semantics the bare 'Chat Name' property name does not convey.

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 ('Sync iMessage/SMS conversations from the local macOS Messages database') and names the exact data source (chat.db). It clearly distinguishes itself from siblings like sync_signal, sync_telegram, and import_sms_backup by anchoring to the local macOS Messages store rather than another provider or an import path.

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

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

It gives clear operational context: macOS-only, read-only, and the Full Disk Access requirement with a concrete remediation command. It does not, however, tell the agent when to prefer this over sync_all or import_sms_backup, so the alternative-selection guidance is implied rather than stated.

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 burden. It covers authentication but fails to disclose critical behavioral traits such as whether syncing overwrites or appends to existing memory, potential rate limits, or error handling. The term 'sync' is ambiguous regarding side effects.

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

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

The description is well-structured with sections (purpose, API details, environment, Args). Every sentence adds value, though it could be slightly more concise by merging the environment and args sections.

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 authentication and parameter details but lacks information on the sync behavior (e.g., does it merge or replace?), error handling, and rate limits. Given that no output schema exists and the tool imports external data, these gaps reduce 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?

Despite 0% schema description coverage, the description thoroughly explains each parameter in the Args section, including defaults and environment variable fallbacks. This adds significant meaning beyond the bare JSON Schema, though it could be more precise about input formats.

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 ('sync'), resource ('Mastodon posts'), and scope ('recent', 'public or hashtag timeline'), making the purpose specific and unambiguous. It distinguishes from sibling tools by explicitly mentioning 'Mastodon', which is unique among the listed 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 on authentication requirements (public/hashtag vs home/private) and environment variable alternatives. While it doesn't explicitly say when to use this tool over alternatives (e.g., sync_all), the sibling tools are clearly for different platforms, so usage is implied.

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?

Without annotations, the description carries the burden of behavioral disclosure. It reveals the use of a pagination token to avoid re-ingesting and the need for environment variables. However, it does not mention potential side effects, idempotency, rate limits, or authorization requirements beyond token provision.

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 well-organized with a purpose paragraph and an Args section. It is concise at 8 lines but repeats the environment variable information slightly. The structure is front-loaded with the core action.

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

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

Given the low complexity (one optional param, no output schema, no annotations), the description covers the main aspects: purpose, parameter, prerequisites (env vars), and internal mechanism (pagination token). It is complete enough for an agent to use, though it omits details like message limits or rate limits.

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 minimal structure (one optional parameter with title only). The description adds critical meaning: the parameter format (example Matrix ID), fallback to environment variable, and default behavior. This fully compensates for the 0% schema description 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 (sync Matrix room messages) and the resource (messages stored for search). It distinguishes itself from sibling sync tools by naming the platform 'Matrix', but does not explicitly differentiate its behavior or use case from 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 mentions required environment variables and optional room_id, but provides no guidance on when to use this tool instead of alternatives like sync_slack or sync_discord. There is no indication of prerequisites or when not to use it.

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

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

With no annotations, the description carries the full burden and does so well. It discloses the required Signal connection and keyring read, exactly what data is kept (texts, captions, links, group changes, calls), how reactions/edits are handled, and that disappearing messages are never stored.

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 three tight sentences: purpose first, then prerequisite/setup, then retention behavior. Every sentence adds useful information and there is no filler or repetition.

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 no parameters, no output schema, and no annotations, the description covers purpose, setup requirements, and data handling policies thoroughly. An agent has enough context to know when and how to invoke it without needing additional structured fields.

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

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

The tool takes zero parameters, so there are no parameter semantics for the description to clarify. The baseline for a parameterless tool is 4, and the description appropriately does not invent or omit parameter details.

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

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

The description states a specific verb and resource: 'Sync Signal from Signal Desktop's database on this computer.' It names the source platform and local database, which distinguishes it from sibling sync tools for WhatsApp, Discord, Telegram, etc. without 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?

It gives a clear prerequisite: Signal must be connected first via the dashboard Sources page or `memoreei setup signal`. This tells the agent when the tool can actually be used, but it does not explicitly contrast this tool with alternatives like sync_all or other sync_* tools.

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

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

No annotations; description mentions API usage and scopes but omits behavior on errors, rate limits, or whether it's read-only (though implied).

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?

Concise, well-structured with clear lead sentence and Args section; no extraneous content.

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

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

Covers parameter and requirements but lacks description of return value or side effects (only says 'into memory').

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?

Adds complete meaning to the single parameter with type, example, and fallback behavior, compensating for 0% 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?

Description clearly states it syncs recent Slack messages into memory, distinguishes from siblings by specifying Slack and using Slack Web API.

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?

Provides prerequisites (scopes, env vars) but lacks explicit guidance on when to use vs alternatives (e.g., sync_all) or when not to use.

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?

Description discloses core behavior: uses getUpdates, syncs since last sync, requires token, and filters by chat_id. However, it lacks details on side effects (e.g., memory updates, deduplication), idempotency, error handling, or rate limits. Without annotations, the description carries the burden but covers only essential mechanics.

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 structured with a clear purpose line, technical details, and an argument section. It is reasonably concise but could tighten the arg description into fewer sentences. 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 no output schema and no annotations, the description explains the tool's operation and parameter adequately but misses output behavior or return value. It does not mention what the tool returns (e.g., count of synced messages) or error scenarios. Sibling tools might have similar gaps, but for a mutating sync tool, more completeness would help.

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 significant meaning beyond the schema: explains chat_id sign convention (positive DM, negative group), default behavior (syncs all chats if omitted), and environment variable fallback (TELEGRAM_CHAT_ID). Schema coverage is 0%, so this full explanation compensates completely.

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 clearly states 'Sync new Telegram messages received by the bot into memory,' providing a specific verb (sync), resource (Telegram messages), and scope (new messages received by bot). It distinguishes from siblings like sync_discord by explicitly naming Telegram and the bot-specific nature.

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

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

No explicit guidance on when to use this tool vs alternatives (e.g., import_telegram, other sync tools). It mentions a prerequisite (TELEGRAM_BOT_TOKEN) but does not specify exclusion criteria or recommend alternatives for different use cases.

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

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

With no annotations, the description carries the full behavioral burden and does notable work: it discloses read-only access to ChatStorage.sqlite, the WHATSAPP_DB_PATH override, the iPhone-backup case, and exactly which content is retained versus dropped. It omits dedup/repeat-sync behavior and any auth or rate-limit notes, keeping it below a 5.

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?

Front-loads the purpose, then the data source, then the retention rule. Every clause carries information, though the kept/dropped enumeration is slightly verbose for a 0-param 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?

For a parameterless sync tool with no annotations and no output schema, the description covers source selection and retention policy well. It stops short of saying where synced chats land or how repeat runs behave, which would complete the 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?

The tool takes zero parameters, so there is no parameter surface to document; the baseline for a no-param tool is 4. The description usefully explains the implicit input (WHATSAPP_DB_PATH or the default Mac database) even though no schema field exists for it.

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

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

States a specific verb and resource (sync WhatsApp chats) and pins the source precisely: WhatsApp for Mac's database on this machine. Among a large family of sync_* and import_* siblings, naming the exact source distinguishes it clearly.

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

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

Usage is implied by the source-specific phrasing, but the description never states when to pick this over siblings like import_messenger or sync_imessage, nor any prerequisites such as WhatsApp for Mac being installed or an iPhone backup existing. Adequate but leaves the when-to-use decision to inference.

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