Quibbly

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

Richly discloses behavior beyond annotations: private by default, team-plan conditional visibility, mention notification via Quibbly and email, solo-plan/team-notes-off fallback to private, and always-private group conversation notes. These are exactly the side effects and defaults an agent needs to call it safely.

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

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

Front-loads the core action and privacy default, then layers in plan-specific behavior. It is dense but mostly earns its space; could be slightly tighter with structured sentences.

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

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

Given a 6-parameter mutation tool with no output schema, the description covers privacy, sharing, plan gating, mention notifications, and fallback behavior. It omits uncommon edge cases such as missing contact_id or group conversation validation, but is sufficiently complete for correct invocation.

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

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

Schema coverage is 50%, so the description compensates by explaining visibility and mentions semantics, including the dependency that mentions need visibility team and the fallback when team notes are off. It does not add detail for name, contact_id, or conversation_urn, leaving those to 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?

States a specific verb and resource ('A note on a person (or a group conversation)') and clarifies the scope of where notes attach. An agent can distinguish it from update_note and delete_note 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?

Explicitly says sharing is only for when the user asks for it, and that mentions require visibility team. It also explains plan-dependent fallbacks, but does not name sibling alternatives such as update_note for edits or delete_note for removal.

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 and readOnlyHint=false, so the description earns credit for adding context annotations cannot: "Sends nothing" rules out outbound messaging, and "the conversation's follow-up date is cleared when nothing else is open" discloses a side effect on adjacent state that would otherwise surprise an agent. It does not say whether the close is reversible or what happens if no open follow-up exists.

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

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

Three sentences, front-loaded with the action and outcomes, then identification, then domain mapping and side effect. Dense but every clause carries information; the parenthetical lists make individual sentences heavy, which costs a point on readability.

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 5-parameter, 0%-schema-coverage mutation with no output schema, the description covers outcome semantics, both identification routes, and the main state side effect. Remaining gaps — precedence between identifier params, behavior when nothing is open, and the response shape — are minor but real for a destructive operation.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does for the most important parts: it glosses the outcome enum ("done (it happened) or cancelled (no longer needed)") and groups the four identification params into either a follow_up_id or a conversation identifier set. It leaves precedence unspecified when both an ID and a conversation identifier are supplied, and says nothing about the name param's matching behavior.

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

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

States a specific verb and resource ("Close an open follow-up reminder") and immediately enumerates the two valid outcomes, which cleanly separates it from the sibling set_follow_up that creates or reschedules one. An agent can tell exactly what this does 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?

Gives two concrete invocation paths — supply a follow_up_id, or supply a conversation (conversation_urn, contact_id, or a person's name) — and names the sibling tools where those IDs come from (list_follow_ups, read_conversation, get_contact). It also maps the action onto the Quibbly UI (Done or delete). It stops short of an explicit exclusion, e.g. pointing to set_follow_up when the reminder should be rescheduled rather than closed.

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, but the description adds genuinely new behavior: the per-author authorization check with its error message, and the side effect that 'Mentions on it are withdrawn.' It stops short of stating irreversibility, an undo path, or confirmation 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?

Three short sentences, front-loaded with the action and scope, then the auth rule, then the side effect. Nothing repeats structured fields and no sentence 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?

For a one-parameter destructive tool whose annotations already flag destructiveness, the definition covers action, permission boundary, error signal, and a downstream side effect. Missing only permanence/undo details and guidance on sourcing the note_id, which are the remaining gaps an agent would want.

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 the single required string parameter, so the description carries the burden and does not explain what note_id is, its format, or how to obtain it (e.g., from read_conversation or search_messages). The only indirect hint is that the ID must refer to a note the user authored.

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

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

States a specific verb and resource ('Delete ... notes') plus scope ('one of the user's own notes'), which immediately separates it from add_note and update_note. An agent knows exactly what the call does 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?

Gives an authorization precondition ('Only the author can delete a note') and the exact failure behavior for the excluded case (a teammate's note returns 'not your note'). There is no explicit when-to-use-vs-alternatives sentence, but for a delete tool the precondition effectively provides that 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?

Annotations say readOnly=false and destructive=true; the description earns that hint by explaining that one live draft per person means a new draft replaces the previous one. It adds traits annotations cannot express: a 20-draft queue cap, 7-day expiry, and the fact that show_at schedules visibility only, never automatic sending.

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?

Dense and front-loaded: the reply/new model comes first, then inputs, then queue/expiry limits. Some clauses are redundant (the 'human sends it, one click per draft' point is made twice via the show_at paragraph), costing a little tightness in an otherwise well-ordered block.

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 7 params, no required fields, and no output schema, the description fills the biggest gap — that at least one of text/attachment is mandatory — plus caps and expiry. The unexplained name and conversation_urn parameters are the remaining hole, but the agent can draft correctly without them.

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

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

Goes well beyond the schema on the parameters that matter: it defines the text+attachment combination as a single message with caption, and imposes an "at least one" rule the schema doesn't enforce (0 required params). It leaves name and conversation_urn unexplained, and show_at's description largely restates the schema, so it isn't fully comprehensive.

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

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

Opens with a specific verb and resource ("Propose a message") and immediately splits the two modes: reply vs. first message to a connection. The reply/new distinction and the contact_id routing make it unmistakable against siblings like withdraw_draft or list_drafts.

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 states that nothing is sent by this tool and that a human clicks Send, which frames the whole use case. It names the upstream sources for each input (list_connections for contact_id, find_attachments/list_library/upload_attachment for attachment_ref) and gives the condition for using show_at versus omitting 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 establish that this is a safe read-only, non-destructive, non-open-world operation. Beyond that, the description adds useful behavior: query also searches transcripts, person narrows to exchanges with a contact, and results can feed draft_reply via attachment_ref. It does not cover pagination, ordering, or return shape, preventing a 5.

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

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

The description is only two sentences and front-loads the main scope before the usage example. The first sentence is dense and contains an undefined term ('Quibblys'), but overall it is appropriately sized with little wasted language.

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 search tool with no output schema, the description covers the main attachment sources and the two filter parameters well. However, it omits limit/pagination behavior and does not fully describe the returned attachment objects beyond their use as attachment_ref values.

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 67%, with query and person already described in the schema. The description adds useful meaning for person by giving an example and explaining that it narrows to that conversation and to Quibblys sent to them, but it does not explain the limit parameter 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?

The description makes clear that this tool locates attachments that can be referenced by draft_reply, and it enumerates the sources: videos, voice notes, snippet files, and LinkedIn conversation files/images/GIFs. It distinguishes itself from draft_reply by naming attachment_ref, though it does not start with a direct verb like 'find' and leaves some terms such as 'Quibblys' unexplained.

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 concrete usage pattern for the person parameter ('the file I sent Priya') and implies narrowing by conversation, but it does not explicitly say when to use this tool instead of siblings such as search_messages, list_library, or recent_messages. Usage is inferable rather than fully specified.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description is free to add what they cannot: the privacy model (teammates' private notes never included, team notes gated on team plan and settings, each with author/visibility/mentions) and the conditional `team` block describing whether a teammate is already in touch. That is exactly the kind of authorization- and data-inclusion context an agent needs before presenting these results to a user.

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 a single sprawling sentence with deeply nested parentheses, and the most actionable content — how to identify the contact — is buried at the very end. Every clause carries information, but the dense run-on structure makes it harder to scan than a three-sentence front-loaded version would be.

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 correctly carries the full burden of describing the return shape and does so in detail, including the conditional team-notes block. The remaining gap is behavioral on the input side: with four optional parameters and no precedence or empty-input rule, an agent can't be sure what a bare call returns.

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 only 25% (only crm_id documented), so the description must compensate, and it does by naming all four lookup keys and giving the crm_id format (hubspot:123) explicitly in prose. The gap is that it doesn't explain precedence when several keys are passed, or matching behavior for name lookups (partial? exact?) on a tool with no required params.

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 makes clear this returns a full contact record sourced from the synced LinkedIn inbox, enumerating the fields it bundles (profile details, CRM links, tags, follow-ups, conversations, notes). It is framed as a noun-phrase data inventory rather than a verb+resource statement, but the identity of the resource and its scope are unmistakable and distinct from siblings like list_connections or link_contact.

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 closing sentence gives lookup keys (contact_id, name, profile_url, crm_id) which implies this is the per-person lookup tool, and it references link_contact as the tool that sets CRM links. However, it never states when to use this versus list_connections, search_messages, or who_watched, nor does it say what happens when multiple keys or no key is supplied despite zero required parameters.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely beyond that by disclosing the return contents: transcript, share link, and recipients with watched/replied status — valuable context absent from any structured field.

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; every clause enumerates a distinct part of the returned record. Nothing wastes space.

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?

Because there is no output schema, the description usefully compensates by summarizing the return payload, which is the main completeness need for this simple read tool. The remaining gap is the unexplained ID parameter and no mention of error behavior, keeping it short of a 5.

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 full burden for the single required parameter library_item_id, but it says nothing about format, where to obtain the ID, or behavior on an invalid ID. With one undocumented parameter, the description fails to compensate for the schema 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 makes clear it returns a single video or voice note 'in full', which implicitly distinguishes it from the sibling list_library. However, it spends its words describing the payload rather than stating an explicit verb (fetch/retrieve) and resource, so an agent relies partly on the tool name and title to confirm 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?

There is no explicit guidance on when to use this versus list_library or who_watched, nor any stated prerequisites. The word 'one' hints at singular retrieval vs the list sibling, but that is inference rather than stated 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 cover safety (readOnly, non-destructive, closed-world), so the description adds real value beyond them: it discloses that the full body is returned and that bodies contain {first_name} and {company} placeholders substituted per recipient at recording time. That materially affects how an agent should present or reuse the 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, front-loaded with what is returned, then the placeholder caveat. No waste, though the placeholder note is the only real payload in the 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?

With no output schema, the description does a fair job of telling the agent what comes back (full body with templated placeholders). It omits error/not-found behavior and gives no hint about the required identifier, which is the main gap for a one-parameter getter.

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 single parameter script_id is undocumented in both schema and description. The description says nothing about where the id comes from (presumably list_scripts) or its format, so the agent gains no parameter meaning it did not already have.

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

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

States a specific verb and resource ('One teleprompter script in full') and scopes the visibility ('personal, or a team script the user can see'). It is clearly distinguishable from list_scripts, though it never names that sibling 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?

Usage is implied rather than stated: an agent can infer this is the fetch-one counterpart to list_scripts, but there is no explicit 'use this when you have a script_id' or guidance on what to do if the script is not visible.

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 destructive and non-read-only; the description adds exactly the needed context: one link per system, re-linking replaces the existing link, and `remove: true` clears it. It also explains the downstream lookup/sync benefit.

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

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

Front-loaded and efficient: purpose, timing, replacement/removal behavior, and downstream usage are all covered without filler. Every sentence contributes useful operational context.

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

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

The definition is largely complete for a destructive linking tool with no output schema, especially around replacement and removal semantics. The main omission is how `contact_id` identifies the person and what `profile_url` is for.

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

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

The description adds meaning for `system`, `external_id`, `url`, and `remove`, and gives the `crm_id system:id` format used by get_contact. However, it does not explain `contact_id` or `profile_url`, which is a meaningful gap given only 50% schema description coverage.

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

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

States a specific verb and resource: storing a CRM record id/url on a contact so later lookups skip the search. It also clarifies the relationship with get_contact by noting how the stored crm_id is consumed afterward.

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 timing guidance: use this after the person has been matched or created in HubSpot, Salesforce, Attio, or another CRM. It explains replace and remove behavior but does not explicitly state when not to use it or name alternative 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/openWorldHint=false, but the description adds real provenance: data comes from the extension's sync of LinkedIn's connection list (on Connections tab load and daily while Inbox is on), with synced_through indicating freshness. It also discloses pagination via next_cursor and the safety note that drafts are not auto-sent. Caching/staleness windows are implied rather than stated, keeping it at 4.

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?

Purpose is front-loaded, then provenance, then filters, then drafting handoff – a sensible progression with no filler sentences. It is dense single-paragraph prose, which slightly hurts scannability for six 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 read-only list tool with no output schema, it supplies what an agent needs: what records appear, how fresh they are (synced_through), how to page, and how filters compose. The undocumented limit parameter and unstated result-shape beyond next_cursor are the only gaps.

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

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

With only 50% schema coverage, the description compensates well: it defines messaged values ('no' = never messaged, 'yes' = has a conversation, 'any'), query matching rules (case-insensitive, all words must match, literal text, no job-title interpretation), days default/max, and cursor = next_cursor. Only limit is left entirely 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?

Opens with a specific resource and scope: 'People the user is connected with on LinkedIn, newest connection first, including people they have never messaged.' This clearly separates it from conversation-listing siblings such as list_conversations and recent_messages.

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 concrete filter-selection advice, including the non-obvious steer to use a broad query plus headline data rather than literal job-title words, and routes drafting to draft_reply. It does not explicitly state when to prefer get_contact or list_conversations instead, so it stops short of full when/when-not coverage.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds genuinely new behavior: result ordering, the pagination scheme, and how unsynced_for resolves against a CRM sync marker. It omits the default/maximum page size and return row shape, which are the remaining useful disclosures.

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 dense sentences with the core scope and ordering front-loaded, and every filter clause earns its place. It does restate the status enum that already exists in the schema, which is mild duplication rather than waste.

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 still conveys ordering, row granularity (conversations, not messages), and pagination cursor semantics, which is enough to call it correctly. The absence of any hint about returned conversation fields or total counts is a minor residual gap.

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

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

Schema coverage is only 57%, and the description compensates well: it defines before as the last_message_at of the last row, explains unsynced_for as 'after its mark_synced marker, or never synced', and lists all status enum members. Only limit and company are left to the schema 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 and resource ('LinkedIn conversations Quibbly has synced') plus default ordering ('newest activity first'), which immediately separates it from read_conversation and search_messages. An agent can tell what this returns 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?

Explicitly routes message retrieval to read_conversation and enumerates the filter axes, giving clear context for when to call it. It stops short of stating exclusions (e.g. use search_messages for text search, or list_follow_ups for follow-up tracking), so routing is clear but not exhaustive.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real value by decoding draft lifecycle states and field meanings (kind, show_at, error), but it omits the implicit filtering behavior, ordering, and pagination that a listing tool needs.

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 a single dense paragraph with the resource front-loaded, and no sentence is pure filler. However, it spends its length field-by-field while omitting the operational details an agent most needs, so the allocation of space is misjudged.

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 filtered list tool with a non-obvious default status and a limit cap, the description should explain filtering and result size. With no output schema and no parameter documentation anywhere, the agent has to open the schema to learn the tool only returns ready drafts by default.

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 there are two parameters, yet the description never names 'status' or 'limit'. The status enum values appear only as prose describing draft outcomes, not as a filter argument, and 'all' and the 100-item maximum go unmentioned.

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 resource precisely ('drafts proposed by assistants') and enumerates the outcome states, so an agent knows what is being listed. It never uses the verb 'list' nor distinguishes itself from siblings like draft_reply or withdraw_draft, but the scope 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?

There is no statement of when to call this versus draft_reply, withdraw_draft, or list_follow_ups. Critically, the description never mentions the status filter or its default of 'ready', so an agent cannot tell that the default call only returns ready drafts rather than all of them.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the filter buckets, which duplicate the schema enum — nothing about ordering, pagination, or how 'all open' relates to completed follow-ups.

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 short fragment with no wasted words, but it is under-specified rather than concise: there is no leading verb or scope statement, so the reader must guess the operation from 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 two-parameter list tool with no output schema, the description should explain the limit/default behavior and what a follow-up record contains. Instead it covers only the due-window buckets, leaving an agent unable to predict result size or shape.

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 carries the burden. It loosely restates the `due` values (adding a hint that 'all' means all open), but the `limit` parameter — with its default of 50 and maximum of 100 — is never mentioned, leaving half the parameters undocumented anywhere.

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 the resource (follow-up reminders) and enumerates the time windows, but it is a noun-phrase fragment with no verb and does not distinguish the tool from siblings like set_follow_up or complete_follow_up. An agent can infer it retrieves options, but only from the name/title, not from the description itself.

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 set_follow_up, complete_follow_up, or recent_messages. The filter values hint at a read/list use case but no explicit usage guidance 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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value beyond them by disclosing what each item contains (send/seen/reply counts, attachment_ref) and that search covers transcripts, not just names and descriptions.

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 with no filler, front-loading what the tool returns, then search semantics, then the handoff to sibling tools. Each sentence earns its place; the only minor gap is the unmentioned limit/pagination behavior.

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 two-parameter read-only list tool with no output schema, the description covers what items look like (counts, attachment_ref) and how to get the full transcript. It stops short of explaining pagination or the limit default, which is the one thing an agent calling it repeatedly would need.

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 carry parameter meaning. It explains the search parameter well, including that it matches names, descriptions, and transcripts, but leaves the limit parameter (default 30, max 100) completely undocumented in both schema and 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 states the resource precisely: 'Your recorded videos and voice notes with send, seen and reply counts', so an agent knows this returns a library listing rather than messages or contacts. It differentiates from the sibling get_library_item by noting that get_library_item returns the full transcript, though it doesn't explicitly contrast with search_messages or find_attachments.

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 concrete usage context for the search parameter ('the video where I talk about pricing' works) and names the follow-up tools: attachment_ref for draft_reply and get_library_item for the full transcript. There are no explicit when-not-to-use conditions, but the routing to alternatives 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful content-level context — that entries carry shortcuts and templated placeholders — but says nothing about ordering, volume, or whether all saved replies are returned.

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 tight sentence with the key concept front-loaded and concrete placeholder examples that earn their space. It is a noun fragment rather than a complete sentence, which slightly weakens the lead.

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 a clear annotation profile and no output schema, the definition supplies enough to select and call it: what the objects are and what fields they contain. Missing only guidance on when in a workflow to reach for 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The mention of placeholders is a bonus hint about the returned data shape rather than a parameter concern.

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 identifies the resource concretely — 'saved snippets with their shortcuts and placeholders' — which maps to quick replies and is distinct from siblings like list_tags, list_scripts, or list_library. It omits the listing verb, but the title supplies it and the content is unambiguous.

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

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

There is no statement of when to call this versus related tools such as draft_reply (which presumably consumes quick replies) or list_library. The agent must infer that this is a lookup used before composing a reply.

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/non-destructive annotations, it discloses non-obvious behavior: team-admin settings can disable the teleprompter or restrict to team scripts only, which silently hides personal scripts from the result. That visibility caveat is exactly the kind of context annotations can't convey. It doesn't cover pagination or result limits.

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 dense sentences, front-loaded with what the tool returns, followed by visibility rules and sibling routing. Every sentence carries information, though the team-admin rules sentence is long and could be tightened.

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 does the work of describing the return shape: word count, short preview, requirement level, and locked flag per script, plus ordering. Remaining gaps are search semantics for query and any result-size 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?

Schema coverage is 50%: query is documented in the schema but scope's enum values carry no schema description. The description discusses team vs personal scripts and their rules, which implicitly grounds the scope values, but it never explicitly ties that to the scope parameter, and it says nothing about the query search behavior.

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 (listing the teleprompter scripts a user can record with) and immediately specifies the composition and ordering of the result: team scripts first, then personal scripts. It names the related siblings get_script and save_script, so an agent can distinguish listing from fetching full text or writing.

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 routes the agent: use get_script for full text, use save_script to write personal scripts, and it explains that team scripts are read-only here. It doesn't state explicit trigger conditions versus other list_* siblings, but the alternatives and their roles are clearly laid 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond that — no indication of return shape, ordering, pagination, or tenant scoping.

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?

There is no waste, but this is under-specification rather than conciseness: a three-word fragment where one full sentence could carry the purpose. Front-loading is irrelevant at this length.

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-param read-only list tool with no output schema, the description should at least say what the returned tags represent (account-level definitions vs. a contact's tags). That ambiguity is left entirely unresolved.

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. Schema coverage is moot with an empty properties object.

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?

"Your CRM tags." is a noun fragment that restates the resource named in the title/name; the verb (list) is only inferable from the tool name. It doesn't clarify whether it returns tag definitions, their usage counts, or assignments to contacts — a meaningful distinction against set_tags in the same namespace.

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 mention of set_tags as the mutation counterpart, despite them being an obvious pair. An agent must infer from the name alone that this is the read path for tags.

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 that this is a safe read operation. The description adds useful behavioral details beyond annotations: the exclusion of the user, name sorting, cursor pagination, and the empty-with-note behavior on solo plans or when team notes are disabled.

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

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

The description is compact and front-loaded: purpose, scope, search behavior, pagination, and edge cases are all covered in a few efficient sentences with no wasted text.

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

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

There is no output schema, and the description does enough for an agent to call the tool correctly: it covers search, pagination, sorting, and empty states. It stops short of describing the returned fields and omits `limit`, so it is not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains `q` matching the start of a first or last name or email, and explains `cursor` as the next_cursor value, but it never mentions `limit`, leaving one of three parameters undocumented in prose.

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 ('List team members'), clarifies that it excludes the user, and states the sort order. An agent can immediately tell this is a read-only teammate listing, distinct from the other list/search 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 gives a concrete use case ('so you can mention them on a team note') and explains the empty-state conditions for solo plans or disabled team notes. It does not explicitly name alternatives or when not to use it, 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 flag it as a write with destructiveHint=true; the description adds useful mechanism — that a time marker is written and that subsequent reads are scoped by it. It stops short of saying the previous marker is overwritten/irreversible or what the call returns, so it adds real context without fully explaining the destructive nature.

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, front-loaded with the core effect and followed by the parameter rule. Nothing is wasted and it gives the agent the mechanism before the usage 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?

No output schema exists, but this is a marker-write whose return is uninteresting; the description covers the state effect and downstream consequences, which is the essential context. The gap is the unexplained identity parameters and any permission/precondition notes for a destructive-marked write.

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 only 40%, and the description compensates for the most important parameter: it explains that the last synced message_id (schema's through_message_id) sets the marker and that omitting it defaults to the latest message. However, name, contact_id, and conversation_urn — how a conversation is identified — are left undocumented, and the description uses 'message_id' where the schema says 'through_message_id', a minor naming mismatch.

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

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

States a specific verb and resource: records how far a conversation has been synced into a CRM. It also names the downstream consumers (recent_messages, list_conversations with `unsynced_for`), which differentiates it from the superficially similar request_sync and sync_status 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?

Explains the effect on later calls and gives a clear rule for the two modes (pass the last synced message_id vs. omit it to use the latest message). It does not explicitly contrast against request_sync/sync_status when a conversation has never been requested, so the when-not guidance is incomplete.

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 establish read-only safety, and the description adds substantial behavioral detail beyond them: oldest-first ordering, included message fields, voice-note transcripts, Quibblys seen/watched status, open follow-ups, pending draft, note visibility rules, exclusion of teammates' private notes, and system sync-flag semantics. 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?

The content is dense and mostly earns its place, but the main description is one very long sentence packed with return-field details. It is not front-loaded as a verb-led purpose statement and would be easier to scan if structured more clearly.

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 read tool with no output schema, the description does a strong job explaining return contents, ordering, inclusion/exclusion rules, and sync behavior. Minor gaps remain around pagination or limit behavior and how multiple lookup matches are resolved.

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 50% schema description coverage, the description adds meaning for the key lookup parameters by saying the conversation can be found by conversation_urn, contact_id, or a person's name. It also explains the system parameter's sync-marker comparison. It does not clarify name-matching behavior or ambiguity resolution, so it falls short of complete parameter guidance.

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 reads the messages and associated metadata for a single conversation, with concrete detail about message_id, direction, transcripts, Quibblys, follow-ups, drafts, and notes. It is specific and non-tautological, but it does not explicitly distinguish itself from siblings such as list_conversations, recent_messages, or search_messages.

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 how to locate the conversation by conversation_urn, contact_id, or person name, and when to pass system for new_since_sync flagging. However, it gives no explicit guidance on when to choose this tool over list_conversations, recent_messages, or search_messages, leaving alternatives 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 declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description still adds real value no annotation carries: the newest-first ordering, the per-message field set, and the once-per-page `conversations` join with person, company and sync markers. It does not mention the default/max page size or whether results are capped by the `limit` ceiling, which is the remaining behavioral gap.

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

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

Four tight sentences, front-loaded with the return shape and then the sync and pagination cases. The colon construction ('The tool for syncing: `unsynced_for` ...') is slightly telegraphic, 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?

With no output schema, the description correctly takes on return-shape duty and explains both the flat message feed and the grouped conversation details. An agent can call it correctly for the syncing and paging flows; only the `limit`/`direction` parameters and result-size behavior remain unexplained.

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 60%, and the description compensates well for the most consequential parameters: `unsynced_for` is explained as returning only messages newer than each conversation's mark_synced marker, and `before` is tied to the `next_before` value returned with a page. The undocumented `limit` and `direction` parameters get nothing, which keeps this from 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?

Opens with a concrete picture of the resource: a flat feed of messages across every conversation, newest first, with the fields each item carries, plus the joined `conversations` block. That distinguishes it from `list_conversations` and `read_conversation`, but it never names `search_messages`, its nearest sibling, so the boundary against searching is left implicit.

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 a clear use case ('the tool for syncing' via `unsynced_for`) and the pagination recipe (`before` = next_before). It stops short of stating when not to use it or naming the alternative for keyword search, so it lands at clear context without 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?

With annotations present, the description usefully adds a hard rate limit (one request per 3 minutes), a runtime precondition (LinkedIn tab must be open), and a note that LinkedIn's own limits still apply downstream. It does not explain why destructiveHint=true for a sync trigger or what state is created/overwritten, which is the remaining behavioral gap.

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

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

Three short sentences, front-loaded with the action, followed by the precondition and limits. No sentence is redundant or padded.

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

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

For a zero-param, no-output-schema tool the description covers preconditions and rate limits well. What it omits is whether the call returns immediately or blocks, and that the agent should follow up with sync_status to observe progress — a relevant gap given a sibling of that name exists.

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 schema carries no semantic burden and the baseline of 4 applies. The description implicitly confirms this is a fire-and-forget trigger with no 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?

The description states a specific verb and resource: trigger an inbox sync now via the extension. It is immediately distinguishable from the read-only sync_status and mark_synced siblings, though it never names those siblings 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?

The precondition 'if a LinkedIn tab is open' is a genuine usage constraint that tells the agent when the call can succeed. However, there is no explicit routing guidance such as when to use this versus polling sync_status, or when a manual sync is preferable to waiting for a scheduled one.

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 annotations by disclosing the refusal condition, that team scripts are read-only here, and how {first_name}/{company} placeholders are resolved per person. It does not explain what an update replaces on an existing script, which matters given destructiveHint=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?

Three tight sentences, create-vs-update stated first, followed by constraints. No filler or duplicated schema 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?

Covers create vs update, refusal rules, and template substitution for a tool with no output schema. It leaves what an update does to existing fields, and the title/body length limits, implicit.

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

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

Adds real meaning the schema lacks: title and body are required only to create (the schema's required list is empty), and the body supports per-person placeholders. The folder parameter is left unexplained, though the schema covers it.

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

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

States a specific verb and resource ('Create a personal teleprompter script, or update one of the user's own personal scripts') and scopes it to personal scripts. It also draws the line against team scripts, which separates it from related tools like get_script and list_scripts.

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 pass script_id to update and omit it to create. It also names the exclusions: team scripts are edited in Quibbly even for admins, and the call is refused when the team allows team scripts only.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful context that results include the surrounding conversation and that contacts are searched, but says nothing about limit/pagination behavior or result 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?

Two short sentences with zero filler; what is searched is front-loaded and the return shape follows immediately.

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's return-value sentence carries weight and does so adequately, and the searchable-field enumeration fills part of the schema gap. However, for a 3-parameter search tool it should explain the limit and since semantics and note the sync prerequisite, which it does 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 only 33% – only 'since' is documented ('ISO date'), while query and limit have no schema descriptions. The description partially compensates by clarifying that the query is full-text over both message text and contact attributes, but it leaves the limit default/max and the since date filtering behavior 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 and resource ('Full-text search across synced LinkedIn messages and contacts') and even enumerates searchable contact fields, so the agent knows exactly what is queried. It stops short of naming the sibling it replaces (recent_messages, list_conversations), so sibling differentiation is only implied.

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 'synced' qualifier hints at a prerequisite (data must be synced via request_sync/sync_status) and 'full-text' implies keyword use, but there is no explicit when-to-use vs recent_messages or read_conversation, and no exclusion 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, so the description does not need to carry the entire safety burden. However, it does not explain what is destructive about moving an existing follow-up, whether the previous reminder is overwritten, or what permissions are required. The phrase 'move an existing one' adds only minimal context 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 a single front-loaded sentence with no filler or repetition. It is concise, though its brevity contributes to the gaps documented elsewhere rather than being an independent strength.

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 mutation tool with five parameters, low schema description coverage, and no output schema, the description is too thin. It does not resolve how to target a conversation or contact, why due_at is the only required field, or what the destructive behavior means in practice.

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 only 20%, with just due_at briefly documented as an ISO date-time. The description adds no meaning for the five parameters, does not clarify that due_at is required, and gives no guidance on contact_id versus conversation_urn or how name and note are used.

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

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

The description states a specific verb and resource: create a follow-up reminder on a conversation, or move an existing one. It is clear at a high level, but it does not explicitly differentiate this tool from siblings like complete_follow_up or list_follow_ups.

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 a context for creating or moving a follow-up, but it gives no explicit when-to-use guidance, prerequisites, or alternatives. It never mentions when to use this instead of complete_follow_up or how to handle an existing follow-up.

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 one genuinely useful behavioral fact ('tags are created if they do not exist'). It does not explain what the destructive aspect means in practice (does removing a tag delete the tag globally, does it affect other contacts, are changes reversible), which is the main thing an agent needs to know for a destructive 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 short sentences, action front-loaded, no filler. The side-effect note is placed right after the action where it belongs.

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, zero-required-parameter mutation tool with no output schema and completely undocumented parameters, the description leaves too much open: how targets are selected, what happens with an empty call, and what removal actually destroys.

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 5 parameters, and the description never names a single one. Critically it does not clarify that contact_id and conversation_urn are alternative targeting mechanisms, nor what the ambiguous 'name' parameter means (tag name? contact name?), nor that add/remove are string arrays.

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 pair of verbs (add/remove) and the exact resource (tags) plus both target entity types (contact, group conversation). It does not name or contrast with the sibling list_tags, so an agent must infer the read/write split from names alone.

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: the reader infers 'use this to change tags, use list_tags to read them.' There is no explicit when-to-use/when-not, no mention of prerequisites, and nothing about which target type is appropriate in which situation.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and closed-world behavior, so the safety profile is covered. The description adds useful behavioral context by specifying exactly which state signals the response contains, which is valuable for a status 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, front-loaded sentence packed with specific return-value detail and no filler. 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?

With no output schema, the description carries the burden of explaining what comes back, and it does so by enumerating the key state fields. It could say a bit more about how the values are formatted or interpreted, but it is largely complete for a no-parameter status 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?

The tool takes zero parameters, so there is no parameter semantics to explain. Baseline 4 is appropriate for a no-argument 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 the resource precisely (data freshness) and enumerates the specific signals it reports: last extension report, online state, Inbox sync state, pending drafts, queued actions. It does not explicitly differentiate from siblings like request_sync or mark_synced, but the read-only framing is clear.

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: call this to check how current the data is. There is no explicit statement of when to prefer it over request_sync or mark_synced, and no exclusions or prerequisites 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?

Goes well beyond the destructiveHint annotation by disclosing authorization behavior, exact error semantics, mention-list replacement, notification side effects for added/removed teammates, implicit mention removal when going private, and constraints around team notes and group conversations. These are exactly the operational details an agent needs before mutating a note.

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

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

Four dense sentences, front-loaded with what changes, followed by permissions, mention semantics, and sharing constraints. Every sentence carries distinct, actionable information with no redundancy.

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

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

For a destructive mutation with no output schema, the description covers permissions, side effects, edge cases, and sharing constraints thoroughly. An agent has everything needed to decide whether and how to call 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?

With schema coverage at only 25%, the description compensates substantially: it explains that mentions replaces the entire list and triggers notifications, clarifies visibility values as private vs team, and notes that going private removes mentions. It does not elaborate on note_id or body length limits, but those are adequately covered by 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?

States a specific verb (change) and resource (the user's own notes), enumerating the mutable fields: body, visibility, and mentions. It is clearly distinguishable from add_note, delete_note, and read-only 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?

Establishes clear preconditions: only the author can edit, a teammate's note yields 'not your note,' sharing requires team notes enabled, and group conversation notes stay private. It does not explicitly name add_note or delete_note as alternatives, but the context is strong enough to select this tool confidently.

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 the write/destructive profile (readOnlyHint=false, destructiveHint=true, openWorldHint=false), and the description adds the traits annotations cannot: 8 MB cap, base64 encoding requirement, and a 24-hour lifetime on the returned attachment_ref. The expiry caveat is exactly the kind of operational context that prevents failed downstream calls.

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, zero filler, and the highest-value facts (what it stores, size limit, return value, lifetime) come before the alternative-path note. 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 3-param write tool with no output schema, the description supplies the return value and its expiry, the size ceiling, and the follow-on call. Only the mime_type parameter and behavior on rejected/oversized uploads are unaddressed, which is minor.

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?

Coverage is 33%, so only 'name' is documented in the schema. The description compensates for data_base64 by stating the encoding and the 8 MB limit, but mime_type semantics (accepted values, whether it drives validation) are left entirely unaddressed.

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 and resource: 'Store a file (PDF, image, document) so a draft can carry it', plus the explicit output (an attachment_ref) and the consumer (draft_reply). It also separates itself from the library path for videos/voice notes, so an agent can route without opening schemas.

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 a clear use condition (attaching to a draft via draft_reply) and an exclusion with an alternative ('For videos and voice notes, use the library instead'). The alternative is named only by concept rather than a specific sibling like list_library/get_library_item, which is the one small gap.

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

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

Annotations already cover the read-only, non-destructive, closed-world profile, so the description's job is to add substance — and it does: it enumerates the returned metrics (watch percent, watch time, plays, source, reply status) and discloses that anonymous viewers are counted but not listed, a real behavioral caveat. It adds no pagination or rate-limit information, so not a 5.

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

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

Two sentences, zero filler: scope first, then returned fields, then the anonymous-viewer caveat. Every clause carries information the agent needs, and the most decision-relevant content 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 output schema, the description does the necessary work of naming the returned metrics, and the safety profile is already covered by annotations. The remaining gaps — limit semantics, result shape/pagination, and behavior when both name and library_item_id are supplied — are minor but real.

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 carry the load. It gives meaning to three of four parameters: days ("last N days"), and name/library_item_id as alternative video selectors. The limit parameter is never mentioned and no result-count or pagination behavior is described, leaving a real gap.

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

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

States a specific resource (viewers) with two explicit scopes: one video via library_item_id or name, or the whole library within a day window. The purpose is unambiguous and no sibling tool overlaps with viewer analytics. It stops short of explicitly naming a contrasting sibling (e.g., get_library_item vs. this), so 4 rather than 5.

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

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

"by library_item_id or name ... or across your library" tells the agent exactly how to switch between single-video and library-wide modes, which is the key decision point. It gives no explicit when-not-to-use guidance or pointer to sibling tools for related tasks, so it lands at clear-context-without-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?

The annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds useful context that this applies to your own unsent draft, but it does not state whether removal is reversible, whether confirmation is required, or what errors occur for invalid or already-sent drafts.

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 words. It is appropriately sized for a simple one-parameter mutation 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 this simple destructive operation, the description covers the core purpose and timing constraint. However, with no output schema and no schema parameter descriptions, it does not explain where the draft_id comes from or what happens after withdrawal, leaving some gaps for an agent invoking a destructive mutation.

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

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

Schema description coverage is 0%, so the schema provides only the parameter name and type. The description does not explain what a draft_id is, how to obtain it, or whether it must be the caller's own draft, leaving the single parameter largely 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 states a specific verb and resource — 'Remove a draft' — and adds scope with 'you proposed before anyone sends it.' It is clearly distinguishable from listing or drafting siblings, though it does not explicitly name an alternative 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?

Usage is implied: use this to remove a draft that you proposed and that has not yet been sent. There is no explicit guidance on when not to use it, what to do if the draft was already sent, or which sibling to use instead.

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