noticed

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds significant behavioral context: it clarifies the target/first record survives and the user's own person always survives, notes reversibility (admin can undo), and explains the needs-confirmation response with a token, including the instruction not to pre-set the token. These details go well beyond the 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 long but information-dense, with the core purpose and identification options up front, followed by behavioral caveats. Every sentence contributes meaningful guidance, but the density makes it slightly harder to parse quickly. It is well-structured overall.

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 complex merge operation with a destructive hint, the description covers all essential aspects: identification methods, survival rules, reversibility, the confirmation flow with token, and the admin-only restriction for verified sign-ins. The output schema exists, so return values need not be explained. Nothing critical is missing.

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

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

The schema covers 100% of parameters, but the description adds valuable usage semantics: which combination of parameters to use (candidate_id vs person_a+b vs profile_a+b), that profile_a+b is for the email→person queue where candidate_id is null, and the confirmation_token usage. This enhances the schema descriptions rather than simply repeating them.

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

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

The description states the verb 'Accept' and the resource 'a PENDING identity match' with the outcome 'merge the two records into one'. It clearly differentiates from sibling tools like dismiss_identity_match (reject) and mark_different_people (mark as different) by specifying the merge 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?

It explains when to use it (for a pending match), how to identify the match (candidate_id, person_a+b, or profile_a+b with a note on which queue), and the confirmation flow when conflicting evidence exists. It also mentions admin-only for verified-sign-in conflicts. It does not explicitly name sibling alternatives like dismiss_identity_match, but the context is clear 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 declare destructiveHint=true and idempotentHint=false, so mutability is covered. The description adds behavioral clarity by specifying the effect: 'A suggested add becomes a member; a suggested removal is removed.' This goes beyond annotations by clarifying the actual outcome of the operation, which is useful context for the agent.

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

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

The description is two sentences with no redundancy. It leads with the core purpose, then clarifies the two possible outcomes. Every word earns its place; it is concise and well-structured.

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

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

Given the tool's simplicity, the output schema (which defines return values), and the annotations covering safety, the description is complete. It covers the action, the scope ('one pending'), and the result. There is no missing information needed to call the tool correctly.

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

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

Schema description coverage is 100% for all three parameters (list_id, list_name, person_id) with explanations for each. The description does not add any parameter-specific guidance beyond what the schema already states. Since the schema fully documents the parameters, the baseline of 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 clearly states the action: 'Accept one pending add/remove suggestion for a list.' It specifies the resource (a pending suggestion on a list) and distinguishes the outcome for adds vs. removals. This differentiates it from sibling tools like reject_list_suggestion, add_to_list, and remove_from_list by focusing on accepting a suggestion rather than directly modifying membership or rejecting.

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 context: it is for accepting pending suggestions on a list. However, it does not explicitly name alternatives or provide when-not-to-use guidance. For instance, it does not mention that reject_list_suggestion should be used instead to decline, or that add_to_list/remove_from_list are for direct actions. The guidance is adequate but not explicit about 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only nature is covered. The description adds useful behavioral context by listing the possible connection/sync states and specifying the two session contexts (browser extension and iOS embedded-browser), which goes beyond the annotations without contradicting them.

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

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

The description is two sentences with no filler. The action ('Check connected accounts') is front-loaded, followed immediately by the intended use case and the specific statuses. Every clause 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 zero-parameter, read-only status check with an output schema present, the description is fully sufficient. It states what is checked, which platforms are covered, and the kinds of states the agent should look for, so no critical information is missing.

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

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

The tool has zero parameters, so there is no parameter semantics burden on the description. A score of 4 is the baseline for a no-parameter tool, and the description does not need to compensate for any schema 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 uses a specific verb ('Check') and resource ('connected accounts across the noticed browser extension and native iOS embedded-browser sessions'), and it names the specific platforms (LinkedIn and X). It is clear in what it does, but it does not explicitly distinguish itself from the similar sibling tool 'get_connected_source_status', which may be the per-source counterpart.

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 includes an explicit usage directive: 'Use this to see whether LinkedIn and X are connected, pairing, syncing, synced, partially synced, or need attention.' This tells the agent when to invoke it, but it does not mention when not to use it or mention alternatives like 'get_connected_source_status' or 'sync_connected_source'.

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 communicate that this is a write operation (readOnlyHint false), non-destructive (destructiveHint false), and idempotent (idempotentHint true). The description adds valuable context: memories are stored in relationship.memories, can be linked via @mention, and are read via get_person. It doesn't contradict annotations. Slightly more detail on idempotent behavior could elevate it, but it's already strong.

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?

Though a bit longer than typical, every sentence earns its place. It front-loads the core purpose, then immediately gives alternatives, linking behavior, retrieval method, and the general-fact case. There is no fluff or redundancy; the structure is logical and easy to parse.

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

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

Given the tool's complexity (5 params, 2 required) and an output schema, the description covers everything an agent needs for correct invocation: definition, distinguishing rules, linking via @mention, retrieval path, and alternative tool usage. The existence of an output schema covers return value expectations, so 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 100%, so all five parameters are documented in the schema itself. The description adds limited new meaning—it reinforces that @mention in content links to your network, but this is also in the schema. Since the schema does the heavy lifting, the description adds marginal value, aligning with the baseline score of 3.

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 verb and resource: 'Save a MEMORY about a SPECIFIC person'. It further distinguishes its purpose from siblings by defining what constitutes a memory (something you inferred, not user-told) and explicitly names add_note and memory_save as alternatives. This makes the tool's role unmistakable.

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 explicit when-to-use and when-not-to-use guidance. It states: 'If the user ASKED you to remember it, it's their note, not your memory — use add_note' and 'For a general fact not about one person, use memory_save instead.' It also tells how to read memories back via get_person. This leaves no ambiguity about selecting 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 declare readOnlyHint=false and destructiveHint=false, setting the write-safety profile. The description adds behavioral context: 'The note is theirs; you're just the keyboard' clarifies authorship, and 'Read them back via get_person' explains how the note is retrieved. It does not contradict annotations and adds useful nuance 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 slightly longer than minimal but every sentence adds value: examples, differentiation, and omission guidance are all present. It front-loads the primary action and uses plain language, making it easy to parse without 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 moderate complexity, full schema coverage, and an existing output schema signal, the description covers when to use it, how to anchor data (occurred_at), how to link people (@mention), and how to retrieve notes. No critical guidance is missing for correct invocation.

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

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

Schema coverage is 100%, so all params are documented, but the description enriches meaning: it explains @mention usage in content, clarifies occurred_at as the date the note refers to with a practical example, and specifies captured_via for skill-driven writes. This exceeds the baseline of 3 by adding usage context.

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

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

The description clearly states 'Write a NOTE on a person's record' with a specific verb and resource, and explicitly differentiates from add_memory by contrasting user-provided content versus agent-derived reasoning. The examples ('remember Rita prefers async') make the scope 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 gives explicit when-to-use: 'whenever they ask you to remember, note, or jot something down' and when-not-to-use: 'If YOU worked something out on your own... use add_memory.' It also mentions alternative read-back via get_person, covering the full usage lifecycle.

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 details the behavior in two scenarios: existing profile (matches and merges with admin hold) and new profile (queues to fetch and enrich). This goes beyond the basic readOnly/destructive hints, providing transparency about potential actions and outcomes.

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

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

The description is reasonably concise but includes some redundancy (e.g., repeating 'Give noticed' and 'Pass person_id + the url'). It is structured with action, parameters, behavior, and usage. Could be tightened but is not excessively verbose.

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

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

The description covers the purpose, usage conditions, expected behavior in different scenarios, and explicitly distinguishes from alternatives. It is comprehensive for the tool's functionality, and the presence of an output schema means return value details are not required in the description.

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

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

While the schema provides clear descriptions for both parameters, the tool description reinforces the intended context (contact missing a profile) and reiterates the requirement to provide both. It adds a slight semantic nuance but not significantly 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 explicitly states the action (adding a profile via URL) and the target (contact missing a profile). It also clarifies the intended use case (enrich thin contact) and distinguishes from alternatives.

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

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

The description provides explicit guidance on when to use this tool (for enriching a thin contact) and when not to (for merging existing records, pointing to accept_identity_match / suggest_identity_match). It also references list_profile_gaps context.

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

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

The description discloses idempotency and the confirmation side-effect, which goes beyond the annotations (idempotentHint: true). It adds valuable behavioral details that are not obvious from the tool name or schema. However, it doesn't mention error cases or authorization requirements, but given the annotations already cover readOnlyHint and destructiveHint, this is sufficient.

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: two sentences that front-load the core action and the key side-effects (idempotent, confirmation) before parameter selection details. Every sentence adds value, and there is no 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 availability of output schema and full parameter documentation, the description is well-rounded. It covers the core behavior, side-effects, and parameter selection logic. It could mention what happens if the list is not found, but that is a minor gap given the schema and the existence of list_lists for reference. The description is complete enough for an agent to call this tool correctly.

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

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

The schema coverage is 100%, describing each parameter and its source. The description adds the clarification that list_id and list_name are mutually exclusive alternatives ('Pass this OR list_name'). This adds meaning beyond the schema descriptions, which already are detailed. The description doesn't add anything about person_id beyond what the schema says, but the schema is sufficient, so a 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?

The description clearly states the action ('Put a person on a list') with a specific verb and resource, and distinguishes it from alternatives like remove_from_list and accept_list_suggestion. It also notes the idempotent behavior and the confirmation side-effect, which is a clear differentiator from similarly named 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?

Explicitly says to identify the list by list_id or list_name, and the person by person_id from specific source tools (search_people/resolve_person). While it doesn't explicitly say when not to use it, the clear mention of alternatives (e.g., accept_list_suggestion) and the confirmation behavior provides strong usage context. The description implies that if a person is merely suggested, this tool confirms them, which guides the agent on when to use this versus accept_list_suggestion.

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 significant behavioral nuance beyond the annotations: the dedupe mechanism (returns created:false, potential_duplicates, and confirmation_token instead of creating), the condition to re-call with confirmation_token only for genuinely new people, and that relationship_types outside the closed set are dropped. It also states the return of a canonical person_id. These details are critical for correct invocation and are not evident from annotations alone.

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 dense yet efficient. It front-loads the core purpose, then methodically covers modes, parameters, return value, and dedupe behavior. Every sentence contributes unique information without redundancy, and the structure guides the agent from selection to invocation to edge-case handling.

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 6 parameters, a nested object, an output schema, and non-trivial dedupe behavior, the description covers all necessary aspects: input mode selection, parameter relationships, validation rules, return values, and the confirmation flow. The presence of an output schema means return-value details need not be spelled out, yet the description still highlights the canonical person_id. 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?

Despite 100% schema coverage, the description adds crucial semantic context: it clarifies that person_id and free_form are mutually exclusive (OR), explains the confirmation_token's role in the dedupe flow, and positions relationship_types as settable at add time. This goes beyond the schema's individual parameter descriptions and directly facilitates correct usage.

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 clear verb and resource: 'Add someone to your network.' It then distinguishes two modes — known persons via person_id become tracked, while new contacts are created/imported and tracked. This precisely scopes the tool and differentiates it from siblings like update_person and remove_from_network.

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

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

It explicitly states when to use each input mode: use person_id for known search_people hits, free_form for brand-new contacts. It also notes that relationship_types can be set at add time, eliminating a follow-up update_person call. While it doesn't name alternative tools directly, the contextual cues (e.g., 'no follow-up update_person needed') effectively guide selection. A slightly more explicit exclusion of update_person for relationship settings would push this to 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?

The description aligns with the annotations (readOnlyHint=false, idempotentHint=true) without contradiction. It does not add extra detail about side effects or idempotency beyond what annotations already convey, but the action is simple and well-covered.

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

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

Two short sentences, directly stating the purpose and providing a source for the parameter. No fluff or redundant information.

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

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

For a simple one-parameter action, the description is complete. It covers what to do and where to get the ID. No output schema is given, so return values need not be explained.

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

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

The schema only says 'The action to complete', but the description adds valuable context: 'Get the action_id from get_person (relationship.actions)'. This enriches the parameter meaning significantly.

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 'mark' and the resource 'follow-up / action done', making the tool's purpose unambiguous. It distinguishes itself from siblings like update_action and delete_action by focusing on the 'complete' action.

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

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

The description provides a specific usage hint: 'Get the action_id from get_person (relationship.actions)', guiding where to source the ID. It does not explicitly contrast with alternatives like update_action, but the purpose is clear enough for typical 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?

Annotations only indicate non-readOnly, non-idempotent, non-destructive hints. The description adds substantial behavioral context beyond that: it explains the @mention linking mechanism, the Team-visible relationship nuance, and the semantics of recommended optional fields (assigned_to, remind_at). It effectively communicates the side effects and constraints of the operation without contradicting any 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 front-loaded with the core purpose, then progressively covers team context, recommendations, and alternative actions. Every sentence adds essential information—there is no filler. The structured flow makes it easy to parse and act on, and the final sentence routes to related tools 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?

Despite the tool's moderate complexity (6 params, multiple contexts, sibling interactions), the description covers the full invocation surface: what it creates, how to use it in Team vs. personal context, which options are recommended vs. optional, how @mentions work, and how to handle the created action afterward (read/close/edit). The output schema exists, so return values need no explanation. Nothing an agent needs to call it correctly is missing.

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

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

All parameters already have schema descriptions (100% coverage), but the description enriches them meaningfully. It clarifies the relationship between team_id and assigned_to ('Required with assigned_to; connected Team chats supply it automatically'), defines the @mention behavior in content, and marks remind_at as 'RECOMMENDED' with a categorical reason ('Omit only for genuinely open-ended work'). This goes well 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 opens with a specific verb+resource: 'Create a follow-up tied to a person — a to-do for the relationship.' It clearly distinguishes this tool from siblings by naming complete_action and update_action for closing and editing, and it gives concrete examples ('send the deck', 'intro to Ana'). The purpose is unmistakable.

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 explicit guidance on when to use this tool and when to use alternatives: 'Read open ones via get_person', 'close them with complete_action or edit them with update_action.' It also covers the Team context condition (when to pass team_id and assigned_to) and recommends when to include certain fields, leaving no ambiguity about the decision process.

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 only indicate non-readOnly, non-idempotent behavior. The description goes beyond that by disclosing the full workflow: noticed proposes people from the network and the user confirms/rejects each one. It also states the return value (list_id) and the auto-generation of the title, providing transparent behavioral context that annotations do not.

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 moderately long but each sentence serves a purpose: it defines purpose, stresses the criticality of the description, explains the matching flow, and mentions the auto-title. It is front-loaded with the core purpose and does not ramble, though it could be tightened slightly.

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 create operation with an output schema and complete parameter documentation, the description supplies everything an agent needs: the purpose, the required parameter's semantics, the optional parameters' behavior, the workflow, and the return value. No essential information 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 coverage is 100%, but the description adds meaning: it explains why the description parameter is required and what happens if it is vague, and it reiterates the auto-title behavior for the name parameter. This goes beyond the schema's own property descriptions and helps the agent craft effective input.

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 clear verb-resource pair ('Create a list') and defines what a list is ('a described set of people'), distinguishing it from sibling tools like add_to_list (which adds to an existing list) and delete_list. The resource and action are unambiguous.

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

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

The description gives strong guidance on how to write the required description parameter (be specific, as it drives matching) and mentions that name is optional because the title auto-generates. It does not explicitly contrast with alternatives, but the create action is self-evident and the context is 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?

The description adds meaningful side-effect context beyond annotations: every occurrence creates a new noticed chat and runs the same prompt. It also discloses formatting constraints such as future timestamps, a 60000 ms minimum, and cron-part counts. This is helpful behavioral detail even though the annotations already indicate this is a non-read-only, non-idempotent mutation.

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 sentences with no filler. It front-loads the core purpose and packs the critical schedule encoding rules into the remaining sentences, making it easy to scan and apply.

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 scheduling semantics well and there is an output schema so return values do not need to be explained. Still, it does not address timezone handling, the enabled flag's default behavior, or how the three schedule kinds interact with timezone, which are meaningful gaps for a scheduled-task creation 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 only 17% schema description coverage, the description must compensate, and it does for the most complex parameter: schedule_value. It precisely explains ISO timestamps for 'at', milliseconds for 'every', and 5-6 part cron expressions for 'cron'. However, timezone and enabled parameters receive no semantic guidance, leaving a small but notable 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 creates a recurring scheduled task and specifies that each occurrence runs the same prompt in a new noticed chat, distinguishing it from update/list/delete siblings. The phrase 'noticed agent work' is somewhat jargon-heavy, which prevents 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?

The description implies this tool is for creating recurring scheduled work, but it never explicitly tells the agent when to use this tool versus update_scheduled_task or delete_scheduled_task. The schedule-format guidance is useful but is parameter-level guidance, not tool-selection 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?

Annotations provide only false hints (readOnlyHint, idempotentHint, destructiveHint), so the description carries most of the behavioral disclosure burden. It states the view is 'saved' and 'live', implying persistence and real-time effects, but does not mention uniqueness constraints, overwrite behavior, permission requirements, or side effects. This is adequate but not comprehensive for a creation 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?

Two sentences with no fluff. The primary purpose is front-loaded in the first sentence, and the second sentence enumerates the definition's components without redundancy. Every word contributes value, making it highly efficient for an agent to parse.

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

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

Given the tool's complexity (nested definition object) and that an output schema exists (so return values are handled separately), the description covers the key aspects of what the view is and what it contains. It does not detail prerequisites like team membership or naming rules, but these are partially addressed by the schema (e.g., name optional). The description is nearly complete for an agent to understand the tool's role, though a mention of when team vs personal is chosen could add clarity.

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 75% (below the high threshold), so the description should add meaning beyond the schema. It does: it lists the components of the 'definition' object (search, filters, sort, Team-member filters, relationship types, visible columns) and clarifies 'personal or Team network' for organization_id. This gives the agent a conceptual map of what the definition parameter contains, supplementing the schema's structural 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 begins with a specific verb ('Create') and a clear resource ('saved live View'), then scopes it to 'personal or Team network'. It distinguishes this from sibling tools like update_view, delete_view, and get_view, making the tool's role unambiguous. The enumeration of what the definition stores further clarifies its purpose 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?

The verb 'Create' and the context of a 'saved live View' clearly indicate this is for creating new views, while siblings like update_view and delete_view exist for modifications and removals. However, the description does not explicitly mention alternatives or state when not to use this tool, leaving the differentiation largely to inference.

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

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

Annotations already declare destructiveHint=true, but the description adds critical nuance: it removes the row outright and does NOT stamp a completion, contrasting with complete_action. This behavioral detail goes beyond the annotations and prevents misuse.

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 four sentences are concise, front-load the core action, and each serves a distinct purpose: definition, irreversibility, alternative, and ID source. No fluff 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?

For a single-parameter destructive tool with an output schema, the description covers all necessary information: what it does, when to use, how to obtain the ID, and the alternative. Nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100%, and the schema's description for action_id already includes the source (get_person → relationship.actions or list_actions). The tool description repeats this exactly without adding new semantic information, so it adds no 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 clearly states the tool performs a permanent delete of an action, specifying the resource and operation. It distinguishes from complete_action by noting it's for actions that should not exist, making its purpose unambiguous even among 40+ 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?

It explicitly tells the agent when to use this tool (mistake, duplicate, irrelevant) and when not to (if follow-up happened, use complete_action). It also provides the source for action_id, giving complete actionable 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?

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds meaningful context: it deletes 'its membership/suggestion ledger' and explicitly states 'People remain in the network'. This goes beyond the annotations by explaining what exactly is destroyed and what is preserved. No contradiction with annotations (both indicate a write/destructive operation).

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

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

The description is three short sentences: purpose, key side-effect, and identification method. It is front-loaded with the primary action, then adds crucial non-destructive context, then parameter guidance. No filler words; 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?

The description covers the essential aspects for a delete operation: what is deleted, what is preserved, and how to identify the target. It does not mention any prerequisites like permissions or confirmation, but given the annotations already flag destructive behavior and the tool has an output schema, this is sufficient. It could have mentioned alternatives but that is not necessary for correct invocation.

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

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

Schema coverage is 100% and each parameter already has a description. The description adds the instruction 'unambiguous list_name', which is a useful semantic constraint not present in the schema (the schema only says 'matched case-insensitively'). It also reinforces the OR relationship between the two parameters. This adds value beyond the schema, so a score above baseline is warranted.

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 ('delete') and resource ('list'), and clarifies the scope: 'its membership/suggestion ledger'. This distinguishes it from other delete tools like delete_action and delete_view. It also clarifies that 'People remain in the network', which differentiates from deleting people. The purpose is unambiguous and distinct 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 gives useful context for when to use this tool: to delete a list and its ledger, while noting that people are not removed. However, it does not explicitly mention alternatives like remove_from_list for just removing a member, or reject_list_suggestion for discarding a suggestion. It implies the use case but does not explicitly route away from those alternatives. Still, it provides enough context for an agent to understand the intent.

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 flag destructiveHint:true, but the description adds important context that the deletion is permanent and that run history is also destroyed. This goes beyond what annotations alone convey and is consistent with idempotentHint:false.

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

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

Two short sentences with no wasted words. The core action is front-loaded, and the alternative usage is provided in a compact second sentence.

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

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

For a one-parameter destructive tool with annotations and an output schema, the description covers the essential facts: action, permanence, destroyed run history, and the pause alternative. The unexplained 'noticed' terminology and unstated id semantics are minor gaps, but the overall context is sufficient for safe 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 needed to explain the id parameter, but it never does. The agent must infer from the tool name that id identifies the scheduled task. The single obviously named parameter mitigates the gap, but the description still fails to explicitly add meaning beyond the schema.

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

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

The description states a specific action ('Permanently delete') on a specific resource ('one noticed agent task') and its run history, which clearly conveys what the tool does. It also distinguishes itself from update_scheduled_task by contrasting deletion with pausing. The unusual wording 'noticed agent task' is a minor blemish but does not obscure the core 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 explicitly says to use update_scheduled_task with enabled:false when the goal is to pause rather than delete. This gives the agent a clear routing rule between sibling tools and specifies when not to invoke 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?

The description clarifies that the operation is non-cascading and permanent, which is critical behavioral information beyond what the annotations provide. However, it doesn't mention failure cases, return behavior, or idempotency, which would be relevant for a destructive operation.

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

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

Two short, dense sentences with minimal fluff. Every word contributes to the meaning, and the key qualifiers (typo: 'only') are front-loaded.

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

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

For a simple two-parameter destructive operation, the description covers the essential context needed to understand its scope and side effects. A couple of minor aspects (e.g., what happens on success, idempotency) are already covered by the presence of an output schema and the annotations, so they aren't critical 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?

The description doesn't add to the parameter-level descriptions already present in the schema, but the schema is 100% complete with descriptions like "The View id. Pass this OR view_name." and "The View name, matched case-insensitively. Pass this OR view_id." The description is largely redundant with the schema, so it adds no new parameter-level context.

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

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

"Permanently delete a Saved View" provides an explicit, specific verb and resource, going beyond the title and generic name. It clearly communicates the destructive nature and the object of the operation.

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 clarifies the scope of the deletion ("only the saved definition"), but it doesn't explicitly contrast with sibling operations like update_view, create_view, or get_view. It lacks explicit 'use when' or 'use instead of' guidance, relying on the reader to infer when to choose 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=false, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral nuance: dismissal is a soft reject, it does NOT assert the two are different people, and the system may re-propose the pair later. This goes beyond what annotations convey.

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, no filler, purpose front-loaded. The first sentence states action and effect; the second adds the key behavioral caveat; the third covers identification methods and the alternative. 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?

With five optional parameters and no required fields in the schema, the description correctly explains the mutually exclusive identification methods and the review-queue scenario. It gives enough context for the soft-reject behavior and names the permanent alternative. A minor gap is not explicitly referencing accept_identity_match, but the output schema and sibling list help fill that.

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

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

Schema coverage is 100% and each parameter has a description, but the description adds the crucial grouping logic: one of candidate_id, person_a+person_b, or profile_a+profile_b identifies the match, with profile pairs specifically tied to the review-queue row. This compensates for the schema's misleading all-optional appearance.

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 ('Dismiss'), a specific resource ('PENDING identity match'), and the immediate effect ('stops surfacing'). It also characterizes the action as a SOFT reject and explicitly contrasts it with mark_different_people, making its purpose distinguishable from 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 explicitly names mark_different_people as the correct alternative for permanent rejection and explains when to use the profile_a+profile_b form (the email→person queue). It does not explicitly mention accept_identity_match as the opposite action, but the sibling name and the 'dismiss' verb make the distinction 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the core safety profile is covered. The description reinforces this with 'Returns metadata only' and adds useful context about the scope ('noticed integration sources') and the kind of status information exposed, but it does not reveal significant behavioral traits beyond what annotations and the output schema already convey.

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, no filler. The first sentence front-loads the verb, resource, and key output dimensions; the second sentence supplies the safety clarification and the intended use case. Every phrase 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-only tool with one optional parameter, full schema coverage, a rich enum, an output schema, and clear annotations, the description is complete. It gives the agent both what the tool returns and when to invoke it, leaving no necessary gap for correct use.

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

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

Schema description coverage is 100%: the single optional 'source' parameter has an enum and a clear description, including the omit-for-all-sources behavior. The tool description does not need to add parameter-level detail, and it does not meaningfully extend 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 opens with the specific verb 'Inspect' and the resource 'noticed integration sources,' then lists the exact status fields returned: safe account labels, connection state, effective sync cadence, and latest attempt or completion. It clearly distinguishes this read-only inspection tool from mutation siblings like sync_connected_source by saying 'Returns metadata only.'

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 'use this before claiming a source is connected or current' gives an explicit, actionable usage condition. It does not name alternative tools or explicitly say when not to use it, but the context is clear enough for an agent to select it appropriately.

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 and idempotentHint, covering safety. The description adds behavioral guidance by instructing 'Present the returned link exactly', which tells the agent not to modify or reformat the result. This is meaningful context beyond the annotations, though the term 'noticed' remains ambiguous.

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

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

Two sentences with zero fluff. The main purpose is front-loaded, followed immediately by the most instructive example and a crisp output-handling directive. 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 a 3-parameter tool with a rendered output schema and safety annotations, the description covers the essential decision points: integration vs. MCP, the Wispr Flow special case, and exact presentation of the result. A minor gap is not explaining mcp_url selection behavior, but the schema fully covers that.

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

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

Schema description coverage is 100%, so the schema documents all parameters. The description adds value by giving a concrete example mapping for Wispr Flow (target='integration', source='wispr-flow'), which clarifies how the enum values should be combined, and by implying the returned value is a link to be used as-is.

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 ('Get') and resource ('connection or management experience for an integration or MCP server'), and explicitly differentiates between the two target types. The Wispr Flow example further pins down the exact usage, making the tool's purpose unmistakable and distinct from any sibling tool.

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 when to use the tool (for retrieving connection/management links) and includes a concrete parameter mapping for Wispr Flow. It does not explicitly state exclusions or alternatives, but no sibling tool appears to overlap with this function, 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the useful context that the tool 'replays the server instructions text on demand,' but does not elaborate on response format or potential caching 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 concise sentences with no filler. The core action is front-loaded, and the secondary note about when to call is brief and useful.

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

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

For a zero-parameter read-only tool with a rich set of annotations and an output schema, the description fully covers what the tool does, what it returns, and when to use it. 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?

The tool has zero parameters, so there is no parameter semantics burden. Schema description coverage is 100% and no parameters exist, making the description sufficient without adding parameter detail.

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

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

The description states a specific verb ('Returns') and resource ('this connector's instructions'), and clarifies what the instructions contain ('what noticed is and how to use it'). It is unambiguous and does not overlap with any sibling tool.

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 directly says 'call anytime to re-read,' which gives clear when-to-use guidance. It does not explicitly name alternatives or exclusions, but none are needed given the tool's self-referential purpose.

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 and idempotent behavior. The description adds that results are ordered by relevance and include suggestion reasoning, which is not covered by annotations. No contradiction detected.

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

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

The description is a single sentence but contains a grammatical error ('people noticed is SUGGESTING') and is slightly convoluted. It could be more concise and direct.

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 mentions members and suggestions but does not specify the exact return structure (e.g., whether list metadata is included). Given no output schema is provided, this is acceptable but 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?

The schema already provides full parameter descriptions ('Pass this OR list_id'), and the description simply echoes them without adding new details. It does not clarify edge cases like mutual exclusivity or defaults.

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 opens a list and returns its members (ordered by relevance) and suggestions for additions/removals with reasoning, distinguishing it from list-mutation tools like add_to_list. However, the phrasing is awkward ('people noticed is SUGGESTING') and could be clearer.

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 list contents but does not explicitly state when to prefer this over other list-related tools. It identifies parameters but lacks explicit guidance on selecting between list_id and list_name 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: it explains the present-tense snapshot semantics (empty field means not recorded, NOT false), the structure of contact and relationship sections, and the pooling behavior for team scope. It also notes that added_at means when they entered your network. This goes beyond annotations, though it doesn't explicitly mention rate limits or auth, but those are not critical for a read 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 fairly long but information-dense. It front-loads the core purpose and then explains key details. Every sentence adds value, though it could be slightly more concise. The structure is logical: purpose, include options, contact section, relationship section, team scope, and snapshot semantics. It's not overly verbose given the complexity.

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 complexity (5 parameters, multiple sections, team pooling), the description is remarkably complete. It covers the return structure (contact, relationship), the meaning of fields, the 'me' special value, the team scope, and the snapshot semantics. The output schema exists, so return values are further specified. Nothing critical is missing for an agent to call this 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?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds extra meaning: it explains the default behavior of include (dossier) and the meaning of 'extras'/'all', clarifies that person_id can be 'me', and details the team scope semantics. It also warns about reading contact.emails instead of top-level email. This adds value beyond the schema, though the schema already covers the basics.

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 one person's full record including profile, current role, and relationship context, with optional extras. It distinguishes itself from siblings like search_people (which finds people) and my_profile (which is about yourself) by specifying the scope and the 'me' option. The verb 'get' and resource 'person' are specific and unambiguous.

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

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

The description explicitly explains when to use this tool: to retrieve a person's record, with options for include and scope. It contrasts with search_people by noting that person_id comes from search_people hits, and it explains the 'me' usage for self. It also clarifies the difference between own and team scope, and when team_id is needed. This is comprehensive 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?

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint, and the description agrees with them. The description adds transparency by explicitly noting that collaborator grants, invitations, and comments are not returned, preventing agents from misinterpreting an incomplete response.

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; the first names the object and purpose, the second clarifies scope exclusions. Every sentence adds value, and there is no redundant restating of the title or schema details.

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

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

For a read-only inspection tool, the combination of the description, output schema, and annotations is complete. The description clearly scopes what is inspected and what is excluded, which is enough for an agent to use it 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 documents all four parameters with 100% coverage, including the 'Pass this OR...' pattern. The description does not need to restate the parameters, but it also does not add extra clarity about choosing between list parameters and view 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 starts with 'Inspect,' a clear verb, and specifies the exact resource: general-access and publication state for a List or View. It further distinguishes itself from broader sharing queries by explicitly omitting collaborator grants, invitations, and comments.

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 establishes when this tool applies: when inspecting general-access/publication state rather than collaborator-level sharing. It also adds a useful exclusion by stating what it intentionally omits. It does not explicitly name an alternative sibling, 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 declare readOnly/idempotent/destructive safe; description adds consent-rule caveat and pagination behavior, which goes beyond annotation baseline. No contradiction.

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

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

One tight sentence that front-loads purpose and includes return behavior; zero 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?

Output schema exists, so return details are covered structurally. Description covers execution scope and consent rules. Lacks error cases or prerequisites, but these are not critical for a read-only tool with strong annotations.

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 covers 100% of parameters with descriptive text. Description adds no new parameter-level meaning beyond schema, so baseline 3 is appropriate.

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

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

Clear verb and resource: 'Open a saved View and execute it' — distinct from list/create/update/delete siblings. Mentions live network scope and return type (definition plus paginated matches), establishing a unique 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?

States execution context (live personal or Team network) and references consent rules, but does not explicitly contrast with siblings like list_views or say when not to use it. The context is clear enough to infer, but explicit routing is absent.

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 well covered. The description adds the meaningful context that this is the canonical voice source and that remembered copies should not be trusted, but it does not disclose additional behavioral details such as return format or potential errors. With annotations covering the core behavior, a mid-score 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 with no filler. The first sentence states what the tool provides and its scope; the second gives clear call timing and an important warning. Every phrase earns its place and the key constraint is front-loaded.

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

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

For a no-parameter, read-only tool with an output schema and comprehensive annotations, the description is complete. It explains the purpose, scope, timing, application, and authority of the tool, leaving no critical gap for an agent to invoke it correctly.

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

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

The tool has zero parameters, and the schema description coverage is 100%, so there is nothing for the description to add about parameter meaning. The baseline for zero-parameter tools is 4, and the description appropriately focuses on usage rather than 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 identifies the tool as the source of writing-voice rules for outbound messages, intros, follow-ups, and posts. It uses a specific verb ('get') and resource ('canonical writing-voice rules') and distinguishes itself from siblings like get_instructions by emphasizing it is the single source of truth for the user's voice.

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 instructs when to call the tool ('BEFORE drafting') and how to apply the result ('apply strictly'). It also warns against relying on remembered or restated copies, which effectively guides the agent to always use this tool rather than cached knowledge. This is strong usage guidance for an agent.

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 safety is covered. The description goes beyond annotations by disclosing ordering behavior (soonest remind_at first, undated last), consent-gating for team scope, attribution to owner, and the read-only nature in words. This adds meaningful behavioral context without contradicting the 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 dense but every clause earns its place: the core sweep behavior is front-loaded, followed by scoping and filtering variants. It is slightly long for a single paragraph, but each sentence contributes a distinct piece of usage or behavioral guidance, so the length is justified.

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 read-only list tool with six optional parameters and an output schema already provided, the description covers the key contexts: whole-network sweeping, team consent gating, goal-based filtering, undated filtering, per-person scoping, and limit capping. Edge cases like team_id being required when multiple teams exist and Goal ownership for team sweeps are addressed, making it complete without needing to describe the return value schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics beyond the schema: it explains that scope:'team' returns consent-gated open actions attributed to their owner, that team_id is needed only when you belong to more than one team, that a team sweep requires a Goal owned by the selected Team, and that undated:true isolates open-ended follow-ups. These enrich the parameter meanings beyond the bare field 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 names a specific verb and resource: lists OPEN follow-up/actions across the whole network in one call, with each action attached to its person. It distinguishes itself from the per-person get_person approach and, among siblings, is clearly the aggregation read call rather than create_action, update_action, complete_action, or delete_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 gives explicit when-to-use guidance: "Use this to sweep all your to-dos... instead of calling get_person per person." It also provides the exclusion condition: "for one person's actions use get_person → relationship.actions." It further clarifies team scope prerequisites, goal ownership constraints, and filtering options, leaving no ambiguity about when to select 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 cover readOnlyHint=true and idempotentHint=true, so the description isn't needed to establish safety. It adds real behavioral context by disclosing the sort order (newest first), that pending suggestions are included by default, and the shape of the result records. Minor omissions like pagination beyond the limit parameter prevent a 5, but the disclosure is strong.

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 front-loaded with the core purpose and orders information from most to least important: purpose, result fields, parameter usage, then a mental-model summary. The closing quoted question is slightly redundant with the opening sentence but reinforces the tool's intent for an agent doing semantic matching.

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 low-complexity read-only list tool with only 3 optional parameters, an output schema, and full parameter coverage, the description leaves no meaningful gap. Ordering, defaults, filtering, and result content are all specified. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaningful value beyond the schema. The 'either side' parenthetical reveals non-obvious asymmetric matching semantics for the person parameter, and the status example ('status='pending' for the review queue') maps parameters to a concrete workflow. This is exactly the kind of behavioral nuance a schema alone wouldn't 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 opens with a specific verb+resource: 'List the cross-source identity matches in your network, newest first' and goes on to detail the exact result fields (linked identities with sources, confidence, reason, status). The read semantics are immediately distinguishable from sibling mutation tools like accept_identity_match, dismiss_identity_match, and suggest_identity_match, so an agent can confidently tell this apart from every sibling.

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

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

The description teaches how to use each filter ('Pass person to scope to one person (matches on either side)') and demonstrates a targeted use case ('status='pending' for the review queue'), plus clarifies the default inclusion of pending suggestions. It does not explicitly name alternatives or state when-not-to-use, but the context for scoping and filtering is unambiguous.

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, idempotentHint, and destructiveHint, covering safety. The description adds the lifecycle statuses and the nature of the list (offered, connected-to), which goes beyond the schema's minimal descriptions. 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?

A single, efficient sentence that front-loads the primary function and includes the useful state enumeration. No fluff, every word contributes.

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 output schema exists and annotations cover safety, the description fully covers the essential semantic context: what the list contains, the statuses, and the user questions it resolves. 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 coverage is 100% with clear per-parameter descriptions. The tool description repeats the status values already in the enum but adds no semantic depth beyond what the schema supplies. Baseline of 3 is appropriate given high 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 identifies the tool as listing pending introductions, specifying the key data elements (who offered, target person, status) and explicitly states the user questions it answers. This is specific and distinct from the sibling tools like track_intro.

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 frames usage around answering 'what intros am I waiting on?' and 'who promised to connect me to someone?', giving clear context for when to invoke it. It doesn't explicitly mention alternatives or exclusions, but the context is strong enough to guide an agent.

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 this read-only, idempotent, and non-destructive. The description adds meaningful context beyond annotations by specifying scope (personal + team), the fields returned (description, member counts, pending suggestions), and the tool's role as the entry point for resolving a list_id. No behavioral contradictions exist.

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

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

Two sentences, no filler. The first sentence defines the resource and return details; the second provides the key usage hint. All content earns its place and is front-loaded.

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

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

With no parameters, an output schema, and annotations covering safety, the description is sufficient for an agent to know when to call the tool and what it returns. The usage note about list_id fills the main practical gap an agent would face.

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

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

The tool has zero parameters and 100% schema description coverage, so there is nothing for the description to explain about parameters. The baseline for a parameterless tool is appropriate, and the description adds no irrelevant parameter detail.

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

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

The description clearly states that this tool returns the user's lists (personal and team) along with key metadata, and it explicitly positions itself as the source for list_id lookup. The plural scope and emphasis on list details distinguish it from siblings like get_list, create_list, and list_actions.

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, direct usage trigger: 'Start here when the user names a list.' This gives the agent a concrete condition for using the tool. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full exclusionary 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 states it's read-only and idempotent (matching annotations), and describes the output fields (person_id, name, email, any URL already submitted). It doesn't cover edge cases like no results or errors, but the annotation hints and the description together provide adequate 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 reasonably concise but includes some redundancy (e.g., repeating 'no LinkedIn or GitHub' and 'any URL already submitted') and a minor typo ('giving noticed'). It could be tightened without losing clarity, so it's slightly above average but not exceptional.

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 fully explains what the tool returns (rows with specific fields), the criteria for inclusion, and the relationship to add_profile_to_person. Given the absence of an output schema, the description provides sufficient context for an agent to understand the tool's purpose and result. Nothing critical is missing.

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

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

The single 'limit' parameter is described with default and max values, and the schema includes a description. Since schema coverage is 100%, baseline is 3, but the added context about the default and maximum elevates it to 4.

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

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

The description clearly states the tool lists contacts missing a profile, specifies the criteria (email-only, no LinkedIn/GitHub, no pending merge), and explicitly ties it to the add_profile_to_person tool. This distinguishes it from other list tools like list_people or list_identity_matches.

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 you need to find contacts to enrich with profiles, and mentions the companion tool add_profile_to_person. However, it doesn't explicitly discuss when not to use it or contrast with alternative listing tools, though the unique purpose makes the usage 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?

Annotations already convey read-only, non-destructive, idempotent behavior. The description adds user scoping and mentions included fields, but does not disclose additional behavioral details such as ordering, pagination, or filtering. This is acceptable but not rich; it stays safely consistent with the 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 a single focused sentence that leads with the action and resource, then lists the relevant output attributes. Every part adds value and there is no redundant or filler 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 parameterless, read-only listing tool with an output schema and strong annotations, the description fully covers what the tool does and what it returns. Nothing essential is missing for an agent to select and invoke it 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?

There are zero parameters and the schema is empty, so there is little for the description to clarify. The baseline for a parameterless tool is 4, and the description adequately identifies the resource and result contents without needing to explain parameter syntax.

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 ('List') with a clear resource ('the user's noticed agent tasks'), and enumerates the returned fields (timing, enabled state, next and last run, run count). It clearly identifies a read-only listing operation and is distinguishable from sibling create/update/delete task 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 makes the tool's context clear: list the user's tasks rather than creating, updating, or deleting them. It does not explicitly name alternatives or exclusion conditions, but the operation is unambiguous and the sibling tool set makes the intended use obvious.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds detail about returning 'saved definition and effective access role', but doesn't mention side effects. It is consistent with annotations, so it adds some but not extensive behavioral info.

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 that are concise and front-load the main action. The second sentence provides usage guidance, making it efficient.

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

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

The description covers what the tool returns (visible views with definitions and roles) and gives a usage hint. Given no parameters and a simple list operation, it seems complete, though output schema details are not described (but that's not required).

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, so schema coverage is 100% by definition. The description doesn't need to explain parameters, and the baseline of 4 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?

States it lists visible personal and Team Views with definitions and access roles, clearly distinguishing from other list_* tools for actions, lists, etc. The verb 'List' and resource 'Views' are 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?

Explicitly says 'Start here when the user names a View.', which gives a clear when-to-use directive. It implies it's the appropriate first step for viewing operations, though it doesn't contrast with alternatives explicitly.

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?

Beyond the annotations, the description discloses that each call appends a new event (non-idempotent), that the tool builds the relationship timeline and affects recency/strength, and that people may be added to the network as a side effect. These behaviors are not visible in the annotations and are clearly surfaced.

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 six tight sentences with no filler: purpose, defaults, side effects, and exclusions each get exactly one clear sentence. The most important action ('Record a touchpoint') is front-loaded, and 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 a tool with a rich schema and an output schema, the description covers what an agent needs to select and invoke it correctly: required type values, optional defaults, side effects, network behavior, and the key sibling alternative. 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?

The schema already provides 100% parameter documentation, including enums and defaults, so the description does not need to repeat them. The description adds high-level guidance like 'Everything else is optional detail that defaults sensibly', but it does not materially enrich individual parameter semantics beyond the schema.

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

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

The description opens with a specific verb and resource ('Record a touchpoint') and enumerates exactly what the `type` field accepts. It also distinguishes itself from the closest sibling by saying 'NOT for notes — ... use add_memory instead', so an agent can select it 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 explicitly tells the agent when to use this tool ('Works on any search_people hit') and when not to use it ('NOT for notes'), naming the alternative tool. It also sets expectations about auto-adding people to the network, which is important contextual guidance for invocation.

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?

Beyond the annotations (readOnlyHint false, destructiveHint true), the description adds behavioral details: 'durable disconnect', 'so notices won't suggest (or auto-) merge them again', and 'Reversible by an admin'. This explains the lasting impact and reversibility, exceeding annotation information.

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 dense but well-organized, using clear separations (semicolons, dashes) to convey purpose, usage, and alternatives. Every sentence adds value, and it avoids unnecessary fluff while remaining readable.

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

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

It covers the action's purpose, how to invoke it, its effects on future suggestions, and its reversibility. Although an output schema exists, the description doesn't need to detail return values; it provides complete operational context for an agent to use 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?

Schema descriptions cover all 5 parameters (100% coverage). The description enriches them by explaining the logical alternatives (candidate_id vs person pair vs profile pair) and the specific scenarios for each, such as handling review-queue rows, adding meaning beyond the basic field comments.

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: 'Mark two records as DIFFERENT people' and explains the durable disconnect effect. It distinguishes from the sibling tool dismiss_identity_match, which is a soft 'not now', making the purpose unambiguous.

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

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

It provides explicit ways to identify the records: by candidate_id, person pair, or profile pair, with specific context for each (e.g., 'use this to clear email→person false positives'). It also references the alternative tool for a softer action, giving clear when-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 annotations already declare readOnlyHint, idempotentHint, destructiveHint, and openWorldHint, covering the safety profile. The description agrees with these annotations and adds the slight behavioral note that ids originate from memory_search, but otherwise defers to the structured data, which is acceptable given the richness of the 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?

Eleven words communicate exactly what the tool does and where the id originates, with the most important action verb leading. Not a wasted word, and the provenance note 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 single-parameter tool with 100% schema coverage, a comprehensive annotations block, and an output schema, the description fully covers what an agent needs to invoke it correctly. The minimal description is complete for the tool's complexity.

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

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

Schema coverage is 100% and the schema defines the id simply as 'The memory entry id.' The description adds value by signaling that a valid id comes from memory_search results, constraining the parameter's valid domain beyond the schema. This is a small but meaningful enhancement.

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 ('Fetch'), a precise resource ('specific memory entry'), and identifies the lookup key ('by id'). The parenthetical '(from memory_search)' further clarifies both the identity domain and the natural workflow, effectively distinguishing this from siblings like memory_search and memory_save.

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 parenthetical '(from memory_search)' implies the expected workflow—search results yield the id to fetch—but stops short of explicitly stating when to choose this tool over alternatives like memory_search or when not to use it. Usage is indicated rather than spelled out.

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 signal idempotent, non-read-only, and non-destructive behavior. The description adds meaningful context beyond annotations: deduplication against existing memories, storage in a global store, and optional attachment to a specific contact's PRM record. This helps the agent anticipate side effects without contradicting the 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 three focused sentences with no wasted words. The core action is front-loaded, followed by the deduplication behavior and the optional person attachment. Every sentence adds a distinct piece of information.

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

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

For a well-schemaed tool with output schema and annotations, the description covers the key behavioral nuances: durability, deduplication, and person scoping. The only notable gap is the lack of explicit differentiation from the sibling 'add_memory' tool, which slightly reduces completeness for an agent choosing among similar tools.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds a little emphasis on the 'person' parameter's attach-to-contact behavior, but that information is also present in the schema. This is the baseline score for full 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: save a durable fact/preference/decision/commitment to long-term memory, with deduplication and optional person attachment. It is specific about the resource and operation, but it does not explicitly distinguish this from the sibling tool 'add_memory', which appears to serve a similar 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 when to use the tool (when storing durable long-term memories that should be deduplicated and possibly linked to a contact), but it gives no explicit guidance about when to choose this tool over alternatives like 'add_memory'. There are no exclusions or alternative routing instructions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully covering the safety profile in structured data. The description adds the content scope of searchable memory (facts, decisions, preferences, commitments) but discloses no further behavioral traits such as result freshness, memory coverage limits, or exclusivity of long-term memory. It adds modest value beyond the annotations, earning a 3.

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 filler: the action and memory scope are front-loaded, followed by a single-line usage directive. Every clause carries information not already present in the schema or annotations.

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 read-only, idempotent search tool with 100% schema coverage, a rich annotation set, and an output schema present, the description need not explain return values. The main remaining gap is the absence of explicit routing between memory_search and memory_get, but the 'use before answering questions about past context' directive provides sufficient operational placement.

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

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

Schema description coverage is 100%, so all four parameters (query, minScore, maxResults, memoryType) are already documented in the schema, making 3 the baseline. The parenthetical memory-content list gives loose semantic context for what query matches against, but adds no syntax, defaults, or format details beyond the schema. No compensation is required and none is meaningfully added.

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

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

The description opens with a specific verb+resource pair, 'Search your long-term memory,' and enumerates the memory scope: facts, decisions, preferences, commitments. This clearly marks it as a query operation, implicitly distinct from write siblings like memory_save and add_memory. However, it does not explicitly differentiate from memory_get, a similarly named retrieval sibling, so it stops short of a 5.

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

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

'Use before answering questions about past context' is explicit, actionable trigger guidance that tells an agent when this tool should be invoked. It provides clear context but names no alternatives or when-not-to-use exclusions, such as a pointer to memory_get for direct key-based retrieval. This matches the 'clear context, no exclusions' level.

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 declare destructiveHint=true and readOnlyHint=false, but the description adds meaningful behavioral detail: the identifier and its Gmail/Calendar/activity move, both records persist ('the identifier ... off the record ... onto the person'), and it 'won't re-attach' to the old record. It also states reversibility via /logs. This is valuable disclosure beyond the annotations, though it stops short of detailing error conditions or permission requirements.

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

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

The description is a single dense paragraph but every clause earns its place: the action, the side effects, the target options, and the alternative tool. It is front-loaded with the verb ('Move...') and purpose. It could be trimmed slightly, but it avoids redundancy and remains readable for an agent.

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 complexity (union-type parameter, nested object, destructive operation, no output schema), the description covers the essential decision points: when to use, what moves, that it's reversible, and what NOT to use it for. It doesn't explicitly cover error cases or the exact behavior if both targets are passed, but those are schema-enforceable. Overall, sufficient for correct invocation.

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

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

All four parameters are well documented in the schema (100% coverage). The description adds practical guidance: refers to get_person for the identifier, marks from_person_id as the 'wrongly attached' record, and explains the to_person_id vs to_new_contact choice. The schema already covers formats, but the description's clarification of the union (either-or) and the get_person hint adds value. Slight overlap with schema prevents a 5.

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

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

The description gives a precise verb+resource+outcome: 'Move one identifier ... off the record it's wrongly attached to and onto the person it really belongs to.' It states both the action and the intent (fixing a mis-attachment), distinguishing it from a merge tool. This is unambiguous and actionable.

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?

Explicitly explains when to use (identifier wrongly attached) and when not to (merging two records → use accept_identity_match). It also provides a prerequisite hint (see identifiers via get_person) and the OR-choice between to_person_id and to_new_contact. Clear guidance with a named alternative.

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

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

Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds meaningful context about what the profile contains and how it is framed, which goes beyond safety traits, though it could clarify the odd 'as noticed sees it' phrasing.

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

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

The description is two short sentences with no filler: it states the resource, its content, and its intended use. Information is front-loaded in the phrase 'Your own developer profile'.

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

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

For a zero-parameter read-only tool with an output schema, the description is largely complete: it names the resource, content, and intended use case. The phrase 'as noticed sees it' is ambiguous and could be clearer, but it does not prevent an agent from invoking the tool correctly.

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

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

The tool has zero parameters, so the description does not need to explain parameters. With no input schema properties, the baseline for this dimension applies and no parameter meaning is missing.

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 indicates this tool returns the calling developer's own profile, with GitHub, LinkedIn, and derived tags as content. It helps distinguish my_profile from profile-related siblings by emphasizing 'your own', though it omits an explicit verb like 'retrieve' or 'get'.

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 "Grounds 'about me' answers" explicitly identifies a use case: answering questions about the caller. It gives clear context but does not mention exclusions or alternatives among sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, establishing safety. The description adds behavioral context beyond annotations by explaining the team-pooled semantics and that it returns 'the distinct total known by ANY teammate plus each member's own network size + consent tier.' This is additive and does not contradict 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 information-dense and front-loads the core purpose, followed by scope details and usage guidance. While slightly run-on, every sentence adds value and no word is wasted, though it could be slightly more concise.

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

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

Given the output schema exists and the tool is read-only and idempotent, the description covers all necessary context: what it does, when to use it, how parameters work, and when to choose an alternative. It fully supports an agent in calling it 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?

Schema description coverage is 100%, so baseline is 3. The description enriches parameter semantics by detailing what scope:'team' returns ('POOLED TEAM network', 'distinct total known by ANY teammate plus each member's own network size + consent tier') and clarifies default values and team_id requirements in the schema itself.

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 provides a 'lightweight overview of your network' with concrete outputs like 'total people, breakdowns by source/company, recent vs stale.' It also differentiates itself from search_people by specifying the exact condition for using the alternative ('for how many <role/type> use search_people').

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?

Explicitly names the alternative (search_people) and the condition that selects it ('for overall how many…' vs 'how many <role/type>'). Also explains when to use the team scope and what it returns, leaving no ambiguity.

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 destructiveHint annotation by explaining that the rejection decision is retained and prevents the suggestion from being proposed again. This adds useful behavioral context about persistence and future 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 concise sentences with no filler. The core action is front-loaded and the retention behavior is stated in the 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?

With full schema coverage, an output schema, and annotations already present, the description is complete for an agent to understand the tool's purpose and side effects. 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?

Schema description coverage is 100%, so the parameters are already well documented. The description adds the 'pending' qualifier but does not need to explain individual parameters further.

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 ('Reject') on a specific resource ('one pending add/remove suggestion for a list'). It distinguishes this from the sibling accept_list_suggestion by focusing on rejection and the retained decision.

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 usage context clear: use it when rejecting a pending add/remove list suggestion. It does not explicitly name alternatives or exclusions, but the context is strong enough that an agent can infer when this tool applies.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false. Beyond that, the description meaningfully adds that the person remains in the network and that suggestions may recur — which are non-obvious behavioral consequences for a destructive operation. It does not fully detail what happens to other list memberships or whether removal cascades, but the key semantic boundary is disclosed.

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

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

Three precise sentences with zero filler. The core action and its non-destructive consequence for the network are front-loaded, followed by identifier guidance. Every sentence contributes distinct information.

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

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

For a 3-parameter tool with 100% schema coverage, an output schema present, and annotations covering safety and idempotence, the description is nearly complete. It covers the one ambiguous area (membership vs. network removal) and identifier method. Minor absence: it doesn't state that the operation is idempotent in plain language, but the annotation already supplies that, so the description need not repeat it.

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

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

Input schema coverage is 100% with each parameter already documented, so the schema carries the primary burden. The description adds a small interpretive note: list_id OR list_name are alternatives, matching the schema's 'Pass this OR' phrasing and the case-insensitivity detail. No new meaning beyond the schema, 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 clearly states a specific verb ('take off') and resource ('list'), and unambiguously differentiates membership removal from removing the person from the network. However, it does not explicitly contrast with sibling tools like add_to_list or remove_from_network beyond the 'stays in your network' phrase, so sibling differentiation is partial rather than explicit.

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 conveys a clear context: use this when removing membership only, not the person from the network. It implies the alternative (remove_from_network) by clarifying what it does not do, and it explicitly tells how to identify the list (by list_id or list_name). It stops short of naming the sibling alternative explicitly, so not a full 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?

The description adds meaningful behavioral context beyond the annotations: 'Soft archive — history is kept and they can be re-added.' This tells the agent the operation is non-destructive and reversible, consistent with destructiveHint=false and idempotentHint=true. It does not mention auth or side effects, but the annotations already establish the safety profile.

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

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

Two sentences with zero filler. The first sentence states the purpose; the second sentence adds the critical behavioral nuance. Everything 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 single-parameter, soft-archive removal operation, the description is complete. Combined with the annotations and an output schema, the agent has enough information to select and invoke the tool correctly.

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

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

The schema already provides 100% coverage for the single parameter, person_id, with a clear description. The tool description merely reiterates the resource being affected. There is no additional semantic value needed here.

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

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

The description clearly states a specific action ('Remove'), a specific resource ('a person'), and the scope ('your active network'). The 'soft archive' phrase distinguishes it from a hard delete, which helps the agent differentiate it from sibling tools like remove_from_list or permanent deletion 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 makes clear when to use this tool: removing a person from your active network. It does not explicitly name alternatives or exclusion criteria, but the scope is unambiguous. For a simple one-parameter tool, this is sufficient context.

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

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

The description enriches the annotations by clarifying the deterministic behavior ('same input always gives the same answer'), which aligns with and expands on the idempotentHint=true annotation. It also details the three possible return states ('matched', 'ambiguous', 'none') and explains the handling of misheard names and fuzzy company hints, all of which go well beyond the structured fields.

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 packs a lot of value into two sentences, with the core purpose front-loaded and usage guidance inserted as an aside. The dash-heavy relative clause ('— same input always gives the same answer—') is slightly redundant with 'deterministically' but reinforces the key point. It could be marginally tighter, but it remains efficient and well-ordered.

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 an output schema exists (likely documenting the return format) and the annotations already establish the safety profile (readOnly, idempotent, non-destructive), the description fully covers the operational semantics. It tells the agent what the tool does, when to use it, how it behaves with ambiguous input, and what to expect in return, leaving no critical gap for a typical 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 100% schema coverage, the base is 3, but the description adds value by explaining that 'name' may be misheard and 'company' serves as a disambiguation hint that 'sharply improves disambiguation.' This contextualizes the purpose of both parameters beyond the schema's mechanical descriptions, justifying a score above the baseline.

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 precise, verb-driven statement: 'Deterministically resolve a (possibly misheard) name — optionally with a company hint — to ONE person in the network.' This clearly defines the action, resource, and scope while setting it apart from siblings like search_people or get_person. The phrase 'PREFER THIS over hand-rolled search_people ladders' explicitly differentiates it from a key sibling, leaving no ambiguity about 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?

The description includes an explicit usage directive: 'PREFER THIS over hand-rolled search_people ladders whenever the task is "who is X?" from a voice note, capture, or mention.' This tells the agent exactly when to choose this tool and hints at the alternative (search_people). While it does not list exclusions, the 'whenever' clause is specific enough to guide correct 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 goes well beyond the annotations by detailing side effects: appending a dated identity note, storing deduplicated memories, recording completion, and the behavior on repeated calls (appends another note while deduplicating). It also notes the conditional 'when available' for the person. No contradiction with annotations; in fact, it enriches the idempotentHint=false annotation by explaining why it's not fully idempotent (deduplication still appends identity notes).

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

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

The description is concise yet informative. It opens with the core purpose in a single sentence, then elaborates on behavior in two more sentences. There is no redundancy or fluff; every sentence contributes to understanding the tool's function and side effects. The structure is effective and front-loaded.

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

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

For a tool with 9 parameters and multiple side effects, the description covers the essential behavioral aspects: what gets stored, where, and what happens on repeat calls. It also notes the conditional person availability. The output schema exists, so return format is implicitly covered. No critical information seems missing for an agent to execute this tool correctly.

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

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

The schema provides 100% coverage with descriptions for all 9 parameters, so the baseline is 3. The description adds meaningful grouping: it maps identity-note fields (name, roles, location, building) and research-answer fields (focus areas, value ranking, current tools, extra notes), which helps an agent understand how parameters are used together. It doesn't repeat schema descriptions but adds contextual organization, justifying a 4.

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

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

The description clearly states the tool's purpose: saving onboarding interview answers in one call. It specifies the trigger (after the onboard skill's questionnaire or when the user shares who they are) and outlines the concrete actions: appending a dated identity note, storing research answers in deduplicated memory, and recording completion. This distinguishes it from generic memory tools like add_memory and add_note.

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

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

The description provides explicit usage context: 'use after the onboard skill's questionnaire, or whenever the user shares who they are and what they want.' It does not explicitly mention alternatives or when not to use it, but the phrase 'in ONE call' and the dedicated nature of the tool imply it is the specialized onboarding entry point, not for ad-hoc memory saves. This is clear enough for an agent to select it appropriately.

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 mark this as read-only and idempotent, but the description goes far beyond them: OR-matching and ranking, AND and + operators, fuzzy matching fallback, semantic embedding fallback, strong_total semantics, matched_on per-row output, and unsupported_filters for public scope. This is rich behavioral disclosure that meaningfully informs invocation and result interpretation.

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 dense and long, but nearly every sentence earns its place given the parameter count and matching complexity. It is front-loaded with the core purpose and operator rules, though the wall-of-text format with many parenthetical asides could be more scannable.

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

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

Given 17 parameters, an output schema, and safety annotations, this description still adds the missing decision context: fuzzy vs semantic fallback, what strong_total means, how filters behave in public scope, team_id requirements, and the meaning of zero structured-filter results. The tool is complex, and the description is complete enough for correct selection and invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description substantially enriches parameter meaning: q gets operator semantics, role gets coverage details and seniority guidance, scope gets whole-network vs warm-intro vs pooled-team distinctions, and date filters get interaction-vs-addition semantics. This is far beyond what the schema alone provides.

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 'Search people by free text — name, company, keywords', naming a specific verb and resource. It clearly distinguishes itself from sibling tools like get_person and list_identity_matches by framing this as a search operation with rich matching 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?

Provides explicit when-to-use guidance: use the role filter instead of free text for roles/functions, use structured filters to count people of a type, and fall back to free text when a structured-filter zero means thin data rather than absence. It also explains scope differences and operator behavior, giving an agent clear decision rules.

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 indicate that the tool is destructive and not read-only, but the description adds valuable behavioral context: it requires user confirmation, states that link access is view-only, and explicitly notes that it does not create invitations or collaborator grants. This goes well beyond the annotation hints and clarifies potential side effects and prerequisites.

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, using three short sentences that front-load the primary purpose and then add key clarifications. There is no redundant or extraneous content, and the structure guides the reader from action to constraints and exclusions efficiently.

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 output schema exists, the description need not explain return values. It covers the core action, prerequisites, and exclusions thoroughly. The main gap is the lack of explanation for the 'role' parameter, which is a minor omission in an otherwise complete description. Overall, the tool is well-contextualized for an agent.

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

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

The schema provides descriptions for four of six parameters, giving a coverage of 67%. The description adds meaning for the 'access' parameter by enumerating the allowed values (restricted, team-visible, anyone-with-link), but it does not explain the 'role' parameter or how it interacts with access. Since coverage is moderate and not low, the description partially compensates but leaves the role parameter 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 that the tool sets a List or View to one of three access levels (restricted, team-visible, or anyone-with-link), plus clarifies that link access is view-only. It also explicitly states what the tool does not do (create invitations or collaborator grants), distinguishing it from related sharing functions. The verb 'set' and specific resource (List or View) make the purpose unambiguous.

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

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

The description provides a usage condition ('After user confirmation') and clarifies that the tool does not create invitations or collaborator grants, which helps a user decide when to invoke it over other sharing-related tools. However, it does not explicitly compare against alternatives like set_published or update_list, so the guidance is slightly indirect. Overall, the context is sufficient for selection in most 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?

The description goes beyond annotations by specifying that unpublishing removes public access and that repeating the same value is idempotent. This is more specific than the generic destructiveHint and idempotentHint.

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 (two sentences), front-loads the core action, and includes important caveats 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?

Given that an output schema exists, return values need not be explained. The description covers the action, side effects, idempotency, and a warning, which is sufficient for a toggle 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?

All parameters have descriptions (100% coverage), but they are minimal and do not explicitly clarify that list and view identifiers are mutually exclusive. The tool description says 'a List or View' implying exclusivity, but the schema leaves ambiguity if both are provided.

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