Server Quality Checklist

Tool Scores

• createCategoryB
  3.1/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 states that the tool creates a new category and lists possible data fields, but it doesn't cover critical aspects like whether this is a write operation (implied by 'create'), error handling, rate limits, or what the response looks like. This leaves significant gaps for a mutation 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, efficient sentence that front-loads the core action ('Create a new product category') and adds useful details without waste. Every word earns its place, making it appropriately sized and well-structured.

  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 that this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., permissions, side effects), response format, and error conditions, which are essential for safe and effective use by an AI agent.

  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 0 parameters with 100% coverage, so no parameters are documented in the schema. The description compensates by listing possible data fields ('title, description, image, and URL'), adding semantic meaning beyond the empty schema. However, it doesn't specify if these are required or optional, leaving some ambiguity.

  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 states the verb ('create') and resource ('new product category in the Omnisend catalog'), making the purpose specific and understandable. It distinguishes from siblings like 'updateCategory' or 'deleteCategory' by focusing on creation. However, it doesn't explicitly differentiate from 'createProduct' or 'createContact' beyond the resource type.

  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 'updateCategory' or 'listCategories', nor does it mention prerequisites such as authentication or permissions. It implies usage for creating categories but lacks explicit context or exclusions.

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

• createContactB
  3.1/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 states the tool 'create[s] or update[s] a contact,' implying a mutation operation, but doesn't disclose critical traits like required permissions, whether it's idempotent, error handling, or rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

  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 appropriately concise with two sentences: the first states the purpose, and the second details the data scope. It's front-loaded with the core function and avoids unnecessary words. However, it could be slightly more structured by explicitly separating creation and update scenarios.

  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 tool's complexity (a mutation operation with no annotations and no output schema), the description is minimally adequate. It covers the purpose and data scope but lacks details on behavioral traits, usage context, and output expectations. For a mutation tool, this leaves gaps in completeness, though the parameter semantics are well-handled.

  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 0 parameters with 100% coverage, so the schema fully documents the lack of parameters. The description adds value by specifying what data can be included ('identifiers, personal information, subscription status, and custom properties'), which provides semantic context beyond the empty schema. This compensates well for the parameter-less design.

  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 states the tool's purpose: 'Create or update a contact in Omnisend.' It specifies the verb ('create or update') and resource ('contact'), and distinguishes it from siblings like 'getContact' or 'listContacts' by indicating it's a write operation. However, it doesn't explicitly differentiate from 'updateContact' (a sibling tool), which slightly reduces clarity.

  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. It doesn't mention when to choose 'createContact' over 'updateContact' (a sibling), nor does it specify prerequisites or contexts for use. The lack of usage guidelines leaves the agent without direction on tool selection.

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

• createProductB
  3.1/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 states this is a creation operation but doesn't mention whether it requires authentication, what happens on duplicate products, rate limits, or what the response looks like. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding 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 perfectly concise - two sentences that immediately state the purpose and provide useful context about data content. Every word earns its place with no redundancy or unnecessary elaboration, making it easy to parse quickly.

  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 creation tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what happens after creation (e.g., returns product ID, success status), error handling, authentication requirements, or how it differs from similar operations like 'replaceProduct'. Given the complexity of product creation and lack of structured metadata, more context is needed.

  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 0 parameters with 100% coverage, so the baseline is 4. The description adds value by specifying what product data 'can include' (title, description, variants, images, price, and more), giving semantic context about expected content even though no formal parameters are defined 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 clearly states the action ('Create a new product') and resource ('in the Omnisend catalog'), making the purpose immediately understandable. It distinguishes from siblings like 'deleteProduct' and 'updateCategory' by specifying creation rather than modification or deletion. However, it doesn't explicitly differentiate from 'replaceProduct' which might also involve product creation in some contexts.

  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 'replaceProduct' or 'updateProduct' (which doesn't exist but 'updateCategory' suggests similar patterns). It mentions what data can be included but gives no context about prerequisites, error conditions, or typical use cases compared to sibling tools.

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

• deleteCategoryB
  3.1/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 implies a destructive operation ('Remove') but doesn't specify if deletion is permanent, reversible, or requires specific permissions. No information on rate limits, error handling, or side effects is included, leaving significant gaps for a mutation 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, efficient sentence that front-loads the key action and resource. There is no wasted verbiage, and it directly communicates the tool's function without unnecessary details, making it highly concise and well-structured.

  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 destructive tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permanence, permissions), response format, or error conditions. Given the complexity of a delete operation, more context is needed to ensure safe and correct usage.

  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 0 parameters with 100% coverage, so no parameter documentation is needed. The description mentions 'by its unique identifier,' which aligns with the schema's lack of properties, suggesting the identifier might be handled elsewhere (e.g., in the URL). This adds minimal but appropriate context given the empty 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 clearly states the action ('Remove') and resource ('product category from the Omnisend catalog'), making the purpose immediately understandable. It distinguishes from siblings like 'deleteProduct' by specifying the resource type. However, it doesn't explicitly contrast with 'updateCategory' or 'getCategory' for full differentiation.

  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 'updateCategory' or 'deleteProduct', nor does it mention prerequisites such as needing the category's unique identifier. It simply states what the tool does without contextual usage instructions.

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

• getContactB
  3.1/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 states this is a retrieval operation, implying read-only behavior, but doesn't mention authentication needs, rate limits, error conditions, or what 'detailed information' includes. The description is minimal and lacks behavioral context beyond the basic 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?

  The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's appropriately sized and front-loaded, with every word contributing to understanding the operation.

  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 retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'detailed information' includes, potential response formats, or error handling. Given the lack of structured data, the description should provide more context about the tool's behavior and outputs.

  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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and the mention of 'unique identifier' is contextual rather than parameter-specific. Baseline 4 is correct for zero-parameter tools.

  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 states the verb ('Retrieve') and resource ('detailed information about a specific contact'), making the purpose understandable. It distinguishes from siblings like 'listContacts' by focusing on a single contact, but doesn't explicitly contrast with 'getCategory' or 'getProduct' which follow similar patterns.

  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. It doesn't mention when to use 'getContact' versus 'listContacts', or clarify that it requires a contact identifier (though implied by 'unique identifier'). No exclusions or prerequisites are stated.

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

• getProductB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states it's a retrieval operation. It doesn't disclose behavioral traits such as error handling, authentication needs, rate limits, or what 'detailed information' entails, which is insufficient for a tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's function without any wasted words. It is appropriately sized and front-loaded, making it easy to understand quickly.

  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 tool's simplicity (0 parameters, no output schema), the description is minimal but lacks completeness. It doesn't explain what 'detailed information' includes, error cases, or how it differs from siblings, leaving gaps in context despite the low complexity.

  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 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by specifying retrieval by 'unique identifier', which clarifies the expected input context beyond the empty schema, justifying a score above the baseline 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 clearly states the action ('retrieve detailed information') and resource ('specific product'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'getCategory' or 'getContact', which follow the same pattern for different resources, so it doesn't reach the highest 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 'listProducts' or 'getCategory'. It mentions retrieving by 'unique identifier' but doesn't clarify prerequisites or exclusions, leaving usage context implied at best.

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

• getCategoryB
  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 states this is a retrieval operation, implying it's likely read-only and non-destructive, but doesn't confirm this explicitly. It lacks details on authentication needs, error handling (e.g., what happens if the ID is invalid), rate limits, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding 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, efficient sentence that front-loads the core action ('Retrieve detailed information') and resource. There is no wasted language or redundancy, making it easy to parse quickly. Every word contributes directly to understanding the tool's function.

  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 tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks behavioral details (e.g., safety, errors) and usage guidelines, which are more critical in this sparse context. Without annotations or output schema, the agent has incomplete information about how to invoke it successfully or interpret results.

  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 0 parameters with 100% coverage, so the schema fully documents the absence of parameters. The description adds value by specifying that retrieval is 'by its unique identifier,' implying an ID is needed, though it doesn't clarify if this is passed differently (e.g., in the URL or context). This extra semantic hint compensates slightly beyond the schema's empty state, warranting a score above the baseline 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 clearly states the verb ('Retrieve') and resource ('detailed information about a specific product category'), making the purpose understandable. It distinguishes from siblings like listCategories (which lists multiple categories) and updateCategory (which modifies categories). However, it doesn't explicitly contrast with getProduct or getContact, which have similar retrieval patterns for different resources.

  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. It doesn't mention prerequisites (e.g., needing a category ID), exclusions (e.g., not for listing categories), or direct comparisons to siblings like listCategories (for browsing) or getProduct (for product details). The agent must infer usage from the name and context alone.

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

• deleteProductB
  3.4/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states the action without disclosing behavioral traits like whether deletion is permanent, requires specific permissions, triggers side effects (e.g., removing associated data), or provides confirmation responses. It lacks critical details for a destructive 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?

  The description is a single, well-structured sentence that efficiently conveys the core action and target without redundancy. It is front-loaded with the main purpose and uses no extra words, making it highly concise and 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?

  For a destructive tool with no annotations and no output schema, the description is incomplete. It fails to address key aspects like return values (e.g., success/failure indicators), error handling, or implications of deletion, leaving significant gaps for an AI agent to understand the tool's behavior fully.

  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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not add parameter details, maintaining focus on the tool's purpose. Baseline is 4 for zero parameters, as it avoids unnecessary information.

  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 clearly states the specific action ('Remove'), target resource ('product from the Omnisend catalog'), and mechanism ('by its unique identifier'). It distinguishes from siblings like 'deleteCategory' by specifying the resource type and from 'replaceProduct' by indicating permanent removal rather than replacement.

  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 'replaceProduct' or 'updateProduct', nor does it mention prerequisites such as needing the product's ID or confirmations for deletion. It only states what the tool does without contextual usage information.

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

• getCurrentBrandB
  3.4/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. It indicates this is a read operation ('Retrieve'), but doesn't disclose behavioral traits like authentication needs, rate limits, or error handling. It adds some context by listing the returned data types, but lacks details on response format or potential side effects. This is adequate but has clear gaps for a tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is two sentences that efficiently state the purpose and scope without redundancy. It's front-loaded with the core function and follows with specific details. Every sentence adds value, and there's no wasted text.

  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 tool's low complexity (0 parameters, no output schema, no annotations), the description is minimally complete. It explains what data is returned but lacks information on response structure or operational context. Without annotations or output schema, it should ideally provide more behavioral details, but it's adequate for a simple retrieval tool.

  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 tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to compensate for any gaps, and it appropriately doesn't discuss parameters. Baseline 4 is applied as it meets expectations for a parameterless 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 clearly states the tool's purpose with a specific verb ('Retrieve') and resource ('information about the current brand'), including what data is returned (brand ID, website, etc.). It distinguishes this from siblings like getCategory or getProduct by specifying brand information rather than other entity types. However, it doesn't explicitly contrast with all siblings, keeping it at 4 instead of 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 alternatives. It doesn't mention prerequisites, context for brand retrieval, or comparisons to other tools like getCategory or listContacts. Usage is implied by the purpose but lacks explicit when/when-not instructions.

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

• listProductsB
  3.4/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 of behavioral disclosure. It adds useful context about pagination support and response structure (including cursors, limit, offset), which goes beyond a basic read operation. However, it doesn't cover aspects like rate limits, authentication needs, or error handling, leaving some gaps in transparency.

  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 efficiently structured in two sentences: the first states the core purpose, and the second adds critical behavioral context (pagination). There is no wasted text, and information is front-loaded appropriately for a tool with no parameters.

  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 tool's complexity (a list operation with pagination), no annotations, and no output schema, the description is moderately complete. It covers the pagination behavior but lacks details on response format, error cases, or integration with sibling tools. For a read-only tool with no params, this is adequate but has clear gaps.

  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 0 parameters with 100% coverage, so the description doesn't need to compensate for undocumented parameters. It appropriately focuses on behavioral aspects (pagination) rather than parameter details, earning a baseline 4 for not adding unnecessary param info.

  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 states the verb ('Retrieve') and resource ('list of products from the Omnisend catalog'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'getProduct' (singular) or 'listCategories'/'listContacts', which would require a more specific distinction to earn 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 alternatives like 'getProduct' (for single products) or 'listCategories'/'listContacts' (for other list operations). It mentions pagination support but doesn't specify scenarios where this is preferred over other list tools, leaving usage context implied at best.

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

• sendEventB
  3.4/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. It mentions that events 'can trigger automations', which adds some behavioral context. However, it lacks details on permissions, rate limits, error handling, or what constitutes a 'customer event'. For a mutation tool with zero annotation coverage, this is insufficient.

  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 appropriately sized and front-loaded: it starts with the core action ('Send a customer event'), then explains purpose and types. Every sentence earns its place by adding context without redundancy. It's efficient with zero waste.

  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 tool has no parameters, no output schema, and no annotations, the description is minimally adequate. It explains what the tool does and the event types, but as a mutation tool, it should provide more behavioral context (e.g., side effects, success indicators). The lack of output schema means the description doesn't explain return values, which is a gap.

  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 0 parameters with 100% coverage, so no parameters need documentation. The description adds value by explaining the semantics: events can be 'custom events or predefined system events', which clarifies what can be sent. This compensates for the lack of parameter details 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 clearly states the tool's purpose: 'Send a customer event to Omnisend' with the specific verb 'send' and resource 'customer event'. It distinguishes this from sibling tools by focusing on event tracking rather than CRUD operations on categories, contacts, or products. However, it doesn't explicitly differentiate from potential sibling event tools (though none exist in the provided list).

  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 provides implied usage context: 'Events are used to track customer behavior and can trigger automations.' This suggests when to use it—for tracking behavior or triggering automations—but doesn't explicitly state when not to use it or name alternatives. No guidance is given on prerequisites or comparisons with other tools.

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

• listContactsA
  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. It discloses that contacts have multiple identifiers and that the response includes pagination details, which is useful behavioral context. However, it doesn't mention rate limits, authentication requirements, or whether this is a read-only operation (though 'Retrieve' implies it).

  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 two concise sentences that efficiently cover purpose and key behavioral details. It's front-loaded with the main action and avoids unnecessary elaboration, though it could be slightly more structured by separating purpose from behavioral notes.

  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 list retrieval tool with no annotations and no output schema, the description provides basic purpose and pagination context but lacks details on authentication, error handling, or response format specifics. It's minimally adequate but has clear gaps given the complexity of a contact listing operation.

  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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on output behavior. A baseline of 4 is applied for zero-parameter tools when the schema is fully covered.

  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 states the action ('Retrieve a list') and resource ('contacts from Omnisend'), making the purpose understandable. It distinguishes from siblings like getContact (singular) and createContact (write operation), but doesn't explicitly contrast with other list tools like listCategories or listProducts.

  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 retrieving multiple contacts rather than single contacts (getContact) or creating them (createContact), but provides no explicit guidance on when to choose this tool over alternatives like listCategories or listProducts, nor any prerequisites or exclusions.

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

• pingA
  3.7/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. It discloses that this is a 'simple tool' for checking server status, which implies a read-only, non-destructive operation. However, it lacks details on response format, error handling, or rate limits, making it adequate but incomplete for behavioral context.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the purpose ('Simple tool to check if the MCP server is running correctly') with zero wasted words. It's appropriately sized for a simple tool and every part 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?

  Given the tool's low complexity (0 parameters, no output schema, simple purpose), the description is mostly complete. It explains what the tool does and its intent. However, without annotations or an output schema, it could benefit from mentioning expected responses or error cases for full completeness.

  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 0 parameters with 100% coverage, so the schema fully documents the absence of inputs. The description doesn't need to add parameter details, and it appropriately doesn't mention any, earning a baseline score for tools with no parameters.

  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 states the tool's purpose as checking if the MCP server is running correctly, which is a specific verb ('check') with a clear resource ('MCP server'). However, it doesn't distinguish from sibling tools like 'sendEvent' which might also indicate server responsiveness, so it misses full sibling differentiation.

  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 server health checks ('check if the MCP server is running correctly'), providing some context. But it doesn't explicitly state when to use this versus alternatives like 'sendEvent' for testing connectivity, nor does it mention exclusions or prerequisites, leaving room for ambiguity.

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

• replaceProductA
  4/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 burden. It discloses that the tool is a mutation ('replace'), requires a specific workflow (get first, then replace), and needs structural preservation. However, it lacks details on permissions, error handling, or side effects, which are important for a mutation tool with no 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 front-loaded with the core purpose, followed by critical usage instructions. Every sentence earns its place by providing essential guidance without redundancy, making it appropriately sized and well-structured.

  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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It covers the workflow and structural requirements but misses details like response format, error conditions, or confirmation of changes, which are needed for adequate context.

  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 0 parameters with 100% coverage, so the baseline is 4. The description adds value by explaining that parameters should mirror the structure from 'getProduct' with only desired changes, providing semantic context beyond the empty 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 clearly states the tool's purpose: 'Replace an existing product with new data.' It specifies the verb ('replace') and resource ('product'), but does not explicitly differentiate it from sibling tools like 'updateProduct' or 'createProduct', which would require 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 Guidelines5/5

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

  The description provides explicit guidance on when and how to use this tool: 'You must first get the product using getProduct and preserve the returned structure when replacing.' It also specifies the alternative tool ('getProduct') for the prerequisite step, making usage clear.

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

• updateCategoryA
  4.1/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 of behavioral disclosure. It reveals that this is a mutation operation ('Update') and specifies a required workflow (get then update with preserved structure), which adds useful context. However, it doesn't address permissions, error conditions, or what happens to unspecified fields during update.

  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 perfectly concise with two sentences: one stating the purpose and one providing critical usage guidance. Every word earns its place, and the important workflow requirement is front-loaded with 'IMPORTANT:'

  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 mutation tool with no annotations and no output schema, the description does well by specifying the required workflow and structural preservation. However, it doesn't explain what the tool returns or potential side effects, leaving some gaps in completeness for an update operation.

  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 0 parameters with 100% coverage, so the schema already fully documents the parameter situation. The description adds value by explaining that parameters should come from 'getCategory' and must 'preserve the returned structure,' providing important semantic guidance beyond the empty 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 clearly states the action ('Update') and resource ('an existing product category'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'replaceProduct' which might also update product-related entities, so it doesn't achieve full sibling distinction.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use this tool: 'You must first get the category using getCategory and preserve the returned structure when updating.' This clearly states a prerequisite workflow and distinguishes it from alternatives like createCategory or deleteCategory.

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

• listCategoriesA
  4.2/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 of behavioral disclosure. It helpfully describes the pagination behavior and response structure, which is valuable context beyond basic functionality. However, it doesn't mention potential rate limits, authentication requirements, error conditions, or whether this operation is safe/read-only (though implied by 'Retrieve').

  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 perfectly concise with two sentences that each earn their place: the first states the core functionality, the second provides crucial behavioral detail about pagination. No wasted words, and the most important information (what the tool does) is front-loaded.

  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 read-only list operation with no parameters and no output schema, the description provides good coverage of what the tool does and its pagination behavior. However, without annotations or output schema, it could benefit from mentioning the expected response format beyond just pagination metadata, and clarifying any authentication or rate limit considerations.

  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 0 parameters with 100% coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist, maintaining focus on the tool's behavior and output. This meets the baseline expectation for zero-parameter tools.

  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 clearly states the specific action ('Retrieve a list'), resource ('product categories from the Omnisend catalog'), and scope ('with pagination support'). It explicitly distinguishes this from sibling tools like getCategory (singular retrieval) and listProducts/Contacts (different resource types).

  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 about retrieving paginated lists of product categories, which implicitly suggests using this for bulk retrieval rather than getCategory for single items. However, it doesn't explicitly state when NOT to use this tool or name specific alternatives among siblings like listProducts or listContacts for different resource types.

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

• updateContactA
  4.3/5.0
  Behavior4/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 effectively describes the mutation behavior ('update'), the required workflow (get-preserve-update), and the structural requirement (same structure as GET response). However, it doesn't mention permissions, error handling, or rate limits, which are typical gaps for mutation 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 front-loaded with the purpose, followed by critical guidelines in two concise sentences. Every sentence earns its place by providing essential workflow and structural information 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 tool's complexity (a mutation with a specific workflow), no annotations, no output schema, and 0 parameters, the description is reasonably complete. It covers the purpose, usage prerequisites, and structural requirements. However, it lacks details on error cases or response format, which could be helpful for a mutation tool.

  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 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by explaining the implicit parameter semantics: the update requires 'the same structure as returned by the GET method, with only your desired changes applied,' which clarifies how to construct the request body beyond the empty 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 clearly states the tool's purpose: 'Update an existing contact's information.' It specifies the verb ('update') and resource ('contact'), though it doesn't explicitly differentiate from sibling tools like 'updateCategory' or 'replaceProduct' beyond the contact focus.

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidelines: 'You must first get the contact using getContact and preserve the returned structure when updating.' It also specifies the alternative tool ('getContact') and the prerequisite workflow, making it clear when and how to use this tool.

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