Server Quality Checklist

Tool Scores

• linkedin_build_activity_timelineC
  2.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure, yet it only states that a chronological summary is produced. It does not say whether the operation is read-only, what activity scope is covered, whether 'from' and 'to' bound the timeline, or what the returned summary contains — especially problematic given that no output schema exists.

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

  Conciseness4/5

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

  A single, front-loaded sentence with no filler — the verb and resource lead immediately, and every word earns its place. It is arguably under-specified, but that is a completeness concern rather than a conciseness defect.

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

  Completeness2/5

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

  For a tool with no annotations and no output schema, the description should at least explain the inputs, the activity scope, and the shape of the returned summary; it explains none of these. At 3 parameters with 33% schema coverage, an agent can guess the basics but cannot confidently predict behavior or output.

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

  Parameters2/5

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

  Schema coverage is only 33%, and the lone description ('Profile ID') is tautological, so the description needed to compensate but never mentions parameters. The words 'chronological' and 'timeline' weakly hint that 'from' and 'to' are date bounds, but this is never stated, and profileId semantics are left entirely to the schema.

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

  Purpose4/5

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

  The description names a specific action ('Constructs') and a concrete deliverable ('a chronological activity timeline summary'), so an agent can tell this assembles activity data into an ordered summary. However, it does not explicitly differentiate the tool from the activity-related siblings (e.g., linkedin_get_recent_activity, linkedin_analyze_recent_activity, linkedin_compare_activity_periods); the distinction rests only on the implicit word 'timeline.'

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

  Usage Guidelines2/5

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

  No when-to-use guidance, exclusions, or alternative routing is provided; the only hint is the bare function statement itself. With 19 siblings, including at least four activity-centric tools, an agent gets no help deciding between this tool and linkedin_get_recent_activity or linkedin_compare_activity_periods.

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

• linkedin_create_lead_shortlistC
  2.7/5.0
  Behavior2/5

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

  There are no annotations, so the description carries full responsibility for behavioral disclosure. It only says 'Generates a curated shortlist' with no details about whether this is a search, a scoring operation, a destructive action, whether results are stored, or what side effects might occur. The behavior beyond the obvious output remains opaque.

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

  Conciseness4/5

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

  The description is a single sentence with no fluff and a concrete example. It is front-loaded with the core verb and resource. While more detail is needed elsewhere, the conciseness itself is effective.

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

  Completeness2/5

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

  This tool has a nested icp object with required fields, a default limit, and no output schema, yet the description provides almost no contextual information. An agent would not know how to construct a valid icp, what the output looks like, or how this tool fits into the broader lead-generation workflow. The description is too thin for the tool's complexity.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate, but it does not meaningfully explain the parameters. The example 'Top 20 PPC agency founders' hints at the limit and ICP concept, but it never explains the icp object, its required nested fields, or how limit behaves. The schema contains more detail than the description.

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

  Purpose4/5

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

  The description states a specific action ('Generates') and resource ('a curated shortlist of top prospects') with a concrete example. It is clear about what the tool accomplishes, but it does not distinguish itself from sibling tools like linkedin_rank_leads or linkedin_filter_leads, which could also produce shortlists.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to use this tool versus alternatives. The description implies it is used to generate a shortlist, but it does not state prerequisites, exclusions, or how this differs from linkedin_find_opportunities, linkedin_rank_leads, or linkedin_filter_leads.

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

• linkedin_find_opportunitiesC
  2.8/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool identifies opportunities from activity, but does not disclose what input is used (beyond a generic profileId), whether it performs analysis, what side effects exist, or what the output looks like. This is minimal and leaves the agent guessing about the tool's behavior.

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

  Conciseness3/5

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

  The description is a single sentence with no wasted words and fronts the verb immediately. However, it is terse to the point of omitting important context, so brevity is achieved at the expense of usefulness rather than through efficient structure.

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

  Completeness2/5

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

  There is no output schema, no annotations, and no mention of return values or expected behavior. The description does not explain what a caller should expect after invocation, what 'opportunities' means in practice, or how the profileId and category parameters influence results. For a 2-parameter tool, this is incomplete.

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

  Parameters2/5

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

  Schema description coverage is 50%: profileId has a description, but category has none. The tool description adds no parameter meaning and does not explain what 'category' values are valid or how category affects opportunity identification. Since the description does not compensate for the under-documented parameter, this is a meaningful gap.

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

  Purpose4/5

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

  The description uses a specific verb ('Identifies') and names a distinct resource ('specific technical tracking or marketing service opportunities') with a stated basis ('observed activity'). This clearly separates it from sibling tools like linkedin_rank_leads or linkedin_extract_topics, though the meaning of 'technical tracking or marketing service opportunities' is somewhat jargon-heavy.

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

  Usage Guidelines3/5

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

  The phrase 'based on observed activity' implies the tool should be used when there is activity data to analyze, but it does not explicitly state when to use this tool versus alternatives like linkedin_detect_business_signals or linkedin_analyze_recent_activity. No exclusions or alternative routing are provided.

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

• linkedin_analyze_profileC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the analysis scope (which profile sections are examined), but says nothing about authentication requirements, whether external profile data must be fetched, side effects (though 'analyzes' implies read-only), or what the analysis output contains. A tool with zero annotation coverage needs more than this.

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

  Conciseness5/5

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

  A single tightly-scoped sentence with no filler. The core action and the analyzed content are front-loaded, and every word contributes meaning.

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

  Completeness2/5

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

  The tool is simple (one parameter, no output schema, no annotations), but it sits among several ambiguously-similar siblings (research_profile, analyze_prospect, analyze_recent_activity). Without return-value information or usage boundaries, an agent cannot fully determine when this is the right tool or what it will receive back. The enumerated analysis scope helps, but significant gaps remain.

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

  Parameters3/5

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

  Schema description coverage is 100% — profileId is already documented as 'LinkedIn profile ID or URL' in the schema. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies; the description neither compensates nor detracts.

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

  Purpose4/5

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

  The description has a specific verb ('Analyzes') and resource ('static profile'), and enumerates the exact components examined: headline, about, experience, skills, and business positioning. The word 'static' helpfully distinguishes it from sibling linkedin_analyze_recent_activity, though it does not delineate how it differs from similarly-named linkedin_research_profile or linkedin_analyze_prospect.

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

  Usage Guidelines2/5

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

  No explicit when-to-use guidance or named alternatives. The term 'static' implies this tool is for a profile snapshot rather than activity streams, but the description never states when an agent should pick this over linkedin_research_profile, linkedin_analyze_prospect, or linkedin_analyze_recent_activity — a real gap given the 18 overlapping siblings.

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

• linkedin_analyze_recent_activityC
  2.9/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full disclosure burden. The word 'Analyzes' implies a non-mutating read operation, and listing three analysis dimensions adds real behavioral context. However, it never explicitly states that the tool is read-only, has no side effects, or requires any preconditions, leaving part of the safety profile implicit.

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

  Conciseness4/5

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

  One sentence, front-loaded with the verb and resource, with zero filler words. It is efficient, though arguably too terse given that no annotations or output schema exist to carry additional context — a few more sentences of guidance would have earned their place.

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

  Completeness2/5

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

  For a tool with no annotations, no output schema, and 18 siblings with meaningful overlap, the description is too thin. It never clarifies how this tool differs from linkedin_extract_topics or linkedin_detect_business_signals, what objective controls, or what the returned analysis looks like.

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

  Parameters2/5

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

  Schema description coverage is only 25% (only profileId is described), so the description must compensate. The phrase 'date-range' gives semantic meaning to the to/from parameters, but it omits any format or boundary details, and the objective parameter is entirely unexplained despite having a default of 'prospect_research'. Compensation is partial at best.

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

  Purpose4/5

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

  The description names a specific verb ('Analyzes') and resource ('date-range activity'), and enumerates three concrete analysis outputs: recurring topics, priority shifts, and business signals. It overlaps somewhat with siblings like linkedin_extract_topics and linkedin_detect_business_signals, but the combined analytic scope is specific enough that an agent knows what the tool produces.

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

  Usage Guidelines2/5

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

  No when-to-use or when-not-to-use guidance is provided, and no alternative tools are named. With 18 siblings including several that closely overlap (linkedin_get_recent_activity, linkedin_extract_topics, linkedin_detect_business_signals, linkedin_compare_activity_periods), an agent cannot reliably decide which tool to invoke.

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

• linkedin_filter_leadsC
  2.9/5.0
  Behavior2/5

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

  No annotations are present, so the description must carry the full behavioral disclosure burden. It states that filtering occurs but doesn't say whether it mutates the original batch or returns a new set, how multiple criteria are combined, or whether minScore is inclusive. This leaves meaningful behavioral ambiguity.

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

  Conciseness5/5

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

  A single front-loaded sentence with no filler; it names the action and the filterable attributes efficiently. Every word contributes to understanding the tool's purpose.

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

  Completeness2/5

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

  For a five-parameter optional-filter tool with no annotations and no output schema, the description is thin. It doesn't explain the relationship between filters (AND/OR), the return value, or what happens when no filters are provided, so an agent may call it with incomplete expectations.

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

  Parameters3/5

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

  Schema description coverage is 100%, so each parameter is already documented. The tool description mostly restates the same filter dimensions without adding semantic details such as how criteria interact or threshold inclusivity, so it adds minimal value beyond the schema.

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

  Purpose4/5

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

  The description uses a specific verb ('Filters') and resource ('lead batches') and enumerates the available filter dimensions, making the core function immediately recognizable. It doesn't explicitly contrast with sibling tools, but the filtering action is distinct enough among the listed siblings.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool over the many lead-analysis siblings, and there is no mention of prerequisite steps or pipeline context. The only usage signal is the generic 'Filters lead batches,' leaving the agent to infer when this tool applies.

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

• linkedin_match_icpC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full behavioral burden. It states that the tool evaluates fit and provides confidence scoring, but it does not disclose whether the operation is read-only, what the output format or score range is, how optional 'icp' is handled, or what happens when no ICP is supplied. This leaves meaningful behavioral gaps.

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

  Conciseness4/5

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

  The description is a single, well-structured sentence that front-loads the core action and includes a useful outcome detail ('confidence scoring'). It is appropriately concise, though it sacrifices some necessary context about behavior and usage.

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

  Completeness2/5

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

  Given the absence of annotations, the lack of an output schema, and the presence of an optional nested ICP object, the description should explain more: expected return value, behavior when 'icp' is omitted, and how this differs from overlapping siblings. The current description is too minimal for an agent to invoke the tool confidently in ambiguous situations.

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

  Parameters3/5

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

  The input schema provides 100% parameter coverage with descriptions for 'leadId' and the nested ICP fields, so the baseline is 3. The description adds no specific parameter-level detail beyond naming 'custom Ideal Customer Profile rules', which does not exceed what the schema already communicates.

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

  Purpose4/5

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

  The description clearly identifies a specific action ('Evaluates lead fit'), the object ('lead'), and the criteria ('custom Ideal Customer Profile rules'), plus a distinguishing output feature ('confidence scoring'). However, it does not differentiate this tool from the similarly named sibling 'linkedin_score_lead', so it stops short of a 5.

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

  Usage Guidelines2/5

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

  There is no guidance on when to use this tool versus alternatives like 'linkedin_score_lead', 'linkedin_filter_leads', or 'linkedin_rank_leads'. The description implies usage for ICP-based evaluation but provides no explicit context, exclusions, or alternative routing.

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

• linkedin_score_leadB
  3/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It adds useful detail about the scoring dimensions and the 100-point scale, showing what kind of computation is performed. However, it does not disclose the output format, whether the optional icp object replaces or supplements stored criteria, or any 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.

  Conciseness5/5

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

  A single sentence that is concise, front-loaded, and free of filler. It immediately communicates the tool's purpose and distinguishing scoring framework.

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

  Completeness2/5

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

  Despite a nested icp object, no output schema, and no annotations, the description is minimal. It lacks sibling differentiation, parameter context, output details, and any indication of whether pre-existing lead research or ICP configuration is required. An agent could easily confuse this with ranking or ICP-matching tools.

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

  Parameters2/5

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

  Schema description coverage is 50%, and the description adds no parameter-level meaning. It does not explain that leadId is the lead/profile identifier nor clarify the role of the icp object in scoring. The schema partially documents properties, but the description fails to compensate for the remaining gaps.

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

  Purpose4/5

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

  The description clearly identifies the action ('scores a lead'), the resource, and the exact scoring framework: '100-point Lead Scoring Engine (ICP Fit, Service Relevance, Authority, Signals)'. It is more specific than a vague 'score lead' statement, though it does not explicitly contrast itself with sibling tools like linkedin_rank_leads or linkedin_match_icp.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives such as linkedin_rank_leads, linkedin_match_icp, or linkedin_filter_leads. It implies single-lead scoring but does not state prerequisites, exclusions, or preferred use cases.

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

• linkedin_analyze_prospectB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description must carry the behavioral disclosure burden, but it only says the tool 'orchestrates' several analyses. It does not state whether the operation is read-only, what side effects or dependencies exist, how output is returned, or whether it invokes the sibling tools.

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

  Conciseness5/5

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

  The description is a single tight sentence that front-loads the core identity ('High-level prospect analyzer') and then lists the orchestrated components. There is no filler or redundancy.

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

  Completeness2/5

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

  For a tool with 3 parameters, a nested object, no output schema, and 19 siblings, this description is under-specified. It fails to state required inputs, expected output, when to use it instead of lower-level alternatives, or any operational constraints, leaving important gaps for an agent.

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

  Parameters2/5

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

  Schema description coverage is only 33%, and the tool description does not compensate by explaining profileId, icp, or objective. The nested icp object has useful subproperty descriptions in the schema, but the main parameters' semantics remain underspecified and the description adds no parameter-level meaning.

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

  Purpose5/5

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

  The description uses a specific verb ('analyzes') and resource ('prospect'), and explicitly frames the tool as a 'High-level' orchestrator combining profile, company, signals, ICP matching, and lead scoring. This clearly distinguishes it from focused siblings like linkedin_analyze_profile, linkedin_match_icp, and linkedin_score_lead.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to choose this orchestrator versus the individual sibling tools, nor are any alternatives or exclusions mentioned. The agent must infer from the word 'high-level' that this is a composite operation, which is not sufficient.

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

• linkedin_generate_boolean_searchB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says the tool 'generates' search strings and gives no detail about side effects, network usage, output format, or whether anything is persisted. This leaves behavioral expectations vague.

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

  Conciseness4/5

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

  The description is a single, front-loaded sentence with no filler. It efficiently communicates the action, output type, and target surfaces, even though the word 'optimized' is somewhat imprecise.

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

  Completeness2/5

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

  There is no output schema and no clarification of whether the tool returns a single string, multiple strings, or an object. Given the absence of annotations and output schema, the description should provide more detail about the return format and behavior to be fully complete.

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

  Parameters3/5

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

  The schema descriptions cover 100% of the parameters with meaningful labels like 'Decision maker job titles', 'Target service/niche keywords', and 'Exclusion keywords'. The tool description itself adds no parameter-level meaning, but the schema already carries the load.

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

  Purpose4/5

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

  The description states a specific verb ('Generates'), a concrete output type ('Boolean search strings'), and three target surfaces (LinkedIn People Search, Company Search, Google X-ray). It clearly conveys what the tool does, though it does not explicitly differentiate it from close siblings like linkedin_build_lead_search.

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

  Usage Guidelines3/5

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

  The description implies usage when Boolean search strings are needed, and specifies the target platforms, but it gives no explicit when-to-use or when-not-to-use guidance. With many LinkedIn siblings, naming alternatives or exclusions would improve tool selection.

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

• linkedin_rank_leadsB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full behavioral disclosure burden. It only says the tool ranks and sorts; it does not say whether the operation is read-only, whether it persists changes, how ranking is computed, what sorting order is used, or how limit is applied. This is a significant transparency gap.

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

  Conciseness5/5

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

  The description is a single concise sentence, front-loaded with the action verb, and contains no filler or redundant detail. Every word contributes to understanding the tool's purpose.

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

  Completeness3/5

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

  With no output schema and no annotations, the description should clarify what the call returns or changes; it does not. It captures the core sorting semantics and optional nature of parameters, but leaves limit behavior, the icp sort option, and result shape unspecified. This is adequate for a low-complexity sort tool, but not complete.

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

  Parameters3/5

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

  Schema description coverage is 0%, but the description partially compensates by explaining three sortBy enum values: 'overall lead score' (score), 'tracking opportunities' (opportunity), and 'intent' (intent). It does not explain 'icp' or the limit parameter, so the compensation is incomplete.

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

  Purpose4/5

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

  States a specific verb ('Ranks and sorts') and resource ('imported lead batches'), and lists the ranking criteria: overall lead score, tracking opportunities, or intent. It is clear but does not explicitly differentiate from siblings like linkedin_filter_leads, so it stops short of a 5.

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

  Usage Guidelines2/5

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

  No guidance is given on when to use this tool versus alternatives such as linkedin_filter_leads or linkedin_find_opportunities. The phrase 'imported lead batches' implies it works on prior imports, but there is no explicit context, prerequisite, or exclusion.

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

• linkedin_analyze_search_resultsB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions categorizing, filtering, and preliminary scoring, but does not clarify whether filtering modifies the stored batch, whether any data is destroyed, how optional ICP affects behavior, or what the output format is. This is a significant transparency gap for a processing tool.

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

  Conciseness5/5

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

  The description is a single concise sentence with no wasted words. It front-loads the primary actions and clearly identifies the resource being operated on.

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

  Completeness2/5

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

  The tool has a nested optional icp object and no output schema, meaning the description should explain what results are produced and whether the batch is mutated. It provides none of that. The description is also too sparse relative to the complexity of the operation and the number of sibling tools performing similar functions.

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

  Parameters3/5

  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 both parameters, including the nested icp properties and searchId meaning. The description adds minimal extra value by linking 'preliminary ICP scoring' to the icp parameter, but it does not need to compensate for schema gaps.

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

  Purpose4/5

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

  The description provides specific verbs and resources: 'Categorizes, filters, and performs preliminary ICP scoring on an imported search result batch.' This clearly states what the tool does. However, it does not explicitly differentiate itself from sibling tools like linkedin_filter_leads or linkedin_match_icp, relying on the word 'preliminary' to imply a distinction.

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

  Usage Guidelines3/5

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

  The phrase 'imported search result batch' implies the tool should be used after an import and before more detailed scoring or ranking, giving some contextual guidance. However, there is no explicit guidance on when to use this tool versus alternatives such as linkedin_filter_leads, linkedin_match_icp, or linkedin_rank_leads, nor any exclusions.

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

• linkedin_extract_topicsB
  3.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It usefully discloses that the tool outputs topic names and mention frequencies and implies a read-only extraction. It does not explain what 'retrieved activity' means operationally, whether data is re-fetched, or what happens if no activity exists.

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

  Conciseness5/5

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

  The description is one concise sentence with no filler. It front-loads the core behavior and output, making it easy to scan and process.

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

  Completeness2/5

  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 must clarify return format and usage pipeline, but it only gives a high-level summary. It omits preconditions such as 'activity must have been retrieved first' and provides no detail on the structure of the returned topics or frequencies.

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

  Parameters3/5

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

  Schema description coverage is 100% and the only parameter, profileId, is already described as 'Profile ID to extract topics from'. The description adds no additional parameter semantics, so the baseline score of 3 applies.

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

  Purpose4/5

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

  The description uses a specific verb ('Extracts') and names the resource ('top professional topics and mention frequencies') from 'retrieved activity'. It clearly distinguishes this from lead-ranking and prospecting siblings, though 'analyze_recent_activity' may overlap somewhat in scope.

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

  Usage Guidelines2/5

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

  The phrase 'from retrieved activity' implies a prerequisite, but the description never explicitly says to use this after retrieving activity or names alternatives. The agent is left to infer when this tool should be selected among 18 siblings.

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

• linkedin_analyze_postB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It lists analysis dimensions but omits input handling (e.g., whether postContent is required to supplement postId), potential network fetches, side effects, or return format. This leaves significant behavioral ambiguity.

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

  Conciseness4/5

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

  The description is a single efficient sentence with the action and scope front-loaded. The parenthetical dimension list adds value without bloat. It earns a slight deduction for listing only 7 of the 15 dimensions, which could be seen as a missed structured summary.

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

  Completeness2/5

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

  The tool is moderately complex (2 parameters, no output schema, no annotations), yet the description does not explain output format, all 15 dimensions, or how the tool obtains data for a post. An agent would lack enough context to anticipate results or handle edge cases like missing post content.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds the context that the tool analyzes a single post and mentions dimensions, but it does not clarify the relationship between postId and postContent or how to choose between them. No additional parameter-level guidance is offered.

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

  Purpose5/5

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

  The description uses a specific verb ('Performs a deep 15-dimension analysis') with a clear resource ('a single LinkedIn post') and enumerates several dimensions. This differentiates it from sibling tools that target profiles, search results, or recent activity, so an agent can identify the correct tool.

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

  Usage Guidelines3/5

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

  No explicit when-to-use or alternative guidance is provided. The description implies the tool is for analyzing a single LinkedIn post, but it does not explain when to choose it over similar tools like linkedin_analyze_recent_activity or linkedin_analyze_profile.

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

• linkedin_build_lead_searchB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavior disclosure. It does convey that the tool produces a plan and Boolean queries rather than executing a search, but it leaves the planning process, output structure, and any limitations unexplained.

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

  Conciseness5/5

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

  The description is a single, focused sentence that immediately identifies the input (business objectives) and output (plan and Boolean queries). Every word contributes value with no redundancy.

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

  Completeness3/5

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

  The schema covers parameters well, but there is no output schema and the description only vaguely mentions a 'structured plan' without specifying its contents, fields, or query formatting. This is adequate but leaves meaningful gaps for an agent deciding how to use the result.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already fully documents all parameters. The description adds no parameter-level meaning beyond what is already present, which aligns with the baseline score of 3.

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

  Purpose4/5

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

  The description states a clear action: translating a business objective into a structured LinkedIn lead search plan and Boolean queries. It identifies the core resource and output, though it does not explicitly differentiate itself from the overlapping sibling tool linkedin_generate_boolean_search.

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

  Usage Guidelines2/5

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

  The description implies an objective-driven lead search planning use case but provides no explicit guidance on when to use this tool versus linkedin_generate_boolean_search or other siblings. No exclusions, prerequisites, or alternative selection criteria are mentioned.

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

• linkedin_get_recent_activityB
  3.3/5.0
  Behavior3/5

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

  With no annotations present, the description carries the full burden. It adds useful behavioral context: the output is normalized and date-filtered, and 'Retrieves' implies a read-only operation. However, it does not disclose pagination, default behavior when from/to are omitted, or what normalized items actually contain.

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

  Conciseness5/5

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

  A single sentence with no filler; the verb, resource, and filtering scope are front-loaded. Every part of the sentence earns its place.

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

  Completeness3/5

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

  For a low-complexity getter, the core retrieval semantics are present, but with no output schema the description doesn't document return shape, and with many sibling analysis tools it doesn't say when this raw-retrieval tool is preferred. These gaps keep it at adequate rather than complete.

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

  Parameters3/5

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

  The input schema already covers all three parameters with descriptions, and the description adds no parameter-specific meaning beyond 'over a specified date range.' This meets the baseline for high schema coverage but does not elevate it.

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

  Purpose4/5

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

  The description clearly identifies the operation as retrieval and the resource as normalized activity items, scoped to a date range. It is not a tautology and echoes the name, but it does not explicitly differentiate from siblings like linkedin_analyze_recent_activity or linkedin_build_activity_timeline.

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

  Usage Guidelines2/5

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

  No guidance is provided about when to choose this tool over siblings such as linkedin_analyze_recent_activity or linkedin_build_activity_timeline. The description implies a data-retrieval use case but states no exclusions, alternatives, or conditions.

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

• linkedin_import_search_resultsA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description bears the full burden. It discloses the normalization behavior but omits side effects such as whether existing Leads are overwritten, duplicates are created, or the operation is reversible. For a data-ingestion tool this is a significant gap.

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

  Conciseness5/5

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

  A single, front-loaded sentence with no redundant words. It efficiently conveys the action, input formats, and result.

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

  Completeness3/5

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

  The tool is simple and the schema covers both parameters, but the description does not mention return value, failure modes, or pipeline fit. Given no output schema and no annotations, some additional context would help an agent invoke it confidently.

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

  Parameters3/5

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

  Schema coverage is 100%, and both parameters are described in the schema. The description adds no meaningful detail beyond the schema's own parameter descriptions, so it stays at the baseline for high coverage.

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

  Purpose5/5

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

  The description uses a specific verb ('Ingests') alongside a clear resource ('JSON/CSV search result objects or profile URL lists') and outcome ('normalized Lead entities'). This clearly differentiates it from the analysis/ranking siblings, none of which import data.

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

  Usage Guidelines3/5

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

  The intended usage is implied by the description: use this when you have raw search results to import as Leads. However, there are no explicit alternatives, exclusions, or conditions compared with siblings like linkedin_analyze_search_results.

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

• linkedin_research_profileA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden for behavioral disclosure. It does describe an internal pipeline and the returned artifact ('actionable outreach angles'), which is useful. However, it does not disclose whether the operation is read-only, whether it has side effects, what data it relies on, how long it might take, or any auth/permission expectations. The high-level step list provides some transparency but not enough for a tool of this complexity.

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

  Conciseness4/5

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

  The description is a single sentence with no filler words, and it front-loads the high-level purpose ('Runs full end-to-end profile research') before listing the component behaviors. The comma-separated list is slightly dense but every item conveys a distinct part of the tool's function. It is concise and readable, though not as tightly structured as a two-sentence version with explicit scoping.

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

  Completeness2/5

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

  This is a complex tool with 5 parameters, a nested icp object, no output schema, and 19 sibling tools, but the description does not clarify output structure, prerequisite relationships, or how the optional parameters affect behavior. It does not explain what happens if icp is omitted despite being required for the claimed 'evaluates ICP match' step, nor does it describe the format of the returned outreach angles. The description is too thin for an agent to confidently invoke this tool in varied contexts.

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

  Parameters3/5

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

  Schema description coverage is 60%, so the schema already documents most parameter meanings. The tool description adds little beyond the schema: it mentions ICP matching, which loosely aligns with the icp parameter, and 'activity normalization', which implies from/to date usage, but it does not clarify how parameters interact or what the objective field controls. The description mostly restates concepts already present in the schema rather than adding new semantic clarity.

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

  Purpose5/5

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

  The description states a specific verb ('Runs'), a clear resource ('full end-to-end profile research'), and enumerates the concrete sub-steps (normalizes activity, extracts topics, detects signals, evaluates ICP match, returns outreach angles). This clearly differentiates it from the many sibling point-tools like linkedin_extract_topics or linkedin_detect_business_signals, which each handle only one step.

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

  Usage Guidelines3/5

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

  The description implies usage for a complete profile research pipeline but gives no explicit guidance on when to choose this over the individual sibling tools. It does not state exclusions, alternatives, or conditions under which a more specialized tool would be preferable. The 'full end-to-end' phrasing hints at the use case but leaves the selection decision mostly to inference.

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

• linkedin_compare_activity_periodsA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, whether it fetches new data or analyzes existing data, what permissions are required, or what the output structure looks like. The description focuses on purpose rather than behavior.

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

  Conciseness5/5

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

  The description is a single, tight sentence that front-loads the core operation and then gives concrete output-oriented examples. Every phrase earns its place, with no redundant wording.

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

  Completeness3/5

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

  With no output schema and no annotations, the description gives the conceptual outcome but omits practical details such as exact return format, data source, inclusivity of date boundaries, or limitations. It is sufficient for a high-level understanding but not fully complete for an agent needing precise invocation expectations.

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

  Parameters3/5

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

  Schema description coverage is 100%, so parameter meaning is already fully documented in the input schema. The description adds the conceptual context of comparing two periods, but does not provide additional parameter-level semantics beyond the schema.

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

  Purpose5/5

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

  The description uses a specific verb ('compares') and resource ('activity across two date periods'), and immediately distinguishes this from single-period or timeline tools among the siblings by focusing on two-period comparison. It also states the analytical purpose: identify strategy shifts, new topics, or disappearing themes.

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

  Usage Guidelines4/5

  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: when comparing activity between two periods to detect strategy shifts or thematic changes. It does not explicitly mention alternatives or exclusion conditions, but the use case is specific enough to guide selection among the many sibling tools.

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

• linkedin_detect_business_signalsA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It clearly communicates a non-mutating 'scan' action and the type of output signals, but it does not disclose potential external data dependencies, auth requirements, rate limits, or any limitations around profile visibility. The core behavior is stated, but depth is missing.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no filler. It names the resource, the action, and the output categories immediately, making it easy to parse and retain.

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

  Completeness3/5

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

  The tool has only two parameters and no nested objects, so the description is sufficient for basic invocation once profileId is known. However, there is no output schema and no annotation, and the description does not explain what the returned signals look like or when this tool should be preferred over the many activity-analysis siblings, leaving meaningful gaps.

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

  Parameters3/5

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

  Schema coverage is 50%, with profileId only described as 'Profile ID' and category having no description. The description adds some semantic value by explaining the categories ('growth, marketing, operational, and technical tracking signals'), but it does not clarify the exact meaning of the enum values, and the mismatch between 'technical' in the description and 'tracking' in the enum could confuse the agent.

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

  Purpose5/5

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

  The description states a specific verb ('Scans'), a clear resource ('profile activity'), and a distinct outcome ('discover growth, marketing, operational, and technical tracking signals'). The mention of GA4, GTM, CAPI, and Attribution clearly distinguishes this from siblings like linkedin_analyze_recent_activity or linkedin_get_recent_activity.

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

  Usage Guidelines3/5

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

  The description implies the tool should be used when the agent needs to detect tracking or business signals from a LinkedIn profile's activity. However, it provides no explicit when-to-use guidance, no exclusions, and no reference to alternative sibling tools, leaving the selection logic to inference.

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