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

The annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true. The description adds useful scope by clarifying that only Copilot conversation memory is deleted, but it does not explain permanence, recovery, confirmation expectations, or revision conflicts.

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

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

The description is a single front-loaded sentence with no wasted language. It is efficient, though perhaps too sparse given the destructive operation and required parameters.

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

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

For a destructive tool with three required parameters and no output schema, the description covers only deletion scope. The annotations help with safety hints, but the missing explanation of revision and confirmation leaves the agent without needed invocation context.

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

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

There are three required parameters with 0% schema description coverage, and the description never explains threadId, revision, or confirmation. In particular, revision and confirmation are completely opaque from the description.

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

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

The description gives a specific verb and resource: deleting Copilot conversation memory. It also explicitly bounds the operation against LinkedIn and CRM records, so an agent can distinguish it from broader CRM deletion or other Copilot management 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 states what is not deleted, but gives no explicit guidance on when to use this instead of alternatives such as pausing a thread, exporting memory, or syncing. Usage is only implied by the scope boundary.

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=false, so the safety profile is covered. The description adds the useful pagination trait ('bounded page'), but says nothing about volume, what 'relationship memory' contains, or whether 'export' returns inline data versus writing a file.

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

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

A single front-loaded sentence with the resource and its bounding constraints up front. Nothing extraneous and no restatement of the name.

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

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

For a read-only export with no output schema and an ambiguous verb, the description should clarify the return shape, page-size limits, and termination condition. It hints at paging but leaves the critical question of what an export actually yields unanswered.

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

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

Schema coverage is 0%, so the description must carry parameter meaning; it only conveys that domain selects one partition and that results are paged. It gives no defaults, no maximum for limit, and no offset semantics, leaving the agent to infer all three 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?

Specific verb ('Export') plus resource ('relationship memory') plus scope ('one bounded page', 'single domain') tells an agent exactly what it gets. It is distinguishable from siblings like copilot_get_activity and copilot_sync, though it does not explicitly name them.

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

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

'One bounded page ... for a single domain' implies the caller iterates with limit/offset and partitions by domain, so the usage pattern is inferable. However, there is no explicit when-to-use, no mention of alternatives such as copilot_get_activity, and no statement about whether export should be repeated until exhausted.

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, and non-destructive, so the safety profile is covered. The description adds essentially nothing beyond the annotations: it never defines 'recent' (time window or count), does not say whether results are paginated or ordered, and gives no indication of auth or scoping requirements, despite openWorldHint=true.

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

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

A single sentence with no filler, and the resource is front-loaded. The conciseness comes at the cost of specificity rather than from trimming 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?

With no output schema and no parameters, the description carries the full burden of explaining what is returned and over what window, and it does not. For a tool that returns 'activity' of unspecified shape and recency, this leaves an agent unable to predict the result.

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

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

The tool takes no parameters and the schema is fully described, so baseline 4 applies. The description does not need to explain inputs, though it should arguably explain what 'recent' implies for the implicit scope.

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

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

It states a specific verb ('Read') and a resource ('recent classification and operator actions'), but the resource is a vague union of two event types and overlaps heavily with siblings like crm_list_actions and crm_get_classification. An agent cannot tell from this sentence how it differs from those tools.

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

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

There is no when-to-use guidance, no exclusions, and no mention of alternatives such as crm_list_actions, which appears to cover similar action data. The only implied usage signal is the word 'recent'.

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, non-destructive, and openWorld, so the safety profile is covered. The description adds only the hint that settings are 'private' and that the CRM route is 'external', which lightly reinforces openWorld behavior but says nothing about response shape or whether sensitive values are redacted.

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

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

A single front-loaded sentence with no filler. It is dense with jargon ('synchronization coverage', 'external company CRM route') that is not unpacked, but nothing is redundant.

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

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

With no output schema, the description is the only place to learn what comes back, and it lists categories without saying what a 'transport limit' or 'CRM route' value looks like. For a zero-parameter read tool this is adequate but leaves the agent guessing about the payload.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly does not waste space on arguments.

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?

Names a specific verb ('Get') and enumerates the resources returned: settings, transport limits, synchronization coverage, and CRM route. It is more specific than the bare name, but it does not distinguish this from close siblings like copilot_get_activity or crm_get_sync_queue, which likely return overlapping sync/status data.

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

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

There is no statement of when to call this versus copilot_get_activity, crm_get_sync_queue, or copilot_update_settings. The agent must infer usage purely from the noun list, and no prerequisites or exclusions are given.

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, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds a genuinely useful side effect not in structured data: 'Pause cancels unsent drafts', which tells the agent this call has a consequential downstream effect on draft content.

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, no filler, and the secondary but important side-effect warning is placed immediately after the core action. Every sentence carries 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 three-required-parameter mutation with no output schema, the description covers the action and the draft side effect but leaves the revision-conflict outcome, post-call state, and threadId semantics implicit. Annotations carry the safety profile, so the remaining gaps are moderate rather than severe.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies 'revision' as an expected/optimistic-concurrency value and implies 'paused' is the pause/resume switch, but 'threadId' gets no explanation and the mismatch behavior is unstated.

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

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

States a specific verb pair and resource ('Pause/resume a thread') with the added qualifier 'at its expected revision'. It's clear what the tool does, but it never distinguishes itself from nearby siblings like copilot_delete_thread or copilot_release_manual_override, so an agent has to infer when this is the right copilot mutation.

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

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

There is no explicit guidance on when to pause vs. resume, when not to call it, or what to do if the thread is already in the desired state. The 'expected revision' phrase implies a concurrency check but the description doesn't say how to obtain the revision or what happens on a mismatch.

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 is not read-only, is open-world, and is non-idempotent. The description adds useful context that release is restricted to explicit owner instruction and does not enable sending. It still does not explain what state change occurs, how revision interacts with the release, or what the required confirmation phrase does beyond the schema enum.

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

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

The description is a single compact sentence with the core action and the most important constraint front-loaded. There is no filler or repetition.

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

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

For a three-required-parameter mutation with no output schema and zero schema description coverage, the description is too sparse. It omits parameter meanings and the mechanics of releasing the hold, leaving the agent dependent on an undocumented schema.

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

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

There are three required parameters with 0% schema description coverage, and the description does not mention threadId, revision, or confirmation at all. The only parameter-related signal is the schema enum value "resume automatic assessment," but the description does not explain its role or the concurrency meaning of revision.

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

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

The description gives a specific verb and resource: "Release a manual hold." It also clarifies the effect with "does not enable sending." It does not explicitly distinguish this tool from siblings such as copilot_pause_thread, so it is clear but not fully sibling-differentiated.

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 "only on explicit owner instruction" gives a clear precondition for use. The note "does not enable sending" helps rule out a related but different intent. However, it does not name alternative tools or explain when to use those instead.

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

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

Annotations already declare openWorldHint, idempotentHint and non-destructive, so the description's job is to add context, which it does: state is mutated per call (readOnlyHint=false is consistent with 'Import'), each call is bounded to one page, and repeated calls resume rather than duplicate — reinforcing the idempotency hint. It stops short of describing rate limits, auth requirements, or what a coverage warning looks like.

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

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

Three short sentences, no filler, with the core action stated first and the safety exclusion immediately after. Every clause carries information an agent needs.

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, no-output-schema tool the description covers the essentials of invocation, but terms like 'bounded provider page' and 'coverage warnings' are undefined and the agent is given no signal for knowing when the page sequence is finished. With no output schema to lean on, more detail on what comes back was warranted.

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

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

The tool takes zero parameters, so per the baseline there is no per-parameter semantics to explain. The description correctly adds nothing parameter-related and spends its words on the call/repeat protocol instead.

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

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

States a specific verb (Import) and resource (one bounded provider page), which is a recognizable paginated-fetch pattern. It also explicitly excludes message-sending, separating it from dm_send, but it never names its closest siblings such as copilot_get_status or copilot_get_activity.

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?

'Repeat deliberately to resume' and 'inspect coverage warnings' imply a loop-until-done protocol, and 'Does not send messages' rules out one misuse. However, there is no explicit statement of when to choose this over copilot_get_activity or how to decide a run is complete.

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 is a non-read-only, open-world, non-idempotent, non-destructive update. The description adds a meaningful behavioral prerequisite about permitted transport for sending, but it does not explain mutation effects, permission requirements, or revision-conflict behavior.

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

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

The description is a single front-loaded sentence with no filler, and the transport constraint is placed after the core purpose. It is efficient, though its brevity contributes to the specification gaps covered elsewhere.

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

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

This is a mutation tool with a nested required patch object, a required revision parameter, no output schema, and no schema descriptions. The description omits critical context about patch shape, revision semantics, and update effects, so it is not complete enough for reliable invocation.

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

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

Schema description coverage is 0%. The description loosely implies the patch relates to owner policies, but it never explains the required patch object's structure or what the required revision parameter means or how it should be chosen.

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 verb and resource: "Update owner policies." However, the resource is ambiguous relative to the tool name "settings," and it does not clarify what policies or settings are covered, leaving the precise scope vague.

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 only usage-like statement is a prerequisite constraint: sending cannot be enabled without a permitted transport. There is no guidance on when to use this tool versus siblings such as copilot_get_status or copilot_sync, nor any explicit when-not-to-use condition.

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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context that unknown values remain explicit and that the external CRM is authoritative, but it does not explain missing-thread behavior, response shape, or evidence contents.

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

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

The description is two compact sentences with no filler. The retreival action is front-loaded, and the second sentence adds important scope about authoritative ownership rather than padding.

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

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

For a simple read tool with annotations covering safety, the description is partly complete. However, with no output schema and 0% parameter coverage, it leaves the meaning of threadId and the detailed form of returned "labels and evidence" unspecified.

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

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

The only parameter, threadId, has 0% schema description coverage, and the description never mentions it or explains that classification is retrieved for a specific thread. With low schema coverage, the description should compensate for the undocumented parameter, but it does not.

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, "Retrieve," and the resource, "LinkedIn channel relationship labels and evidence." It is clearly a read operation and distinguishes itself from the mutating sibling crm_set_classification, though it does not explicitly name alternatives.

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

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

It gives implied usage context by saying the external company CRM owns the authoritative pipeline, suggesting this tool is for LinkedIn-sourced relationship labels rather than authoritative company pipeline data. However, it does not explicitly state when to use this tool instead of crm_get_thread or other CRM retrieval 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 readOnly, idempotent, openWorld, and non-destructive behavior. The description adds a useful scope boundary by noting that company master data stays in the external CRM, but it does not explain authorization needs, rate limits, or what 'compact' and 'source-linked' mean in practice.

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

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

The description is a single front-loaded sentence with no filler. It is compact, though some of its density comes from vague jargon rather than precise 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 no output schema and 0% schema description coverage, the description should explain what 'context' includes and how the domain parameter changes the result. It does not, so an agent cannot predict the response shape or the effect of domain from the definition.

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

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

Schema description coverage is 0%, so the description must compensate for two undocumented parameters. It clarifies that personId is a 'stable person ID', which is helpful, but it leaves the domain enum (business/personal/unknown) completely unexplained and adds no detail about how domain affects results.

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 verb+resource ('Get ... context for a stable person ID'), which is clearer than the name alone. However, 'compact source-linked LinkedIn channel context' is vague about what data is actually returned, and it does not clearly distinguish this tool from siblings like linkedin_get_connection_status, crm_get_thread, or crm_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?

There is no explicit guidance on when to use this tool versus the many CRM and LinkedIn siblings. The clause about the company master remaining in the external CRM hints at a boundary but does not state when an agent should choose this tool over alternatives.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds genuine semantics: inspected events are not applied and stay queued until CRM persistence is verified, so calling this has no side effect on business state. It does not describe ordering, volume, or what an empty queue looks like in the 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 tight sentences with the resource named first and the state caveat second; nothing is redundant. Minor deduction for jargon ('consumer', 'routing metadata') that is not glossed, though it is standard for a queue-inspection tool.

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

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

With no parameters, no output schema, and annotations already covering the safety profile, the description supplies exactly the missing piece: what the queue contains and why entries are still pending. An agent has everything needed to decide to call it and interpret the result at a high level.

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

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

The tool takes zero parameters, so the baseline is 4 and there are no argument semantics left ambiguous. The description correctly implies a full-queue inspection with no filtering dimension, matching the empty 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?

States a specific verb (Inspect) and a specific resource (business-only updates queued for the crm_sync_business_queue consumer) plus the payload attribute examined (routing metadata). It is clearly distinguishable from write-side siblings like crm_queue_update or copilot_sync, though it never names them explicitly.

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

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

There is no explicit statement of when to call this versus crm_queue_update (which enqueues) or copilot_sync. The clause about events remaining queued until persistence is verified hints that this is a diagnostics/inspection tool, but the agent must infer that condition rather than being told 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 readOnly/idempotent/non-destructive, but the description adds genuinely new context: pagination is bounded, and the returned content is untrusted data rather than authoritative company state — a real prompt-injection/trust warning for an agent. It stops short of stating auth requirements or what the actual bound is.

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 dense sentence with the primary action front-loaded and no filler. The trust caveat is appended efficiently, though "bounded" is asserted without being specified, which slightly undercuts the economy.

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 three-parameter read tool with no output schema and zero schema coverage, the description should at least explain pagination behavior and the threadId format. It covers the trust model well but leaves the calling mechanics thin.

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% for all three parameters, so the description must carry meaning and largely doesn't: it never says what threadId looks like, what limit/offset default to, or what the "bounded" maximum is. "Bounded message pagination" hints that limit/offset exist but adds no usable 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?

States a specific verb ("Read") and resource ("one LinkedIn channel conversation"), with scope narrowed to a single thread rather than a list — implicitly distinguishing it from crm_list_threads. It does not name any sibling explicitly, so differentiation is left partly to inference.

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

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

There is no statement of when to use this versus crm_list_threads, linkedin_get_recent_messages, or linkedin_get_inbox_page, and no prerequisites or exclusions. Only the generic implication that it fetches one conversation is conveyed.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the scope boundary about master tasks and pipeline; it says nothing about pagination, result ordering, or volume, which matters for an openWorld list 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?

A single sentence with the positive scope front-loaded and the exclusion trailing; no filler or restatement of the tool name.

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

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

For a zero-parameter, read-only list tool with full annotation coverage and no output schema, the description conveys what the result set represents and what it deliberately omits. Only the shape of the returned records and any paging behavior remain unspecified, which is minor here.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond the filter semantics, which it does state (actions needed, due follow-ups). Baseline 4 applies for a no-parameter tool.

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

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

The description names a specific verb (list) and a specific resource subset (LinkedIn channel conversations needing action and due follow-ups), which separates it from a generic thread lister. The negative clause ('does not read company master tasks or pipeline') further bounds scope, though it doesn't name the sibling a user should pick instead.

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

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

Usage is implied by the 'needing action and due follow-ups' qualifier, and the exclusion of master tasks/pipeline rules out one adjacent use case. There is no explicit when-to-use or alternative-sibling routing (e.g. crm_list_threads vs linkedin_get_inbox_page), so the agent must infer.

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 non-destructive, so the safety profile is covered. The description adds context that annotations do not: the data is derived from channel memory, it is not authoritative, and results are paginated in a bounded way, which warns the agent against treating it as a complete dataset.

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 front-loaded sentence with no wasted words; the scope, pagination, and provenance caveat all appear immediately. It is slightly dense, packing three clauses into a semicolon-joined sentence, but nothing is 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?

There is no output schema, and the description never hints at what an entity looks like or what fields come back, nor does it document the two enum values. Safety behavior is adequately covered by annotations, so this is adequate but with clear gaps for a paginated listing tool with an undocumented enum.

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

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

Schema description coverage is 0%, so the description must explain parameters. It mentions 'bounded pagination' but never explains what limit bounds, what offset means, or what 'organization' vs 'opportunity' selects for the required 'kind' enum. The agent must guess at page-size ceilings and whether offset is a row count or page index.

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

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

The description states a clear verb and resource: list LinkedIn channel-memory organizations or opportunities. It also distinguishes this data from the authoritative company pipeline, which separates it from sibling tools such as crm_search_people and crm_upsert_entity. It does not name an alternative, so it earns 4 rather than 5.

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

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

The caveat 'these are not the authoritative company pipeline' implies this is a secondary, derived source. However, it does not say when to prefer it or which sibling to use for authoritative pipeline data, leaving the agent to infer that from 25 sibling names.

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

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

Annotations already cover read-only, idempotent, non-destructive, open-world behavior. The description adds useful scope context: it lists 'recent' threads and explicitly excludes the authoritative company pipeline, which helps set expectations beyond the annotations. It does not, however, discuss pagination or default ordering.

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

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

A single compact sentence with the verb and resource front-loaded, followed by a meaningful scope caveat. There is no filler and every clause adds information.

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

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

The description gives the returned content categories (threads, classifications, revisions) and a scope boundary, but omits any explanation of pagination behavior or result ordering for a list tool with two bare pagination parameters and no output schema. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, and the description never mentions the limit or offset parameters. With two undocumented pagination parameters, the description fails to compensate for the schema gap, leaving their purpose and behavior inferred from naming alone.

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

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

States a specific verb ('List') and resource ('recent LinkedIn channel threads, classifications and revisions'), making the operation clear. It also distinguishes itself from the 'authoritative company pipeline' scope, though it does not explicitly name sibling tools like crm_get_thread.

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 'does not read the authoritative company pipeline' implies a when-not condition, but no explicit when-to-use guidance or named alternative is given. An agent must infer that this is for listing threads rather than fetching a single thread via crm_get_thread.

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 a non-read, open-world, non-idempotent write, and the description adds real context: the write lands in channel memory rather than the master record, and name-based matching is forbidden. It does not discuss repeat-call behavior, which matters given idempotentHint=false, but there is no contradiction 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?

A single front-loaded sentence with no filler, and the key constraint (memory mapping, not master write) arrives before the caveats. It is dense to the point of being slightly hard to parse, but nothing is wasted.

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

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

The description covers intent, scope, and the main safety constraint, which is adequate for a two-parameter write tool with no output schema and annotations present. It leaves the opaque parameter formats and the return value unaddressed, which is a real gap for a caller assembling IDs.

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 both parameters rest entirely on the description, which only alludes to a recordId and a 'LinkedIn thread' without giving formats, ID schemes, or what kinds of IDs are accepted. An agent cannot tell from either source whether threadId is a URN, numeric ID, or free string.

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?

Specific verb (store) plus specific resource (a reviewed exact existing company CRM recordId mapping scoped to a LinkedIn thread in channel memory). It implicitly separates itself from master-record tools by saying it does not write the company master, though it never names the sibling (e.g. crm_upsert_entity) that would handle the master.

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

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

Gives clear preconditions ('reviewed', 'exact existing') and explicit exclusions ('never match by name or write the company master'), which tells the agent when this tool is and is not appropriate. It stops short of naming the alternative tool to use for record creation/fuzzy matching.

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 the write/open-world/non-idempotent profile, and the description adds genuinely non-redundant behavior: the update is asynchronous, a hosted consumer (crm_sync_business_queue) must apply and verify it, and 'Queued does not mean applied'. That last line is exactly the kind of caveat that prevents an agent from reporting success prematurely. It stops short of saying what happens on duplicate eventId or how to observe the queued state.

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

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

Two dense sentences, zero filler, with the async caveat front-loaded in the final short clause. The jargon ('hosted crm_sync_business_queue consumer') costs some readability but is load-bearing 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?

No output schema exists, and the description does cover the most important semantic (queueing is not applying). But for a 4-required-parameter, nested-object mutation it leaves the payload shape undocumented and never points at crm_get_sync_queue as the way to confirm application, which is the natural follow-up an agent needs.

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

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

With 0% schema description coverage and four required parameters, the description must carry the burden but only weakly gestures at recordId ('exact existing company CRM recordId mapping'). threadId, eventId, and especially the free-form nested 'changes' object (additionalProperties=false, unbounded shape) get no explanation at all.

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

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

States a specific verb (Queue) and a narrowly scoped resource (a business-only update to an existing company CRM recordId mapping). An agent can tell this is an enqueue operation rather than a direct write, though no sibling (e.g. crm_upsert_entity, crm_map_existing_record) is named to sharpen the boundary.

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?

Preconditions are embedded ('business-only', 'reviewed exact existing'), which implies the mapping must already exist and have been reviewed before calling. However, there is no explicit when-to-use vs when-to-use-an-alternative guidance against crm_upsert_entity for direct writes or crm_get_sync_queue for checking status.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the search avoids loading the inbox and operates over private LinkedIn channel indexes, which is useful context, but it does not disclose return format, pagination behavior, 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 front-loaded sentence with no obvious filler. Its semicolon clause is somewhat awkward, but the overall length is appropriate for the tool.

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

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

For a search tool with three optional parameters, no output schema, and 0% schema description coverage, the description is too thin. It does not explain what is returned, how results are paginated, or what distinguishes the searchable indexes.

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

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

Schema coverage is 0%, so the description must explain query, limit, and offset semantics. It only implies a query through the word "Search" and says nothing about limit or offset, leaving two of three parameters undocumented.

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 verb and an unusual resource ("private LinkedIn channel indexes"), but it does not clearly say it searches people even though the tool name is crm_search_people. It does distinguish itself from searching company master records, but the core resource remains ambiguous.

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 hints at when not to use this tool by saying it works "without loading the inbox" and by pointing company master record searches to the external CRM native search. However, it does not explicitly state when this tool should be chosen over sibling tools like crm_list_entities or linkedin_get_inbox_page.

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 write (readOnlyHint=false), non-idempotent, non-destructive and open-world. The description adds real value by disclosing the write target is channel memory rather than the authoritative pipeline, plus an implied revision-staleness failure mode. It stops short of saying what happens on a revision mismatch, whether prior labels are replaced, or whether the call is retryable.

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 sentence, front-loaded with what is stored, scope limit last. Dense noun stacking ('classifier provenance') costs a little readability but every clause carries 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?

With no output schema, three required parameters, a nested object, and zero schema descriptions, the description should do more: it omits the return value, revision-mismatch behavior, and whether existing classification is replaced. It credibly covers what is written and what is deliberately not touched.

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

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

Schema coverage is 0%, so the description carries the burden, and it partially does: 'expected thread revision' gives revision (an integer with only minimum 0 in the schema) concurrency semantics that the schema does not, and 'source-backed' hints at the evidence field. threadId and the nested rationale/classifierVersion/confidence fields remain unexplained, and the overwrite behavior of classification is unstated.

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

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

States a specific verb (store) and specific resource (source-backed labels, confidence, classifier provenance in LinkedIn channel memory). The trailing clause 'does not update the authoritative company pipeline' draws a sharp boundary against the CRM write siblings, though no sibling is named directly.

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 'at an expected thread revision' implies the caller must hold a current revision and that this is an optimistic-concurrency-aware write, and the 'does not update' clause implies when the tool is the wrong choice. But there is no explicit when-to-use statement, no pointer to crm_get_classification for reads, and no prerequisite/error 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?

Goes beyond the annotations by disclosing optimistic-concurrency behavior ('at an expected revision') and a manual-override guard, which the readOnly/destructive/idempotent hints do not convey. It also scopes the blast radius (not authoritative pipeline). It stops short of saying what happens on revision mismatch (reject vs. merge), which is the key failure mode.

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 dense sentences with no filler; the concurrency precondition comes first and the scope exclusion last. Slight cost is the jargon, which makes the first reading slower than the length suggests.

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 non-idempotent mutation with a free-form nested patch object and no output schema, the description omits the two things an agent most needs: acceptable patch contents and conflict/retry semantics on revision mismatch. Concurrency and override handling are covered; the payload contract is not.

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% across 3 required params, including a nested, unconstrained 'patch' object. The description only gestures at 'revision' via 'at an expected revision' and says nothing about threadId or what patch keys are legal, so it does not compensate for the undocumented 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?

Names a specific verb and resource (update source-backed classification in LinkedIn channel memory) and carves out a boundary by stating it does not touch the authoritative company pipeline. However, 'source-backed classification' and 'channel memory' are internal jargon, and the closest sibling crm_set_classification is never mentioned, so the agent must still infer which classification tool to pick.

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

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

'Respect manual overrides' and 'does not update the authoritative company pipeline' imply usage constraints and one when-not case. But there is no explicit when-to-use-vs-alternatives guidance, and the obvious alternative for setting classification (crm_set_classification) is not routed away from.

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 cover the safety profile (write, open-world, non-idempotent, non-destructive), so the bar is lower, and the description still adds real substance: 'Revision 0 creates a new stable ID' discloses the create-vs-update discriminator and the ID lifecycle, and the pipeline-scope disclaimer prevents a costly misread of blast radius. It still says nothing about conflict/revision-mismatch behavior, which matters for a 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?

Three tight sentences, front-loaded with the core purpose and followed by the two highest-value constraints; nothing is padding. Minor deduction for the telegraphic 'Revision 0 creates a new stable ID' fragment, which lacks the surrounding context needed to be immediately actionable.

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 6-required-parameter, nested-object, non-idempotent mutation with no output schema and zero schema descriptions, the description covers kind and record well but leaves the entityId/revision/thread linkage — the exact fields that decide whether this creates or overwrites — underspecified. Adequate to attempt a call, not sufficient to call it correctly with confidence.

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

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

With 0% schema description coverage on 6 required parameters, the description carries the full burden and only partially discharges it: it correctly splits record fields by kind (name+evidence for organizations; organizationId, stage, participant IDs for opportunities), which maps to the nested object. But entityId, threadId, and threadRevision are never explained, and 'participant IDs' does not match the schema's 'people' array, leaving a term-mapping 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?

Names a specific verb pair (create/update) and a precise resource (channel-memory organization or opportunity), then draws a hard scope boundary: 'does not update the authoritative company pipeline.' That boundary is what separates it from the many other crm_* write tools in the sibling list, so the agent can classify it without opening the schema.

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?

'from an evidenced business thread' and 'does not update the authoritative company pipeline' imply the usage context and one exclusion, but no sibling is named as the alternative (crm_queue_update, crm_map_existing_record, crm_update_relationship are all closer fits for certain cases and go unmentioned). The agent must infer which tool owns the pipeline write path.

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, and openWorldHint=true, covering the safety profile. The description adds that drafts and their actual states are returned, but does not clarify freshness, pagination, auth, or what "actual states" means.

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

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

The description is a single, front-loaded sentence with no wasted text. It efficiently conveys the core action and resource.

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 tool with annotations covering safety, the description is minimally adequate. However, with no output schema, it leaves the meaning of "recent" and "actual states" vague and does not describe return contents or limits.

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

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

The tool has zero parameters, so there is no parameter semantics burden; baseline 4 applies. The description does not need to compensate for missing schema details.

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

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

The description states a specific verb and resource: reading recent drafts and their actual states. It is clear what the tool does, but it does not explicitly differentiate this from sibling tools such as dm_prepare_draft or dm_send.

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 viewing the outbox but gives no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. Sibling tools like dm_prepare_draft and dm_send are not referenced.

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 calls the draft 'idempotent', but the annotations declare idempotentHint=false. This directly contradicts structured behavioral metadata. Beyond the contradiction, it does not explain permissions, side effects, or what the returned draft looks like.

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 and front-loads the core action. It is efficient, though the phrase 'this thread domain' is vague and the idempotency claim is misleading.

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 four required parameters, zero schema descriptions, no output schema, and annotations that contradict the description, the definition is not complete enough for an agent to invoke it confidently. It needs parameter semantics and accurate behavioral details.

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% for all four required parameters. The description hints at thread scope and idempotency, but does not explain what threadId, body, revision, or actionId mean or how they should be supplied.

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

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

The description states a specific verb and resource: preparing a draft, and clarifies it must never be sent. This distinguishes it from dm_send, though it does not explicitly name or compare against that 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?

It gives a usage constraint ('Use only context from this thread domain') and implies when to use it by saying 'never send it'. However, it does not explicitly say when to choose this over dm_send or other drafting/sending alternatives.

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

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

Annotations already declare mutation (readOnlyHint=false), open-world and non-idempotent behavior, so the safety profile is covered. The description does add one genuinely valuable fact beyond them — that the tool currently returns transport_unavailable, i.e. it is non-functional — but it omits what gets sent, what permissions are needed, and whether a draft must exist first.

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?

It is short and front-loaded, so there is no padding, but the single semicolon-joined sentence is grammatically vague and spends its first clause on a constraint while omitting the actual purpose.

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

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

For a mutation tool with an undocumented required ID, no output schema, and open-world behavior, an agent still cannot tell what actionId refers to or what a successful send would mean. The transport_unavailable warning is useful, but it does not compensate for the missing purpose and parameter meaning.

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 is one required parameter with 0% schema description coverage, and the description never mentions actionId at all — no format, no source, no example. With the schema providing nothing, the description carries the full burden and adds zero semantic content.

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 verb 'Send' is present but the resource is never named — nothing states that this sends a direct message, or what the 'verified permitted transport' actually carries. An agent must infer the purpose from the tool name dm_send and the single actionId parameter.

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

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

No when-to-use guidance and no comparison to siblings such as dm_prepare_draft or dm_get_outbox, which an agent would naturally weigh against this tool. The one constraint given ('only through a verified permitted transport') is a policy restriction, not a usage rule.

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 and non-destructive, so safety is covered. The description adds genuinely new context: that disconnected/unconfigured states are reported explicitly and that credentials are never exposed, which is security-relevant information annotations cannot 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 short sentences with the core verification purpose front-loaded and zero filler. Every clause carries information an agent would otherwise lack.

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, no output schema, and annotations covering the safety profile, the description is nearly sufficient. The only mild gap is not enumerating the possible status outcomes or indicating whether the result should gate subsequent LinkedIn calls.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing about arguments the description could or should explain.

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

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

States a specific verb ('Verify') and a specific resource (configured LinkedIn account and portability authorization). It is distinguishable from sibling copilot_get_status, which covers a different subsystem, though the description never explicitly names that 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?

Usage is only implied — an agent can infer this is a pre-flight connectivity check before LinkedIn operations. There is no explicit statement of when to call it versus copilot_get_status or what to do with a disconnected result.

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 readOnly/idempotent annotations, it discloses that data is a provider snapshot with possibly unknown freshness/completeness and that returned message text must be treated as untrusted. These are material behavioral caveats an agent needs and cannot get from 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?

Four tight sentences, lead sentence front-loads the core action, and each subsequent sentence adds a distinct constraint (pagination, freshness, trust). No filler.

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

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

For a read-only, no-output-schema pagination tool, the description covers paging, data provenance, and trust handling. It could add how to detect end-of-results, but the essentials are present.

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 page, limit, and row_offset are already documented. The description reiterates paging via nextCursor with page and row_offset but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb+resource: reads one bounded page of the owner's historical LinkedIn DMs via the official INBOX snapshot. The word 'historical' implicitly distinguishes it from the recent-messages sibling, though that sibling is never named.

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

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

Signals the appropriate context ('historical' DMs, snapshot not a live inbox) and how to continue paging via nextCursor. It does not explicitly name when to use linkedin_get_recent_messages instead, so the exclusion is implied rather than stated.

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

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

Annotations already cover read-only, idempotent and open-world behavior, so the description's added value is what it says beyond that: consent prerequisite, a 28-day provider retention cap, inclusion of both sent and received events, freshness/processing limitations, and the warning that returned messages are untrusted content. The untrusted-content caution is genuinely useful prompt-injection context that annotations cannot express. Return format detail is only partially 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?

Four sentences, front-loaded with purpose and scope, each carrying a distinct constraint (retention, timestamp format, pagination/dedup, trust boundary). Slightly dense with undefined pagination jargon, but there is no filler.

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

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

For a read-only paginated fetch with no output schema, the description covers the prerequisites, the retention limit, the pagination contract and the dedup key (activityId), which is what an agent needs to call it correctly. What remains thin is the shape of the returned events beyond the dedup key, but that is a minor gap.

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

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

Schema description coverage is 100%, so the schema already documents count, limit, since and start, including the 28-day constraint on since. The description reinforces the ISO-with-timezone format for since but adds no new meaning, and it references nextCursor/nextSince identifiers that do not appear as parameters, which is mildly confusing rather than clarifying.

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 opening sentence names a specific verb and resource ('Read LinkedIn message events') plus a hard scope constraint (consent, 28-day retention window), which is far more than a restatement of the name. It does not explicitly distinguish itself from the sibling linkedin_get_inbox_page, so an agent must infer which one to reach for.

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

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

Usage is implied by the resource and the retention window, and the pagination rule ('Exhaust nextCursor before advancing nextSince') is operational guidance. However, there is no explicit statement of when this tool is preferred over linkedin_get_inbox_page or linkedin_get_connection_status, and no exclusions.

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