Server Quality Checklist

Tool Scores

• add_leadC
  2.9/5.0
  Behavior2/5

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

  The description only says 'Add a lead' and does not disclose behavior beyond what the non-destructive annotations and schema already convey. It does not mention idempotency, duplicate handling, whether the lead must already exist, or what side effects may occur.

  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 or redundant elaboration. It is front-loaded with the action and resource, but it is also minimal to the point of omitting helpful contextual distinctions.

  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?

  Given that the schema and output schema cover parameter semantics and return shape, the description is adequate for basic invocation. However, the existence of sibling tools performing narrower versions of the same action means an agent lacks enough context to reliably select between add_lead, add_lead_to_list, and add_existing_lead_to_campaign.

  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 linkedin_url, list_id, campaign_id, and the optional data mapping. The description adds no parameter-level meaning beyond saying 'by LinkedIn URL,' which is already reflected in 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 states a specific verb and resource: it adds a lead to a Prosp contact list and campaign, identified by LinkedIn URL. This clearly conveys the combined action and is more specific than the title alone, though it does not explicitly distinguish itself from the sibling tools add_lead_to_list and add_existing_lead_to_campaign.

  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 combined tool versus the separate add_lead_to_list or add_existing_lead_to_campaign tools. The description names the operation but gives no exclusions, preconditions, or alternative routing.

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

• get_campaign_statusC
  2.9/5.0
  Behavior2/5

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

  The annotation readOnlyHint=true already covers the read-only nature, and the description adds no extra behavioral context such as possible status values, error behavior, or handling of invalid campaign IDs. It merely restates the action from the title.

  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 short sentence with no redundant words. It loses a point because it is essentially a restatement of the tool title and lacks any additional structural or contextual elements.

  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 a single parameter, full schema coverage, an output schema, and a readOnlyHint annotation, the context is mostly complete. However, the description leaves ambiguity about what status values look like and how it differs from get_all_campaigns, so it is merely 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 schema provides 100% coverage for the single campaign_id parameter, including its type and 'Prosp campaign UUID' description. The description's word 'campaign' adds no meaning beyond what the schema already specifies, so the baseline 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 states the verb 'Get' and the resource 'current status of a campaign,' making the basic purpose clear. It does not differentiate from the sibling get_all_campaigns, which may also expose status, so it falls 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?

  The description provides no guidance on when to use this tool versus siblings like get_all_campaigns or get_lead_stage, nor any prerequisites such as a valid campaign ID. The only implied context is that it targets a campaign, which is not sufficient for tool selection.

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

• send_voice_messageC
  2.9/5.0
  Behavior2/5

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

  The annotations only provide destructiveHint=false, and the description adds little beyond the bare sending action. It does not disclose that this sends an external, likely irreversible communication, nor does it mention authorization needs, rate limits, or side effects. The description is not contradictory, but it does not carry the behavioral disclosure burden well.

  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 one concise sentence with no filler and the core action is front-loaded. However, it mostly restates the title plus 'LinkedIn' and 'to a profile', so it is efficient but not exceptional.

  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 input schema has no message content or audio parameter, yet the description does not explain that the voice message is predefined, attached to a campaign, or selected elsewhere. An agent cannot fully understand what will actually be sent, even though an output schema may cover return values.

  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%: both linkedin_url and campaign_id have descriptions in the schema. The tool description adds no additional parameter meaning, so the high-coverage baseline of 3 is appropriate.

  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 and resource: 'Send a LinkedIn voice message to a profile', which clearly identifies the action and target. It does not explicitly compare against the sibling 'send_message', so differentiation relies mainly on the word 'voice' instead of an explicit contrast.

  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 about when to choose this tool over alternatives like send_message. It gives no exclusions, prerequisites, or routing cues, so an agent must infer the appropriate context from the tool name alone.

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

• send_messageB
  3.1/5.0
  Behavior2/5

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

  Annotations only provide destructiveHint=false, which is minimal. The description does not disclose that sending a message is a non-reversible side effect, that it may create a conversation, or any rate-limit or authentication expectations. No contradiction with annotations 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 a single efficient sentence with no filler. It front-loads the action and resource clearly, and every word 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?

  With an output schema present and full parameter coverage, the description is minimally viable. However, it lacks guidance on choosing between text and voice messaging, potential side effects, and any campaign context, making it incomplete for richer decision-making.

  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%, so the schema already documents linkedin_url, message, and campaign_id. The description adds no additional meaning about parameter semantics beyond what the schema provides, so the baseline 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 states a specific verb and resource: 'Send a LinkedIn message to a profile.' This is clear and actionable, and the input schema confirms it is a text message. It does not explicitly differentiate from the sibling send_voice_message, so it misses the top score.

  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 like send_voice_message or when not to use it. It does not mention prerequisites, such as the lead being reachable or needing a valid LinkedIn URL.

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

• get_analyticsA
  3.6/5.0
  Behavior3/5

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

  The readOnlyHint annotation already signals that this is a safe read operation, and the description's 'Get' aligns with that. The description adds minimal context about campaign/workspace scope, but does not reveal additional behavioral traits such as aggregation windows or whether results are cached.

  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 states the core action and scope efficiently, earning its place without redundancy.

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

  Completeness4/5

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

  Given the readOnly annotation, full schema documentation, and presence of an output schema, the description is largely sufficient. It could have explicitly noted that omitting campaign_id returns workspace-level analytics, but that detail is already in the parameter schema and is not essential in the main description.

  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%: the only parameter (campaign_id) is documented with its default and behavior. The description itself adds no parameter-level meaning beyond what the schema already provides, so the baseline 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 states a clear verb ('Get'), a resource ('analytics data'), and a scope ('a campaign or the entire workspace'). It is clear enough to distinguish from siblings like get_campaign_status, but it does not explicitly differentiate itself from other tools.

  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 when to use the tool: for analytics data at campaign or workspace level. It does not explicitly state alternatives or exclusions, such as using get_campaign_status for status checks, leaving the usage guidance mostly implicit.

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

• get_lead_stageA
  3.6/5.0
  Behavior3/5

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

  The description adds no behavioral context beyond what the readOnlyHint annotation already conveys. It does not mention edge cases such as missing leads, invalid campaign IDs, or the meaning of an absent stage, but the annotation sufficiently covers the safety profile and the description does not contradict it.

  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, direct sentence that front-loads the operation and resource with no superfluous words. It is maximally concise while still being informative.

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

  Completeness4/5

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

  For a simple read-only tool with complete parameter schema, a readOnlyHint annotation, and an output schema present, the description provides sufficient context to select and invoke the tool. It could be slightly more complete with a note on typical use cases, but nothing essential is missing.

  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 fully describes both required parameters (linkedin_url and campaign_id) with clear definitions, achieving 100% coverage. The tool description does not add extra meaning about the parameters, 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.

  Purpose5/5

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

  The description states a specific verb ('Get') and resource ('current stage of a lead in a campaign'), making the tool's purpose immediately clear. It uniquely identifies the operation among sibling tools such as get_campaign_status and get_leads_in_campaign, so there is no ambiguity about the resource or 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?

  No guidance is provided about when to use this tool versus the many sibling tools. There are no exclusions, alternative recommendations, or context for typical scenarios, so the agent must infer usage from the name and description alone.

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

• stop_campaignA
  3.6/5.0
  Behavior3/5

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

  The destructiveHint annotation already flags the operation as destructive; the description adds the state precondition that the campaign must be running. It does not describe consequences such as irreversibility or impact on results, but the annotation covers the key safety signal.

  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?

  Single declarative sentence with no filler; front-loads the action and the target. Every word earns its place.

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

  Completeness4/5

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

  For a one-parameter destructive command with an output schema and destructiveHint annotation, the description is nearly complete. It clearly states the action and target state, though it could mention whether stopping is reversible or how it interacts with campign status.

  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?

  With 100% schema description coverage and a single campaign_id parameter, the description adds no additional parameter-level meaning. The schema already documents the parameter as a Prosp campaign UUID, so the baseline of 3 is appropriate.

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

  Purpose4/5

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

  The description states a specific action ('Stop') and resource ('campaign'), and adds the qualifier 'running' to clarify the intended state. It is clearly distinct from siblings like start_campaign, though it does not explicitly name alternatives.

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

  Usage Guidelines3/5

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

  The description implies the appropriate use case—when a campaign is running and should be halted—but provides no explicit when-to-use or when-not-to-use guidance. It also does not direct the agent to alternatives such as start_campaign or get_campaign_status.

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

• delete_leadA
  3.7/5.0
  Behavior3/5

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

  Annotations already flag destructiveHint=true, and the description reinforces this with 'permanently al delete,' adding irreversibility beyond the annotation. It does not disclose side effects like removal from lists/campaigns or inability to undo, but the destructive annotation covers the core safety profile.

  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?

  Single sentence, no filler, front-loaded action verb, and every word contributes. The description is appropriately sized for the tool's simplicity.

  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, with a complete input schema and an output schema, so the short description may be sufficient. However, given its destructive nature, it would benefit from clarifying that deletion is workspace-level and distinct from removing a lead from a campaign, making it slightly under-specified.

  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%, with linkedin_url fully described as 'Lead's full LinkedIn profile URL.' The tool description adds no additional parameter semantics, so the baseline 3 applies.

  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?

  States the exact action ('permanently delete') and resource ('a lead from the workspace'), clearly distinguishing it from the sibling remove_lead_from_campaign, which only removes a lead from a campaign. The verb and target are unambiguous.

  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 word 'permanently' implies this is for full deletion rather than campaign removal, but the description does not explicitly contrast it with remove_lead_from_campaign or state when not to use it. Usage context is implied, not stated.

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

• check_api_keyA
  3.8/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so no contradiction exists. The description adds that the tool checks both key validity and API reachability, which is useful, but it does not describe side effects, error behavior, or what happens on failure beyond the structured output schema.

  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 conveys the tool's core purpose efficiently and does not repeat the name or title.

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

  Completeness5/5

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

  For a zero-parameter health-check tool with readOnly annotation and an output schema, the description covers the essential purpose: validating the API key and reachability. Nothing critical is missing for an agent to decide whether to invoke it.

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

  Parameters4/5

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

  The input schema is empty, and the schema description coverage is 100%, so there are no parameters requiring elaboration. The description correctly implies the tool needs no arguments, which is sufficient for this zero-parameter tool.

  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 ('Verify') and a clear resource ('Prosp API key'), and it states both aspects of the check: key validity and API reachability. It is unambiguous, though it does not explicitly differentiate itself from siblings like get_server_info.

  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 is for validating credentials and connectivity, but it does not explicitly state when to prefer this tool over alternatives or mention any preconditions. The usage context is inferable rather than directly instructed.

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

• start_campaignA
  3.8/5.0
  Behavior3/5

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

  Annotations provide destructiveHint=false, and the description adds the precondition of a startable state. However, it does not disclose what happens on failure, whether the operation is reversible, or what side effects starting a campaign may have. Some behavioral context is present, but gaps remain.

  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 two short sentences with no filler. The main action and the critical precondition are front-loaded and every word earns its place.

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

  Completeness4/5

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

  The tool is simple with one parameter, full schema coverage, and an output schema. The description covers the essential precondition. It could be more explicit about what 'startable state' means or what happens if violated, but the current level is sufficient for a straightforward state-change tool.

  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 parameter campaign_id is already documented as a 'Prosp campaign UUID'. The description adds no parameter-level detail beyond the schema, which is acceptable given the high coverage.

  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?

  Clearly states the operation as starting a campaign, which is a specific verb and resource. It is distinguished from siblings like stop_campaign by the opposing action, though the description largely repeats the tool name.

  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 notes the key precondition: the campaign must be in a startable state. This gives an agent a clear condition to check, likely via get_campaign_status, before calling the tool. It does not explicitly name alternatives or exclusions, but the precondition is meaningful guidance.

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

• add_lead_to_listA
  3.9/5.0
  Behavior3/5

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

  Annotations only declare destructiveHint=false, so the description carries most of the burden. It adds a useful scoping behavior ('only, no campaign assignment'), but it does not disclose whether the lead must already exist, how duplicates are handled, or other side effects. Adequate but with meaningful gaps.

  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 front-loads the action and resource, with the scope exclusion packed into a short parenthetical. Every word earns its place; no filler or 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?

  Given the output schema and fully documented parameters, the definition is usable, but it leaves out routing guidance vs. sibling add tools and any preconditions (e.g., lead existence). For a mutation tool with sparse annotations, a bit more context would be warranted.

  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%, with list_id, linkedin_url, and data each described in the schema. Per the baseline rule, the description need not repeat parameter info, and it does not add extra meaning beyond the schema. This is a correct baseline-3 case.

  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 and resource: adding a lead to a contact list. The parenthetical '(no campaign assignment)' explicitly differentiates it from siblings like add_existing_lead_to_campaign and add_lead, so an agent can distinguish it without opening the schema.

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

  Usage Guidelines4/5

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

  The description clearly scopes the operation to list membership only and explicitly excludes campaign assignment, giving agents a when-not condition. However, it stops short of naming the alternative tools (e.g., add_existing_lead_to_campaign) or stating a positive selection condition, so guidance is strong but not fully explicit.

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

• get_conversationA
  3.9/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, and the description's 'Get' is consistent with that. It adds the useful behavioral fact that the response contains historical conversation content with a lead, but does not disclose pagination, empty-result behavior, or authorization. With annotations covering the safety profile, this is adequate for a simple read operation.

  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?

  One concise sentence with no filler. The action and object are front-loaded, and 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.

  Completeness5/5

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

  For a single-parameter, read-only tool with full schema coverage, a readOnlyHint annotation, and an output schema present, the description plus structured data are sufficient for an agent to invoke it correctly. No critical invocation details are missing.

  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 is already described as the lead's full LinkedIn profile URL. The tool description adds no new parameter semantics beyond the implicit link between the URL and the lead, so the baseline 3 applies.

  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?

  States a specific verb ('Get') and resource ('LinkedIn conversation history with a lead'). The phrase makes clear this is a read operation retrieving existing history, which distinguishes it from siblings like send_message or send_voice_message without needing to name them.

  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 use is implied: call this when you need a lead's past LinkedIn conversation history. However, it does not explicitly say when not to use it or how it relates to alternatives such as send_message or get_lead_stage, leaving routing decisions to inference.

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

• get_leads_in_campaignA
  3.9/5.0
  Behavior3/5

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

  The readOnlyHint annotation already establishes this as a safe read operation, and the description is consistent with it. The description adds only that pagination is optional; it does not disclose pagination defaults, ordering, or any edge-case behavior, though for a read-only listing tool that gap is relatively minor.

  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 efficient sentence with no filler. The action and resource are front-loaded, and 'with optional pagination' adds relevant nuance without redundancy.

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

  Completeness5/5

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

  For a simple read-only listing tool with one required parameter, complete parameter documentation, and an output schema available, the description is sufficient. It does not need to explain return values or parameter details because the structured data already carries that information.

  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 campaign_id, page, and limit are already fully documented in the schema. The description merely restates that pagination is optional without adding any meaning beyond what the parameter descriptions already encode, so it meets the baseline for high schema 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 ('Get'), a specific resource ('all leads in a campaign'), and adds a qualification ('with optional pagination'). This clearly distinguishes it from siblings like get_campaign_status or add_lead without ambiguity.

  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 says this tool gets leads in a campaign, so the intended use is implied from its name and wording. However, it provides no explicit guidance on when to choose this over siblings, no exclusions, and no conditions for when not to use it.

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

• add_existing_lead_to_campaignA
  4/5.0
  Behavior3/5

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

  Annotations only provide destructiveHint=false, so the description carries some responsibility. It adds the useful workflow precondition that the lead is already in the workspace, but it does not disclose behavior around duplicate membership, idempotency, or what happens if the campaign is inactive. No contradiction with annotations.

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

  Conciseness5/5

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

  The description is a single well-structured sentence with no wasted words. The parenthetical qualifier '(already in workspace)' adds meaningful context without bloat.

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

  Completeness4/5

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

  For a simple two-parameter operation with full schema coverage and an output schema, the description provides the key precondition (existing lead) and clear intent. It could be slightly more complete by naming when to prefer add_lead, but nothing critical is missing for invocation.

  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 parameter descriptions already document campaign_id and linkedin_url. The tool description adds context about the lead being existing but does not add new parameter-specific meaning 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 ('add') and resource ('existing lead ... to a campaign'), and clarifies the lead must already be in the workspace. This clearly differentiates it from sibling tools like add_lead or add_lead_to_list.

  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 gives a clear usage condition: the lead must already exist in the workspace. However, it does not explicitly name alternatives or state when not to use this tool, such as for adding new leads.

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

• remove_lead_from_campaignA
  4/5.0
  Behavior4/5

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

  Annotations declare destructiveHint=true, and the description adds valuable nuance by specifying that the lead itself remains in the workspace—so destruction is limited to the campaign membership. This clarifies the scope of the destructive action, though it does not mention reversibility or effects on campaign analytics.

  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 with a useful parenthetical qualifier. Every word adds meaning, and the core action is front-loaded. There is no redundant or filler content.

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

  Completeness4/5

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

  This is a simple two-parameter operation with complete schema documentation, a destructive hint, and an output schema. The description covers the key outcome and the main boundary (lead stays in workspace). It is sufficient for an agent to call the tool correctly, though a note on irreversibility or when to use delete_lead would make it 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?

  Schema description coverage is 100%, with both campaign_id and linkedin_url already documented in the schema. The tool description adds no additional parameter semantics beyond referring to 'lead' and 'campaign,' 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.

  Purpose5/5

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

  The description uses a specific verb and resource: 'Remove a lead from a campaign.' The parenthetical '(lead stays in workspace)' clearly delineates this from delete_lead and other destructive operations, making the tool's purpose unambiguous.

  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 'lead stays in workspace' implies this tool should be used when the lead should be preserved but removed from a specific campaign. However, it does not explicitly name alternatives like delete_lead, add_existing_lead_to_campaign, or state conditions for when to choose those instead. Usage context is implied rather than explicit.

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

• get_server_infoA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description adds meaningful detail about what the tool exposes: server version, config status, and loaded tools. For a zero-parameter read-only informational tool, this is sufficient transparency about its 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 immediately says what the tool does and enumerates the three key outputs. There is no redundancy or filler.

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

  Completeness5/5

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

  With zero parameters, an output schema present, and a readOnlyHint annotation, the description covers everything an agent needs to decide whether and when to call this tool. It is complete for an informational server-status endpoint.

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

  Parameters4/5

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

  The input schema has zero parameters, so parameter-level semantics are not applicable. Per calibration, zero-parameter tools get a baseline of 4, and the description does not need to compensate for any missing parameter documentation.

  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 ('Get') and identifies a distinct resource ('Prosp MCP server'), then lists exactly what is returned: version, config status, and loaded tools. This clearly distinguishes it from sibling tools that operate on campaigns, leads, or messages.

  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 use is implied by the name and description: call this tool when you need server-level information like version or config status. However, there is no explicit guidance contrasting it with related tools such as check_api_key or get_campaign_status, nor any when-not-to-use conditions.

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

• get_all_campaignsA
  4.5/5.0
  Behavior4/5

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

  The readOnlyHint annotation already establishes the safe, read-only nature of the operation. The description adds the 'all campaigns' scope, indicating no filtering, and the output schema covers the return shape. No contradiction 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 a single, short sentence with no filler. It is front-loaded with the action and resource and earns its place without redundancy.

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

  Completeness5/5

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

  For a zero-parameter, read-only list-all operation with an output schema, nothing essential is missing. The readOnlyHint, empty input schema, and output schema together with the description provide a complete picture.

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

  Parameters4/5

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

  The input schema has zero parameters, so there is no parameter semantics for the description to add. The schema description coverage is effectively 100% because the schema is empty, so baseline 4 applies.

  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 the exact verb 'Get' and the resource 'all campaigns' with workspace scope. This clearly distinguishes it from siblings like get_campaign_status, which targets a single campaign's status, and other lead/analytics tools.

  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 makes clear this is the tool for retrieving the full campaign list in the workspace. It does not name alternatives or exclusion criteria, but for a parameterless list-all operation, the context is unambiguous.

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