LinkedIn MCP Server (Salesbot)

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

Annotations provide idempotentHint=true and no destructive hint. The description adds behavioral details: automatic blacklist/duplicate/manual exclusion checks, scheduling of steps, and return of added vs. filtered counts. This goes beyond annotations, fully disclosing the tool's behavior.

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

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

Three sentences, each serving a purpose: action, process, result. No wasted words. Front-loaded with the core action.

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

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

Given no output schema, the description compensates by stating the return value (added vs. filtered). The tool is simple; the description covers all needed aspects for an agent to use it correctly.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds context that contacts are added by ID and that automatic filters apply, complementing the parameter descriptions. It does not repeat schema info.

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

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

The description clearly states the action: 'Add selected contacts (by ID) to an existing campaign.' It uses a specific verb and resource, and distinguishes from sibling tools like 'create_campaign' or 'list_contacts' by focusing on adding to an existing campaign.

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

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

The description implies usage by describing automatic filtering (blacklist, duplicates, manual exclusion) and the scheduling of campaign steps. While it doesn't explicitly state when to use vs. alternatives, the context of sibling tools makes this less critical. It could benefit from an explicit 'when to use' statement.

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

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

Annotations already indicate non-destructive behavior. The description adds value by revealing that a key is automatically generated from the label and that 'type' defaults to 'text'. This provides behavioral context beyond what annotations cover.

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 pack all essential information: purpose with example, type enumeration with default, and key generation. No extraneous words, highly efficient.

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

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

Given only two parameters, no output schema, and annotations present, the description covers the tool's purpose, parameter types, defaults, and automatic key generation. It is sufficient for an agent to use the tool correctly, though it could mention success/error behavior.

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

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

Schema coverage is 100%, so both parameters are documented. The description adds meaning by explaining the purpose ('Add a custom field'), providing an example, and clarifying the default for 'type' and the key generation from 'label'. This enhances understanding beyond 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?

The description clearly states the action ('Add a custom field to CRM leads') with a specific example ('Budget' of type number). It distinctly differentiates from sibling tools like 'set_lead_fields' (which sets values) and 'add_crm_stage' (which adds stages), making the purpose unambiguous.

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

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

The description implies usage for creating new custom fields but does not explicitly state when to use this tool versus alternatives (e.g., 'set_lead_fields' for setting field values, 'list_crm_fields' for viewing). No guidance on when not to use it.

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

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

Annotations indicate it is a mutation (readOnlyHint=false) and not idempotent. The description adds behavioral details: 'a key is generated from it' and 'Appended to the end of the pipeline', which go beyond the annotations and help the agent understand side effects.

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

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

The description is two sentences, no wasted words. It front-loads the action and immediately gives an example. Every sentence adds meaningful information.

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

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

Given the tool's low complexity (2 parameters, no output schema), the description adequately covers behavior: what it does, parameter usage, and placement in pipeline. It lacks mention of return value, but that is acceptable since no output schema 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 schema covers both parameters with descriptions (100% coverage), so baseline is 3. The description adds value by clarifying that the label is shown as display name (with example), a key is auto-generated, and color is optional hex format. This extra context justifies a score above baseline.

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

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

The description clearly states the tool adds a new pipeline stage, with specific verb 'Add' and resource 'pipeline stage'. It provides an example label and distinguishes from sibling tools like rename_crm_stage or delete_crm_stage.

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 specifies the action but does not provide explicit guidance on when to use this tool versus alternatives, such as rename_crm_stage or delete_crm_stage. Usage is implied by context but no exclusions or when-not-to-use 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?

Discloses key behaviors beyond annotations: respects daily limits and allowed hours, optional edited_messages overwrite, quality check with automatic rewrite. No contradiction with annotations.

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

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

Three concise, well-structured sentences. Front-loaded with main action. No redundant information.

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

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

Adequately explains the approval process, optional edits, and quality check. Lacks details on return value or success state, but acceptable given no output schema and moderate complexity.

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

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

Adds meaning to edited_messages and skip_gpt_check beyond schema descriptions. Schema coverage is 100% but description clarifies that edited_messages overwrite specific drafts and that skip_gpt_check bypasses quality checks.

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?

Clearly states 'Approve a draft and hand it to the campaign executor for sending' with specific verb and resource. Distinguishes from sibling 'reject_message' and other campaign tools by focusing on approval.

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

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

Provides guidance on when to use the skip_gpt_check parameter and explains automatic rejection/rewrite behavior. Lacks explicit 'when not to use' but context is clear from sibling tool names.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false. The description adds the default status behavior ('defaults to done'), but does not disclose other behavioral traits like error handling or permission requirements, which is adequate for a simple update 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 concise sentences with front-loaded purpose. No extraneous words; every sentence adds value.

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

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

For a 2-parameter tool with no output schema and clear annotations, the description covers the essential behavior and usage context. It lacks details about error states or return value, but these are not critical for such a simple mutation 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?

Schema coverage is 100%, with both parameters having descriptions. The description restates the default status value, providing minimal additional meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Mark' and resource 'CRM task', specifying three possible status changes (done, reopen, cancel). This differentiates it from sibling tools like create_task and list_tasks.

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

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

The description provides explicit context: 'Use after a follow-up is handled.' It does not list alternatives or when-not-to-use, but the context is clear and distinct from other task-related 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 (readOnlyHint: false, idempotentHint: true, destructiveHint: false) indicate non-destructive, idempotent behavior. The description adds useful detail about the link format (white-labeled auth.salesbot.cz) and 2-hour validity, complementing the annotations without contradiction.

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

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

The description is concise with three sentences, each serving a purpose: main action, when to use, parameter details. No redundant information. Front-loaded with the core purpose.

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

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

For a simple tool with two optional parameters and no output schema, the description adequately explains the return value (link) and usage process. It covers the end-to-end workflow, though missing potential error scenarios.

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

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

Schema coverage is 100%, but the description adds value by stating defaults: 'profile_id defaults to active/first profile' and clarifies 'reconnect=true' is for reconnecting blocked/expired accounts. This exceeds baseline 3.

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

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

The description clearly states the tool generates a secure LinkedIn connect/reconnect link for browser authentication. It specifies the action ('generate a link') and resource ('LinkedIn connect/reconnect link'), and distinguishes from siblings like 'get_linkedin_status' and 'send_connection_request' by mentioning when to use it.

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 instructs to use the tool when 'get_linkedin_status shows not connected/blocked' or after specific errors. It explains the output is a link the user opens to complete login. While it doesn't explicitly state when not to use or mention alternatives, the guidance is clear and contextual.

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

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

Annotations already indicate non-readonly, but description adds crucial behavioral detail: the campaign is created as draft and not automatically active. This goes beyond annotation hints. No contradictions.

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

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

Description is concise (3 sentences) and front-loaded with key info: purpose, draft state, required params, step structure, return value, next step. No wasted words.

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

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

Covers all essential aspects: creation, draft status, step requirements, return of campaign_id, and a prompt for the next step. Complete for a creation tool lacking output schema.

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

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

Schema coverage is 100%, so baseline is 3. Description adds value by explaining step structure, defaults for use_ai and delay_hours, and the purpose of each parameter beyond the schema descriptions.

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

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

The description uses a specific verb ('Create'), names the resource ('campaign'), and clarifies it's saved as 'draft'. It distinguishes itself from sibling tools like start_campaign and add_contacts_to_campaign.

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 the campaign does NOT start sending until activated, and directs to use add_contacts_to_campaign next. Provides clear context for when to use this tool versus alternatives.

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

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

Annotations already indicate non-read-only and non-destructive. Description adds the plan restriction (Pro plan only) which is a critical behavioral constraint. No contradictions.

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

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

One sentence plus plan restriction, highly concise and front-loaded. Every part is useful.

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

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

For a tool with 4 parameters and no output schema, the description covers essential context: creation of follow-up tasks with optional lead linking and plan restriction.

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

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

Schema coverage is 100%, baseline 3. Description's example implicitly shows parameter usage (title, due_at, contact_id) but adds no new details beyond the schema.

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

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

The description clearly states the action 'create' and the resource 'task', with a concrete example that distinguishes it from siblings like 'complete_task' and 'list_tasks'.

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 mentions 'Pro plan only' constraint and optional linking to a lead, providing context for when to use contact_id. Does not explicitly exclude alternatives but the purpose 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 indicate destructiveHint=true and idempotentHint=true, but the description adds valuable context: stored values remain but are hidden. This goes beyond the annotations to clarify the non-destructive effect on existing data.

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

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

The description is concise, two sentences with no redundant information. The first sentence clearly states the primary action, making it front-loaded and efficient.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers the essential behavioral context (values remain) and is complete for an agent to understand the tool's effect.

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

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

With 100% schema description coverage and a single parameter, the schema already fully documents the 'key' parameter. The description adds no additional meaning beyond the schema, hence baseline score of 3.

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

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

The description clearly states the verb 'remove' and the resource 'custom field definition by key'. It also distinguishes itself from sibling tools like add_crm_field and list_crm_fields, and provides specific detail about the effect on existing data.

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

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

The description implies usage for deleting a custom field but does not explicitly state when to use this tool versus alternatives (e.g., when not to delete, or prerequisites). No exclusions or alternative tools are mentioned.

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?

Adds significant behavioral context beyond annotations: leads are moved to reassign_to or first remaining stage, and the restriction on deleting the last stage. No contradiction with annotations.

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

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

Two concise sentences with no waste. Front-loaded with the main action. Every word adds value.

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

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

For a tool with 2 parameters, no output schema, and no nested objects, the description covers all essential behavior: reassignment and the last-stage restriction. No gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds extra context about the reassign_to parameter's effect and the stage deletion constraint, improving understanding.

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

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

The description clearly states the action 'delete' and the resource 'pipeline stage'. It distinguishes from siblings like add_crm_stage and rename_crm_stage by specifying the deletion behavior.

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

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

Provides guidance on when to use: to delete a stage with optional reassignment of leads. Mentions the constraint of not deleting the last stage. Lacks explicit alternatives but sibling tools are listed.

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

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

Description discloses that it scrapes LinkedIn profiles, saves data onto the contact, and merges into profile_data. Annotations indicate non-destructive, idempotent, open-world. No contradictions; adds context about LinkedIn profile views.

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

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

Four sentences, front-loaded with purpose, then specifics, then usage guidelines, then limitation. Every sentence adds value, no redundancy.

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

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

Given tool complexity and no output schema, description covers purpose, parameters, usage context, behavioral limits, and return value ('Returns per-contact enrichment status'). Sibling tools list is large but description sufficiently differentiates.

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

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

Schema coverage is 100%, and description adds meaning: explains profile_id as UUID of LinkedIn account (defaults to active), contact_ids as UUIDs of contacts, and reinforces the batch limit. Provides rationale for max 8.

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

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

The description clearly states it enriches contacts with full LinkedIn profile data, listing specific fields (headline, location, experience, etc.). It distinguishes from sibling 'search_google_xray' by positioning itself as a follow-up step.

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 'Use after search_google_xray to flesh out lightly-saved leads.' Also states batch size limit (max 8 per call) and notes that each contact is a real LinkedIn profile view, implying cost/rate limits.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds that it returns up to limit rows as CSV. This is useful but not extensive behavioral detail beyond annotations.

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

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

Two efficient sentences: first states purpose, second adds usage guidance. No redundant or vague phrasing.

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

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

For a simple export tool with one parameter and safety annotations, description provides adequate context: output format, field scope, and limit. Could specify CSV structure more, but not critical.

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

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

Schema covers the single parameter 'limit' with description of default and max. Description repeats 'up to limit rows', adding no new semantics. Baseline 3 due to full schema coverage.

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

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

Description clearly states the tool exports CRM (leads with pipeline stage and key fields) as CSV text. It distinguishes from sibling tools by specifying the output format and mentioning a limit, which is unique among siblings.

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

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

Provides explicit guidance on when to use (for exports up to limit) and suggests an alternative (in-app download) for very large databases. Lacks explicit 'when not to use' beyond large databases but is sufficient.

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

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

Annotations already indicate non-destructive and non-read-only. The description adds behavioral context: the message is stored as a draft with status 'pending_approval' and waits for review. This goes beyond annotations by describing the lifecycle step. No contradictions.

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

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

The description is three sentences, front-loaded with the core action and key constraints. Every sentence adds value: the first states the action, the second clarifies the non-sending and status, the third provides next steps. No wasted words.

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

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

Despite lacking an output schema, the description thoroughly covers what the agent needs to know: the tool creates a draft, the resulting status, and the follow-up tools (list_pending_approvals, approve_message). It also references sibling tools, fitting into a workflow.

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

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

Schema coverage is 100%, with each parameter described. The description adds meaning beyond the schema by explaining the purpose of custom_instructions (appended to step's ai_prompt, e.g., tone or angle). This helps the agent understand how to use the optional parameter effectively.

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

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

The description clearly states the tool generates an AI personalized message draft for a specific campaign_contact and step, using the template and lead profile. It also explicitly distinguishes itself by stating what it does NOT do (the message is not sent; it is stored as a draft with status 'pending_approval'). This differentiates it from sibling tools like approve_message and save_lead_message.

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

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

The description provides explicit context on usage: generate the draft, then use list_pending_approvals + approve_message to release it. It gives a clear workflow. However, it does not explicitly state when NOT to use this tool or list alternative tools for different scenarios.

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?

Adds behavioral details beyond annotations: 'real time', 'newest last' ordering, and the `is_sender` flag in response. Consistent with readOnlyHint and idempotentHint 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?

Three concise sentences front-loading purpose, then usage context. No wasted words; every sentence adds value.

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

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

No output schema; description mentions response field `is_sender` but not full return structure. Adequate given simplicity and annotations, but could note pagination.

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

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

Schema coverage is 100% with parameter descriptions. Description does not add significant meaning beyond schema, but provides context for chat_id source.

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

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

Description clearly states 'Read the messages of a single LinkedIn conversation in real time', specifying the verb and resource. It distinguishes from siblings by referencing chat_id from list_inbox_chats and connecting to reply_to_chat.

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

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

Provides explicit context: use to understand conversation before composing a reply, and chat_id source. Does not list exclusions or alternatives, but guidance 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 provide readOnlyHint, idempotentHint, destructiveHint. Description adds no behavioral details (e.g., error handling, auth needs). With annotations, bar is lower, but no added context.

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

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

Two sentences, no fluff, front-loaded with verb and resource. Every sentence adds value.

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

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

Lists returned fields (no output schema), covers purpose and usage. Lacks error handling or edge cases, but sufficient for a simple retrieval 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?

Schema coverage is 100% with description for contact_id. Description does not elaborate on parameter beyond schema, but lists returned fields which aids understanding of output. Baseline 3.

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

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

Clearly states verb 'Return' and resource 'full contact profile', listing specific fields like name, headline, etc. Distinguishes from sibling tools (e.g., get_lead_context, list_contacts) by focusing on a single contact's rich profile.

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 'Used as context for personalized messages or next-step decisions' – clear when to use. Lacks explicit when-not or alternatives, but context is sufficient given sibling diversity.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds valuable behavioral details beyond annotations: what data is returned (usage vs limits, ramp-up, allowed hours, actions allowed) and the fallback behavior for missing profile_id. No contradictions.

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

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

The description is extremely concise: two sentences that first state the purpose and return values, then provide parameter semantics. Every sentence adds critical information without repetition or fluff.

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

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

Given the tool's simplicity (one optional param, no output schema), the description adequately covers inputs, behavior, and return details. It could optionally mention that the response structure (e.g., JSON keys) but the listed fields provide sufficient context for an agent to understand the output.

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

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

The schema covers profile_id with 100% description coverage. The description adds semantic value by explaining the optionality, default behavior (active or first profile), and the error case when no profile exists, which the schema alone does not convey.

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

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

The description clearly specifies the action ('Check remaining daily quota') and the resource ('a profile'), and lists specific return fields (usage vs limits, ramp-up status, allowed hours, actions allowed). It is distinct from sibling tools, which focus on contacts, campaigns, tasks, etc.

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 states when to use the tool (to check daily quota) and provides context on the optional profile_id parameter, including default behavior and error response. While it does not explicitly exclude scenarios, the tool's purpose is sufficiently scoped.

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, idempotentHint, destructiveHint false. Description adds that it returns applicant/view counts and uses connected LinkedIn account (Classic, no Recruiter). This provides additional context on data and access 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 concise sentences with no wasted words. Front-loaded: first sentence states purpose, second gives usage context, third adds behavioral details.

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

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

No output schema, so description must hint at return values. It mentions 'full details including hiring team, applicant and view counts'. While not exhaustive, it gives sufficient context for tool selection and understanding.

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

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

Schema has 100% coverage with description linking job_id to search_job_postings. Description reinforces this by mentioning 'after search_job_postings', but doesn't add new parameter semantics beyond schema.

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

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

Description clearly states it gets full details of a LinkedIn job posting, including hiring team. It differentiates from sibling search_job_postings by specifying it returns detailed information for a single posting.

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 'Use this after search_job_postings to find the exact person to reach out to', providing clear when-to-use guidance and sequencing.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral context by listing the extensive data returned (profile, pipeline stage, custom fields, saved messages, conversation summaries, tasks, LinkedIn interactions, stage history). No contradictions; it complements the annotations well.

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 consists of two sentences. The first sentence lists the fetched data in a run-on but comprehensive manner; the second provides a strong usage guideline. It is front-loaded and efficient, though the list could be slightly better structured for 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 tool with 2 parameters, 100% schema coverage, and annotations, the description covers the purpose and output categories adequately despite lacking an output schema. It includes usage context and lists the types of data returned, making it fairly complete for an agent to understand what to expect.

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

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

Schema coverage is 100%, with both parameters already described. The description adds practical meaning by implicitly using contact_id and mentioning 'recent conversation summaries' corresponding to notes_limit. It goes beyond the schema by providing usage context for the parameters.

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

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

The description clearly states the tool fetches 'full CRM context for a lead' and enumerates specific data types (profile, pipeline stage, custom fields, messages, etc.), using the specific verb 'Fetch' and resource 'lead context'. It distinguishes from siblings by recommending it as a first step for personalized outreach.

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

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

The description explicitly says 'Call this first for highly personalized outreach,' providing clear when-to-use guidance. It implies that the tool should be used before writing pitches or follow-ups, though it does not list alternative tools specifically. The context is sufficient for an agent to decide when to invoke 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 indicate safe, read-only operation. Description adds behavior: returns connection state and fix info, and explains default profile_id behavior.

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

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

Two sentences efficiently convey purpose, usage context, and parameter default. No wasted words.

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

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

Tool is simple with one optional param and no output schema. Description covers all needed context: purpose, usage triggger, return content, and 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 covers the parameter fully. Description adds that profile_id defaults to active/first profile, providing useful default behavior beyond schema.

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

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

The description clearly states the tool checks LinkedIn connection status and returns state with fix instructions. It distinguishes from sibling 'connect_linkedin' as a status check versus connection action.

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

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

Explicitly advises calling this tool when another returns specific error codes. Doesn't state when not to use, but sibling connect_linkedin provides alternative 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 already indicate readOnlyHint=true and destructiveHint=false. The description adds that the tool lists specific fields (ID, name, status, description, lead counts) and provides use case context. No contradictions.

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

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

Two sentences, front-loaded with the purpose, and immediate usage guidance. No unnecessary words. Every sentence earns its place.

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

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

For a simple list tool with one optional parameter and no output schema, the description is complete. It specifies returned fields and provides usage context for obtaining campaign_id.

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

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

The input schema has 100% description coverage for the single parameter 'status', including its enum values and optional nature. The description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states 'List your campaigns' with specific fields (ID, name, status, description, lead counts). It distinguishes from sibling tools like create_campaign by focusing on reading data and obtaining campaign_id for downstream operations.

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

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

The description explicitly says 'Use this to obtain campaign_id when adding leads, generating messages or approving drafts.' This provides clear context for when to use the tool, though it does not mention alternatives or when not to use it.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context by listing returned fields and the role of providing IDs, without contradicting annotations.

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

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

Two sentences front-load the purpose and key details. Every sentence adds value without redundancy.

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

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

Given the simple list operation and good schema/annotations, the description adequately covers purpose, return fields, and usage. The mention of output fields compensates for the lack of output schema.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema for parameters; it only mentions the list context.

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

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

The description specifies the verb 'List' and the resource 'contacts in a specific lead list', along with enumerated fields (ID, name, etc.). This clearly distinguishes it from sibling tools like get_contact_profile or enrich_contacts.

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 states that 'The AI picks IDs from this list for further tools', indicating when to use it. While it does not explicitly list alternatives, the clear purpose helps differentiate from similar 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 cover readOnlyHint, idempotentHint, destructiveHint. Description adds no extra behavioral context beyond listing, which is consistent with annotations.

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

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

Two sentences, efficient, no filler. Front-loaded with action and purpose.

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

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

For a simple list tool with no output schema, the description provides sufficient context including what is listed and how it relates to setting fields.

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

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

Zero parameters, schema coverage 100%. Baseline 4 applies since description adds nothing about params but none needed.

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

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

Clearly states it lists custom fields on CRM leads with key, label, type. Distinguishes from sibling tool set_lead_fields by referencing it.

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

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

Implies usage: list fields to know them before setting values with set_lead_fields. No explicit when-not-to-use, but siblings are distinct so no confusion.

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, indicating a safe read operation. The description adds that the tool returns lead counts per stage, which is beyond what annotations provide, offering useful behavioral context.

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

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

The description is two sentences, front-loaded with the primary purpose and output, with no unnecessary words.

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

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

Despite no output schema, the description lists the return fields (key, label, order, color, lead counts) and references sibling tools, making it complete for a simple list operation.

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

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

The tool has zero parameters, and schema description coverage is 100% (trivially). Per rubric, baseline for 0 parameters is 4.

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

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

The description clearly states the purpose as listing CRM pipeline stages with specific fields (key, label, order, color) and lead counts, distinguishing it from sibling tools like add_crm_stage or delete_crm_stage.

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

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

The description mentions that stages are user-configurable and points to other crm_stage tools for modifications, providing context. However, it does not explicitly state when to use this tool versus alternatives but it is implied.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by noting real-time nature, that message preview text may be missing, and that profile_id defaults to active profile. No contradictions.

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

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

The description is concise, front-loaded with purpose, and includes essential caveats (like missing preview text). No unnecessary words, every sentence adds value.

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

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

For a simple read-only list tool with three optional parameters and no output schema, the description provides sufficient detail: return fields, usage hints, parameter defaults, and pagination cursor. No gaps.

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

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

Schema description coverage is 100%; parameters have clear schema descriptions. The description does not add significant new meaning beyond the schema, e.g., for limit and cursor. Baseline 3 is appropriate.

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

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

The description clearly states the tool lists recent LinkedIn inbox conversations in real time, specifies exact return fields (chat_id, attendee provider id, unread count, last-message timestamp), and distinguishes from sibling tools by mentioning chat_id usage in get_chat_messages and reply_to_chat.

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

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

The description explains when to use this tool (list chats) and when to use alternatives (get_chat_messages for actual message text). It also notes that profile_id defaults to active profile, providing clear context. However, it does not explicitly exclude other tools like list_lead_messages.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful context beyond annotations by stating the scope (authenticated user's data), the returned fields, and that the returned list_id can be passed to list_contacts. No contradiction with annotations.

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

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

Two sentences with no filler. The first sentence states what the tool returns; the second provides the cross-tool usage direction. Every word earns its place.

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

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

There is no output schema, so describing the returned fields is essential and the description does exactly that. For a zero-parameter, read-only list operation, this is complete and even connects to the next logical step via list_contacts.

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?

This tool has zero parameters, so the schema fully covers parameter semantics. The description still adds value by explaining what the output contains, which is the main semantic detail an agent needs for this no-argument call.

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

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

The description starts with the specific verb 'List' and identifies the exact resource: 'the authenticated user's contact groups (lead lists)'. It also enumerates the returned fields (list_id, name, description, contact count), making it immediately distinguishable from list_contacts and other sibling tools.

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

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

The description gives concrete downstream guidance: 'Use list_id with list_contacts to retrieve the contacts in a specific group.' It does not explicitly contrast this tool with other list tools beyond that, so it doesn't earn a 5, but the chaining instruction is clear and actionable.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds ordering ('newest first') and clarifies that it retrieves drafts and follow-ups, providing useful behavioral 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 concise with two sentences. The first sentence defines the tool's purpose and behavior, the second gives a usage guideline. No unnecessary words or repetition.

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

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

Given the rich annotations and well-documented schema, the description provides sufficient context for the tool. It covers the key aspects of listing lead messages without requiring explanation of return values (no output schema).

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

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

The input schema covers all 4 parameters with descriptions (100% coverage). The description mentions optional filters by channel or kind, adding minimal extra meaning. Baseline 3 is appropriate as the schema already does the heavy lifting.

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

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

The description clearly states the verb 'list', the resource 'stored outreach messages saved on a CRM lead', and specifies ordering ('newest first'). It effectively distinguishes the tool from siblings like list_contacts or list_campaigns by focusing on lead 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?

The description provides a clear use case ('pull the copy back out of the CRM before sending it via the right channel') and mentions optional filters. While it doesn't explicitly state when not to use the tool, the context is sufficient for an AI agent to infer appropriate usage.

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

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

The description adds context about the returned fields and purpose beyond the annotations (readOnlyHint, destructiveHint, idempotentHint are already present). No contradictions; it explains the function without repeating annotation details.

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

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

The description is concise with two efficient sentences, front-loading the core purpose and then adding context and optional filter.

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 2 parameters and good annotations, the description sufficiently covers usage context and filtering. No output schema is present, but the description mentions the included fields, which is adequate.

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

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

Schema coverage is 100% with descriptions for both limit and campaign_id. The tool description rephrases these but doesn't add new semantic detail, meeting the baseline expectation.

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

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

The description clearly states the tool returns AI drafts waiting for approval with a specific condition (messages_approved=false) and lists the fields included. This distinguishes it from siblings like approve_message or reject_message.

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

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

The description explains the tool is for bulk review by an AI assistant to iterate and approve/reject drafts, and mentions optional campaign_id filtering. It provides clear context but does not explicitly state when not to use it.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds filter defaults and return fields but no additional behavioral insights beyond what annotations and schema provide.

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

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

Two sentences, front-loaded with the action, no wasted words. The structure efficiently conveys purpose, filters, and return fields.

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

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

For a simple list tool with no output schema, the description adequately covers all relevant aspects: what it lists, available filters, default behavior, and returned fields.

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

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

Schema coverage is 100%, and the description only reiterates filter options and default status already documented in the schema, adding minimal new meaning.

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

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

The description clearly states the verb 'List', the resource 'your CRM tasks', and includes filtering options, distinguishing it from sibling list tools like list_contacts or list_campaigns.

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

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

It explicitly says 'Use to see what follow-ups are outstanding', providing clear usage context, but does not mention when not to use or suggest alternative tools like complete_task.

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

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

Annotations show readOnlyHint=false and destructiveHint=false, consistent with a write operation. The description adds that the note builds durable context for follow-ups and is stored separately from raw history, providing useful behavioral 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 two sentences plus a parenthetical, front-loaded with the main action. Every sentence adds value: purpose, usage instructions, storage detail. No wasted words.

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

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

For a simple write tool without an output schema, the description adequately covers purpose and parameter guidance. It does not explain return values or post-logging behavior, but that is acceptable for such a 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?

Schema coverage is 100% so baseline is 3. The description adds value by guiding the agent to derive pain points and sentiment from the conversation, thereby enriching the meaning of those parameters.

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

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

The description clearly states the tool saves a structured summary into the CRM for a lead. It distinguishes from siblings like save_lead_message by noting it is stored separately from raw LinkedIn message history, and instructs the agent to analyze context before calling.

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

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

The description explicitly tells the agent to analyze the chat/context first, then call the tool with a summary, pain points, and sentiment. It implies when to use (after analysis) versus raw message logging, but does not provide explicit when-not or list 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 provide readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds minimal behavioral context beyond stating it marks as read, which is already implied. No contradictions.

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

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

Two concise sentences. First sentence states purpose and key identifier. Second provides usage motivation. No wasted words.

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

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

For a simple idempotent mutation with good annotations and a clear single purpose, the description is complete. No output schema needed for such a 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?

Schema covers both parameters with descriptions (chat_id source, profile_id optional). Description adds no further parameter-level details. With 100% schema coverage, baseline of 3 is appropriate.

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

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

Description clearly states the action ('mark as read') on a specific resource ('LinkedIn conversation') by a clear identifier ('chat_id'). It differentiates from sibling tools like reply_to_chat or get_chat_messages by focusing on the read-status operation.

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

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

Explicitly suggests usage after processing a thread to prevent re-surfacing as unread. This provides clear context for when to invoke, though it does not list explicit alternatives or when-not-to-use.

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

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

Beyond the annotations (readOnlyHint=false, etc.), the description discloses important behaviors: default draft, auto_publish respects MCP setting, and a random anti-detection delay before publishing. These details help the agent understand what happens during invocation.

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

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

The description is concise at four sentences, with the main action stated first. Each sentence provides necessary detail without redundancy. The structure is logical and easy to parse.

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

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

The description covers the core workflow, limitations (no attachments), and edge cases (MCP approval). While no output schema exists, the description doesn't elaborate on return values, but that is acceptable given the tool creates a resource. The description is sufficiently complete for an agent to use it correctly.

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

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

The input schema covers all parameters with descriptions, but the tool description adds context: text is plain text without Markdown, profile_id must be a connected LinkedIn account, auto_publish behavior and interaction with MCP approval, external_link as optional URL, and as_organization requiring admin rights. The anti-detection delay is also noted.

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

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

The description clearly states the tool's purpose: creating a LinkedIn post on behalf of a connected profile. It distinguishes between saving as draft and immediate publishing, and notes that attachments are not supported. This differentiates it from sibling tools like send_linkedin_message.

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

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

The description explains the default behavior (draft) and the auto_publish option with its interaction with MCP approval settings. While it doesn't explicitly state when not to use this tool, it provides sufficient context for typical usage.

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 indicate idempotentHint and readOnlyHint false, but description adds the behavioral trait of resetting generation_status to 'pending', which provides context beyond the annotations. No contradictions.

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

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

Two tightly written sentences with no extraneous information. The key action and effect are front-loaded.

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

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

Despite no output schema, the description fully explains the tool's purpose, parameters, and side effects. Given low complexity (2 params), it is 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 covers 100% of parameters with descriptions. The description adds the meaning of 'reason' as regeneration feedback, providing beyond-schema value.

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

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

The description clearly states the action (reject), the resource (current drafts on a campaign_contact), and the effect (resets generation_status to 'pending'). It distinguishes from siblings like 'approve_message'.

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

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

The description implies when to use (to reject drafts with feedback for regeneration) and when not to use (when wanting to approve, as 'approve_message' is a sibling). However, it lacks explicit 'when not to use' statements.

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 indicate the tool is not readOnly, not destructive, and idempotent. The description adds that the stage key and leads are unchanged, which clarifies the non-destructive nature and provides behavioral context beyond annotations.

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

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

The description is two sentences and front-loads the main purpose. Every word serves a purpose—no fluff, no redundancy. It efficiently conveys the tool's function and key constraints.

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

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

For a simple mutation tool with no output schema, the description covers all essential information: what changes, what remains unchanged, and how to obtain the required key. No gaps are present.

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

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

All parameters are documented in the schema (100% coverage). The description adds context by noting that key comes from list_crm_stages and that color expects a hex value, providing practical usage hints.

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

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

The description clearly states the tool renames a stage's label and/or changes its color. It specifies the resource (CRM stage) and the operations, and distinguishes from sibling tools like add_crm_stage, delete_crm_stage, and list_crm_stages by focusing on cosmetic updates.

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 says to use list_crm_stages to get keys, providing explicit guidance for preparing input. It implies usage for cosmetic changes to stage properties, but does not explicitly exclude cases like reordering or moving leads, though the sibling set_deal_stage handles that.

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

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

The description extensively discloses behavioral traits beyond annotations: allowed hours, human-in-the-loop queuing, random delay, idempotency guard, prompt-injection scanning, rate limits. Annotations already indicate non-readOnly, open world, non-idempotent, non-destructive; description adds critical operational details without contradiction.

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

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

The description is somewhat lengthy but every sentence adds necessary information. It is well-structured, front-loading the core purpose, then detailing constraints and behaviors. Minor redundancy could be trimmed, but overall it justifies its 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?

Given no output schema, the description fully covers return conditions (OUTSIDE_ALLOWED_HOURS, queuing, direct send, refusal). It addresses edge cases (idempotency, injection scan) and contextual effects (daily limits, MCP throttle). Very comprehensive.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds minor context (chat_id from list_inbox_chats, message max 5000 chars, profile_id optional) but does not significantly expand on the schema's own descriptions.

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

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

The description clearly states the action ('Send a reply into an existing LinkedIn conversation') and the required identifier ('by chat_id'). It distinguishes this tool from siblings like send_linkedin_message (which creates new conversations) by focusing on replying to existing chats.

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

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

The description explains when to use the tool (to reply to an existing chat) and provides important constraints (allowed hours, human-in-the-loop, prompt-injection scanning). However, it does not explicitly mention when not to use it or indicate alternatives among siblings (e.g., send_linkedin_message for new messages).

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 (readOnlyHint=false, destructiveHint=false) are consistent. Description adds crucial context: the CRM is a 'sponge', no sending occurs, and message_id enables updating drafts. No contradictions.

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

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

Two sentences with no wasted words. First sentence explains purpose with examples, second clarifies non-sending and update capability. Front-loaded and efficient.

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

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

For a 7-parameter tool with no output schema, the description fully covers the workflow (save-then-push), mentions sibling tools for reading and sending, and explains the status lifecycle. No gaps.

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

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

Schema coverage is 100%, so baseline is 3. Description adds guidance on status field ('set sent after push') and clarifies that message_id updates instead of creates. This extra context raises the score.

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

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

The description clearly states the tool stores a generated outreach message on a CRM lead, with specific examples (email, follow-up, LinkedIn). It distinguishes from siblings by explicitly saying it does not send, and mentions updating via message_id.

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

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

The description explains when to use: after generating copy, save here. It warns 'Does NOT send anything' and directs to channel-specific tools for sending. It also names complementary read tools (get_lead_context, list_lead_messages).

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

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable details: returns plain text (HTML stripped, truncated) and emails, treats content as untrusted data (security warning), rate-limited to weekly quota, and refuses private URLs. No contradictions with annotations.

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

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

The description is concise (3 sentences) and front-loaded with purpose. Every sentence adds distinct value: purpose, return format & security note, and constraints (rate limit, private refusal). No redundant or vague 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?

Given the tool's simplicity and strong annotations, the description covers purpose, usage, return values, security, and constraints. It lacks only an explicit output schema reference, but the description adequately describes what is returned. For a straightforward fetch tool, this is sufficient.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description reinforces the 'public http(s)' nature of the URL and mentions default/max for max_chars implicitly via schema. It does not add new parameter details beyond what the schema provides, meeting the baseline.

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

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

The description clearly states the verb 'Fetch', the resource 'PUBLIC web page', and the use case 'context when writing/editing messages'. It provides concrete examples (prospect's website, article) and distinguishes from internal pages by emphasizing 'PUBLIC' and noting private addresses are refused.

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

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

The description gives clear when-to-use guidance ('when writing/editing messages', 'read a prospect's website or an article') and an explicit exclusion ('private/internal addresses are refused'). It does not directly mention sibling tools as alternatives, but the context is clear enough for an agent to decide.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, so the description adds critical behavior beyond that: found profiles are saved into contacts, deduplicated by profile URL, and leads are UNVERIFIED cached snippets. It also reveals the JSON return shape, including rejected_low_quality, giving the agent a realistic model of side effects and data trust.

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

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

The description is dense but every sentence serves a purpose: purpose, usage scenario, targeting trick, side-effect, return format, sibling comparison, data quality warning, and follow-up actions. It is front-loaded with the core purpose and does not waste words on redundant 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?

With no output schema, the description thoroughly explains the return JSON and key contact fields. It also covers side effects, data freshness, and downstream CRM steps, making it nearly self-sufficient for an agent to correctly invoke and interpret the tool. The only minor gaps like pagination or error handling are not critical for a search 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?

Input schema covers all 5 parameters, so baseline is 3. The description provides a meaningful semantic addition by explaining that 'put the name/company in `keywords`' lets the tool target a specific person. This goes beyond the schema's generic 'Additional keywords' wording. Other parameters rely on the schema, which is acceptable at 100% coverage.

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

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

The description states a specific verb and resource: 'Google X-Ray search for public LinkedIn profiles via Google operators (site:linkedin.com/in).' It clearly distinguishes itself from search_linkedin_people by naming the different return fields (contacts/profile_url vs results/linkedin_url), so an agent can tell them apart.

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

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

The description explicitly says when this is useful: 'when you don't want to consume LinkedIn search limits.' It also provides a concrete alternative for CRM follow-up: 'add_contacts_to_campaign ... or use a CRM tool like set_deal_stage.' The sibling comparison with search_linkedin_people adds clarity for choosing the right search tool.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description adds value by specifying that it uses the connected LinkedIn account and performs a classic search. No contradictions.

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

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

The description is concise (two sentences), front-loaded with the core purpose, and includes a helpful benefit statement. No wasted words.

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

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

The tool has 9 parameters (1 required) and no output schema. The description mentions return of job offers with company info but lacks details on pagination or response structure. However, given the annotations and schema coverage, it is largely complete.

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

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

The input schema has 100% description coverage for all 9 parameters. The description provides a high-level summary of filter types but does not add significant detail beyond the schema. Baseline of 3 is appropriate.

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

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

The description explicitly states the tool searches LinkedIn job postings with various filters and returns job offers with company info. It clearly distinguishes from sibling tools like search_linkedin_people and search_linkedin_navigator by focusing on job postings.

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

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

The description provides context on when to use the tool (finding actively hiring companies) and notes the account requirements (Classic search, no Recruiter needed). It does not explicitly mention when not to use it, but the context is clear given the sibling tools.

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

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

The description adds valuable behavioral details beyond the annotations: the exact return shape, the critical nuance that linkedin_url (not profiles/url) is the profile URL, and the fact that this tool does not persist results. This is the kind of context that prevents misuse and is not covered by readOnlyHint or openWorldHint.

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 efficient and well-structured: it front-loads the core action, then explains the return format, flags a likely point of confusion, and concludes with the follow-up action. Every sentence earns its place with no filler.

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

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

Since there is no output schema, the description fully covers the return structure and field names, which is essential. It also clarifies side effects and the next step for persisting results. The only omission is a direct comparison to sibling search tools, but this is a minor gap given how explicit the rest is.

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

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

Schema coverage is 100% and both parameters (search_url and limit) already have clear descriptions. The description does not add parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Scrape') and a clear resource ('Sales Navigator (or standard LinkedIn) search URL'), making the tool's function immediately obvious. It also differentiates from siblings by explicitly stating it does not save results as contacts and redirecting to upsert_linkedin_contact for persistence.

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

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

It gives clear context for when to use the tool: when you have a Sales Navigator or LinkedIn search URL to scrape. It also provides explicit next-step guidance for saving profiles via upsert_linkedin_contact. However, it does not directly contrast with alternatives like search_linkedin_people or other search tools, so it stops short of a 5.

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

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

Goes well beyond the annotations by explaining the ordered-title execution behavior ('tries them one at a time and stops at the first that returns anyone'), the `company_filter.mode` fallback between `current_company` and `keyword_fallback`, and the critical return-field warning to read `linkedin_url` rather than `profiles`/`url`. It also discloses that the tool does not save contacts and that upsert is required next.

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

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

The description is long but dense and front-loaded with the core purpose before diving into parameter behavior and return shape. Nearly every sentence carries useful information, though the density of return-format details and inline examples makes it slightly heavy to parse at a glance.

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

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

For a tool with 8 parameters, no output schema, and non-obvious behavior like title priority and company-filter fallback, the description is exceptionally complete. It explains the full JSON response, per-result fields, the meaning of `matched_title` and `company_filter.mode`, the not-saving behavior, and the follow-up action via `upsert_linkedin_contact`, leaving almost no ambiguity.

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

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

Even though schema coverage is 100%, the description adds substantial meaning: `titles` is an ORDERED priority list with CZ/EN variant guidance and the '~3 tried per call' runtime limit; `company` is a name resolved to LinkedIn's CURRENT COMPANY filter; `location` vs `locationId` usage is clarified. This materially helps an agent choose and format parameters correctly.

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

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

The description opens with a specific verb and resource: 'Search people on LinkedIn by job title(s), current company and location.' It clearly distinguishes this from sibling tools like search_linkedin_navigator and upsert_linkedin_contact by stating it performs people search and explicitly does not save contacts.

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

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

Provides strong usage direction: pass `company` to filter current workers, pass `titles` for decision-maker discovery, and call `upsert_linkedin_contact` to actually save profiles. It lacks an explicit 'when not to use this vs. search_linkedin_navigator' statement, but the next-step routing to upsert and the clear parameter guidance are highly actionable.

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. Description adds that results are not saved to contacts, which is useful context beyond annotations. No contradictions.

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

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

Two sentences front-loaded with purpose, followed by usage examples and a critical behavioral note. Every sentence adds value with no 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?

No output schema, but return format (organic results) is implicit from the description. Sufficient for an agent to use correctly given the simplicity of the 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?

Schema coverage is 100% with descriptions for each parameter. Description does not add significant meaning beyond the schema, but mentions operators which are already described. Baseline 3 is appropriate.

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

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

Clearly states 'General-purpose Google search — returns organic results for any query.' Distinguishes from sibling search_google_xray by noting it is LinkedIn-only. Verb and resource are specific.

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

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

Explicitly tells when to use: for finding job postings, company info, news, etc. Also states when not to use: results are not saved to contacts. Sibling differentiation is clear.

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

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

The description discloses critical behavioral traits beyond annotations: always empty message (to avoid blocks), daily limits, allowed hours, blacklist, random delays, and usage tracking. Annotations only provide basic hints; this adds substantial context.

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

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

Two sentences: first states purpose, second lists constraints. Front-loaded, no unnecessary information, every sentence adds value.

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

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

The description covers input behavior and constraints thoroughly. It does not mention possible errors or return values, but given no output schema, this is acceptable. Still, a brief note on success/failure indicators would enhance completeness.

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

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

Schema coverage is 100% with descriptions for each parameter. The overall description does not add further parameter-level meaning, so baseline 3 applies.

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

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

The description clearly states the tool sends a LinkedIn connection invitation. It distinguishes from siblings like send_linkedin_message by explicitly noting that the message is always empty, a key differentiator.

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

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

The description provides context on when to use (for connection requests) and mentions constraints (daily limits, allowed hours, blacklist, random delays). However, it does not explicitly name sibling tools like send_linkedin_message as alternatives for sending messages with text.

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

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

Annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false) indicate mutation but no destruction. The description adds critical behavioral details: a random 30–180 s delay for anti-detection, counts against daily message limit, respects allowed hours, and is logged. This is valuable context beyond annotations.

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

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

Two efficient sentences, front-loaded with purpose, no redundant words. Every sentence adds value.

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

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

Despite no output schema, the description covers all relevant behavioral aspects (delay, limits, logging), making it complete for the agent to understand what the tool does and what side effects occur.

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

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

Schema coverage is 100% (all three parameters have descriptions). The description does not add further meaning beyond the schema—e.g., it repeats the max 5000 chars for message but does not explain how linkedin_id or profile_id are used beyond schema.

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

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

The description clearly states 'Send a one-off LinkedIn message to a specific contact outside any campaign'. It uses a specific verb+resource (send message) and distinguishes from campaign-related tools by specifying 'outside any campaign'.

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

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

The description explains when to use this tool (outside campaigns) and mentions it counts against daily limits and respects allowed hours. However, it does not explicitly state when not to use it or list alternatives beyond the sibling tool 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 already indicate idempotentHint=true (safe to retry) and destructiveHint=false (no destructive actions). The description adds that it 'Logs who changed it and an optional note to the deal history', disclosing additional side effects. No contradiction with annotations is present.

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

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

The description is three sentences long, with the core action in the first sentence. Every sentence provides value: main purpose, usage trigger, and logging behavior. No redundant or extraneous 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?

For a tool with 3 parameters, no output schema, and rich annotations, the description covers the primary use case, gives example triggers, and notes key behavioral traits like logging. It could mention error handling for invalid stages, but the reference to 'list_crm_stages' mitigates this. Overall complete and helpful.

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

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

Schema description coverage is 100%, so baseline is 3. The description reiterates default stage keys from the schema ('prospect, contacted, demo, won, lost') and notes 'Optional context for the history log' for the 'note' parameter. It adds no new meaning beyond what the schema already provides.

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

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

The description clearly states 'Move a lead to a different pipeline stage', specifying the verb 'move' and the resource 'lead to stage'. It distinguishes from siblings like 'add_crm_stage' or 'rename_crm_stage' by focusing on moving a lead through stages, not manipulating the stage definitions themselves.

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

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

The description explicitly says 'Call when the user confirms a real-world event in plain English (like 'they booked a demo')', providing clear guidance on when to invoke the tool. It also references 'list_crm_stages' for valid stage keys, but does not explicitly state when not to use it, leaving some ambiguity.

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

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

Description adds beyond annotations by noting the side effect of adding the lead to CRM if needed, and does not contradict any annotations.

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

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

Two sentences, front-loaded with main purpose, no wasted words.

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

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

Given no output schema, description adequately explains behavior (sets fields, adds lead if needed) and directs to list_crm_fields for valid keys. Complete for a mutation 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?

Schema coverage is 100%, description adds value by clarifying the format for fields parameter as an object mapping. Contact_id is already clear from schema.

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

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

The description clearly states it sets custom field values on a lead by contact_id, distinguishing it from sibling tools like update_contact or add_crm_field.

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

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

Provides explicit guidance on passing fields as an object, referencing list_crm_fields for accepted keys, and noting it adds the lead to CRM if needed. Lacks explicit 'when not to use' but overall strong.

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 (readOnlyHint=false, destructiveHint=false, idempotentHint=true) are complemented by description detailing that it schedules actions, changes status, and respects daily limits and delays. No contradictions.

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

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

Two sentences: first defines action and effect, second gives prerequisites and constraints. No wasted words, front-loaded.

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

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

For a simple tool with one parameter and no output schema, the description covers purpose, prerequisites, and constraints fully.

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?

Only one parameter (campaign_id) with full schema description coverage (100%). The description does not add additional parameter details beyond the schema, so baseline of 3 is appropriate.

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

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

The description clearly states the verb 'start' (activate) and the resource 'an existing campaign', and specifies the effects: schedules actions and sets status to 'running'. It distinguishes from siblings like stop_campaign and create_campaign.

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

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

The description gives explicit prerequisites: campaign must already have contacts (via add_contacts_to_campaign) and steps. It also notes constraints like daily limits and delays. Could explicitly mention not to use if already running, but implied.

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

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

Adds detail beyond annotations: cancels pending scheduled actions via DB trigger. Annotations already indicate destructive and idempotent. Description confirms and elaborates without contradiction.

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

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

Two sentences, front-loaded with primary action. No wasted words. Efficient and easy to scan.

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

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

For a simple tool with one parameter and no output schema, the description sufficiently explains the effect (status change, action cancellation) and provides alternative. No gaps.

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

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

Schema coverage is 100% with a clear description of campaign_id as UUID. Description does not add additional parameter meaning, meeting baseline for high 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?

Clear verb ('stop') and resource ('campaign') with specific results: sets status to 'stopped' and cancels pending scheduled actions. Distinguishes from sibling tool update_campaign_settings for pausing.

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 when to use (to stop a running campaign) and when to use alternative (update_campaign_settings for temporary pause). Also explains the effect on scheduled actions.

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

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

Annotations indicate idempotentHint=true and destructiveHint=false. The description adds that only provided fields are changed, reinforcing idempotency. No contradiction; transparency is adequate but doesn't detail error cases or side effects.

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

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

Two sentences, front-loaded with the overall purpose, then details. No fluff; every word earns its place.

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

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

With no output schema and 7 parameters (1 required), the description covers core behavior and field semantics. It lacks return value info but is sufficient for basic usage. Consider adding ownership prerequisite explicitly.

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

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

Schema description coverage is 100%, so baseline 3. The description adds value by explaining enum semantics for status (pause/resume) and reiterates that only provided fields are changed, which clarifies partial update 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 clearly states the tool updates settings of an existing campaign the user owns, listing specific fields (name, description, daily_limit, etc.). It distinguishes from sibling tools like create_campaign, start_campaign, and stop_campaign by focusing on settings updates, not lifecycle actions.

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

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

The description implies ownership prerequisite and provides examples for status transitions (pause/resume). It doesn't explicitly exclude alternatives like start_campaign or stop_campaign, but the context is clear: this tool updates multiple settings, not just status.

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

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

States that only passed fields are changed ('omit the rest'), consistent with idempotentHint=true. No contradiction with annotations. However, does not disclose any authorization requirements or return behavior.

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

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

Three sentences with no wasted words. Front-loaded with verb and resource, then lists updatable fields, then usage guidance and key behaviors.

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?

Adequate given low complexity—no output schema, but the operation is straightforward. Could mention the return value (e.g., updated contact object) but not required.

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

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

Schema coverage is 100% and each parameter has a clear description. The description adds value by explaining that only provided fields are updated, which is not explicit in the schema.

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

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

Description explicitly states 'Update a lead's contact details' and lists the specific fields (email, phone, location, company, position, headline). This clearly differentiates from sibling tools like 'set_lead_fields' or 'enrich_contacts'.

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

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

Provides explicit use case: 'Use to enrich a lead (e.g. save an email address you found).' Also clarifies that it does not create contacts, but does not mention when to use alternatives like 'create_contact'.

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 provide idempotent and non-read-only hints, but the description adds valuable behavioral context: existing contacts are returned, web_research and personalization_note are merged rather than overwriting, and contacts are saved to a dedicated CRM Imports list. No contradiction with annotations.

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

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

The description is about four sentences and every sentence earns its place: purpose, usage condition, downstream workflow, and merge semantics. It is dense but not bloated.

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 an upsert tool with rich annotations and full schema coverage, the description covers purpose, side effects, parameter behavior, and downstream usage well. The lack of an output schema is partially mitigated by the 'return the existing contact' clause, though a bit more detail about what the tool returns would strengthen 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?

Schema coverage is 100%, so the schema already documents each parameter. The description adds extra meaning for web_research and personalization_note by explaining they are stored on the contact and fed to the LinkedIn message generator, plus the merge behavior on existing contacts.

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 contact from a LinkedIn profile URL, or return the existing contact if already imported. It clearly conveys the upsert semantics and distinguishes this from search-oriented tools like search_linkedin_people.

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

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

It explicitly says to use this tool when the exact profile URL is already known and no search is needed, and it mentions the downstream workflow via add_contacts_to_campaign. It does not name a specific alternative tool explicitly, so it stops just short of a 5.

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