LinkedIn MCP Server (Salesbot)

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

With no annotations, the description carries full burden. It discloses automatic blacklist, duplicate checks, manual exclusion, and scheduling of campaign steps with daily limits. It also mentions return value (added vs filtered). Missing details on permissions or failure modes, but sufficient for safe usage.

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: first states primary action, second covers automatic filters, third details scheduling and return. No redundant information; efficient and front-loaded.

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

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

Given no output schema and moderate complexity (filtering, scheduling), the description covers key aspects: what happens during addition, automatic checks, and what is returned. Minor gaps remain (e.g., meaning of 'manual exclusion'), but overall 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 description coverage is 100% with clear UUID descriptions. The description adds no new parameter-specific meaning beyond restating that contacts are added by ID. Baseline score of 3 applies as schema already explains 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 adds contacts to an existing campaign by ID, distinguishing it from sibling tools like create_campaign or list_contacts. It specifies the action and resource uniquely.

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 adding contacts to campaigns and notes automatic filtering (blacklist, duplicate checks), which guides appropriate context. However, it lacks explicit when-to-use or when-not-to-use guidance relative to siblings.

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

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

No annotations provided, so the description carries full burden. It mentions key generation from label but omits details like idempotency, validation, 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?

Three sentences with no redundancy, front-loaded with action and resource, efficient and clear.

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 creation tool with 2 params and no output schema, the description covers the action, parameters, and key generation. Lacks error conditions or response format, but 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%, but description adds value by providing an example, listing allowed types, stating default type 'text', and explaining key generation from label.

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 and allowed types, distinguishing it from sibling tools like list_crm_fields or set_lead_fields.

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

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

No explicit guidance on when to use this tool versus alternatives like set_lead_fields or delete_crm_field. The purpose is implied but not compared.

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

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

No annotations provided, so description carries burden. Discloses that stage is appended, key is auto-generated, but does not mention permissions, side effects, 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 concise sentences, each adding information. No redundancy or fluff. Front-loaded with main 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?

For a simple creation tool with 2 params and no output schema, the description covers the main points. Could mention what is returned (e.g., the new stage object) but not mandatory.

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 params with descriptions. Description adds value: explains key generation from label and hex color format. Enriches parameter 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?

Description uses clear verb+resource ('Add a new pipeline stage') and specifies key details (label, key generation, optional color, appending to end). Differentiates from siblings like rename/delete.

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 for adding a pipeline stage but no explicit when-to-use or alternatives. Sibling names provide context but description itself lacks guidance.

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

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

With no annotations, the description bears full burden. It discloses key behaviors: it respects daily limits and allowed hours, optionally overwrites drafts, performs a default quality check, and sends back for rewrite on rejection. It does not mention authentication requirements or side effects, but the main behavioral traits are covered.

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

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

The description is concise (3 sentences) and front-loaded with the main purpose. Every sentence adds valuable information: purpose, optional edits, quality check behavior, and fallback action. 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 description fully explains the approval process, including optional edits, the quality check, and the rewrite loop. It is complete for a tool with 3 parameters and no output schema, covering all relevant 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%, baseline 3. The description adds meaning beyond the schema: it explains that skip_gpt_check bypasses the quality check and that edited_messages overwrites specific drafts. This provides context not evident from parameter names 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 (approve a draft), the specific resource (draft message), and its outcome (handed to campaign executor for sending). It distinguishes from sibling tools like 'reject_message' and 'list_pending_approvals' by focusing on approval and mentioning the quality check and rewrite loop.

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 approve a draft) and provides context on optional parameters (edited_messages, skip_gpt_check) and the quality check behavior. However, it does not explicitly state when not to use it or compare to alternatives like 'reject_message' or 'list_pending_approvals'.

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

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

No annotations provided, so description carries full burden. It discloses the three possible statuses and default, but lacks details on potential side effects or system changes beyond status update.

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 waste. Front-loaded with main action ('Mark a CRM task done'), then provides parameter guidance and usage context.

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

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

Given the tool's low complexity (2 parameters, no nested objects), the description is nearly complete. Could mention return value or confirmation, but not critical for this simple mutation.

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

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

Schema description coverage is 100%, and the description adds value by explaining the default behavior ('status defaults to 'done'') and clarifying the options 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 verb ('Mark', 'reopen', 'cancel') and resource ('CRM task'), and distinguishes from sibling tools like 'create_task' (creation) and 'list_tasks' (listing).

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 usage context: 'Use after a follow-up is handled.' While it doesn't mention when not to use or alternatives, the context is clear and helpful.

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?

Describes key behavioral traits: returns a white-labeled https://auth.salesbot.cz link valid ~2 hours, user opens in browser to finish login, nothing else needed. Also explains optional parameters. With no annotations provided, the description carries full burden and does so adequately, though it omits potential side effects or rate limits.

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

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

The description is a concise 4-sentence paragraph that front-loads the main purpose and efficiently covers usage, behavior, and parameters. Every sentence adds value, with no redundancy. Could be slightly more structured with separations, but overall concise.

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

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

Given the tool's low complexity (2 optional parameters, no output schema, no annotations), the description is relatively complete. It explains the authentication flow, link validity, and usage scenarios. Missing details like return value format are minor since the description states 'returns a link' implicitly.

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

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

Schema coverage is 100%, but the description adds meaning beyond the schema by explaining default behavior for profile_id (defaults to active/first) and the specific use case for reconnect (reconnect blocked/expired account). This helps the agent understand parameter semantics.

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 'Generate a secure LinkedIn connect (or reconnect) link the user opens in their browser to authenticate,' specifying both the action and resource. It distinguishes the tool from siblings like send_connection_request and get_linkedin_status by focusing on authentication link generation rather than direct connection or status checking.

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

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

Provides explicit when-to-use guidance: 'Use when get_linkedin_status shows not connected/blocked, or after an ACCOUNT_NOT_CONNECTED/ACCOUNT_BLOCKED error.' Also covers the reconnect scenario. However, it does not explicitly state when not to use, and while siblings are listed, no direct alternatives are named.

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

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

With no annotations, the description carries full burden. It discloses the draft state, return of campaign_id, and step structure. However, it does not mention required permissions, rate limits, or effects on other resources.

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 key point (draft), then explains inputs and next steps. 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 tool's complexity (nested steps, 6 parameters), the description provides a clear overview and identifies the next step. It does not describe optional parameters or error conditions, but with 100% schema coverage, that is acceptable.

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 parameters. The description adds value by summarizing the step structure and the draft nature, providing high-level context beyond isolated schema entries.

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

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

The description states the tool creates a new campaign, saved as draft, and specifies it does not start sending until activated. It distinguishes from siblings by mentioning 'Use add_contacts_to_campaign next', contrasting with start_campaign which activates the 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 explicitly tells when to use (to create a campaign) and what to do next (add contacts). It indirectly differentiates from siblings by noting the draft status, but does not explicitly state when not to use or list 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?

No annotations provided, but the description discloses the operation (create), optional linking to a lead, and the Pro plan restriction. No contradictions or hidden behaviors.

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?

Extremely concise—single sentence with an example and a constraint. 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?

With 4 parameters all described in schema, no output schema, and no nested objects, the description covers the essential behavior. Could mention confirmation or return value but not necessary.

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 adds context by framing the task as a follow-up and clarifying that contact_id is for a lead. This provides additional meaning beyond the schema.

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

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

The description clearly states the tool creates a follow-up task, optionally linked to a lead, with an example. It distinguishes from siblings like 'complete_task' or '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 notes 'Pro plan only' as a prerequisite and gives an example use case. Does not provide explicit when-not-to-use or compare with 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?

The description discloses that existing values stay but are hidden, which is important behavioral context. However, it does not specify whether the action is reversible, error handling for missing keys, or any permission requirements. With no annotations, the description carries full burden and is moderately transparent.

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 the action. No filler or redundant information. 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 simple one-parameter tool with no output schema and no annotations, the description covers the main action and one behavioral consequence. However, it lacks error handling, undoability, and return value information. Adequate but not fully complete.

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

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

Schema coverage is 100%, so the schema already documents the 'key' parameter. The description adds minimal extra meaning beyond 'by key'. The behavioral note about values staying relates to the tool's effect, not directly to parameter semantics. 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 it removes a custom field definition by key. The verb 'Remove' and resource 'custom field definition' are specific. It also adds a behavioral note that distinguishes it from just deleting data. Siblings like add_crm_field or delete_crm_stage are clearly different.

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

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

No explicit guidance on when to use this tool vs alternatives, nor prerequisites or side effects beyond what is mentioned. The description implies usage when you want to remove a field definition, but does not cover when not to use it or compare to other deletion tools.

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

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

No annotations are provided, so the description carries the full burden. It explains the key behavioral aspects: leads are moved to reassign_to or the first remaining stage, and the last stage cannot be deleted. It does not mention return values or permissions, but overall it is transparent about the core behavior.

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

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

The description is extremely concise, consisting of two sentences that efficiently communicate the core action, constraints, and side effects. No unnecessary words or redundancy.

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

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

Given the lack of output schema and annotations, the description covers the essential behavioral context: what the tool does, its side effects, and a key constraint. It could be improved by mentioning error handling or idempotency, but it is sufficiently complete for a simple delete operation.

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

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

The input schema has 100% coverage for both parameters, and the description does not add new semantic details beyond what the schema provides. The description implies the role of reassign_to in lead movement, but that is already inferable from the schema description. Thus, the description adds limited extra 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: delete a pipeline stage by key. It distinguishes from sibling tools like add_crm_stage and rename_crm_stage by specifying deletion and providing context about lead reassignment and the constraint on the last 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 gives clear context for use: it explains what happens to leads and the restriction on deleting the last stage. It doesn't explicitly mention when not to use or provide alternative tools, but the context is sufficient for an AI agent to understand when this tool is appropriate.

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

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

With no annotations, the description fully discloses that the tool returns CSV text up to a configurable limit (default 5000, max 20000). It implies read-only nature through the export action, though does not explicitly state safety. No contradiction.

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

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

Two concise sentences covering purpose, output, limit behavior, and an alternative. No fluff; 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?

Given one parameter, no output schema, and no annotations, the description adequately covers what the tool does, its output format, and usage caveats. Minor omission: does not specify exact CSV columns, but 'pipeline stage and key fields' is sufficiently descriptive.

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 sole parameter `limit` is described in the schema with defaults. The description adds context by clarifying that it limits the number of rows returned and mentions the output format (CSV text), providing meaning beyond the schema.

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

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

The description clearly states the tool exports CRM leads as CSV text, specifying the content (leads with pipeline stage and key fields). It distinguishes from sibling tools that deal with individual fields or stages rather than full export.

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 to use the in-app button for very large databases, indicating when not to use this tool. Does not mention other alternatives, but the context of sibling tools provides implicit differentiation.

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

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

No annotations are provided, so the description carries the full burden. It states the message is stored as a draft with status 'pending_approval' and not sent, and mentions regeneration. However, it does not clarify whether existing drafts are overwritten or other 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 a single paragraph with four sentences, front-loading the action and then explaining status and workflow. It is fairly concise but could be tightened slightly.

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

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

There is no output schema, so the description should explain what the tool returns. It omits return value or response format entirely. Also, no mention of error conditions, required permissions, or rate limits, leaving a significant gap.

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

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

Schema description coverage is 100%, so the input schema already explains the parameters. The description adds minimal extra meaning beyond the schema, such as that custom_instructions are appended to the ai_prompt, but that is also in the schema for that parameter.

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 verb 'generate' and resource 'campaign_contact and step', distinguishing it from sibling tools like approve_message by stating the message is stored as a draft and not sent.

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

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

The description provides clear context about when to use this tool (generating drafts for review) and hints at the workflow by referencing list_pending_approvals and approve_message, but does not explicitly list exclusions or alternatives for sending directly.

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

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

With no annotations, the description carries full burden. It mentions real-time reading, newest-last ordering, and the meaning of is_sender=true. It implies non-destructive behavior. However, it does not discuss rate limits, auth, or error handling.

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

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

Two sentences with no fluff. First sentence clearly states purpose and behavior; second provides usage guidance and field meaning. 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?

The description is adequate for the complexity (4 params, no output schema). It explains the workflow (use chat_id from list_inbox_chats, then reply with reply_to_chat). However, without an output schema, some details about the return format (e.g., message fields) would improve 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%, so baseline is 3. The description adds value beyond schema by explaining the provenance of chat_id ('from list_inbox_chats') and the interpretation of is_sender ('marks messages sent by you'). 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 'Read the messages of a single LinkedIn conversation in real time (newest last).' This is a specific verb (read) and resource (messages of a conversation), and it distinguishes from siblings like reply_to_chat and mark_chat_read.

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 user to get chat_id from list_inbox_chats and to use the tool to understand context before replying with reply_to_chat. It provides clear context but does not explicitly mention when not to use it or 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?

No annotations provided, so description carries full burden. Mentions 'Return' implying read-only, but fails to explicitly disclose any behavioral traits (e.g., side effects, permissions, rate limits). Incomplete for a tool with zero annotation coverage.

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

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

Two concise sentences with no fluff. Front-loaded with purpose and specifics. 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?

With only one parameter and no output schema, description sufficiently describes return content (name, headline, etc.) and usage context. Minor gap: fails to mention any output format or pagination, but acceptable for a single-contact profile.

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% (contact_id with clear description). Description adds no extra meaning beyond what schema provides; 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 uses strong verb 'Return' and specific resource 'full contact profile' with detailed field list including Czech vocative. Clearly distinguishes from sibling tools like list_contacts or get_lead_context by focusing on single-contact full 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?

States 'Used as context for personalized messages or next-step decisions', implying when to use, but does not explicitly exclude alternatives or provide when-not-to-use guidance. No mention of sibling tools with overlapping purposes.

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

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

Without annotations, the description carries full burden. It explains the tool's read-only nature, return values, and default/fallback behavior. It doesn't mention authentication or rate limits, but those are likely expected for a quota-check tool.

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

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

Two sentences, no wasted words. The first sentence states the core purpose and outputs; the second adds parameter behavior detail. Well-structured and front-loaded.

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

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

For a simple tool with one optional parameter and no output schema, the description is complete. It covers purpose, return contents, parameter behavior, and error case, leaving no important questions unanswered.

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

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

Schema description coverage is 100%, so the schema already documents the parameter. The description adds valuable context: defaulting to active profile and error behavior when no profile exists, which goes beyond the schema.

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

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

The description clearly states the tool checks remaining daily quota for a profile, listing specific returned fields (usage vs limits, ramp-up status, allowed hours, action allowance). This is a specific verb-resource pair that distinguishes it from all sibling tools, which focus on campaigns, CRM, LinkedIn actions, 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 implicitly defines when to use (to check daily quota before actions) and explains behavior for omitted profile_id. However, it does not explicitly state when not to use or mention alternatives, though no direct alternatives exist among siblings.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It does not state that the tool is read-only, nor does it mention authorization requirements, rate limits, or any side effects. For a data retrieval tool, at least a read-only hint would be expected.

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

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

The description is two sentences with no redundancy. The first sentence lists all retrieved data types, the second provides a usage directive. Every word earns its place, and critical information is front-loaded.

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

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

Despite lacking an output schema, the description enumerates the six types of data returned, which is helpful for an agent. It could briefly mention the default for notes_limit or whether results are paginated, but for a simple retrieval tool with two parameters, the description is nearly 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 coverage is 100% (both parameters described). The description reinforces that 'notes_limit' controls conversation summaries, but adds marginal value beyond the schema descriptions. It includes context about 'pain points' which hints at the nature of summaries, but does not significantly augment parameter 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 explicitly states it fetches 'full CRM context for a lead' and lists specific data (profile, pipeline stage, conversation summaries, tasks, LinkedIn interactions, stage history). This clearly distinguishes it from sibling tools like get_contact_profile, which return less comprehensive 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 provides clear usage context: 'Call this first for highly personalized outreach.' It implies this should be used before writing pitches or follow-ups, which guides the agent to prioritize this tool. It does not explicitly exclude alternatives, but the call to action is 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?

Describes return value (connection state and fix instructions) but does not explicitly state it is read-only or non-destructive. However, given no annotations, it covers the main 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, no redundancy. Every sentence provides critical information (purpose, usage hint, parameter behavior).

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

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

Adequately describes return values despite no output schema. Explains error-driven usage context. Simple tool with one optional parameter, fully covered.

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. Description adds extra context: profile_id is optional and defaults to active/first profile.

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 checks LinkedIn account connection status and returns state plus fix instructions. Distinguishes from sibling 'connect_linkedin' which would perform connection.

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 call: when another tool returns ACCOUNT_NOT_CONNECTED or ACCOUNT_BLOCKED. Also explains default behavior for optional profile_id.

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

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

No annotations are provided, so the description carries the burden. It states the returned fields (ID, name, status, description, lead counts) and implies read-only behavior. It doesn't disclose any side effects, pagination, or ordering, but as a simple list tool, this is adequate.

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, concise and front-loaded. The first sentence states the purpose and outputs, the second gives usage guidance. No wasted words.

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

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

Given the tool has one optional parameter and no output schema, the description provides sufficient context by listing return fields and typical use cases. It lacks details on limits or pagination, but for a campaign list tool, this 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% (one optional parameter 'status' with enum). The description adds no extra meaning beyond what the schema provides; it mentions 'status' in the list of returned fields but does not elaborate on filtering. Baseline of 3 applies as schema 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 'List your campaigns' with specific fields (ID, name, status, description, lead counts), and distinguishes its utility by mentioning obtaining campaign_id for related actions like adding leads or generating messages, differentiating it from sibling tools.

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

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

The description explicitly states when to use this tool: 'Use this to obtain campaign_id when adding leads, generating messages or approving drafts.' This provides clear context for invocation, though it doesn't mention when not to use it or alternatives it.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool lists contacts and returns specific fields, including status values like invite_sent, connected, replied, which indicates a read-only operation. It does not mention destructive effects, rate limits, or authentication, but the read behavior is sufficiently implied.

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

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

The description consists of two concise sentences. The first states the primary action and output, the second explains the workflow purpose. There is no redundant information, and every sentence serves a clear function.

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 (3 parameters, no output schema, no annotations), the description is largely complete. It explains what fields are returned and the tool's role. However, it could mention pagination behavior (limit/offset defaults) which is only in the schema, but overall it covers the essential context.

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

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

The input schema covers 100% of parameters with descriptions (list_id UUID, limit max 200, offset default 0). The description does not add any additional meaning beyond the schema; it focuses on output fields rather than parameter details. Therefore, the description meets the baseline but provides no extra semantic value for 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 'List contacts in a specific lead list' and enumerates the returned fields (ID, name, headline, company, profile URL, gender, current status). It also explains the tool's role in a workflow by stating that 'The AI picks IDs from this list for further tools,' which distinguishes it from sibling tools like list_campaigns or list_crm_fields that deal with different entities.

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 saying 'The AI picks IDs from this list for further tools,' which guides the agent to use this tool for obtaining contact identifiers before invoking other tools like send_connection_request or add_contacts_to_campaign. However, it does not explicitly state when not to use it or compare with alternatives, missing some explicit guidance.

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

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

No annotations are provided, so the description carries the full burden. It discloses the output fields but does not mention any behavioral aspects like permissions, pagination, or whether the list covers all leads. For a simple read operation, the transparency is adequate but could be more explicit.

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

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

The description is two sentences with no wasted words. It front-loads the core purpose and immediately provides the output structure, then adds a useful cross-reference to a related tool.

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

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

Given the tool's simplicity (zero parameters, no output schema), the description covers everything needed: what it does, what it returns, and how to use the data. It is fully self-contained.

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 zero parameters and 100% schema coverage, the baseline is 4. The description adds value by specifying the output fields (key, label, type) and linking to set_lead_fields, which clarifies the tool's purpose beyond the empty schema.

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

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

The description clearly states the tool lists custom fields on CRM leads and specifies the returned attributes (key, label, type). It distinguishes from sibling tools like set_lead_fields and add_crm_field by indicating the read-only nature.

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

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

The description implies usage: list fields before assigning values with set_lead_fields. However, it does not explicitly state when to use this tool versus alternatives like add_crm_field, nor does it provide exclusion criteria.

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

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

No annotations provided, so the description carries the full burden. It discloses that the tool lists stages and lead counts, indicating a read operation. However, it does not mention any authentication requirements, rate limits, or potential side effects. The description adds value beyond the empty schema but lacks depth.

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

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

Two sentences that are efficient and front-loaded. The first sentence defines the core purpose and output, the second adds context about configurability. No redundant or unnecessary 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 no output schema, the description could be more explicit about the return format (e.g., array of objects). It lacks details on sorting, filtering, or error scenarios. For a simple list tool, it is adequate but leaves some gaps for an agent to fully understand the output structure.

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 has zero parameters with 100% coverage. The description does not need to add parameter info. Baseline for no parameters is 4, and the description is appropriately silent on 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 lists CRM pipeline stages with specific fields (key, label, order, color) and lead counts. It uses the verb 'list' and specifies the resource, distinguishing it from sibling CRUD tools like add_crm_stage, delete_crm_stage, and rename_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 explicitly mentions that stages are user-configurable and refers to the other crm_stage tools for rename/add/delete operations, providing clear context on when to use this tool versus siblings. It does not include explicit 'when not to use' statements but is adequate.

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

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

No annotations, but description discloses real-time behavior, returned fields, limitation on preview text, and pagination aspects (cursor, limit). Does not cover rate limits or authentication, but for a read-only list tool, transparency is adequate.

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 essential: first states action and result, second explains chat_id usage and limitation, third mentions optional parameter. No redundant 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 covers key return fields and behavior. Mentions pagination and optional parameter. Could briefly explain that pagination requires cursor from previous call, but overall sufficient for a list 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 all three parameters. The description adds context (profile_id defaults to active profile, cursor for pagination) but aligns closely with schema. Baseline 3 is appropriate as description adds minor value 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?

Clearly states 'List recent LinkedIn inbox conversations (chats) in real time'. Specifies the resource, verb, and returned fields (chat_id, attendee id, unread count, last-message timestamp). Distinguishes from siblings get_chat_messages and reply_to_chat by mentioning chat_id usage.

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 this tool (to list chats) and when to use get_chat_messages to read actual messages (since preview text may be missing). Notes optional profile_id defaults to active profile. Does not explicitly state when not to use, but context is clear.

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

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

Since no annotations are provided, the description carries the burden. It discloses that the tool returns drafts with specific fields and optionally filters by campaign_id. It does not mention pagination or side effects, but for a read-only list tool with a limit parameter, the transparency is adequate.

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

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

The description is three short sentences, each adding value: purpose, output details, and usage context. No unnecessary words, and it is front-loaded with the core function.

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 covers the return fields and provides usage context. It does not mention edge cases like empty results or sorting, but for a straightforward list tool with a limit parameter, it is reasonably 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 coverage is 100% with both parameters described. The description adds no additional meaning beyond what the schema provides for the parameters, only repeating the optional filter. However, it does explain the output fields, which is related but not parameter semantics.

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, specifies the filter condition (messages_approved=false), and lists the fields included. It distinguishes itself from sibling tools like approve_message and reject_message by indicating it provides input for bulk review.

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 states the tool is used as input for bulk review by an AI assistant to iterate through drafts and approve/reject them, providing clear context. However, it does not explicitly exclude use cases or mention alternatives, though sibling tools imply those.

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

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

No annotations are provided, so the description must carry the burden. It explains the tool is read-only (lists tasks) and returns specific fields. However, it does not mention pagination, ordering, or any potential side effects, leaving some gaps.

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 purpose, and every sentence adds value with zero 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?

Given no output schema, the description explains return fields. It covers filtering and default filter. However, it lacks details on pagination and ordering, which are important for a list 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 the baseline is 3. The description adds minimal value beyond the schema, restating the parameter options and defaults that are already documented.

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 lists CRM tasks with filtering by status and contact, which is a specific verb+resource. It distinguishes from sibling tools like create_task and complete_task.

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 ('Use to see what follow-ups are outstanding'). It implicitly indicates when to use, but does not explicitly exclude alternative tools or mention 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?

No annotations are provided, so the description must carry the full burden. It mentions durable context and separate storage but omits key behaviors such as whether notes are appended or replaced, authentication requirements, or side effects of repeated calls.

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

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

The description is brief at three sentences plus a parenthetical, front-loads the action, and contains 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?

Given the tool has 4 parameters and no output schema, the description covers the main usage pattern but lacks details on return values, error handling, or prerequisites. It is adequate but not 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 context by framing the parameters (e.g., 'concise summary', 'key pain points') but does not provide significant additional meaning 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 clearly states the verb 'save' and resource 'structured summary into the CRM for a lead', and distinguishes it from sibling tools like get_lead_context or raw message storage. It is specific and unambiguous.

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

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

The description instructs the agent to analyze the chat/context first before calling, and notes that the note is stored separately from raw messages, providing clear context. However, it does not explicitly state when not to use this tool or list 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?

No annotations provided, so description carries full burden. States the state change (mark as read) but does not disclose potential side effects (e.g., notifications, reversibility). Adequate for a simple action but lacks deeper 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?

Two sentences: first defines the action, second provides usage guidance. No extraneous words. Efficient and well-structured.

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

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

For a simple mutation tool with no output schema, the description is mostly complete. It explains what it does, why, and by which parameter. Minor gap: no mention of return behavior (e.g., success response), but acceptable.

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 has 100% coverage with descriptions for both parameters. The description does not add additional meaning beyond what the schema provides. 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?

Clearly specifies the action (mark a conversation as read) and the resource (LinkedIn conversation by chat_id). Distinguishes from sibling tools like list_inbox_chats, reply_to_chat, etc., which handle different 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?

Provides a clear use case: after AI processes a thread to prevent re-surfacing as unread. Explicit usage context, though does not mention when not to use or list 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?

With no annotations provided, the description carries full burden. It discloses the default draft behavior, the auto_publish path respecting approval settings, a 30–180s anti-detection delay, and the lack of attachment support. It does not mention rate limits or detailed authentication steps, but the profile_id requirement is clear.

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 four sentences long, front-loaded with the primary purpose. Each sentence adds value without redundancy. It efficiently covers default behavior, settings, delay, and limitations.

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

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

Given no output schema and no annotations, the description comprehensively covers the tool's behavior: what it does, default vs immediate publish, approval handling, delay, and what is not supported (attachments). It is complete for the tool's complexity.

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

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

The description adds meaning beyond the schema: it explains the draft/publish flow, the anti-detection delay, and that text is plain text (no Markdown). It clarifies the purpose of auto_publish and the requirement for profile_id to have a connected LinkedIn account.

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 'Create a LinkedIn post on behalf of a connected profile', specifying the verb and resource. It differentiates this tool from sibling tools like send_linkedin_message or connect_linkedin by focusing on posting content. The default draft behavior is explicitly noted.

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 auto_publish vs default draft, mentions the MCP human-in-the-loop setting, and explicitly states that attachments are not supported via MCP. However, it does not directly compare to other sibling tools for alternative use cases.

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

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

No annotations are provided, but the description discloses the key behavioral effect: resetting generation_status to 'pending' and triggering regeneration. It also notes that the new version waits for approval.

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 concise sentences with no filler. The main action is front-loaded, followed by the behavioral effect.

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

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

Given no output schema and the tool's simplicity, the description adequately covers purpose, effect, and parameter meaning. It could mention return value or error handling, but this is not essential.

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 has 100% coverage, but the description adds value by explaining that 'reason' is used as regeneration feedback and provides an example, going beyond the bare 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 uses a specific verb ('reject') and resource ('current drafts on a campaign_contact') and clearly distinguishes from the sibling 'approve_message' tool by mentioning rejection and regeneration feedback.

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 effect (resets generation_status) and links to the approval flow, but does not explicitly state when not to use this tool or contrast with alternatives like 'approve_message'.

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

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

No annotations are provided, so the description carries the full burden. It states that 'the stage key and the leads in it are unchanged,' which is critical behavioral context for a rename operation. It does not mention permissions or reversibility, but the scope of changes is well-defined.

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 verb 'Rename', and every word adds value. No extraneous 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 no output schema, the description explains the effect (unchanged key/leads) and provides a pointer to a related tool ('list_crm_stages'). It is sufficient for basic understanding, though it could mention potential downstream effects (e.g., updates in the CRM).

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 maps 'label' and 'color' to the action and mentions 'key' as the identifier. This adds no new meaning beyond the schema, but effectively summarizes the parameters' roles.

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 renames a stage's label and/or changes its color, specifying the use of 'key' and referencing 'list_crm_stages' to obtain keys. This distinguishes it from sibling tools like 'add_crm_stage' (create) and 'set_deal_stage' (move leads), making the purpose unambiguous.

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

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

It tells users to use 'list_crm_stages' to get keys, which is a prerequisite. It implies usage for modifying stage metadata but does not explicitly contrast with alternatives (e.g., 'delete_crm_stage' for removal). The guidance is clear but lacks explicit 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?

The description fully discloses behavioral traits: allowed hours behavior, random delay, prompt injection scanning, daily message limit, and MCP throttle. Since no annotations are provided, this carries the full burden and is exceptionally transparent.

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

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

The description is concise, using a single paragraph of about six sentences. It front-loads the main action and each sentence adds necessary detail 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?

The description covers key aspects: allowed hours, delay, security scan, limits. It does not detail the daily limit numbers or success response, but given the complexity and the presence of get_daily_limits sibling, it is sufficiently complete.

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

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

With 100% schema description coverage, the description adds minimal extra meaning beyond the schema. It restates that chat_id comes from list_inbox_chats and message has max 5000 chars, but these are already in the schema. The default behavior for profile_id is also in the schema. Thus baseline of 3 applies.

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

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

The description explicitly states 'Send a reply into an existing LinkedIn conversation (by chat_id),' clearly identifying the verb (Send), resource (reply in existing conversation), and distinguishing it from sending a new message via 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 provides context on when to use: only within allowed hours, and when it might fail (outside hours, prompt injection, limits). It implicitly distinguishes from send_linkedin_message but does not explicitly state 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?

With no annotations, the description carries full burden and discloses key behaviors: HTML stripping, truncation, email extraction, rate limits, and refusal of private URLs. It omits details about truncation behavior (e.g., character limit based on max_chars), but the schema covers that, so the description adds sufficient transparency.

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

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

The description is concise (4 sentences) and front-loaded with the core purpose. Every sentence adds value without redundancy, and the structure is clear 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 (2 parameters, no output schema, no annotations), the description covers the main aspects: purpose, output details, usage guidelines, and constraints (rate limits, private URL refusal). It lacks error handling details but is otherwise complete for effective use.

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

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

Schema coverage is 100% (both parameters described). The description adds value by explaining how parameters affect output (e.g., max_chars influences truncation) and describes the return fields (plain text, emails). This provides meaning beyond the schema's basic 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 it fetches readable text of a public web page, with examples (prospect's website, article) and specifies the output (plain text and emails). It distinguishes itself from sibling tools like search_google_xray and search_linkedin_navigator, which serve different purposes.

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

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

The description provides explicit guidance: use this tool for context when writing/editing messages, treat returned content as untrusted data, and notes that private/internal addresses are refused. It also mentions rate-limiting, helping the agent decide when to invoke the 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?

With no annotations, the description carries full burden and discloses important behaviors: pagination up to 15 pages of 100 results and automatic filtering of duplicates and blacklist. This provides valuable transparency beyond a basic purpose statement.

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 two sentences, front-loading the core purpose. Every word adds value without redundancy 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 no output schema or annotations, the description covers purpose, usage context, and key behaviors (pagination, dedup). It could mention return format or error conditions, but for a search tool, the provided information 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?

Schema coverage is 100%, and parameter descriptions are clear. The main description adds no additional parameter-specific details, but the pagination note indirectly relates to the 'limit' parameter. No extra semantics are provided beyond what the schema offers.

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's purpose: performing Google X-ray searches for public LinkedIn profiles using the 'site:linkedin.com/in' operator. It clearly distinguishes from sibling tools like search_linkedin_people by using a different search method and highlighting the benefit of not consuming LinkedIn search limits.

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 ('useful when you don't want to consume LinkedIn search limits'), implying when to prefer this tool over alternatives. However, it does not explicitly state when not to use it or compare directly with siblings like search_linkedin_navigator.

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

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

No annotations are provided, so the description carries the burden. It discloses the core behavior (scrape, save, return IDs) but omits details on authentication, rate limits, or side effects like overwriting existing contacts. This is adequate but not comprehensive.

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-loading purpose, and providing actionable instructions. 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 lack of output schema and simple parameters, the description covers input expectations and output behavior. It could specify the return format (e.g., array of IDs), but it's still sufficiently complete for an AI agent.

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

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

Schema coverage is 100%, so baseline is 3. The description adds context for 'search_url' by specifying it must be a ready-made URL with filters. However, it doesn't explain the 'limit' parameter beyond what the schema provides, so marginal added 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 tool scrapes a Sales Navigator or standard LinkedIn search URL, saves leads into contacts, and returns IDs. It uses a specific verb ('scrape') and resource ('search URL'), and distinguishes from siblings like 'search_linkedin_people' by emphasizing a ready-made URL with filters.

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: when a pre-configured search URL is available. It doesn't explicitly exclude other scenarios or mention alternatives like 'search_linkedin_people', but the context of 'ready-made search URL' provides clear guidance.

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

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

No annotations are provided, but the description discloses behavioral traits: results are saved into contacts with deduplication and blacklist filtering, and the tool returns IDs. It also explains the two location parameter options. No contradictions detected.

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

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

The description is two sentences: first covers purpose and side effects, second explains parameter usage. It is front-loaded with the most important information and contains 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?

Given 5 parameters with 100% schema coverage and no output schema, the description adequately covers the side effects (saving to contacts) and the return of IDs for other tools. It does not detail the exact return structure, but it is sufficient for the agent to understand the tool's function.

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 explaining the usage pattern for location vs locationId and the network filter values. It also mentions 'keywords' and 'company' which are not explicit parameters but implied by the title field, adding contextual meaning beyond the schema.

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

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

The description clearly states it searches people on LinkedIn by keywords, title, location, or company. It specifies that results are saved into contacts with deduplication and blacklist filtering, and returns IDs for other tools. This distinguishes it from sibling tools like search_google_xray and search_linkedin_navigator.

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 location vs locationId, and that results are saved into contacts for use by other tools. It does not explicitly state when not to use this tool, but the sibling list provides context for 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?

No annotations are provided, so the description bears full responsibility. It fully discloses that the message is always empty (critical behavioral trait), and details enforcement of daily limits, allowed hours, blacklist, random delays, and usage tracking. This provides good insight into the tool's operation.

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

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

Two sentences: the first clearly states the purpose, the second provides essential behavioral constraints. Every word earns its place; front-loaded and efficient with no redundancy.

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

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

Given no output schema and no annotations, the description covers the main behavioral aspects (empty message, limits, delays, blacklist, tracking). It does not mention return values or error handling, but for a simple action tool these are not critical gaps. Completeness is high for the tool's complexity.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description does not add new semantic meaning beyond what the schema provides; the empty message policy is behavioral context, not parameter-level detail. 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 explicitly states 'Send a LinkedIn connection invitation' – a specific verb and resource. It distinguishes from siblings like 'send_linkedin_message' and 'connect_linkedin' by focusing solely on the invitation action.

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

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

The description implies usage context by stating the message is always empty and that limits are enforced, but it does not explicitly say when to use this tool versus alternatives (e.g., for connection requests without messages, use this). Clear but lacks explicit exclusions.

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

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

With no annotations provided, the description discloses key behaviors: random 30-180s delay for anti-detection, counting against daily limit, respecting allowed hours, and logging. It does not detail failure handling or authentication, but still adds significant 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-loading purpose and efficiently listing behavioral traits without any 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, the description covers purpose, timing, rate limits, and logging. It lacks return value hints (e.g., success indicator) but is thorough enough for a straightforward sending action.

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 all three parameters. The description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states 'Send a one-off LinkedIn message to a specific contact outside any campaign', providing a specific verb and resource, and distinguishing from campaign-related tools and other messaging siblings like send_connection_request.

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 specifies the tool is for messages 'outside any campaign', giving clear context for one-off use, but doesn't explicitly mention alternatives for existing conversations (reply_to_chat) or connection requests.

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

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

No annotations, so description must disclose behavior. It mentions logging ('Logs who changed it and an optional note to the deal history'), which is good. However, it omits permission requirements, idempotency, or other 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?

Three concise sentences, front-loaded with action. Every sentence provides useful information 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?

For a simple mutation tool with 3 plain params and no output schema, description covers purpose, when to use, and visible side effect (logging). Missing details on return value or error cases, but 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?

All 3 parameters described in schema (100% coverage). Description adds value by listing default stage keys and advising to call list_crm_stages, which supplements 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?

Description clearly states 'Move a lead to a different pipeline stage' with specific verb and resource. It doesn't explicitly differentiate from sibling tools like add_crm_stage or rename_crm_stage, but implies context by mentioning list_crm_stages.

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 when to call ('when user confirms a real-world event in plain English'), and directs to list_crm_stages for valid stages. Lacks explicit when-not-to-use, but context is clear.

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

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

No annotations provided, so description carries full burden. Discloses side effect (adds lead to CRM if needed) and validation (only defined keys accepted). Does not mention whether fields overwrite or merge, or error handling.

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 redundancy. Each sentence adds essential information: action, parameters, constraints, and side effect.

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 core functionality, parameter usage, and side effects. No output schema, but for a mutation tool this is acceptable. Could mention what the tool returns, 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?

Both parameters have descriptions in schema, but description adds value by explaining usage of fields (object of field_key:value) and linking to list_crm_fields for valid keys, which schema does not mention.

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 the verb 'Set' and resource 'custom field values on a lead'. Distinguishes from siblings like update_contact and add_crm_field. Also mentions side effect of adding lead to CRM.

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?

Instructs to pass fields as object of field_key:value and directs to list_crm_fields for valid keys. Implicitly indicates when to use (when setting custom fields) but no explicit when-not-to or 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?

With no annotations provided, the description carries the full burden. It discloses that the tool schedules actions, sets status to 'running', and respects daily limits, allowed hours, and anti-detection delays. This is good transparency for a non-destructive activation tool.

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

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

Two sentences efficiently convey the action, prerequisites, and behavioral traits with no wasted words. The description is front-loaded and 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?

Given the tool's simplicity (one parameter, no output schema), the description is complete enough. It covers prerequisites and behavioral constraints. It could mention return values but is sufficient for correct agent usage.

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 one parameter well-described in the schema. The description adds context about prerequisites (contacts and steps) but does not add further parameter-specific semantics. 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 action (start/activate), the resource (existing campaign), and what it does (schedules outreach, sets status to 'running'). It distinguishes from siblings like stop_campaign and add_contacts_to_campaign by mentioning prerequisites and 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?

The description provides clear context for when to use the tool, specifying that the campaign must already have contacts and steps. It does not explicitly state when not to use or compare to alternatives, but the context 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?

With no annotations, description fully discloses behavioral effects: status change, cancellation of pending actions, and DB trigger marking them skipped. 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 efficient sentences: first describes core action, second provides alternative. 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?

Given simple input schema and no output schema, description is nearly complete. Could mention return value or confirmation, but not essential for usage clarity.

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

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

Schema coverage is 100% with a clear description for campaign_id. Description does not add extra meaning beyond schema, so baseline 3 is appropriate.

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

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

Explicitly states it stops a running campaign, sets status to 'stopped', and cancels pending scheduled actions. Distinguishes clearly from pausing via update_campaign_settings.

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

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

States when to use this tool (stop permanently) and when to use update_campaign_settings (pause temporarily). Provides explicit alternative and 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?

With no annotations, description discloses partial update behavior ('Only provided fields are changed') and ownership requirement. Does not mention side effects or return value, but core behavioral traits are covered.

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

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

Two sentences, no fluff. First sentence states purpose and fields, second sentence adds key usage detail. 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?

No output schema, but update tools typically return updated object; description omits this but is otherwise complete for the tool's complexity. Missing mention of response format is minor.

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

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

Schema coverage is 100%, baseline 3. Description adds value by listing updatable fields and explaining status values for pause/resume, going beyond 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?

Explicitly states 'Update settings of an existing campaign' and lists the specific fields (name, description, etc.), providing strong verb+resource clarity and differentiating from sibling tools.

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

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

Provides explicit guidance on using status to pause/resume and states that only provided fields are changed. Lacks explicit mention of when not to use or alternatives like stop_campaign, but still 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?

Discloses partial update behavior ('Only the fields you pass are changed') and negates creation. Without annotations, this covers key behavioral expectations adequately, though side effects are not mentioned.

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: purpose with fields, usage scenario, and behavioral caveats. No redundancy, front-loaded with essential 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 covers all aspects for a simple update tool. No output schema needed; description provides sufficient context for selection and invocation among 42 siblings.

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. The description adds value by grouping parameters as 'contact details' and explaining partial update semantics, moving beyond bare 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 clearly states the tool updates a lead's contact details and lists the exact fields (email, phone, etc.). It distinguishes itself from creation by explicitly stating 'Does not create 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 a concrete usage example ('save an email address you found') and clarifies non-creation. However, it does not explicitly compare to sibling tools like 'set_lead_fields' or state 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.