Server Quality Checklist

Tool Scores

• affiliate_awin-advertiser_list_programmesB
  3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does mention that it returns an array of Programme records, which is helpful, but it omits important behavior such as authentication requirements, pagination behavior, default scoping (joined vs. available), and any filtering semantics. These gaps leave the agent without sufficient understanding of side effects or operational constraints.

  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 compact, with three sentences that each add value: the core action, example usage prompts, and related tools. It is front-loaded with the main purpose and avoids verbose explanations, though the list of example questions is slightly redundant with the opening sentence.

  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 7 parameters, no output schema, and no annotations, the description is insufficiently complete. It does not explain the required 'brand' parameter, the distinction between advertisements available vs. joined, or pagination and filtering behavior. The inclusion of return type and related tools is positive, but too much critical context is missing for an agent to use this tool correctly.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description provides no information about any of the 7 parameters. The required 'brand' parameter is entirely unexplained, and there is no guidance on how 'limit', 'cursor', 'status', or 'categories' affect the results. The description fails to compensate for the lack of schema details.

  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 lists affiliate programmes the publisher has joined (or are available), giving a specific verb and resource. The mention of 'Awin (advertiser)' and pairing with get_programme/list_transactions provides some distinction from siblings, but it does not explicitly differentiate from the non-advertiser 'affiliate_awin_list_programmes' tool.

  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 explicitly provides example user queries ('which merchants am I working with?', 'what programmes do I have on Awin (advertiser)?') and mentions 'wants a partner inventory.' This gives clear when-to-use guidance. It also references related tools for drill-down and activity, but does not explicitly state when not to use this tool or name alternative list_programmes tools.

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

• affiliate_daisycon-advertiser_list_programmesB
  3.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description bears the transparency burden. It adds useful context such as 'or which are available to join' and states the return type ('array of Programme records'), but it does not disclose authentication requirements, side effects, or clarify the ambiguous advertiser/publisher semantics. This is minimally adequate but not rich.

  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 concise (three sentences) and front-loads the primary action. The phrase 'publisher has joined on Daisycon (advertiser)' is awkward and slightly confusing, but the overall structure is efficient and to the point.

  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 7 parameters, no output schema, and no annotations, the description must provide more context to be usable. It gives useful user-intent examples and mentions return shape, but lacks parameter definitions, pagination details, and fails to resolve the advertiser/publisher ambiguity, making it incomplete for a tool of this complexity.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description offers no explanation for any of the 7 parameters, including the required 'brand' parameter. The description fails to compensate for the lack of schema-level documentation, leaving the agent guessing how to populate parameters correctly.

  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 lists affiliate programmes on Daisycon from an advertiser perspective, with example queries ('which merchants am I working with?'). However, the phrase 'the publisher has joined' creates ambiguity about whether this is for an advertiser account viewing publisher memberships or a publisher listing programmes, which muddies the resource scope.

  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?

  It explicitly provides user-query examples ('which merchants am I working with?') and mentions complementary tools (get_programme for drill-down, list_transactions for activity). It does not explicitly state when not to use it, but the advertiser qualifier in the name implies distinction from the publisher-side daisycon_list_programmes.

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

• affiliate_partnerstack-advertiser_list_programmesB
  3.1/5.0
  Behavior3/5

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

  No annotations are present, so the description must disclose behavior itself. It states the return type ('array of Programme records') and that results include both programmes the publisher has joined and those available to join, but it doesn't mention pagination, authentication, or any side effects.

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

  Conciseness4/5

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

  The description is three sentences and front-loaded with the main purpose, followed by usage examples and a pairing note. It's concise and without fluff, though the example queries restate the platform context.

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

  Completeness2/5

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

  This tool has seven parameters, no annotations, and no output schema, yet the description covers only the high-level purpose and return type. Essential details about the 'brand' parameter, pagination via cursor/limit/offset, and status/categories filtering are left unexplained, making it incomplete for correct invocation.

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

  Parameters1/5

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

  With 0% schema description coverage and seven parameters, the description fails to explain the required 'brand' parameter or any optional parameters like limit, cursor, offset, search, status, and categories. The parameter names are somewhat self-explanatory, but 'brand' is ambiguous and could refer to the publisher, advertiser, or network.

  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 opens with a clear action: 'List affiliate programmes the publisher has joined on PartnerStack (advertiser)', and reinforces with concrete user query examples. It distinguishes from the sibling partnerstack_list_programmes by specifying the advertiser context, although the publisher/advertiser phrasing creates some ambiguity about the intended perspective.

  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 explicit when-to-use signals via quoted user questions and describes a natural pairing with get_programme and list_transactions for downstream actions. It doesn't explicitly exclude the non-advertiser sibling variant, but the context is sufficiently clear.

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

• affiliate_value-commerce_list_programmesB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions returning an array of Programme records but is ambiguous about whether it lists only joined programmes, only available ones, or both ('or which are available to join'). It does not disclose pagination behavior, authentication requirements, or how the status parameter affects results.

  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 compact at three sentences, front-loaded with purpose and usage examples. The return type is mentioned. However, the first sentence's ambiguity around 'or which are available to join' slightly detracts from clarity, so not a perfect score.

  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 6 parameters, no annotations, and no output schema, the description is insufficiently complete. It does not explain parameter usage, expected filters, or pagination. It only states the broad purpose and return type, leaving the agent with little guidance for correct invocation.

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

  Parameters1/5

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

  The schema has 6 parameters (limit, cursor, offset, search, status, categories) with zero description coverage. The description does not mention any parameter, how to use them, or what values are expected. This is a significant gap for a tool with this many optional filters.

  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 tool lists affiliate programmes the publisher has joined on ValueCommerce, with a specific verb and resource. It also distinguishes itself from sibling tools like get_programme and list_transactions by focusing on the programme list, and noting it returns Programme records.

  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?

  It provides concrete example user queries ('which merchants am I working with?', 'what programmes do I have on ValueCommerce?') and mentions pairing naturally with get_programme for drill-down and list_transactions for activity. However, it does not explicitly state when not to use this tool versus alternatives, so it falls just short of a 5.

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

• affiliate_admitad-advertiser_list_programmesB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It adds useful context by noting programmes may be joined or available to join and that the result is an array of Programme records. However, it omits read-only status, pagination behavior, auth needs, and any side effects, which is a gap for a list 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 three sentences, each earning its place: it states the core function, gives concrete usage prompts, and notes return type plus related tools. It is well-structured and free of fluff.

  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 description covers purpose and usage context well, but with 7 parameters at 0% schema coverage and no output schema or annotations, it lacks enough information for confident invocation. Parameter semantics and behavioral details are essential for this tool and are largely missing.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description provides no explanation for any of the 7 parameters, including the required brand parameter. The agent gets no guidance on how to set limit, cursor, offset, search, status, or categories, making correct invocation difficult.

  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 it lists affiliate programmes on Admitad (advertiser), gives example user queries, and specifies the return type. It does not explicitly contrast with the sibling affiliate_admitad_list_programmes, but the scope and use cases are specific enough to identify this tool.

  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?

  Provides explicit trigger examples ('which merchants am I working with?') and suggests natural companion tools (get_programme, list_transactions). It does not mention when not to use it or how it differs from other list_programmes siblings, but the context is clear.

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

• affiliate_clickbank_list_programmesB
  3.3/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 the return type ('an array of Programme records') and the subtle 'joined or available' behavior, which is useful. However, it does not mention authentication requirements, pagination behavior, read-only nature, or filtering semantics, leaving significant behavioral gaps.

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

  Conciseness5/5

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

  The description is three sentences, front-loaded with the primary purpose, followed by usage examples and return/pairing info. Every sentence adds value with no fluff or redundancy, making it both 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?

  Given the tool has no annotations, no output schema, and 0% parameter coverage, the description is the only documentation. It covers purpose and return type but leaves the six parameters, error handling, pagination, and the joined-vs-available ambiguity unexplained. A more complete description would detail parameter behavior and clarify the listing scope.

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

  Parameters1/5

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

  The input schema has six parameters (limit, cursor, offset, search, status, categories) with 0% schema description coverage, and the description does not mention any of them. This is a critical gap: an agent has no guidance on how to use these parameters for filtering or pagination beyond their names.

  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 ('List') and resource ('affiliate programmes the publisher has joined on ClickBank'), distinguishing it from the many sibling list_programmes tools. However, the parenthetical '(or which are available to join)' introduces ambiguity about whether the tool returns joined programmes only or also available ones, preventing a perfect score.

  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 explicit example user queries ('which merchants am I working with?') and a general use case ('wants a partner inventory'), guiding when to invoke the tool. It also names complementary siblings (get_programme, list_transactions), but does not explicitly state when not to use it, e.g., for non-ClickBank networks.

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

• affiliate_everflow-advertiser_list_clicksB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description must carry the burden of behavioral disclosure. It mentions that it returns Click records and supports optional filtering by programme and date, but it does not disclose pagination behavior, authentication requirements, rate limits, or error handling. This is moderate transparency but incomplete for a tool with no annotation support.

  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 three concise sentences that are front-loaded with the core action, then provide use cases, output type, and a pairing recommendation. Every sentence adds value and there is no redundant content.

  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 7 params, no output schema, and no annotations, the description is insufficiently complete. It fails to mention the required 'brand' parameter, pagination controls, output record structure, or error scenarios, making it difficult for an agent to reliably invoke the tool without additional context.

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

  Parameters2/5

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

  The schema has 7 parameters with 0% description coverage, so the description must compensate. It only vaguely references 'programme and date' filtering, ignoring required 'brand' and pagination params like 'limit', 'cursor', and 'offset'. This leaves the agent without guidance on how to properly construct calls.

  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 function with a specific verb ('List') and resource ('recent affiliate clicks on Everflow (Advertiser)'), and provides concrete use case examples. However, it does not explicitly differentiate from the sibling tool 'affiliate_everflow_list_clicks', relying on the name suffix 'advertiser' rather than explaining the distinction.

  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 explicitly says 'Use this for traffic-side debugging' and gives example questions ('are my links being clicked at all?'), which provides clear usage context. It also recommends pairing with 'list_transactions' to compare clicks vs conversions, but does not mention when not to use it or alternative tools.

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

• affiliate_everflow-advertiser_list_programmesB
  3.3/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses the return type ('array of Programme records') and the scope nuance ('or which are available to join'), which adds value. However, it does not mention read-only status, authentication requirements, or pagination behavior, leaving gaps for a safe and effective invocation.

  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, front-loaded with purpose, and includes examples and related-tool references. Every sentence earns its place with no wasted words.

  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 7 parameters, no annotations, and no output schema, the description is inadequate. It fails to explain parameter semantics, pagination, or the structure of returned Programme records. The cross-references to get_programme and list_transactions help but do not compensate for missing invocation details.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description adds no parameter explanations. The required 'brand' parameter is not described, nor are optional filters like status, categories, or search. An agent would have no guidance on what values to provide, making correct invocation guesswork.

  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 lists affiliate programmes on Everflow (Advertiser) and provides concrete example user queries. It distinguishes from the non-advertiser sibling by naming the platform variant. However, the phrase 'publisher has joined' in an advertiser context introduces ambiguity, and the dual joined/available behavior could be stated more precisely.

  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 explicit trigger queries ('which merchants am I working with?', 'what programmes do I have on Everflow (Advertiser)?') and explains how it pairs with get_programme and list_transactions for drill-down and activity. It lacks explicit when-not-to-use or alternatives, but the examples provide sufficient context for selection.

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

• affiliate_growsurf_list_programmesB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool lists programmes and returns an array of Programme records. It does not disclose whether authentication is required, whether this is a read-only operation, how the required 'brand' parameter filters results, or any pagination/rate-limit behavior. The omission of the required brand parameter's role is a significant transparency gap.

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

  Conciseness5/5

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

  The description is three sentences long, front-loaded with the core purpose, followed by usage examples and related-tool guidance. Every sentence earns its place with no redundant filler. It is concise and well structured for quick scanning by an agent.

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

  Completeness2/5

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

  For a tool with 7 parameters, no output schema, and no annotations, the description is incomplete. It provides usage context and return type but omits any parameter semantics, particularly the required 'brand' field, and gives no details on filtering, pagination, or output envelope. The included related-tool references are helpful but do not compensate for these gaps.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description provides no explanation of any of the 7 parameters, including the required 'brand' parameter. It does not clarify what 'brand' refers to, how filters like 'status', 'categories', or 'search' behave, or what 'limit', 'cursor', and 'offset' control. The description fails to compensate for the lack of schema descriptions.

  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 tool's function: 'List affiliate programmes the publisher has joined on GrowSurf (or which are available to join).' It uses a specific verb ('List'), identifies the resource ('affiliate programmes on GrowSurf'), and distinguishes this tool from the many sibling list_programmes tools by naming the network. Example user queries further reinforce the intended purpose.

  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 explicit usage guidance with example queries ('which merchants am I working with?', 'what programmes do I have on GrowSurf?') and suggests companion tools for drill-down (get_programme) and activity (list_transactions). It does not explicitly state when not to use this tool or mention alternatives for other networks, but the network-specific name and context make the appropriate use case clear.

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

• affiliate_partnerize-advertiser_list_programmesB
  3.3/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 transparency burden. It discloses that the tool returns an array of Programme records and covers both joined and available programmes, but the 'or' phrasing is ambiguous about whether both are included. It does not mention pagination, required brand authorization, or other behavioral details beyond the basic return shape.

  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 compact and well-structured: purpose first, then concrete usage triggers, then return type and related tools. Every sentence adds value, and the text is easy to scan.

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

  Completeness2/5

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

  For a tool with 7 parameters, no output schema, and no annotations, the description is too sparse. It covers the core use case and return type, but omits required parameter semantics, filter behavior, pagination, and output fields. The companion tool hints are useful, but they do not compensate for the missing operational details.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not explain any of the seven parameters, including the required 'brand'. The agent is left without guidance on what values to provide for brand, status, limit, cursor, offset, search, or categories. This is a significant gap for a tool with a mandatory parameter.

  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 ('List affiliate programmes') with a clear scope ('the publisher has joined on Partnerize (Advertiser) or which are available to join'). It also gives example user queries, which helps disambiguate intent. It does not explicitly contrast with the sibling affiliate_partnerize_list_programmes, so it lacks 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 Guidelines4/5

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

  The description provides explicit trigger phrases ('when the user asks...') and suggests natural companion tools (get_programme for drill-down, list_transactions for activity). It does not state when not to use the tool or name an alternative list_programmes tool, so it stops short of a 5.

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

• affiliate_addrevenue_list_programmesB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description must carry behavioral transparency. It discloses the return type and the scope (joined or available programmes), but omits key behavioral traits such as authentication prerequisites, pagination behavior, and filtering semantics, which are important for correct invocation.

  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 concise and well-structured: the first sentence states the core purpose, the second gives usage triggers, and the third explains the return type and related tools. Every sentence earns its place without unnecessary filler.

  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 description adequately covers selection and basic use, including return type and related tools, but lacks details on parameter semantics and behavioral preconditions like authentication. Given the absence of an output schema and annotations, this is a clear gap for advanced usage.

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

  Parameters1/5

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

  The schema has 6 parameters with 0% description coverage, and the description does not mention any of them (limit, cursor, offset, search, status, categories). The agent receives no guidance on how to filter or paginate results, leaving the parameters to be guessed from names alone.

  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 tool lists affiliate programmes the publisher has joined or can join on Addrevenue, with a specific verb and resource. It also distinguishes itself from sibling get_programme and list_transactions tools by naming them and the platform.

  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 explicit query examples for when to use this tool and mentions pairing with get_programme and list_transactions. It doesn't explicitly state when not to use it or compare to other networks' list_programmes, but the Addrevenue-specific context makes the usage clear.

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

• affiliate_clickbank_list_clicksB
  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 of behavioral disclosure. It only adds 'recent' and 'Returns Click records' — it does not mention auth requirements, default date ranges, pagination behavior (cursor/offset/limit), ordering, or rate limits. For a tool with zero annotation coverage, this is insufficient 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.

  Conciseness4/5

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

  The description is compact at roughly 75 words across 3-4 sentences, front-loaded with the core purpose, and uses quoted examples efficiently. No filler or redundancy; the only slight inefficiency is having two similar debugging examples, but both add practical value.

  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 complexity (6 optional params, 0% schema coverage, no annotations, no output schema), the description is incomplete. It covers the what/when/return-type well but omits parameter details, pagination defaults, and behavioral guarantees needed for correct invocation. The pairing hint with list_transactions is valuable but does not compensate for the missing operational specifics.

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

  Parameters2/5

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

  Schema description coverage is 0% and the description compensates only nominally by mentioning 'filtered by programme and date'. It fails to explain the format or semantics of the 6 parameters (e.g., date format for to/from, meaning of limit, cursor, offset, or programmeId). With no parameter info in either the schema or description, agents cannot reliably construct correct arguments.

  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 opens with a specific verb+resource+scope: 'List recent affiliate clicks on ClickBank, optionally filtered by programme and date.' It distinguishes from sibling tools by explicitly stating it returns 'Click records' and referencing list_transactions for conversion comparison, clearly separating click data from transaction data.

  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 concrete use cases for traffic-side debugging ('are my links being clicked at all?', 'where is traffic going on ClickBank?') and names the alternative tool list_transactions for comparing clicks vs conversions. However, it lacks an explicit when-not-to-use statement, relying on implied differentiation.

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

• affiliate_commission-factory-advertiser_list_programmesB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosure. It mentions the return type ('Returns an array of Programme records') and the scope of data (joined or available to join), which is useful. Yet it does not disclose pagination behavior, credentials required, rate limits, or any potential side effects, which are relevant for a tool with pagination parameters (cursor, offset).

  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 concise and front-loaded: the first sentence states the main action, the second gives usage triggers, and the third mentions return type and companion tools. Every sentence earns its place with no fluff 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?

  For a list tool with 7 parameters and no output schema or annotations, the description provides the essential purpose, usage context, and return type, but omits important invocation details such as parameter meanings and pagination behavior. It is adequate for basic understanding but not fully complete for confident invocation without additional inference.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not explain any of the 7 parameters (brand, limit, cursor, offset, search, status, categories). The description adds no parameter-level meaning beyond what the schema property names imply, which is insufficient given the low 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?

  The description clearly states 'List affiliate programmes the publisher has joined on Commission Factory (advertiser) (or which are available to join)' with a specific verb and resource. It includes example user queries, making the purpose easy to grasp. However, it does not explicitly distinguish itself from the sibling 'affiliate_commission-factory_list_programmes' tool, and the phrase 'publisher has joined' is slightly confusing given the 'advertiser' context.

  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?

  It provides explicit trigger phrases ('when the user asks...') and names companion tools ('pairs naturally with get_programme for drill-down and list_transactions for activity'). However, it does not clearly state when NOT to use this tool versus the non-advertiser variant, leaving some ambiguity about alternative selection.

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

• affiliate_connexity_list_programmesB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It discloses the scope (joined or available programmes) and return type (array of Programme records), which is useful for a read-only listing tool. However, it does not mention pagination, auth requirements, or filter behaviors, which are important for list operations.

  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 three sentences, front-loaded with the core purpose, then examples, and then relationship to sibling tools. It is efficient and focused, though the first sentence could be split for slightly better readability. Each sentence adds value.

  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 description explains purpose and high-level use cases, but with six undocumented parameters and no output schema, the agent lacks complete context. It does not explain pagination, filtering, default scope (joined vs available), or the structure of Programme records. The vague 'array of Programme records' is insufficient given the tool's complexity.

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

  Parameters1/5

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

  The input schema has six parameters (limit, cursor, offset, search, status, categories) with zero schema descriptions and zero coverage in the tool description. The description gives no guidance on what these parameters mean, how they interact, or their expected formats, leaving the agent with no semantic information beyond parameter names.

  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 that the tool lists affiliate programmes on Connexity, including those joined and available to join. It provides specific example user queries and mentions the return type (array of Programme records), distinguishing it from the many sibling list_programmes tools by network and from get_programme/list_transactions.

  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 explicitly says when to use it ('when the user asks...') and gives example natural-language queries. It also points to get_programme for drill-down and list_transactions for activity, providing useful alternatives. However, it does not explicitly state when NOT to use this tool or compare against other list_programmes tools.

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

• affiliate_flexoffers_list_programmesB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It discloses the return type (array of Programme records) and dual joined/available scope, but does not mention pagination, auth requirements, or side effects. The read-only nature is implied by 'List' but not explicitly stated.

  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?

  Three sentences, front-loaded with the main action and resource. The additional sentences provide useful usage examples and return info without fluff. Slightly long but each sentence earns its place.

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

  Completeness2/5

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

  For a six-parameter tool with no annotations or output schema, the description explains what the tool does and when to use it, but omits parameter semantics, pagination behavior, and other invocation details. It is adequate for tool selection but not for parameter-level use.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not mention any of the six parameters (limit, cursor, offset, search, status, categories). The agent is left without any guidance on how to use these parameters, making invocation difficult.

  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 tool lists affiliate programmes on FlexOffers, specifying the scope (joined or available to join). It distinguishes from sibling list_programmes tools by naming the network and providing example queries.

  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?

  Provides explicit example user queries and notes natural pairing with get_programme and list_transactions, giving clear when-to-use context. Does not explicitly exclude other networks, but the FlexOffers naming implies that.

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

• affiliate_kwanko_list_programmesB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It adds useful context by stating it returns an array of Programme records and notes that the tool can list both joined and available programmes. However, it omits details about pagination (cursor), authentication requirements, or how the 'available to join' vs 'joined' distinction is represented, leaving gaps in behavioral 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 three sentences, well-structured, and front-loaded with the action and resource. It includes usage examples and return type without unnecessary fluff. Minor room for improvement in compactness, but it earns its length.

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

  Completeness2/5

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

  The tool has 5 optional parameters and no output schema, yet the description only explains the general purpose and return type. It fails to describe parameter semantics, pagination behavior, or how filtering (status, categories, search) works. The pairing with get_programme helps, but the missing parameter details and lack of output schema leave the agent under-equipped to use the tool correctly.

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

  Parameters1/5

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

  The schema has 5 parameters (limit, cursor, search, status, categories) with 0% coverage (no descriptions). The tool description provides no explanation of what these parameters do, how they should be formatted, or their constraints. This is a major gap since schema coverage is zero and the description does nothing to compensate.

  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 action (List), resource (affiliate programmes), and scope (on Kwanko), distinguishing it from other networks' list_programmes tools. It also clarifies the dual nature (joined or available to join) and provides example user prompts, 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 Guidelines4/5

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

  The description provides explicit example queries that should trigger this tool ('which merchants am I working with?', 'what programmes do I have on Kwanko?') and suggests complementary tools (get_programme, list_transactions), giving clear context for when to use it. It does not explicitly exclude other networks or explain when not to use it, but the Kwanko-specific naming and examples make usage reasonably clear.

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

• affiliate_partnerize-advertiser_generate_tracking_linkB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It mentions that it returns a TrackingLink and advises confirming programmeId with list_programmes first, but it does not disclose side effects, authentication requirements, or error behavior. The term 'Generate' implies a mutation but no reversibility or quota impact is noted.

  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 three sentences with no redundant content. It front-loads the purpose, then adds usage context and a return/note. This is compact 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 no annotations, no output schema, and zero parameter descriptions, the description is insufficient for an agent to confidently invoke the tool. It fails to explain the brand parameter, does not describe the TrackingLink return shape, and omits error or prerequisite details beyond the programmeId tip.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must explain all parameters. It mentions 'programme' and 'destination URL' but does not explain the 'brand' parameter at all, which is listed as required in the schema. It also does not clarify the expected formats or relationship between programmeId and brand.

  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 tool generates a tracking link on Partnerize (Advertiser) for a given programme and destination URL, and explicitly frames it for sharing affiliate links. This distinguishes it from sibling tools like the publisher-oriented Partnerize tool or other networks' tracking link generators.

  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?

  It provides explicit usage context ('Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined') and a concrete prerequisite ('pair with list_programmes to confirm the programmeId before calling'). It does not name alternatives for when this tool should not be used, but the context is clear enough.

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

• affiliate_partnerize-advertiser_list_media_partnersB
  3.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 of disclosing behavior. It mentions that the tool 'Returns MediaPartner records with normalised status', which adds some behavioral context about output normalization. However, it omits key behavioral details like pagination, rate limits, or that this is a read-only operation, which are especially relevant given the cursor/limit parameters in the schema.

  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 composed of three sentences, each serving a purpose: defining the action, providing usage triggers, and noting the output and complementary tool. It is front-loaded and not overly verbose, though it could be slightly tightened by removing redundant phrasing like 'running on the brand's programme' when the scope is already clear.

  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 has 6 parameters, no output schema, and no annotations, the description should explain pagination, filtering, and return structure. While it covers the core purpose and output type, it omits any mention of cursor-based pagination, offset/limit behavior, or the search/status filtering capabilities, leaving significant gaps for an agent to invoke the tool correctly.

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

  Parameters1/5

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

  The schema coverage for parameter descriptions is 0%, and the description provides no explanation of any parameter (brand, limit, cursor, offset, search, status). It does not even mention that 'brand' is required or how 'status' filters results. The description fails to compensate for the absence of schema-level 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 clearly states the tool's purpose: 'List the media partners (publishers) running on the brand's programme at Partnerize (Advertiser)'. It uses a specific verb and resource, and distinguishes itself from sibling tools by focusing on media partners rather than programme details or transactions. The example queries further clarify the intended scope.

  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 explicitly says 'Use this when the user asks...' and provides concrete example questions, making usage context highly clear. It also suggests pairing with get_programme_performance for further drill-down. However, it does not explicitly state when NOT to use this tool versus other list tools, such as list_programmes, though the context is strongly implied.

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

• affiliate_post-affiliate-pro_list_programmesB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It discloses the return type (array of Programme records) and the inclusion of both joined and available-to-join programmes. However, it does not mention authentication needs, pagination behavior, or whether the operation is read-only, leaving significant behavioral gaps.

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

  Conciseness4/5

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

  Two sentences, front-loaded with the core purpose, followed by usage examples and related tools. The example queries add a little length but are useful for matching user intent.

  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 7 parameters, no annotations, and no output schema, the description is incomplete. It does not explain parameter semantics, pagination, output shape beyond 'array', or any operational constraints, leaving the agent to guess significant details.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description provides no parameter meanings. The 7 parameters (brand, limit, cursor, offset, search, status, categories) are only bare property names in the schema, so the agent gets no guidance on formats, defaults, or expected values.

  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 ('List'), a clear resource ('affiliate programmes'), the platform ('Post Affiliate Pro'), and the scope ('joined or available to join'). It distinguishes itself from sibling list_programmes for other networks by naming the platform.

  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 concrete example queries ('which merchants am I working with?') and pairs the tool with get_programme for drill-down and list_transactions for activity. It does not explicitly state when not to use it, but the platform-specific naming makes the context clear.

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

• affiliate_profitshare_list_programmesB
  3.4/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It adds some context by noting the tool lists both joined and available-to-join programmes and returns an array of Programme records. However, it does not disclose pagination behavior, authentication requirements, or confirm this is a read-only operation, which the lack of annotations makes more critical.

  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: three sentences with the purpose front-loaded. The example queries and pairing note are useful. It is not wordy, though the second sentence could be slightly integrated without losing clarity.

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

  Completeness2/5

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

  The tool has 6 optional parameters, no output schema, and no annotations. The description covers the basic purpose, return type, and companion tools, but omits behavior around pagination, filtering, and the meaning of status/categories. It is incomplete for an agent to confidently use all features, especially without any schema-level descriptions.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description does not explain any of the six parameters (limit, cursor, offset, search, status, categories). The description adds no meaning beyond the bare parameter names, which is insufficient for an agent to know how to filter or paginate. This is a major gap.

  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 action ('List affiliate programmes'), the scope ('on Profitshare'), and differentiates from siblings like get_programme and list_transactions by noting it returns a list rather than a drill-down or activity log. The examples of user queries further pin down the intent.

  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?

  It explicitly provides when-to-use examples ('which merchants am I working with?', 'what programmes do I have on Profitshare?', 'wants a partner inventory') and suggests complementary tools (get_programme, list_transactions). However, it does not explicitly state when NOT to use this tool or name an alternative for distinct use cases, so it misses the full bar for exclusionary guidance.

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

• affiliate_tolt_list_programmesB
  3.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 the return type (array of Programme records) and the joined/available scope, but omits details like authentication requirements, pagination behavior, or any side effects. This is a read operation, but more explicit safety disclosure would be helpful.

  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 three sentences, front-loaded with the core purpose, followed by usage examples and return type/pairing. Every sentence contributes useful information with no redundancy.

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

  Completeness2/5

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

  With 7 parameters and no output schema, the description is incomplete. It fails to explain parameter semantics, filter behavior, or how the joined/available distinction is represented. The tool requires more context for effective use.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description does not mention any of the 7 parameters. The required 'brand' parameter is left completely unexplained, leaving the agent without guidance on how to populate filters like status, search, or categories.

  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 it lists Tolt affiliate programmes, specifying a verb ('List') and resource ('affiliate programmes'). It distinguishes from sibling list_programmes tools by naming the network (Tolt) and gives example user queries to clarify scope.

  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?

  Provides explicit when-to-use triggers with example phrasings and mentions complementary tools (get_programme, list_transactions). However, it does not explicitly state when not to use it or contrast with other networks' list_programmes tools.

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

• affiliate_accesstrade_list_clicksA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It only says 'Returns Click records' and mentions optional filters, but does not clarify whether this is read-only, how 'recent' is bounded, pagination behavior, or any authentication/rate-limit implications. The description offers little beyond the tool's basic function.

  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 three sentences, front-loaded with the core purpose, followed by a concrete use case and a helpful pairing suggestion. Every sentence earns its place with no wasted words.

  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 six parameters, no annotations, and no output schema, the description is incomplete. It fails to explain pagination controls, the meaning of 'recent', default limits, or the shape of the returned Click records. The traffic-debugging context is useful, but significant operational details are missing.

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

  Parameters2/5

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

  The input schema has 0% description coverage and no parameter descriptions. The description vaguely mentions filtering by 'programme and date', which hints at programmeId and from/to, but provides no semantics for limit, cursor, offset, or date formats. It does not sufficiently compensate for the lack of schema detail across all six parameters.

  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 verb and resource: 'List recent affiliate clicks on AccessTrade', with optional filters by programme and date. It also distinguishes the tool from sibling transaction tools by explicitly framing it for traffic-side debugging and referencing list_transactions for comparison.

  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 explicit use cases ('are my links being clicked at all?', 'where is traffic going on AccessTrade?') and suggests pairing with list_transactions to compare clicks vs conversions. However, it does not explicitly state when not to use this tool or mention alternative click-listing tools.

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

• affiliate_adcell_list_programmesA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description must carry the burden of behavioral disclosure. It does disclose that the tool returns an array of Programme records and that it may also list programmes available to join. However, it omits potentially important behavioral details such as pagination behavior, default limits, filtering semantics, or any side effects, though as a read-only list tool the risk is relatively low.

  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 three sentences long, efficiently front-loading the core purpose, then providing concrete usage examples and pairing information. Every sentence adds value with no fluff or repetition, making it appropriately sized for the complexity.

  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?

  Although the description covers the tool's overall purpose and usage context well, it is incomplete for a tool with six optional parameters and no output schema. It does not explain parameter semantics, return record structure, or pagination, leaving the agent without critical invocation and interpretation details. Given the complexity (6 params, no annotations, no output schema), more depth is required.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description provides no explanation of any of the six parameters (limit, cursor, offset, search, status, categories). The agent is left without any guidance on how to use these filters or what values are accepted, especially for status and categories which are not self-explanatory. The description fails to compensate for the lack of schema 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 clearly states the tool lists affiliate programmes on Adcell, with the specific scope of programmes the publisher has joined or that are available to join. It distinguishes itself from the many sibling list_programmes tools by explicitly naming Adcell and providing example user queries.

  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 examples of when to use the tool ('which merchants am I working with?', 'what programmes do I have on Adcell?', 'partner inventory') and suggests related tools for drill-down and activity (get_programme, list_transactions). However, it does not explicitly mention when not to use it or direct to alternative network-specific list tools, so it lacks a full when-not/alternatives statement.

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

• affiliate_admitad_list_programmesA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It does add useful behavioral context by stating it returns an array of Programme records and can list either joined or available programmes. However, it omits pagination behavior, authentication requirements, and any side effects, leaving meaningful gaps for a 6-parameter list 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?

  Three sentences deliver purpose, usage examples, and related-tool guidance without redundancy. The description is front-loaded with the core action and keeps supplementary guidance brief and relevant.

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

  Completeness2/5

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

  For a tool with no output schema, no annotations, and six undocumented parameters, the description is too thin. It explains the high-level return type and companion tools, but not parameter meaning, pagination, or how 'joined' vs 'available' is controlled, making it incomplete for confident invocation beyond a default no-parameter call.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not explain any of the six parameters (limit, cursor, offset, search, status, categories). The description only characterizes the result set, not how the parameters influence it, providing no value beyond the raw 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 and resource ('List affiliate programmes') and clearly scopes to Admitad publisher programmes, including joined or available ones. It also differentiates from sibling tools like get_programme and list_transactions by stating its list-level purpose.

  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?

  Explicit use cases are given with example user questions ('which merchants am I working with?'). It also suggests complementary tools (get_programme for drill-down, list_transactions for activity), but it doesn't explicitly mention when not to use it (e.g., advertiser-side tools or other networks), so it's slightly shy of a 5.

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

• affiliate_adrecord_list_programmesA
  3.5/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the burden. It discloses that the tool returns both joined and available programmes, and that it returns an array of Programme records. However, it does not mention pagination behavior, auth requirements, or potential side effects (though read-only is implied). Adds some useful behavioral context but not comprehensive.

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

  Conciseness5/5

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

  The description is three sentences that are front-loaded with the primary purpose, then usage examples, then related tools. Every sentence earns its place with no redundancy or filler.

  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 has 6 undocumented parameters and no output schema, the description's high-level overview is insufficient. It mentions return type and complementary tools, but does not describe what fields a Programme record contains or how the status/categories filters work. The agent gets little help for correct invocation beyond the basic purpose.

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

  Parameters1/5

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

  The input schema has 6 parameters with 0% description coverage, and the description does not explain any of them (limit, cursor, offset, search, status, categories). This leaves the agent without guidance on how to filter or paginate, a major gap that the description fails to compensate for.

  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 tool's purpose with a specific verb ('List') and resource ('affiliate programmes the publisher has joined on Adrecord or which are available to join'). It also distinguishes itself from siblings by giving example queries and mentioning complementary tools like get_programme for drill-down.

  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 usage context with example user phrasings (e.g., 'which merchants am I working with?', 'what programmes do I have on Adrecord?') and suggests pairing with get_programme and list_transactions. It lacks explicit exclusions or 'when not to use', but the context is strong enough to guide selection.

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

• affiliate_affise_list_programmesA
  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 of behavioral disclosure. It does add some context: it lists both joined and available-to-join programmes, and states that it 'Returns an array of Programme records.' However, it does not disclose pagination behavior, filtering semantics, authentication requirements, or rate limits. This is minimal but non-zero behavioral transparency, so a 3 is appropriate.

  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 long, front-loaded with the core purpose, and includes usage guidance and related tools without any fluff. Every sentence adds value: the first defines what the tool does, and the second covers when to use it and what it pairs with. This is 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?

  The tool has 6 optional parameters, no annotations, and no output schema, so a complete description is critical. While the purpose and return type are stated, the description ignores parameter semantics, pagination, and filtering behavior, leaving an agent unable to fully understand how to use the tool beyond a simple call. This is a significant gap, making the description incomplete for operational use.

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

  Parameters1/5

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

  The schema has 0% description coverage for its 6 parameters (limit, cursor, offset, search, status, categories), and the description does not explain any of them. It only mentions the return type and use cases, providing no semantic meaning for the parameters. Given the low coverage, the description was expected to compensate but fails to do so, resulting in a score of 1.

  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 tool's function: 'List affiliate programmes the publisher has joined on Affise (or which are available to join).' This is a specific verb+resource+scope and distinguishes it from sibling list_programmes tools for other networks. It also provides example user queries to reinforce the purpose.

  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 explicit context for when to use this tool: 'Use this when the user asks "which merchants am I working with?", "what programmes do I have on Affise?", or wants a partner inventory.' It also mentions complementary tools (get_programme, list_transactions) for drill-down and activity. However, it does not explicitly state when not to use it or list alternative network-specific tools, so it falls short of a 5.

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

• affiliate_awin_get_creative_performanceA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the return structure ('creative report rows plus the exact query and raw Awin response') and implies a read-only operation via 'Fetch'. However, it does not describe pagination, rate limits, or potential side effects, and the mention of 'raw Awin response' could imply large or messy output without warning. Some transparency, 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 exactly two sentences, front-loaded with the core action and resource, then the use case, then return value. Every sentence contributes value without repetition or filler. It is efficiently structured and appropriately sized.

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

  Completeness2/5

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

  There is no output schema, so the description must explain return values and invocation context. It gives a high-level return summary but does not explain the date range, region, or timezone parameters, nor what 'creative report rows' contain. For a 5-parameter tool with minimal schema info, important contextual details are missing, making the description inadequate for confident invocation.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description does not compensate. It mentions no details about the five parameters (to, from, region, dateType, timezone), leaving the agent without any clues about their meaning, constraints, or default behavior. This is a critical gap for a tool with 5 optional params.

  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 'Fetch' and a clear resource 'Awin publisher performance aggregated by creative', with concrete examples of creativity types (banners, text links, creative tags). This clearly distinguishes it from siblings like get_advertiser_performance or get_campaign_performance by focusing on the creative dimension.

  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 phrase 'Use this when comparing banners, text links, and creative tags across advertisers' provides clear contextual guidance for when to select this tool. It stops short of naming alternative tools or explicit exclusions, but the context is strong and covers the primary use case.

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

• affiliate_awin_list_programmesA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the behavioral transparency burden. It only states that the tool returns an array of Programme records and covers both joined and available programmes, but fails to disclose pagination behavior, default status filtering, or how to distinguish joined vs available results. The description offers minimal behavioral context beyond the basic list 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 two well-structured sentences with no redundancy. It front-loads the core purpose, includes practical query examples, and briefly notes the return type and sibling tool relationships—every clause earns its place.

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

  Completeness2/5

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

  Despite clear purpose, the tool has 6 parameters, no output schema, and no annotations. The description lacks essential operational details: how filtering works, pagination, or how joined vs available programmes are selected. This is insufficient for an AI agent to correctly invoke the tool with appropriate parameters.

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

  Parameters1/5

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

  Schema description coverage is 0% with 6 parameters (limit, cursor, offset, search, status, categories) and no parameter-level descriptions. The description does not mention any of these parameters or explain how they affect results, providing zero compensation for the missing schema 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 tool lists affiliate programmes on Awin, distinguishing between joined and available-to-join. It provides concrete user query examples and explicitly contrasts with related tools (get_programme and list_transactions), making its purpose unambiguous relative to the many sibling list_programmes tools.

  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?

  Explicit when-to-use guidance is given with real user phrasing like 'which merchants am I working with?' and 'what programmes do I have on Awin?'. It also pairs with get_programme for drill-down and list_transactions for activity, indicating appropriate alternatives and natural workflows.

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

• affiliate_awin_list_transaction_queriesA
  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 the tool returns paginated rows with specific fields (advertiser, click reference, status, amount), which is useful. However, it lacks details on authentication, default behavior with no parameters, rate limits, or how pagination works, so transparency is only moderate.

  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 three concise sentences, front-loaded with the core purpose, followed by usage context and return details. Every sentence adds value with no wasted words, making it highly scannable for an agent.

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

  Completeness2/5

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

  Despite having 9 parameters and no output schema, the description does not cover essential context such as date range requirements, default values, timezone handling, or how to filter by advertiser. It mentions return fields but omits behavioral details like whether all queries are included by default. The description is insufficient for full autonomous use.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description adds no parameter-level semantics. It does not explain the purpose or format of to/from, dateType, statuses, or any other parameters. The description must compensate for the lack of schema descriptions but fails entirely, leaving the agent to guess parameter meanings.

  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 it lists Awin transaction queries, with the scope 'raised by or visible to the publisher', distinguishing it from general transaction listing tools. It also specifies the resource (transaction queries) and provides a concrete use case, making its purpose immediately understandable.

  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 explicitly says when to use this tool: 'when investigating missing, incorrect, pending, or declined transaction enquiries.' This provides clear context for selection, though it does not explicitly mention alternatives or when not to use it. The guidance is actionable and sufficient for distinguishing from sibling tools.

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

• affiliate_daisycon_list_programmesA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that the tool returns an array of Programme records and that it lists joined or available programmes. However, it does not specify pagination behavior, auth requirements, or the exact meaning of 'available to join', leaving some behavioral ambiguity.

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

  Conciseness5/5

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

  The description is three sentences and front-loads the core purpose in the first sentence. Every sentence adds value: purpose, usage triggers, and return type/pairing with related tools. No redundant or irrelevant content.

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

  Completeness2/5

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

  Despite having 6 parameters and no output schema, the description is minimal. It states the return type but does not explain Programme record fields, pagination, default filtering behavior, or the meaning of 'available to join'. The tool is simple but the description leaves significant gaps for an agent to invoke it correctly.

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

  Parameters1/5

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

  The schema has 0% description coverage for its 6 parameters (limit, cursor, offset, search, status, categories). The description does not explain any of these parameters or how to use them to filter results. The only vague hint is 'joined (or which are available to join)', which could relate to a status filter but is not explicitly linked to any parameter.

  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 tool lists affiliate programmes on Daisycon, with a specific verb and resource. It distinguishes itself from sibling list_programmes tools by naming the network (Daisycon) and specifies the publisher's perspective (joined or available to join). This is more specific than a generic list tool.

  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 explicit example user questions ('which merchants am I working with?', 'what programmes do I have on Daisycon?') and states it is used for partner inventory. It also mentions pairing with get_programme for drill-down and list_transactions for activity, which implies alternatives, though it does not directly say 'use X instead' or when not 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.

• affiliate_eduzz_list_programmesA
  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 transparency burden. It discloses that the tool returns an array of Programme records and mentions the joined/available scope. However, it leaves ambiguity about whether both joined and available programmes are returned together, and gives no details on pagination behavior, filtering semantics, or authorization requirements.

  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 three sentences, each earning its place: the purpose, concrete trigger examples, and related tools. It is front-loaded and free of fluff or repetition.

  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 has 6 parameters, no output schema, and no annotations, the description is incomplete. It omits parameter details entirely and leaves the joined/available list behavior ambiguous, which is problematic for a tool with cursor/offset pagination and status/category filters.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not explain any of the six parameters (limit, cursor, offset, search, status, categories). Parameter names are somewhat self-explanatory, but the description adds no meaning about valid values, formats, or how filters combine, so it fails to compensate for the lack of schema 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 clearly states the tool lists affiliate programmes on Eduzz, scoped to the publisher's joined or available programmes. It includes specific example user queries ('which merchants am I working with?') that distinguish it from the many sibling list_programmes tools for other networks.

  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 explicit trigger phrases and states when to use the tool for partner inventory. It also names complementary tools (get_programme for drill-down, list_transactions for activity), acting as alternatives. However, it does not explicitly state when not to use it (e.g., for other networks), relying on the Eduzz scoping to imply this.

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

• affiliate_everflow_list_programmesA
  3.5/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 transparency burden. It adds useful context by noting the result is 'an array of Programme records' and clarifies the two possible states (joined vs. available to join). However, it does not disclose authentication requirements, pagination behavior, rate limits, or how filtering via parameters affects results, which is a notable gap for a tool with six parameters.

  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 three sentences, front-loaded with the primary action, followed by usage examples and return type/complementary tools. Every sentence provides value and there is no redundancy or filler.

  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?

  While the core purpose and usage are clear, the description omits essential context for a tool with six optional parameters and no output schema. It does not explain how parameters like status, categories, or search behave, nor does it describe pagination, even though cursor/offset/limit exist. The agent would be unable to reliably construct complex queries or understand the expected data shape beyond 'array of Programme records.'

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

  Parameters1/5

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

  The schema has 0% description coverage, and the description provides no explanation for any of the six parameters (limit, cursor, offset, search, status, categories). It does not mention what values are accepted or how these parameters affect the listing. Given the low coverage, the description fails to compensate, leaving the agent to guess parameter meaning.

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

  Purpose5/5

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

  The description opens with a specific verb and resource: 'List affiliate programmes the publisher has joined on Everflow (or which are available to join).' This clearly scopes the operation to Everflow and the publisher's relationship, distinguishing it from sibling list_programmes tools for other networks. It also gives concrete example queries, making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description explicitly states when to use: 'Use this when the user asks "which merchants am I working with?", "what programmes do I have on Everflow?", or wants a partner inventory.' It also names complementary tools (get_programme, list_transactions) to guide follow-up actions, but does not mention when not to use it (e.g., other networks) or alternatives, so it stops short of full exclusion guidance.

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

• affiliate_firstpromoter_list_programmesA
  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 reveals that the tool lists both joined and available programmes and returns an array of Programme records. However, it does not disclose pagination behavior, required authentication, or whether the operation is read-only. This is some transparency but not exhaustive for a list tool with 7 parameters.

  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 three sentences long, front-loaded with the primary purpose, and each sentence contributes value. It includes example queries and related-tool pairing without unnecessary fluff or repetition.

  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 has 7 parameters, no output schema, and no annotations, the description is too thin to be fully actionable. It explains the core purpose and related tools but omits crucial information about parameters, pagination, and return value structure. The agent would need to infer or guess how to populate fields like status, categories, and cursor.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It does not mention any of the 7 parameters (brand, limit, cursor, offset, search, status, categories). The only hint is 'partner inventory', which does not clarify how to use the required 'brand' parameter or optional filters. This is a significant gap.

  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: 'List affiliate programmes the publisher has joined on FirstPromoter', and distinguishes the scope ('or which are available to join'). It also includes concrete example user queries and mentions the tool pairs with get_programme and list_transactions, clearly distinguishing it from other list_programmes tools for different networks.

  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 explicitly states when to use the tool with example user intents ('which merchants am I working with?', 'what programmes do I have on FirstPromoter?') and mentions related tools (get_programme for drill-down, list_transactions for activity). It lacks an explicit when-not-to-use clause, but the guidance is clear and actionable.

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

• affiliate_impact-advertiser_list_programmesA
  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 the return type ('array of Programme records') and that it lists joined or available programmes. However, it omits details on whether the operation is read-only, required authentication, pagination behavior, or any side effects. The description adds some context but not rich behavioral insight.

  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 concise and well-structured. It opens with the core purpose, provides usage examples, then mentions returns and related tools. Every sentence adds value, with no filler or redundancy.

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

  Completeness2/5

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

  For a tool with 7 parameters, no output schema, and no annotations, the description is incomplete. It covers purpose and returns but leaves parameter semantics, pagination options (limit, cursor, offset), and filtering behavior (search, status, categories) entirely unexplained. The description is not entirely inadequate but leaves critical gaps for execution.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not explain any of the 7 parameters. The required 'brand' parameter is completely unexplained, leaving the agent without any guidance on what values to provide. The description fails to compensate for the lack of 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 clearly states the verb and resource: 'List affiliate programmes the publisher has joined on Impact (advertiser)'. It distinguishes itself from sibling tools by explicitly noting '(advertiser)', differentiating from affiliate_impact_list_programmes. It also provides example user queries, making the purpose unmistakable.

  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 explicit when-to-use guidance with example queries like 'which merchants am I working with?' and states it pairs with get_programme and list_transactions. However, it does not explicitly state when not to use it or contrast with the non-advertiser version, though the '(advertiser)' qualifier implies this.

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

• affiliate_indoleads_list_programmesA
  3.5/5.0
  Behavior3/5

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

  The description reveals a key behavioral nuance—that it includes programmes 'available to join' in addition to those joined—and states the return type as an array. However, it doesn't mention authentication requirements, pagination behavior, or any side effects, which is notable given there are 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?

  Three sentences: purpose, usage triggers, and return/related tools. No filler; each sentence serves a distinct function, and the most important information is front-loaded.

  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 description competently covers selection context and return type, but it omits parameter semantics, pagination details, and any behavioral caveats. With 5 undocumented parameters and no output schema, the agent lacks sufficient operational detail for correct invocation beyond the simplest calls.

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

  Parameters1/5

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

  The input schema has 5 parameters with 0% description coverage, and the tool description provides no explanation of `limit`, `cursor`, `search`, `status`, or `categories`. The names are somewhat self-explanatory, but the description adds zero semantic value beyond the schema, so it fails to compensate for the coverage gap.

  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 starts with a clear verb and resource ('List affiliate programmes'), specifies the platform ('Indoleads'), and clarifies scope: 'the publisher has joined' or are 'available to join'. This distinguishes it from the many sibling list_programmes tools for other networks, even without naming alternatives.

  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?

  It provides explicit user query examples ('which merchants am I working with?', 'what programmes do I have on Indoleads?') and mentions related tools for drill-down and activity, giving clear context for when to invoke it. However, it doesn't explicitly state when not to use it or name alternative tools for exclusion, unlike the gold-standard get_calls example.

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

• affiliate_refersion_list_programmesA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description must carry behavioral disclosure. It reveals the return shape ('array of Programme records') and the two-scope behavior (joined or available), but it does not mention pagination, filtering behavior, authentication requirements, or side-effect safety. This is acceptable but not comprehensive.

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

  Conciseness5/5

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

  Three sentences, all informative and front-loaded with the core action. There is no fluff, and the natural pairing note adds value without bloating the text.

  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 has 7 parameters, no output schema, and no annotations, the description is not complete enough. It covers purpose and return type but leaves parameter semantics and behavioral details (pagination, filtering, required brand) entirely to the user, making it inadequate for a tool of this complexity.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description adds no parameter-level meaning. It never explains the required 'brand' parameter or the optional filters like 'search', 'status', 'categories', 'limit', 'cursor', or 'offset'. The description is of no help in understanding how to pass arguments correctly.

  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 ('List') and resource ('affiliate programmes the publisher has joined on Refersion'), clearly distinguishing this from other network-specific list_programmes tools. It also clarifies that it includes both joined and available programmes, which further sharpens the scope.

  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 explicit example user queries ('which merchants am I working with?') and a context ('wants a partner inventory'). It also pairs with get_programme for drill-down and list_transactions for activity, which signals how to combine tools, though it does not explicitly state when not 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.

• affiliate_rewardful_list_programmesA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden for behavioral disclosure. It discloses that the tool returns an array of Programme records and lists both joined and available programmes, which is useful. However, it omits important behavioral details such as authentication requirements, pagination behavior (despite limit/cursor/offset params), and how the 'status' parameter affects results. The description adds some value but leaves significant 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?

  The description is front-loaded with the main action and resource, and every sentence earns its place: it states the core function, gives usage triggers, describes the return value, and suggests related tools. It is compact and well-structured with no redundant text.

  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 has 7 parameters, no annotations, and no output schema, the description is not complete enough. It covers purpose and return type but does not explain the required brand parameter or any of the filter/query parameters (limit, cursor, offset, search, status, categories). An agent would be left uncertain about how to invoke the tool correctly beyond the basic call.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must compensate for the 7 parameters, but it mentions none of them explicitly. The required 'brand' parameter is not explained at all, and there is no guidance on what values 'status', 'categories', or 'search' expect. The description fails entirely to add semantic meaning beyond the bare 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 ('List') and resource ('affiliate programmes the publisher has joined on Rewardful'), clearly distinguishing it from sibling tools by naming the Rewardful platform and the scope (joined or available). It also provides example user queries, which makes the purpose unmistakable.

  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 explicitly states when to use the tool ('Use this when the user asks...') and gives concrete query examples. It also mentions natural companion tools (get_programme for drill-down, list_transactions for activity), which provides helpful context, though it does not explicitly state when NOT to use it or name alternatives for exclusion.

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

• affiliate_shopmy_list_programmesA
  3.5/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the burden. It discloses the return type ('array of Programme records') and scope (joined or available programmes), but does not mention pagination behavior, authentication requirements, or how the 'available to join' vs 'joined' distinction is controlled. This is partial but not rich 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?

  Three sentences with no wasted words: first sentence states the purpose, second gives usage examples, third describes return and complementary tools. The description is front-loaded and every sentence earns its place.

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

  Completeness2/5

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

  For a tool with 6 undocumented parameters and no output schema, the description is incomplete. It explains the high-level purpose and return type but omits essential invocation details like how to filter by status, paginate with cursor/offset, or use search and categories. The user cannot fully understand how to use the tool correctly.

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

  Parameters1/5

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

  Schema coverage is 0% and the description does not mention any of the 6 parameters (limit, cursor, offset, search, status, categories). The only indirect hint is 'or which are available to join,' which could relate to status but is not explained. The description fails to compensate for the lack of schema 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 clearly states the tool lists affiliate programmes on ShopMy with a specific verb ('List') and resource ('affiliate programmes'). It differentiates from sibling tools by specifying the ShopMy network and contrasts with get_programme and list_transactions, making its unique role clear.

  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 explicit usage triggers with example user queries ('which merchants am I working with?', 'what programmes do I have on ShopMy?') and recommends pairing with get_programme and list_transactions. It lacks an explicit when-not, but context and alternatives are strongly provided.

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

• affiliate_skimlinks_list_programmesA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It discloses the output ('Returns an array of Programme records') and the scope (joined or available), which is useful. However, it omits details about pagination, filtering, authentication, or any side effects (though listing is inherently read-only). It adds some context beyond the name but lacks rich behavioral detail.

  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, front-loaded with the action and directly followed by usage guidance and return type. Every sentence contributes: the first defines the scope, the second provides triggers and related tools. No filler or redundancy.

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

  Completeness2/5

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

  The description gives a clear purpose and return type, but with 6 undocumented parameters and no output schema, an agent lacks crucial details needed to invoke it correctly (e.g., how status/categories filtering works, pagination semantics, or what fields a Programme record contains). It also omits authentication requirements and edge cases like empty results or the 'available to join' distinction. For a tool with this complexity, the description is incomplete.

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

  Parameters1/5

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

  The input schema has 6 parameters (limit, cursor, offset, search, status, categories) with 0% description coverage, and the description does not explain any of them. Parameter names are self-explanatory, but the description adds no semantic meaning, leaving the agent to infer usage from names alone. With no schema descriptions and no additional context, this is a significant gap.

  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 opens with a specific verb and resource: 'List affiliate programmes the publisher has joined on Skimlinks (or which are available to join).' It provides concrete example queries ('which merchants am I working with?', 'what programmes do I have on Skimlinks?') and distinguishes from siblings by naming Skimlinks and noting the return type (Programme records). It also explicitly pairs with get_programme and list_transactions, clearly separating it from other list_programmes tools for different networks.

  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 explicitly states when to use the tool: 'Use this when the user asks...' with specific natural-language triggers. It also mentions complementary tools (get_programme for drill-down, list_transactions for activity), providing context. However, it does not explicitly state when not to use it or present direct alternatives for the same network, so it falls short of a 5.

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

• affiliate_tapfiliate_list_programmesA
  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 the tool returns an array of Programme records and that it includes both joined and available programmes. However, it does not mention pagination behavior, authentication requirements, or that results are scoped by the required `brand` parameter. This is acceptable but not rich.

  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 three sentences, front-loaded with the core action, and each sentence adds value: purpose, usage triggers, and return/paired tools. There is no fluff or redundant repetition of the tool name.

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

  Completeness2/5

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

  Despite a clear purpose and usage guidance, the description is incomplete for a tool with 7 parameters and no output schema. It fails to explain the required `brand` parameter or the meaning of the filter/pagination parameters, and it does not describe the Programme record structure. The agent cannot reliably construct a correct invocation based on this description alone.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description compensates not at all. The required `brand` parameter is never mentioned, and there is no explanation of `limit`, `cursor`, `offset`, `search`, `status`, or `categories`. An agent reading the description would not know what arguments to supply or how they affect the results.

  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 opens with a clear action ('List affiliate programmes the publisher has joined on Tapfiliate') and adds scope by including available-to-join programmes. It provides example user queries ('which merchants am I working with?') that distinguish it from other list_programmes tools across networks, and it names related Tapfiliate tools (get_programme, list_transactions) for drill-down context.

  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 explicitly states when to use the tool ('Use this when the user asks...') and gives concrete example phrasings. It also indicates how it pairs with get_programme and list_transactions, providing a sense of alternative/complementary tools. It does not explicitly say when not to use it, but the guidance is clear enough.

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

• affiliate_value-commerce-advertiser_get_programme_performanceA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return type (ProgrammePerformanceRow records) and scope, but does not explain pagination behavior (despite limit/cursor/offset parameters), authentication requirements, rate limits, or date range handling. This leaves significant ambiguity for an agent invoking an 8-parameter 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 three concise, front-loaded sentences. Each sentence earns its place: the core action, the usage triggers, and the return type/complementary tools. There is no fluff or repetition.

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

  Completeness2/5

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

  Despite clear purpose and usage examples, the tool has 8 parameters, no annotations, no output schema, and no parameter descriptions. The description omits pagination details, parameter semantics, and expected response structure, making it incomplete for an agent to use effectively without additional context.

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

  Parameters2/5

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

  With 0% schema description coverage, the description must compensate but only minimally maps parameters: 'by date' hints at from/to, 'per-publisher' hints at publisherId, and 'programme' hints at programmeId. It does not explain brand, limit, cursor, offset, or their formats, which is a major gap for an 8-parameter tool.

  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 tool fetches per-publisher performance for the brand's programme at ValueCommerce, listing specific metrics (clicks, conversions, gross sale, commission) and the 'by date' scope. It also differentiates from sibling tools like list_media_partners and list_transactions by explicitly noting usage for per-publisher rollups.

  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 concrete use-case examples ('how is each publisher performing', 'top-earning partners last month') and names complementary tools (list_media_partners for publisher IDs, list_transactions for drill-down). It does not explicitly state when not to use this tool versus other performance tools like get_earnings_summary, so it's slightly less than exhaustive.

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

• affiliate_webgains-advertiser_list_programmesA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the return format ('array of Programme records') and the scope (joined or available), but it does not mention authentication, rate limits, or any side effects. The phrase 'or which are available to join' is ambiguous about the exact filter 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?

  Three sentences, each with a distinct purpose: main action, user intent, and related tools. It is front-loaded and free of unnecessary detail.

  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 7-parameter schema and no output schema, the description leaves significant gaps: no parameter meanings, no pagination/filtering info, and ambiguity about the available-to-join scope. It is sufficient for basic selection but not for correct invocation with complex queries.

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

  Parameters1/5

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

  Schema coverage is 0% for 7 parameters, and the description provides zero explanations for any of them. The required 'brand' parameter is not mentioned at all, leaving the agent without guidance on what to pass.

  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 ('List') and resource ('affiliate programmes on Webgains (advertiser)'), and it provides example user queries that distinguish it from sibling tools for other networks. It clarifies both joined and available programmes, removing ambiguity.

  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?

  It explicitly states 'Use this when...' and lists concrete user intents, making selection easy. It also mentions pairing with get_programme and list_transactions, which provides complementary tool guidance. However, it doesn't explicitly state when not to use it, though the Webgains-specific naming helps.

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

• affiliate_adcell_generate_tracking_linkA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the core action and return type (TrackingLink), but omits authentication requirements, failure modes, side effects, or rate limits. The mention of confirming programmeId hints at a prerequisite but does not reveal underlying 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?

  Three concise, front-loaded sentences: the primary action first, then usage context, then return type and prerequisite. Every sentence earns its place with no redundancy.

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

  Completeness3/5

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

  The description covers the main purpose, usage context, and return type, and gives a practical prerequisite. However, with no annotations and no output schema, it leaves gaps around authentication, URL formatting, and error cases, making it adequate but not fully complete for a two-parameter tool.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate. It restates the parameter names ('programme and destination URL') but adds minimal semantic detail. The advice to pair with list_programmes gives some value for programmeId, but there is no format, constraint, or example for either parameter.

  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 tool generates an Adcell tracking link for a given programme and destination URL, with a specific use case ('when the user wants to share an affiliate link to a specific product or page'). It distinguishes from sibling generate_tracking_link tools by naming the Adcell network and the exact resource.

  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 explicit usage context ('when the user wants to share an affiliate link') and recommends pairing with list_programmes to confirm the programmeId before calling. This gives clear when-to-use guidance, though it does not explicitly exclude alternative network tools (but network-specific naming covers that).

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

• affiliate_admitad-advertiser_generate_tracking_linkA
  3.6/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden. It discloses the return type 'TrackingLink' and the workflow hint about list_programmes, but it does not mention authentication requirements, side effects, error cases, or what the TrackingLink contains. For a generation tool, this is a notable gap.

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

  Conciseness5/5

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

  The description is three efficient sentences, front-loaded with the core action, followed by use case and return/pairing advice. Every sentence adds value and there is no fluff.

  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 three required parameters, no annotations, and no output schema, the description covers the core purpose, use case, return type, and a prerequisite, but falls short on the 'brand' parameter and does not cover authentication or error scenarios. It is adequate for a simple tool but with clear gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It explains 'programme' (likely programmeId) and 'destination URL', but does not clarify the 'brand' parameter at all. It adds some meaning but incomplete.

  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 verb 'Generate', the resource 'tracking link on Admitad (advertiser)', and the inputs 'programme and destination URL'. It distinguishes from sibling tools by explicitly scoping to the Admitad advertiser context and the use case of sharing affiliate links for merchants the user has joined.

  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?

  It provides an explicit when-to-use scenario: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also recommends pairing with list_programmes to confirm programmeId, giving clear context, though it does not mention when not to use or alternatives.

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

• affiliate_adtraction-advertiser_generate_tracking_linkA
  3.6/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It states that a TrackingLink is returned and implies a prerequisite (confirming programmeId), but it does not disclose authentication requirements, potential errors, or any side effects of generating a link. For a tool that generates a resource, this is a significant gap.

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

  Conciseness5/5

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

  The description is two sentences long and front-loaded with the primary action. Every sentence adds value: the first defines the operation, the second gives usage context and a practical pairing tip. No redundant or filler content.

  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 3-parameter tool with no annotations and no output schema, the description covers the purpose, return type, and a prerequisite. However, it misses an explanation of the 'brand' parameter and does not mention authentication or validation behavior. The tool is simple, so this is adequate but not complete.

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

  Parameters2/5

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

  The schema has 0% description coverage for its three parameters. The description mentions 'programme' and 'destination URL' but completely omits the required 'brand' parameter. This leaves the agent guessing what 'brand' refers to and how to populate it, so the description does not adequately compensate for the schema's lack of detail.

  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 identifies the action ('Generate a tracking link'), the target system ('Adtraction (advertiser)'), and the inputs ('programme and destination URL'). It distinguishes this from sibling tools by specifying the advertiser variant and pairs it with list_programmes, making the tool's role unambiguous.

  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 explicit when-to-use context: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to confirm the programmeId. However, it does not explicitly exclude using the non-advertiser variant or other network tools, though the name provides implicit differentiation.

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

• affiliate_adtraction-advertiser_list_clicksA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description must carry the full burden. It discloses that the tool returns Click records, uses 'recent' as a time scope, and supports optional programme/date filtering. However, it omits behavioral details like pagination behavior, auth/side effects, defaults, or whether results are sorted.

  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 three sentences with no fluff. Each sentence adds value: function, use case, and return/pairing. It is well-structured and front-loaded.

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

  Completeness2/5

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

  Given the absence of annotations, output schema, and parameter descriptions, the description leaves significant gaps. It explains the high-level purpose and return type but fails to cover essential invocation details such as the meaning of the required 'brand' parameter and pagination controls, making correct invocation uncertain.

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

  Parameters2/5

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

  Schema coverage is 0% and the description only refers to 'programme and date' filters without mapping them to specific parameters (programmeId, from, to). The required 'brand' parameter is completely unexplained, and pagination parameters (limit, cursor, offset) are not addressed at all.

  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 verb and resource: 'List recent affiliate clicks on Adtraction (advertiser)' and specifies optional filters. It distinguishes from siblings by network/advertiser scope and the pairing note with list_transactions helps separate clicks from conversions.

  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 explicit usage context: 'Use this for traffic-side debugging' with concrete example questions. It also suggests pairing with list_transactions for comparison. It does not explicitly state when not to use it, so it falls short of a 5.

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

• affiliate_adtraction-advertiser_list_media_partnersA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses the return type ('MediaPartner records') and that status is 'normalised', plus a hint to pair with performance tool. However, it says nothing about pagination, filtering behavior, or auth requirements. The added context is moderate but not rich.

  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?

  Three sentences, front-loaded with the core action and including useful example queries and a pairing tip. Slightly verbose with multiple quote examples, but overall efficient.

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

  Completeness2/5

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

  The tool has 6 parameters, no output schema, and no annotations; the description provides the return type and usage scenarios but omits parameter semantics and pagination. For a list tool with this complexity, the description leaves too much unsaid.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not explain any of the six parameters. It only implies 'brand' via 'the brand's programme', leaving limit, cursor, offset, search, and status entirely undocumented. This is a serious gap.

  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 opens with a specific verb+resource: 'List the media partners (publishers) running on the brand's programme at Adtraction (advertiser).' It also provides example user queries, clearly distinguishing this Adtraction (advertiser) tool from sibling list_media_partners tools for other networks.

  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?

  Explicitly states when to use: 'Use this when the user asks...' and then indicates a complementary tool: 'pair with the matching get_programme_performance tool...' This gives clear invocation context and an alternative.

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

• affiliate_affilae_list_programmesA
  3.6/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 burden. It discloses the return type ('Returns an array of Programme records') and the scope (joined vs available), which adds useful context. However, it does not explain pagination behavior, auth requirements, or side effects (though 'list' implies read-only).

  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, front-loaded with the core action, followed by concrete usage examples and related-tool pairings. Every clause earns its place with no redundancy.

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

  Completeness3/5

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

  For a list tool with six optional parameters and no output schema, the description provides adequate context for when to use it and what it returns, but it omits parameter semantics and deeper behavioral details (e.g., status meanings, pagination conventions). It is minimally viable but leaves clear gaps.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description provides no meaning for any of the six parameters (limit, cursor, offset, search, status, categories). The description does not compensate for the missing schema semantics, leaving the agent without guidance on how to filter or paginate.

  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 opens with a specific verb and resource: 'List affiliate programmes the publisher has joined on Affilae (or which are available to join).' This clearly distinguishes the tool from sibling list_programmes tools for other networks and clarifies the Affilae-specific scope.

  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 explicitly provides example user prompts ('which merchants am I working with?', 'what programmes do I have on Affilae?') and the general use case ('wants a partner inventory'). It does not name exclusions or alternative tools, but the contextual guidance is clear and specific to Affilae.

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

• affiliate_affise_get_earnings_summaryA
  3.6/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 full burden. It discloses that the tool returns an EarningsSummary including oldestUnpaidAgeDays, which gives some ontext. However, it does not state whether the operation is read-only, whether authentication is needed, or how it behaves when optional parameters are omitted. For a query tool this is a moderate gap.

  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 compact and front-loaded, with the core action stated first and an example in the same sentence. The second sentence adds a return detail and a pairing suggestion without going overboard. It is slightly dense but still 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?

  With 8 parameters, no output schema, and no annotations, the description leaves significant gaps. It does not address pagination, default behavior, or the full return shape beyond one field. The pairing suggestion helps but cannot compensate for missing parameter semantics and behavioral details.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for parameter meaning. It only loosely references a 'date window' (from/to), 'breakdowns by programme' (programmeId), and 'by transaction status' (status). Parameters like maxAgeDays, minAgeDays, cursor, and limit are not explained, leaving the agent without sufficient guidance to set them correctly.

  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 tool summarizes Affise earnings over a date window with breakdowns by programme and transaction status. The example query 'total earnings in Q1 with status split' makes the use case concrete. It also distinguishes itself from list_transactions by positioning itself as a summary rather than a detailed record 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?

  It explicitly says 'Use this when the user wants a single-figure answer plus context' and provides an example. It suggests pairing with list_transactions to 'drill into the underlying records', which names an alternative. However, it does not explicitly state when not to use it, so it falls short of a perfect 5.

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

• affiliate_amazon-creators_generate_tracking_linkA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description must fully disclose behavior. It only mentions a return value ('Returns a TrackingLink') and a prerequisite (check programmeId via list_programmes). It does not disclose authentication needs, potential errors, side effects, or rate limits. For a tool with no annotation safety net, this is a significant gap.

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

  Conciseness5/5

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

  The description is three sentences with clear functions: action, when-to-use, and follow-up guidance. Every sentence adds value, and the information is front-loaded. No redundant or filler content.

  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 simple two-parameter tool, the description covers the main purpose and gives a useful pairing instruction. However, with no output schema and no annotations, it leaves out important context such as what a TrackingLink contains, authentication prerequisites, and failure modes. It is adequate but incomplete.

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

  Parameters2/5

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

  Schema descriptions are absent (0% coverage), so the description must compensate. It offers minimal semantics: 'programme and destination URL' and that programmeId should be confirmed via list_programmes. However, it does not explain acceptable URL formats, constraints, or validation behavior for either parameter, leaving substantial ambiguity.

  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 tool's action ('Generate a tracking link on Amazon Creators'), its key inputs ('programme and destination URL'), and its purpose (sharing an affiliate link to a product/page). This distinguishes it from the many sibling generate_tracking_link tools for other networks by naming the network explicitly.

  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 explicit guidance on when to use it ('when the user wants to share an affiliate link to a specific product or page on a merchant they have joined') and instructs practitioners to pair with list_programmes to confirm programmeId beforehand. It lacks explicit when-not-to-use or alternative network guidance, but the use case is clearly scoped.

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

• affiliate_amazon-creators_list_programmesA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden and discloses the return type ('array of Programme records') and the scoping ('joined... or which are available to join'). However, it lacks details on filtering, pagination, or authentication requirements, leaving gaps about actual 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 concise and front-loaded with the core purpose, using only three sentences with no fluff. Every sentence adds value: what it does, when to use it, and related tools.

  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?

  It covers purpose, usage triggers, return type, and related tools, which is decent for a list operation. However, the presence of 6 undocumented parameters and absence of any explanation about filtering or pagination leaves the description incomplete for a tool of this complexity.

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

  Parameters1/5

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

  Schema coverage is 0% with 6 parameters (limit, cursor, offset, search, status, categories), yet the description doesn't mention or explain any of them. It fails to compensate for the low coverage, leaving the agent without any guidance on parameter usage.

  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 tool lists affiliate programmes on Amazon Creators, with scope of joined or available ones. It differentiates from sibling list_programmes tools by specifying 'on Amazon Creators' and mentions pairing with get_programme and list_transactions.

  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?

  It provides explicit example queries ('which merchants am I working with?') and states when to use it. It also references complementary tools (get_programme, list_transactions) for drill-down and activity, though it doesn't explicitly exclude other networks because the name already scopes that.

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

• affiliate_awin_generate_tracking_linkA
  3.6/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 full responsibility for disclosing side effects and requirements. It mentions the return type (TrackingLink) but fails to mention that generating links may consume quota (see sibling affiliate_awin_get_link_builder_quota), whether authentication is required, or any rate limits. This is a significant gap for a tool that may have resource implications.

  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?

  Three sentences, each adding value: purpose, use case, and return type with a pairing note. No wasted words; the message is front-loaded with the core action.

  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 description covers the main inputs, return value, and a prerequisite step, which is sufficient for basic invocation. However, it does not address the plural sibling tool, the quota consumption implied by the sibling quota tool, or authentication needs. For an Awin-specific tool, this leaves meaningful gaps in the overall 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?

  With 0% schema description coverage, the description compensates by explaining both parameters in context: 'given programme and destination URL' and 'to confirm the programmeId before calling.' It adds meaning beyond the bare names, though it does not specify URL format or encoding requirements. Still, for a simple two-parameter tool, this is adequate semantic explanation.

  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 (generate a tracking link), the network (Awin), and the two inputs (programme and destination URL). However, it does not distinguish itself from the sibling tool affiliate_awin_generate_tracking_links, which may confuse an agent deciding between the singular and plural variants.

  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 an explicit use case: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also recommends pairing with list_programmes to confirm the programmeId, which is useful guidance for when to use the tool and what to do beforehand. It does not explicitly state when not to use it or mention alternative tools.

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

• affiliate_cake_list_programmesA
  3.6/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 the scope (joined or available), the return type (array of Programme records), and natural pairings, but omits authentication requirements, pagination behavior, and parameter effects. For a read-only list tool this is moderate but not rich.

  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?

  Three sentences, each adding distinct value: purpose, usage triggers, and return/complementary tools. No redundancy or filler.

  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 description covers purpose, usage context, and return type, but with 6 undocumented optional parameters and no output schema, it lacks sufficient detail for full invocation confidence. It is adequate for a simple list operation but leaves questions about filtering and pagination.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description never mentions limit, cursor, offset, search, status, or categories. All six parameters are undocumented in both schema and description, leaving the agent to guess their semantics.

  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 verb ('List'), resource ('affiliate programmes'), and platform ('CAKE'), distinguishing it from sibling list_programmes tools for other networks. It also clarifies the scope ('joined or available to join') and provides example user queries.

  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 explicitly provides when-to-use context with example queries ('which merchants am I working with?') and notes complementary tools (get_programme for drill-down, list_transactions for activity). However, it does not explicitly state when not to use this tool or mention alternatives among siblings.

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

• affiliate_effiliation_list_programmesA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description adds useful behavioral info: it returns an array of Programme records and covers both joined and available programmes. However, it omits details like pagination behavior, authentication requirements, or how filters affect results, leaving some transparency 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?

  Three sentences, each earning its place: the first states the core function, the second gives trigger phrases, and the third describes the return type and related tools. No filler or repetition.

  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 description covers the primary purpose, return shape, and common use cases, making it minimally viable. But with no output schema and 6 undocumented parameters, the lack of guidance on pagination and filtering (search, status, categories) makes it incomplete for a complex invocation.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not explain any of the six parameters (limit, cursor, offset, search, status, categories). The agent gets zero guidance beyond parameter names, so this dimension is nearly absent.

  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 tool lists affiliate programmes on Effiliation, specifying both joined and available-to-join scope. It distinguishes itself from the many other network-specific list_programmes tools by naming Effiliation and describing the exact action.

  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?

  Provides concrete example user queries and suggests pairing with get_programme for drill-down and list_transactions for activity. This gives clear context for when to use it, though it doesn't explicitly state when not to use it or name alternative network options.

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

• affiliate_growsurf_list_transactionsA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It discloses that the tool returns Transaction records including derived ageDays and mentions statuses, which adds value. However, it doesn't mention pagination, side effects, or auth requirements, leaving gaps for a tool with 10 parameters.

  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 three sentences, front-loaded with purpose, and includes practical usage examples and a complementary tool reference. It is efficient without being terse, though slightly longer than necessary.

  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 no annotations, no output schema, and 10 parameters, the description is incomplete. It covers the core purpose and usage, but does not explain required brand, pagination, or the full range of filter options, making it insufficient for confident invocation without additional knowledge.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate. It explains from/to as 'window' and programmeId as 'specific programme', and status via the status list, but leaves brand, limit, cursor, offset, maxAgeDays, and minAgeDays unexplained. The mention of ageDays is about output, not filtering, missing key filter semantics.

  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 verb 'List' and the resource 'affiliate transactions' on GrowSurf, with specific scope details (window or programme). It distinguishes from sibling tools like get_earnings_summary and list_clicks by specifying transaction-level data including statuses (earned, pending, reversed, paid).

  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 explicit example queries ('what did I earn last month?') and suggests pairing with get_earnings_summary for aggregate totals, which guides tool selection. However, it doesn't explicitly state when not to use this tool (e.g., for click data), though the sibling names imply that distinction.

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

• affiliate_hotmart_generate_tracking_linkA
  3.6/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 full responsibility for behavioral disclosure. It mentions the return type (TrackingLink) but does not disclose side effects, failure modes, authentication requirements, or whether the link is permanent or revocable. This is a significant gap for a creation-like 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?

  Three sentences, each adding value: the action, when to use, and a prerequisite pairing tip. No filler or redundancy. The description is front-loaded with the core purpose.

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

  Completeness3/5

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

  For a two-parameter tool with no output schema and no annotations, the description covers the main purpose and usage context, and gives a relevant pairing hint. However, it lacks information about error handling, response structure beyond the mention of TrackingLink, and authorization prerequisites, leaving the agent under-informed for edge cases.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It indicates the two parameters are 'programme' and 'destination URL', and suggests programmeId comes from list_programmes, but it does not specify required URL formats, allowed values, or any validation rules. The added meaning is minimal beyond the parameter names.

  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 tool generates a Hotmart tracking link given a programme and destination URL. The verb 'Generate' and resource 'tracking link on Hotmart' are specific, and it is distinguishable from sibling generate_tracking_link tools via the network 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?

  It explicitly says when to use the tool: when the user wants to share an affiliate link to a product/page on a merchant they joined. It also advises pairing with list_programmes to confirm the programmeId, which is a concrete usage instruction. However, it does not explicitly state when not to use it or name alternative tools.

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

• affiliate_impact_list_programmesA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral transparency burden. It discloses that the tool returns an array of Programme records and that it lists both joined and available programs, adding some context. However, it does not mention pagination behavior, rate limits, authentication requirements, or any side effects—leaving significant gaps in behavioral understanding.

  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 three sentences, front-loaded with the core action, followed by example queries and return type. Every sentence adds value without redundancy or unnecessary detail. It is efficiently structured and easy to scan.

  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 description covers the primary purpose, usage examples, return type, and relationships to sibling tools. However, it omits parameter semantics, pagination details, and any caveats about filtering or response shape. Given the tool has 6 optional parameters and no output schema, these omissions leave the agent with moderate uncertainty about how to invoke the tool correctly for complex requests.

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

  Parameters1/5

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

  The schema has 6 parameters (limit, cursor, offset, search, status, categories) with 0% description coverage, and the tool description does not explain any of them. The agent is left entirely without guidance on how to use these parameters, and the description does not compensate for the schema's lack of descriptions.

  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 tool 'List affiliate programmes the publisher has joined on Impact (or which are available to join)', using a specific verb and resource. It distinguishes itself from sibling tools like get_programme and list_transactions by mentioning drill-down and activity use cases. Example user queries make the purpose unmistakable.

  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 explicit when-to-use guidance with example queries ('which merchants am I working with?') and mentions natural pairings with get_programme and list_transactions. However, it does not explicitly state when not to use the tool or contrast it with a direct alternative in the same way as a 'use X instead' formulation.

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

• affiliate_kwanko-advertiser_list_programmesA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It states the return type (array of Programme records) and scopes to joined/available programmes, which adds behavioral context. However, it does not disclose auth requirements, read-only guarantees, or pagination behavior. Since listing is implicitly read-only, this is adequate but not rich.

  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 concise and well-structured: three sentences covering purpose, usage cues, and related tools without redundancy. Every sentence earns its place, and it is front-loaded with the core verb and resource.

  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 description covers purpose, usage, return type, and related tools, which is reasonable for a list operation. However, with 7 parameters and no annotations or output schema, it omits parameter behavior, pagination, and any edge-case context. It is complete for basic selection but lacks depth for a complex tool.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description provides no parameter explanations. Parameter names like limit, cursor, status, and categories are somewhat self-explanatory, but the required 'brand' parameter is undefined and no parameter semantics are added beyond the raw schema. The description fails to compensate for the lack of schema descriptions.

  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 tool lists affiliate programmes for the publisher on Kwanko (advertiser), including those joined or available to join. It explicitly distinguishes from sibling tools by noting it pairs with get_programme for drill-down and list_transactions for activity, making its purpose specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description provides explicit when-to-use guidance with example user queries ('which merchants am I working with?', 'what programmes do I have on Kwanko (advertiser)?') and identifies related tools for drill-down and activity. However, it does not clarify the difference between this tool and the sibling affiliate_kwanko_list_programmes (non-advertiser variant), which is a minor gap.

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

• affiliate_kwanko-advertiser_list_transactionsA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description must disclose behavior on its own. It mentions that it returns Transaction records with derived ageDays, giving some output transparency. However, it does not state that the operation is read-only, nor does it discuss pagination behavior, default date windows, or authentication requirements, leaving gaps for an agent relying solely on this text.

  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 reasonably concise, with two sentences that avoid redundancy. The first sentence packs the core function and network/role context, while the second provides practical use cases and return details. It could be slightly tighter but is well-structured and front-loaded with the action.

  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 10 parameters, no output schema, and no annotations, the description is insufficient for full invocation accuracy. It lacks explanation of the required `brand` field, drops several optional parameters, and does not clarify default behavior for date ranges or pagination. The mention of derived ageDays is helpful but not enough to make the tool self-explanatory.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It explains the purpose of from/to ("window"), programmeId ("specific programme"), and status (via statuses listed), but it leaves the required `brand` parameter unexplained and does not cover limit, offset, cursor, minAgeDays, or maxAgeDays. An agent would struggle to correctly populate all parameters.

  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 it lists affiliate transactions with statuses (earned, pending, reversed, paid) on Kwanko specifically in the advertiser role. It distinguishes itself from sibling tools by explicitly mentioning 'Kwanko (advertiser)' and provides concrete example queries that indicate the tool's scope.

  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 explicit usage examples ("what did I earn last month?", "what's still pending?") and recommends pairing with get_earnings_summary for aggregate totals, which is a helpful cross-reference. However, it does not explicitly state when not to use this tool or mention alternatives for other cases (e.g., clicks or programmes).

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

• affiliate_lomadee_list_programmesA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It reveals the scope (joined vs. available programmes) and return type (array of Programme records), but omits behavioral details such as pagination, authentication requirements, or filtering semantics.

  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 three sentences long, front-loaded with the core action, followed by usage examples and return/companion tool context. It is efficient and free of fluff, though it could integrate parameter guidance.

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

  Completeness2/5

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

  For a tool with 6 parameters and no output schema, the description lacks essential details on pagination, filtering, and Programme record structure. It provides high-level purpose and sibling hints but is insufficient for correct invocation in richer scenarios.

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

  Parameters1/5

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

  The schema has 6 parameters with 0% description coverage, and the description does not mention any of them. limit, cursor, offset, search, status, and categories remain unexplained, so the description fails to compensate for the coverage gap.

  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 tool lists affiliate programmes on Lomadee, including both joined and available ones. It distinguishes itself from sibling tools like get_programme (drill-down) and list_transactions (activity).

  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?

  Provides explicit trigger questions and use cases (e.g., 'which merchants am I working with?', 'partner inventory'). It also names complementary tools, giving the agent clear alternatives for drill-down and activity-related queries.

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

• affiliate_mrge_list_programmesA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It discloses the return type ('Returns an array of Programme records') and the inclusive scope ('joined ... or which are available to join'), but it does not mention pagination, auth requirements, default ordering, or filtering behavior. Some context is added, but significant gaps remain for a list 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 three sentences, front-loaded with the core purpose, then usage triggers, then return type and companion tools. Every sentence adds distinct value with no redundancy or wasted words.

  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 operation with 5 optional parameters and no output schema or annotations, the description covers purpose and usage well but is incomplete on parameter semantics, pagination behavior, and return record structure. The pairing hints are useful, but an agent would still lack critical details about how to filter or paginate.

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

  Parameters1/5

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

  The schema has 5 optional parameters (limit, cursor, search, status, categories) with 0% schema description coverage, and the description provides no parameter explanations at all. The description does not compensate for the complete lack of parameter documentation; an agent would have no guidance on how to use these fields.

  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 action ('List affiliate programmes'), the resource ('affiliate programmes'), and the network scope ('on mrge'), with an additional parenthetical about availability. It clearly distinguishes from sibling tools by naming the mrge network and pairs with related get_programme/list_transactions 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 provides explicit user query examples ('which merchants am I working with?', 'what programmes do I have on mrge?') and a general use case ('wants a partner inventory'). It also mentions natural pairings with get_programme and list_transactions, though it does not explicitly state when not to use this tool versus other network list_programmes.

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

• affiliate_partnerize_list_programmesA
  3.6/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 returns 'an array of Programme records,' which is helpful. However, it does not disclose behavioral traits such as authentication requirements, pagination behavior (despite 'cursor' and 'limit' parameters), or whether the list includes only joined programmes or also available ones. These gaps leave the agent without a complete safety/behavioral 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?

  The description is two sentences, front-loaded with the primary purpose, and every sentence adds value. It includes example queries, return type, and related tools without any fluff. This is an ideal example of concise, well-structured documentation.

  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 description covers the basics: what the tool does, when to use it, return type, and related tools. However, with 6 parameters and no output schema, the description does not provide enough detail for an agent to confidently use filters (status, categories, search) or understand pagination. This is a medium-complexity tool, and the description leaves gaps for full autonomous usage.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description provides no explanation for any of the 6 parameters (limit, cursor, offset, search, status, categories). The description mentions the list content but does not explain how these parameters affect results. With no compensation from the description, the agent is left guessing about parameter usage.

  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 tool's function: 'List affiliate programmes the publisher has joined on Partnerize (or which are available to join).' It uses a specific verb ('List'), a clear resource ('affiliate programmes'), and scopes it to Partnerize, distinguishing it from sibling list_programmes tools for other networks. The inclusion of example user queries further reinforces the purpose.

  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 explicit usage context with example queries ('which merchants am I working with?', 'what programmes do I have on Partnerize?') and states when to use it ('wants a partner inventory'). It also mentions complementary tools (get_programme for drill-down, list_transactions for activity), providing guidance on alternatives. However, it does not explicitly state when NOT to use this tool vs alternatives, so it falls short of a perfect 5.

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

• affiliate_partnero_list_programmesA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It does disclose the return type ('Returns an array of Programme records') and scope ('joined... or available to join'), but does not mention authentication requirements, pagination behavior, or whether the operation is read-only. For a list operation this is adequate but not comprehensive.

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

  Conciseness5/5

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

  The description is three sentences long, front-loads the core purpose, and includes example queries and related tool references without unnecessary verbiage. Every sentence earns its place.

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

  Completeness3/5

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

  Given the tool's complexity (7 params, no output schema, no annotations), the description provides essential purpose and usage guidance but omits parameter semantics, filter behaviors, and pagination details. It is a viable minimum but leaves notable gaps for an agent to fully understand the tool's capabilities.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description provides no parameter details. The 7 parameters (brand, limit, cursor, offset, search, status, categories) are left unexplained, and the description does not compensate for the schema gap. This is a critical failure for tool selection/invocation.

  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 verb 'List' and the resource: 'affiliate programmes the publisher has joined on Partnero (or which are available to join)'. It also provides concrete example user queries, making the tool's purpose unambiguous and distinct from sibling list_programmes tools for other networks.

  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 explicitly says 'Use this when the user asks...' and gives specific example phrases, providing clear guidance on when to invoke the tool. It also mentions natural pairings with get_programme and list_transactions, but does not explicitly state when not to use it (e.g., other network tools), so it's not a full 5.

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

• affiliate_pepperjam_list_programmesA
  3.6/5.0
  Behavior2/5

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

  There are no annotations, so the description must carry the full burden. It discloses that it returns an array and that programmes may be joined or available, but it does not mention pagination behavior, authentication requirements, filtering semantics, or error/rate-limit behavior. For a read tool, it leaves too much implicit beyond the name itself.

  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 three concise sentences that are front-loaded with the core action, then usage context, output type, and companion tools. Every sentence adds value and 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.

  Completeness3/5

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

  For a list tool with 6 optional parameters and no output schema, the description provides purpose, usage, return type, and sibling relationships, but it omits details about pagination (cursor/limit/offset), filter behavior (search/status/categories), and whether results are joined, available, or both. These gaps make the tool only somewhat complete for an agent to use correctly.

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

  Parameters2/5

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

  Schema coverage is 0% and there are 6 parameters (limit, cursor, offset, search, status, categories). The description does not explain any of them, their allowed values, or how they interact. Parameter names are only weakly self-explanatory, and ambiguous ones like 'status' and 'categories' need elaboration. The description therefore fails to compensate for the schema's lack of parameter details.

  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-resource pair ('List affiliate programmes') and clearly scopes to Pepperjam. It also distinguishes from sibling tools by saying 'or which are available to join' and by giving example user queries, which helps identify this exact tool among many network-specific list_programmes.

  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 explicitly says 'Use this when the user asks...' and provides example queries, which is clear context. It also names companion tools ('pairs naturally with get_programme for drill-down and list_transactions for activity'), giving alternatives. However, it does not explicitly state when NOT to use this tool (e.g., for other networks), though the network-specific name implies this.

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

• affiliate_rakuten_list_programmesA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It adds meaningful context: the tool lists both joined and available programmes and returns an 'array of Programme records.' However, it does not disclose pagination behavior, filtering semantics, authentication needs, or potential rate limits, which are relevant for a list tool with cursor/offset parameters. It adds some value but is not deeply transparent.

  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 three sentences, front-loaded with the core purpose, and each sentence earns its place: definition, usage triggers, and return/related tools. No fluff or redundancy. It is optimally concise and 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?

  For a list tool with 6 parameters and no output schema, the description is moderately complete: it states the return type, scope, and related tools. However, it does not explain parameter use cases, pagination, or what a 'Programme record' contains, which are gaps given the lack of annotations and output schema. It is adequate for selection but incomplete for sophisticated invocation.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description does not explain any of the six parameters (limit, cursor, offset, search, status, categories). The schema provides bare types without descriptions or enums, so an agent has no guidance on what values are valid (e.g., what statuses are allowed, how search works). The description completely fails to compensate for the lack of 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 opens with a specific verb and resource: 'List affiliate programmes the publisher has joined on Rakuten Advertising (or which are available to join).' It clearly identifies the network (Rakuten) and the scope (joined or available), which distinguishes it from sibling list_programmes tools for other networks. Example user queries are provided to reinforce the purpose.

  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 clear when-to-use context via example queries ('which merchants am I working with?', 'what programmes do I have on Rakuten Advertising?') and mentions it pairs naturally with get_programme and list_transactions for drill-down. However, it does not explicitly state when NOT to use this tool (e.g., for other networks), so it misses the 'when-not' guidance for a 5.

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

• affiliate_rewardful_get_programme_performanceA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden for behavioral disclosure. It indicates a read-only 'Fetch' action and discloses the return type (ProgrammePerformanceRow records) and included metrics. However, it does not explain pagination behavior (limit/cursor/offset), date range requirements, or potential auth implications, which are relevant for a data-fetching tool.

  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 three sentences, with the primary action and metrics front-loaded in the first sentence. The subsequent sentences add usage examples and related tool context without fluff. It is slightly longer than strictly minimal but every clause adds value.

  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 8 parameters, no annotations, and no output schema, the description is incomplete. It does not explain pagination, filter semantics, response structure beyond the row type, or how the various optional parameters affect results. It provides useful usage context but leaves major gaps for an agent to invoke it correctly for non-trivial queries.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only adds minimal parameter context: it implies date-based filtering and per-publisher granularity, and hints at publisherId through the list_media_partners pairing. It does not explain the purpose of brand, to, from, programmeId, publisherId, limit, cursor, or offset beyond what raw names suggest. This is insufficient for an 8-parameter tool.

  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 opens with a specific verb and resource: 'Fetch per-publisher performance for the brand's programme at Rewardful', listing exact metrics (clicks, conversions, gross sale, commission). It clearly distinguishes from sibling tools by emphasizing per-publisher rollup and the Rewardful network, making it uniquely identifiable.

  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?

  Provides explicit example user requests and context: 'Use this when the user asks...' and mentions pairing with list_media_partners and list_transactions for related tasks. However, it does not explicitly state when not to use it or name a direct alternative that should be used instead in other scenarios, so it falls short of the highest bar.

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

• affiliate_sovrn-commerce_list_programmesA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden for behavioral disclosure. It mentions returning an array of Programme records and the 'available to join' scope, which adds some nuance. However, it does not explain pagination behavior, filtering semantics, or how to distinguish joined vs available programmes, leaving notable gaps for a list 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 concise, front-loaded with action and purpose, and every sentence adds value. It includes usage examples, scope clarification, and related tools without unnecessary verbosity.

  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 annotations, no output schema, and 6 underdocumented parameters, the description partially compensates by stating the return type and offering usage context. However, it remains incomplete because it omits parameter guidance and key behavioral details like pagination, leaving an agent with insufficient information to effectively use all features.

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

  Parameters1/5

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

  The input schema has 6 parameters with zero description coverage, and the tool description does not explain any of them. The description adds no meaning to limit, cursor, offset, search, status, or categories, failing to compensate for the complete lack of 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 clearly states the tool lists affiliate programmes on Sovrn Commerce, including both joined and available ones. It distinguishes from siblings by naming the specific network and provides example user queries. The mention of pairing with get_programme and list_transactions further clarifies its role.

  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 explicit example queries that trigger this tool and states natural pairings with get_programme for drill-down and list_transactions for activity. While it doesn't explicitly say 'don't use for other networks,' the network-specific naming and examples make the appropriate context clear.

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

• affiliate_tradedoubler-advertiser_generate_tracking_linkA
  3.6/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden but doesn't disclose auth requirements, side effects, idempotency, or rate limits. It mentions the return type but other behavioral traits are omitted.

  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?

  Three concise sentences, purpose first, no filler. Every sentence adds value: purpose, usage context, and prerequisite.

  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?

  Covers purpose, usage, and return type, but missing parameter details (brand) and behavioral context. For a tool with no annotations and no output schema, it's adequate but has notable gaps.

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

  Parameters2/5

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

  Schema covers 0% of parameters. The description explains destinationUrl and implies programmeId via pairing advice, but the required 'brand' parameter is left unexplained, leaving ambiguity.

  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 tool generates a tracking link on Tradedoubler (Advertiser) for a given programme and destination URL. This is specific and distinguishes the tool from other network-specific tracking link generators and the publisher variant.

  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?

  Provides explicit use case: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' Also advises pairing with list_programmes to confirm programmeId. Lacks explicit exclusions but gives clear context.

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

• affiliate_value-commerce-advertiser_generate_tracking_linkA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full disclosure burden. It mentions the return type (TrackingLink) and a caveat about confirming programmeId, but does not disclose authentication requirements, side effects (if any), rate limits, or error behavior. This is a significant gap for a generation 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 three sentences: main action, use case, and workflow tip. It is front-loaded and every sentence adds value. No redundancy or fluff.

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

  Completeness3/5

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

  With no output schema and no annotations, the description should do more. It covers purpose, use case, and return type, but leaves the 'brand' parameter undocumented and does not describe the structure of a TrackingLink. It is adequate for a simple tool but has clear gaps.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate. It explains programmeId and destinationUrl implicitly via 'programme and destination URL', and gives extra guidance for programmeId (confirm with list_programmes). However, the 'brand' parameter is completely unexplained, and the descriptions are still not full parameter-level semantics.

  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 verb (Generate), the resource (tracking link on ValueCommerce advertiser), and the key inputs (programme and destination URL). It distinguishes from sibling network-specific tools by naming ValueCommerce and the advertiser role.

  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 says when to use it ('when the user wants to share an affiliate link to a specific product or page on a merchant they have joined') and advises pairing with list_programmes to confirm the programmeId. It does not explicitly exclude the non-advertiser ValueCommerce variant, but the use case and network/role are clear enough.

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

• affiliate_webgains-advertiser_generate_tracking_linkA
  3.6/5.0
  Behavior2/5

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

  With no annotations, the description must disclose side effects, auth requirements, or other behavioral traits. It only states that it returns a TrackingLink and suggests a precondition; it does not clarify whether the operation is a persistent write, requires specific permissions, or has rate limits. This leaves a significant transparency gap.

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

  Conciseness5/5

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

  Two concise sentences with the action front-loaded. The first sentence states the purpose, and the second adds return type and a useful usage tip. No wasted words.

  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 description covers the core purpose, when to use, a return hint, and a key precondition, which is decent for a simple 3-param tool. However, the unexplained 'brand' parameter and absence of any behavioral or safety context mean it falls short of being fully complete for reliable invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It clarifies 'programme' and 'destination URL', but the required 'brand' parameter is never mentioned or explained. This omission means an agent cannot confidently determine what value to supply for 'brand'.

  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 ('Generate'), names the resource ('tracking link on Webgains'), and explicitly notes the advertiser scope, distinguishing it from the publisher-side Webgains tool and other networks' link generators. The first sentence fully captures the tool's action and target.

  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?

  It provides a clear when-to-use scenario ('when the user wants to share an affiliate link to a specific product or page') and a valuable prerequisite ('pair with list_programmes to confirm the programmeId'). However, it does not mention when not to use it or point to alternative tools.

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

• affiliate_2performant_get_earnings_summaryA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the return type and a specific field (oldestUnpaidAgeDays), it does not explicitly state whether this is a read-only operation, whether it requires authentication, how pagination works, or any side effects. The verb 'summarise' implies a read operation, but the description lacks explicit safety or 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 concise and well-structured, with two sentences that front-load the primary purpose and usage example. It avoids redundant explanations and includes a practical example and a pointer to a related tool, making it efficient and easy to parse.

  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 has 8 optional parameters and no output schema or annotations, the description is not complete enough for an agent to fully understand invocation. It lacks information about all parameters, pagination, date formats, authentication prerequisites, and the full contents of the EarningsSummary response. The description is a good start but leaves too many gaps for a tool with this complexity.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate, but it only hints at parameters like date window (from/to), programme (programmeId), and status, omitting explainations for limit, cursor, maxAgeDays, and minAgeDays. There is no detail on date formats, how status filtering works, or the meaning of the age-related parameters. The description provides minimal insight beyond what parameter names already imply.

  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 it summarizes earnings on 2Performant over a date window with breakdowns by programme and transaction status. It explicitly distinguishes from sibling tools like list_transactions by positioning this as the summary-level tool and suggesting list_transactions for drilling into records. The verb 'summarise' and resource 'earnings' are specific and unambiguous.

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

  Usage Guidelines5/5

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

  The description provides explicit usage guidance: 'Use this when the user wants a single-figure answer plus context' and gives an example query. It also names an alternative or complementary tool (list_transactions) for drilling into underlying records, effectively indicating when not to use this tool alone. This meets the 'when/when-not/alternatives' criterion.

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

• affiliate_adcell_list_clicksA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It mentions 'recent' clicks and the return type ('Click records'), but does not disclose pagination behavior, authentication requirements, or rate limits. Given the presence of cursor and offset parameters, this is a notable gap.

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

  Conciseness5/5

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

  The description is compact and front-loaded with the core action. The example questions and pairing note are concise and add value without wasting words.

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

  Completeness2/5

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

  The tool has 6 parameters, no output schema, and no annotations, yet the description fails to explain pagination, date formats, or return structure beyond 'Click records'. The pairing tip with list_transactions is useful, but overall completeness is insufficient for reliable invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must explain parameters. It covers programme and date filters generically, but omits limit, cursor, and offset entirely, leaving pagination semantics undocumented. This undercuts an agent's ability to invoke the tool correctly.

  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 tool lists recent Adcell clicks with optional programme and date filters. It distinguishes itself from sibling list_clicks tools by naming the network and providing contextual examples like 'are my links being clicked at all?'.

  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?

  Explicitly directs use for traffic-side debugging and suggests pairing with list_transactions to compare clicks vs conversions. However, it does not explicitly state when not to use this tool or contrast it with alternative tools, so it falls short of a full 5.

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

• affiliate_addrevenue_list_clicksA
  3.7/5.0
  Behavior3/5

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

  No annotations provided, so the description must disclose behavior itself. It mentions returns 'Click records' and the traffic-debugging use case, but does not clarify read-only status, auth requirements, pagination behavior, or what 'recent' means. This is adequate but has 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?

  Three sentences, front-loaded with the main action, and every sentence adds value: what it does, when to use it, and what it returns/partners with. No fluff or repetition.

  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?

  With 6 optional parameters, no annotations, and no output schema, the description is incomplete. It does not explain pagination defaults, date range behavior, authentication prerequisites, or what fields are in a Click record. The use-case framing is helpful but operational detail is missing.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It mentions 'optionally filtered by programme and date' which loosely maps to programmeId and from/to, but the pagination parameters (limit, cursor, offset) are completely unexplained. The mapping from 'date' to from/to is also implicit.

  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 tool's function: 'List recent affiliate clicks on Addrevenue' with optional filtering. It includes specific example use cases ('are my links being clicked at all?') and distinguishes from list_transactions by recommending pairing to compare clicks vs conversions.

  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 explicitly says 'Use this for traffic-side debugging' and provides concrete example questions. It also suggests pairing with list_transactions for click-vs-conversion analysis, giving clear practical context. It does not explicitly state when not to use it, but the guidance is strong.

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

• affiliate_admitad-advertiser_get_earnings_summaryA
  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 must disclose behavior. It mentions the return type 'EarningsSummary' and a specific field 'oldestUnpaidAgeDays', which is useful. However, it omits details like authentication requirements, whether the date window is inclusive, or any pagination/limitation behavior. It adds some value but does not fully carry the burden.

  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 three sentences, front-loaded with the core function, followed by usage guidance and return details. Every sentence adds value with no fluff or repetition. It is concise yet informative.

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

  Completeness2/5

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

  Despite having a clear purpose, the tool has 9 parameters, no param descriptions, no output schema, and no annotations. The description covers only the high-level summary and one return field, leaving significant gaps about parameter meanings, pagination, and output structure. It is insufficient for safely invoking the tool correctly in many cases.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for the 9 parameters. It only vaguely references 'date window' (from/to), 'breakdowns by programme and by transaction status' (programmeId/status), and the example implies using status. It does not explain brand, limit, cursor, maxAgeDays, minAgeDays, or programmeId semantics, leaving most parameters ambiguous.

  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 a specific verb ('Summarise earnings') and resource ('Admitad (advertiser)') with explicit scope ('across a date window, with breakdowns by programme and by transaction status'). The example use case ('total earnings in Q1 with status split') further clarifies intent, making it distinct from sibling tools like list_transactions or list_clicks.

  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?

  It explicitly says 'Use this when the user wants a single-figure answer plus context' and provides a concrete example. It also recommends pairing with list_transactions for drilling into underlying records, giving a clear alternative. However, it does not state when NOT to use it (e.g., for raw transaction-level details), which would be stronger.

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

• affiliate_adtraction-advertiser_list_programmesA
  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 burden of behavioral disclosure. It mentions the return type (array of Programme records) and the distinction between joined and available programmes, but it does not address auth requirements, pagination, or potential side effects. For a simple read-only listing tool, this is moderate but not rich 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 two sentences long, front-loaded with the core action, and includes relevant examples without unnecessary detail. Every sentence earns its place.

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

  Completeness2/5

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

  The tool has 7 parameters, no output schema, and no annotations. While the purpose and usage guidance are excellent, the complete absence of parameter semantics and lack of return record details make the description insufficiently complete for an agent to confidently select and invoke the tool correctly.

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

  Parameters1/5

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

  The schema has 7 parameters with 0% description coverage, so the description must compensate. It does not explain any parameter, including the required 'brand', nor do the example queries illuminate how parameters like status, categories, or pagination work. This is a critical gap for correct invocation.

  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 action (list), resource (affiliate programmes), and scope (Adtraction advertiser). It provides example user queries that trigger this tool and distinguishes it from the non-advertiser sibling by explicitly naming 'Adtraction (advertiser)'.

  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 gives explicit when-to-use guidance with concrete user phrasings, and mentions complementary tools (get_programme for drill-down, list_transactions for activity), which helps the agent choose among alternatives.

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

• affiliate_adtraction_get_earnings_summaryA
  3.7/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 burden of disclosing behavioral traits. It reveals that the tool returns an EarningsSummary including oldestUnpaidAgeDays, which is useful, and implies a read-only summarize operation. However, it doesn't mention pagination (despite limit/cursor in schema), date-window boundaries, or any other behavioral characteristics that would help the agent understand the tool's side effects or constraints.

  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 three sentences long, front-loaded with the primary purpose, and includes a helpful usage example and a related-tool tip. Every sentence adds value without redundancy or fluff.

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

  Completeness2/5

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

  Despite the complexity of 8 optional parameters and no output schema, the description provides only high-level context and a single return field. It lacks parameter semantics, pagination behavior, auth requirements, and a clear explanation of the returned structure. The example and pairing hint help, but the description is not sufficient for an agent to invoke the tool correctly in varied scenarios.

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

  Parameters2/5

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

  The input schema has 8 parameters with 0% description coverage, and the tool description does not explicitly map parameters to their meanings. It alludes to 'date window' (from/to), 'by programme' (programmeId), and 'by transaction status' (status), but gives no details for limit, cursor, maxAgeDays, minAgeDays, or the exact expected format. With 0% schema coverage, the description fails to adequately compensate for the undocumented parameters.

  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 tool 'summarise[s] earnings on Adtraction across a date window' with breakdowns by programme and transaction status. This specific verb+resource+scope distinguishes it from sibling earnings summary tools for other networks, and it also mentions the return type (EarningsSummary) and a key field.

  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 explicit guidance on when to use this tool ('when the user wants a single-figure answer plus context') and provides a concrete example. It also recommends pairing with list_transactions for deeper drill-down, which names a complementary alternative tool. It doesn't explicitly state when not to use it, but the guidance is clear enough.

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

• affiliate_affiliate-future_get_earnings_summaryA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden. It mentions the return type (EarningsSummary with oldestUnpaidAgeDays) but does not disclose auth requirements, default behavior when date range is omitted, pagination semantics, or side effects. For a read tool with no annotation support, 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?

  Three sentences, each earning its place: the first states the function, the second gives usage guidance with an example, and the third describes the return value and a pairing with list_transactions. No fluff, front-loaded with purpose.

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

  Completeness2/5

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

  With 8 undocumented parameters, no annotations, and no output schema, the description is too sparse to provide complete context. It only hints at the return structure (one field) and does not cover date formats, status values, or pagination. The overall context is insufficient for reliable tool invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It maps 'date window' to from/to, 'breakdowns by programme' to programmeId, and 'transaction status' to status, but leaves limit, cursor, maxAgeDays, and minAgeDays completely unexplained. The description adds some meaning but is incomplete for 8 parameters.

  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 tool summarizes earnings on Affiliate Future across a date window with breakdowns by programme and transaction status. It distinguishes itself from sibling tools like list_transactions by explicitly framing this as a summary and suggesting list_transactions for drilling down.

  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?

  Explicitly states when to use: 'Use this when the user wants a single-figure answer plus context' with a concrete example. Also points to list_transactions as the alternative for underlying records, giving clear guidance on tool selection.

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

• affiliate_affiliate-future_list_programmesA
  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 the return type ('Returns an array of Programme records') and implies a read-only operation via 'List'. However, it does not mention authentication requirements or clarify whether 'joined' and 'available to join' are both returned or mutually exclusive, which could confuse the agent.

  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 moderately concise with two sentences. It leads with the core action, then provides usage examples and related tools. It could be slightly more compact, but every sentence adds value.

  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 tool with six optional parameters and no output schema, the description adequately covers purpose, usage, and return type. However, it lacks parameter explanations, pagination details, and clarification of the joined-vs-available ambiguity, leaving gaps for a fully informed tool invocation.

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

  Parameters1/5

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

  Schema coverage is 0% and the description makes no mention of any of the six parameters (limit, cursor, offset, search, status, categories). It does not explain what these parameters filter or how to use them, forcing the agent to rely on parameter names alone.

  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 tool 'List affiliate programmes the publisher has joined on Affiliate Future (or which are available to join)' with a specific verb, resource, and network scope. It distinguishes itself from sibling tools by naming Affiliate Future and providing example user queries that map to the tool's purpose.

  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?

  Explicit usage guidance is provided: 'Use this when the user asks...' followed by concrete example queries. It also recommends pairing with get_programme and list_transactions, giving clear context for when this tool is appropriate relative to alternatives.

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

• affiliate_afilio_list_programmesA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It discloses the return type (array of Programme records) but does not mention auth requirements, rate limits, default behavior, or filtering semantics beyond the ambiguous 'joined or available to join' scope. This is sufficient for a basic list operation but lacks depth.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the core action and enriched with usage examples and related tools. Every sentence earns its place with no redundancy.

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

  Completeness2/5

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

  Given the tool has 6 parameters and no output schema or annotations, the description is underspecified for correct invocation. It explains why to use the tool but not how to configure it (e.g., what 'status' values are allowed, how pagination works), leaving a significant gap for a tool with this complexity.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not mention any of the six parameters (limit, cursor, offset, search, status, categories). The agent gets no guidance on what these parameters control, how to use pagination, or valid values, making parameter usage highly guesswork.

  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 tool lists affiliate programmes on Afilio, with the scope including both joined and available-to-join programmes. It distinguishes itself from sibling tools by pairing with get_programme and list_transactions, and provides concrete example user queries.

  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?

  Explicitly states when to use this tool ('when the user asks...') and names alternatives for drill-down (get_programme) and activity (list_transactions), giving clear guidance on selection vs. other tools.

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

• affiliate_awin-advertiser_get_earnings_summaryA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description must disclose behavioral traits. It mentions the return type (EarningsSummary) and that it offers breakdowns, which is useful. However, it does not discuss pagination, auth requirements, rate limits, or how the various filtering parameters affect behavior, leaving significant 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?

  The description is concise and well-structured: purpose, when to use, return info, and pairing suggestion. Every sentence adds value without unnecessary detail. It is front-loaded with the primary function and remains easy to scan.

  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 (9 params, no output schema, no annotations), the description provides useful context: purpose, example query, return field, and a pointer to list_transactions. However, it lacks parameter explanations, pagination behavior, and a full return description, so it is not fully complete for an agent to invoke confidently.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It hints at 'date window' (from/to), 'breakdowns by programme' (programmeId), and 'by transaction status' (status), but many parameters (limit, cursor, maxAgeDays, minAgeDays, brand) are not explained. The required 'brand' parameter is not even mentioned. This is insufficient for a 9-parameter 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 summarizes Awin advertiser earnings with breakdowns by programme and status. It uses a specific verb ('Summarise') and identifies the resource ('Awin (advertiser)'). However, it does not explicitly differentiate from the sibling 'affiliate_awin_get_earnings_summary' (likely the publisher counterpart), relying on the 'advertiser' qualifier in the name and description.

  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 explicitly tells when to use this tool: when the user wants a single-figure answer plus context, with an example ('total earnings in Q1 with status split'). It also names an alternative for deeper detail ('pair with list_transactions to drill into the underlying records'), giving clear usage guidance.

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

• affiliate_awin-advertiser_list_transactionsA
  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 transparency burden. It discloses that the tool returns Transaction records including derived ageDays and enumerates statuses (earned, pending, reversed, paid), which adds behavioral context. However, it does not mention pagination behavior, date window semantics, or any side effects/auth requirements, though as a list operation the safety profile is relatively clear.

  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 three sentences, each earning its place: purpose, usage triggers, and return/complementary tool. It is front-loaded with the action and resource, includes concrete examples, and has no redundancy or extraneous detail.

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

  Completeness2/5

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

  This is a complex tool with 10 parameters, no annotations, and no output schema. The description provides the core purpose and return type, but it fails to document most parameters, pagination, or input formats. An agent would likely struggle to correctly construct calls beyond the basic examples, so the description is incomplete for its complexity.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It implicitly covers a few parameters ('window' for from/to, 'specific programme' for programmeId, and the status categories), but it does not explain the required brand parameter, nor limit, cursor, offset, minAgeDays, maxAgeDays, or date formats. With 10 parameters, this is a significant gap.

  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 verb 'List' plus the resource 'affiliate transactions' on Awin (advertiser), and defines the scope as 'within a window or for a specific programme.' It distinguishes itself from sibling list_transactions tools by specifying the Awin advertiser platform and from get_earnings_summary by noting the complementary relationship.

  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 explicitly provides when-to-use guidance with concrete user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and suggests pairing with get_earnings_summary for aggregate totals. However, it does not state when not to use this tool or directly name alternative tools, so it falls slightly short of full exclusion guidance.

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

• affiliate_awin_get_advertiser_performanceA
  3.7/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. It states what the tool returns: 'Returns report rows plus the exact query and raw Awin response.' This goes beyond a simple 'fetch' by disclosing the response structure. It doesn't cover pagination or error behavior, but for a read-only performance tool, this is meaningful 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 two sentences, front-loaded with the core purpose, and each sentence earns its place. The second sentence adds usage context and return details without fluff. It is appropriately 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?

  The tool has 5 parameters, no output schema, and no annotations. The description explains the aggregation and return format but leaves parameter semantics completely unaddressed. An agent would not know how to set dateType, what region values are valid, or the format for 'from'/'to'. This is a significant completeness gap.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must compensate. It does not explain any of the five parameters (to, from, region, dateType, timezone). Even 'daily or weekly' is not clearly tied to dateType or date range. The description adds no value for parameter understanding, making this a critical gap.

  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 starts with a specific verb and resource: 'Fetch Awin publisher performance aggregated by advertiser.' This clearly differentiates it from sibling tools like get_creative_performance and get_campaign_performance by emphasizing advertiser-level aggregation and by naming the network (Awin).

  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 explicit usage context: 'Use this for daily or weekly revenue, click, impression, approval, and commission summaries by merchant.' This tells the agent when to select this tool, though it does not mention exclusions or alternatives. Since the need for daily/weekly summaries is a clear signal, it earns a 4.

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

• affiliate_awin_get_campaign_performanceA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full transparency burden. It discloses return behavior ('Returns campaign report rows plus the exact query and raw Awin response'), which is useful, but it does not mention auth requirements, rate limits, pagination, or explicitly confirm it is a read-only operation (only implied by 'Fetch').

  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, front-loaded with the primary action and purpose, with no redundant information. It is concise and to the point.

  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 complexity (9 parameters, no annotations, no output schema), the description is incomplete. It does not explain parameter semantics, defaults, how to construct a valid request, or what happens when optional parameters are omitted. The statement about returning 'the exact query' hints at debugging value but lacks the detail needed for an agent to fully understand invocation.

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

  Parameters2/5

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

  Schema coverage is 0% with 9 parameters, so the description must compensate. It only explains the 'campaign' concept and the metrics returned, leaving from, to, dateType, interval, timezone, advertiserIds, and includeNumbersWithoutCampaign entirely unexplained. This is a significant gap for a tool with optional parameters.

  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 tool fetches Awin publisher performance aggregated by campaign parameter, using a specific verb ('Fetch') and resource ('Awin publisher performance'). It distinguishes itself from sibling tools like get_advertiser_performance and get_creative_performance by emphasizing the campaign-level aggregation.

  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?

  Provides explicit usage context: 'Use this when the user tracks placements with the campaign parameter and wants campaign-level clicks, sales, and commission.' It does not explicitly name alternatives, but the condition is clear enough to guide selection among performance-report siblings.

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

• affiliate_cj-advertiser_list_programmesA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It discloses the return type ('array of Programme records') and that it may include programmes available to join. It does not mention pagination, authentication, or read-only safety, which would be valuable absent 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?

  Three sentences with the core functionality in the first, use cases in the second, and return type/related tools in the third. Front-loaded and concise with no wasted words.

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

  Completeness2/5

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

  The tool has 7 parameters (1 required), no output schema, and no annotations. The description covers purpose and return type but fails to explain the required `brand` parameter, filtering options, or output structure. It also leaves ambiguity around 'publisher' vs 'advertiser' roles.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate, but it does not explain any of the seven parameters, including the required `brand`. Parameter names like `search` and `limit` are self-explanatory, but `brand` and `categories` are ambiguous without guidance.

  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 ('List') and resource ('affiliate programmes the publisher has joined on CJ Affiliate (advertiser)'), includes example user queries, and clarifies scope. It distinguishes from the sibling `affiliate_cj_list_programmes` with the '(advertiser)' qualifier.

  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?

  Explicitly states when to use this tool with concrete user questions and notes natural pairings with `get_programme` and `list_transactions`. However, it does not explicitly mention when not to use it or name the publisher-side alternative.

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

• affiliate_cj-advertiser_list_transactionsA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description discloses that results are Transaction records with derived ageDays and implies status and time-window filtering, adding some behavioral context. But it does not mention pagination behavior, authentication requirements, rate limits, or whether this is strictly read-only, leaving significant unknowns for a list 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 three sentences that convey the core action, usage triggers, and a complementary tool suggestion without redundancy or fluff. It is front-loaded with the main purpose and remains easily scannable.

  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 10 parameters and no output schema or annotations, the description leaves many gaps: it doesn't explain the required 'brand' parameter, date formatting, pagination fields, or how ageDays is calculated. The example phrases help with intent recognition but do not cover the full interface, so it is not complete enough for reliable invocation without further inference.

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

  Parameters2/5

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

  Schema coverage is 0%, and the description only implicitly references a few parameters: from/to as 'a window', status via 'pending/reversed/paid', and programmeId as 'specific programme'. It leaves brand, limit, cursor, offset, minAgeDays, and maxAgeDays entirely unexplained, failing to compensate for the schema's lack of parameter details despite having 10 parameters.

  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 tool lists affiliate transactions on CJ Affiliate (advertiser), enumerating status categories (earned, pending, reversed, paid) and filtering by window or programme, which distinguishes it from publisher-side or other networks' transaction tools. The verb 'List' plus resource and scope makes it highly specific and unambiguous.

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

  Usage Guidelines4/5

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

  It provides explicit user-intent examples ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and suggests pairing with get_earnings_summary for aggregate totals, giving clear situational guidance. However, it doesn't explicitly state when not to use it (e.g., publisher-side CJ transactions) or name alternative list_transactions tools for other sides.

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

• affiliate_cj_get_earnings_summaryA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It discloses return type (EarningsSummary) and a notable field (oldestUnpaidAgeDays), implying read-only behavior. However, it omits pagination behavior, filtering semantics, and any rate limits or auth requirements. The mention of breakdowns suggests output structure but is ambiguous (could be filters).

  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?

  Two sentences, front-loaded with purpose and an example, followed by return info and a pairing suggestion. Every sentence earns its place with no redundancy or fluff.

  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 has 8 parameters and no annotations/output schema, the description is too thin. It does not explain pagination parameters (limit/cursor), age filters (min/maxAgeDays), or the full shape of the returned summary. The example and pairing hint are helpful, but the agent is left guessing on many invocation details.

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

  Parameters2/5

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

  Schema coverage is 0% and the description is the only source of parameter meaning. It indirectly covers date window (from/to), status, and programme, but entirely misses limit, cursor, maxAgeDays, and minAgeDays. This leaves the agent without enough to correctly set these five parameters.

  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 ('Summarise') and resource ('earnings on CJ Affiliate') with clear scope (date window, breakdowns by programme and transaction status). It distinguishes from siblings by naming the network and focusing on summary rather than transactions.

  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?

  Provides explicit when-to-use context: 'when the user wants a single-figure answer plus context' with an example. Also prescribes complementary use with list_transactions to drill into records. It stops short of naming explicit alternatives for other summary tools, but the network-specific naming handles that.

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

• affiliate_cj_list_programmesA
  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 of disclosing behavioral traits. It states the output type (array of Programme records) and the scope (joined or available), but it does not disclose pagination behavior (despite cursor/limit/offset parameters), filtering options, rate limits, or authentication requirements. The phrase 'or which are available to join' is slightly ambiguous about whether both categories are returned by default or selectable via parameters.

  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 compact yet information-dense, with two sentences that front-load the core purpose, then provide usage context, output type, and related tools. Every sentence earns its place, and 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.

  Completeness2/5

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

  For a tool with 6 parameters and no output schema, the description is incomplete. While it provides strong usage context and return type, it fails to explain parameter semantics, pagination, or filtering behavior. The agent selecting and invoking this tool would need additional information to construct a well-formed request beyond the simplest call.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not mention any of the six parameters (limit, cursor, offset, search, status, categories). The agent receives no guidance on how these parameters affect the query or what valid values are expected. With the schema providing no descriptions and the description adding none, this is a critical gap for correct invocation.

  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 tool lists affiliate programmes on CJ Affiliate, with a specific verb ('List') and resource ('affiliate programmes'). It distinguishes itself from siblings by naming CJ Affiliate and noting the scope includes both joined and available programmes. It also differentiates from related tools by suggesting pairings with get_programme and list_transactions.

  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 gives explicit usage triggers with example user queries ('which merchants am I working with?', 'what programmes do I have on CJ Affiliate?') and states 'Use this when...'. It also provides guidance on alternatives by mentioning that it pairs with get_programme for drill-down and list_transactions for activity, implying when those tools would be used instead.

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

• affiliate_daisycon_get_earnings_summaryA
  3.7/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 it 'Returns an EarningsSummary including oldestUnpaidAgeDays', which provides some return structure. However, it does not mention pagination behavior despite having cursor and limit parameters, nor does it explicitly state whether the operation is safe/read-only. This is a moderate disclosure but incomplete.

  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, front-loaded with the core purpose, and includes a concrete example and a cross-reference to list_transactions. Every sentence adds value with no unnecessary detail, making it 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 tool with 8 parameters, no annotations, and no output schema, the description is insufficient. It lacks explanations for important parameters (limit, cursor, maxAgeDays, minAgeDays), does not clarify pagination or defaults, and only mentions one return field. The agent would need to infer too much to use it correctly.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It implicitly maps 'date window' to from/to, 'status' to status, and 'programme' to programmeId, but does not explain limit, cursor, maxAgeDays, or minAgeDays. These parameters are left undocumented, making it difficult for an agent to invoke the tool correctly.

  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 action: 'Summarise earnings on Daisycon across a date window' with 'breakdowns by programme and by transaction status'. This specific verb+resource+scope distinguishes it from list_transactions and other network-specific summary tools. The example 'total earnings in Q1 with status split' further reinforces the intended use.

  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 explicitly says 'Use this when the user wants a single-figure answer plus context' and provides an example. It also mentions pairing with list_transactions to drill into underlying records, which is an alternative usage. However, it does not explicitly state when NOT to use this tool (e.g., for transaction-level details), though the pairing suggestion implies it.

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

• affiliate_digistore24_list_clicksA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the transparency burden. It adds 'Returns Click records', which clarifies the output type, and the 'List' verb implies read-only behavior. However, it leaves 'recent' undefined and does not mention pagination, default date range, or cursor/offset behavior, leaving 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?

  Three sentences are front-loaded: purpose, use case, then return value/companion tool. No wasted words; the examples add concrete value.

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

  Completeness2/5

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

  Despite good purpose framing, there is no output schema or annotations, and the description fails to explain pagination parameters, date range semantics, or what a Click record contains. For a 6-parameter tool with no parameter descriptions, this leaves the agent to guess at critical invocation details.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description only says 'optionally filtered by programme and date', which loosely maps to programmeId and from/to but not to limit, cursor, offset, or their formats. With six unannotated parameters, this is insufficient compensation.

  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 opens with 'List recent affiliate clicks on Digistore24, optionally filtered by programme and date', naming the exact resource and verb. It distinguishes this from Digistore24's list_transactions and from other networks' list_clicks by naming Digistore24 and focusing on clicks.

  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?

  It explicitly says 'Use this for traffic-side debugging' and gives concrete example questions, which tells when to invoke it. It also points to list_transactions as the conversion-side complement, though it does not mention explicit 'do not use for conversions' exclusions or other alternative tools.

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

• affiliate_ehub_list_clicksA
  3.7/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 of behavioral disclosure. It mentions the tool 'List recent affiliate clicks' and says 'Returns Click records', indicating a read-only operation and basic output. However, it does not disclose important behavioral traits such as authentication requirements, default time ranges, rate limits, or pagination behavior (despite cursor/offset parameters in the schema).

  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 three sentences with a clear front-loaded statement of purpose. The traffic-side debugging examples add practical value and the pairing note with list_transactions is useful. It is concise and well-structured, though the examples could be trimmed slightly without loss of clarity.

  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 lack of annotations and output schema, the description provides a reasonable overview: purpose, filters, use case, and a pairing recommendation. However, it is incomplete for a 6-parameter tool, lacking details on default date range behavior, pagination semantics, auth requirements, and output structure. The description is adequate for a simple list tool but leaves gaps that an agent would need to resolve via experimentation.

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

  Parameters2/5

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

  The schema has 0% description coverage across 6 parameters, so the description must compensate. It does explain the 'programme and date' filters (mapping to programmeId and from/to), but falls short on limit, cursor, and offset—common pagination parameters that are left completely unexplained. The description adds some meaning but is insufficient for an agent to correctly use all parameters without external knowledge.

  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 tool's purpose: 'List recent affiliate clicks on eHUB', using a specific verb (list) and resource (affiliate clicks on eHUB). It also distinguishes itself from related tools like list_transactions by mentioning pairing for clicks vs conversions, and the 'eHUB' scope separates it from sibling list_clicks tools for other networks.

  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 explicitly provides context for when to use the tool: 'Use this for traffic-side debugging' with concrete examples like 'are my links being clicked at all?' and 'where is traffic going on eHUB?'. It also suggests pairing with list_transactions to compare clicks vs conversions, offering a clear alternative use. However, it does not explicitly state when NOT to use this tool (e.g., when other network-specific list_clicks should be used).

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

• affiliate_everflow_list_clicksA
  3.7/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 transparency burden. It discloses that the tool returns Click records and implies a read-only, recent-data scope, but it does not explain pagination behavior, default date ranges, authentication requirements, or ordering — leaving some behavioral ambiguity.

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

  Conciseness5/5

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

  Three sentences, front-loaded with the action and purpose, followed by practical use-case examples and a pairing suggestion. Every sentence adds value, and the format is easy to scan.

  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?

  With no output schema and six optional parameters, the description is under-specified. It gives the purpose and return type but omits pagination semantics, time-window defaults, and detailed parameter meaning, leaving an agent to guess at invocation details.

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

  Parameters2/5

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

  The input schema has 0% description coverage, so the description must compensate. It only mentions 'filtered by programme and date', which maps to programmeId and from/to, but leaves limit, cursor, offset, and parameter format/relationships unexplained.

  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 ('List recent affiliate clicks on Everflow'), mentions optional filters for programme and date, and clearly links to traffic-side debugging with example questions. It also differentiates from list_transactions by suggesting a paired comparison use case.

  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?

  Explicitly says 'Use this for traffic-side debugging' and provides concrete example scenarios, which clearly indicates when to invoke it. It also suggests pairing with list_transactions for clicks-vs-conversions comparison, though it does not explicitly name alternative tools or 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.

• affiliate_financeads_get_earnings_summaryA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden for behavioral disclosure. It usefully adds that the tool 'Returns an EarningsSummary including oldestUnpaidAgeDays' and mentions breakdowns, but it does not cover pagination, filtering behavior, authentication requirements, or potential side effects. The description adds some value beyond the name but omits significant behavioral details.

  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 three sentences with a clear front-loaded purpose. Each sentence earns its place: what it does, when to use it, and what it returns/pairs with. No fluff or repetition.

  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 8 parameters, zero schema descriptions, and no output schema, the description is incomplete. It does not explain how to set the date window, how status filtering works, or what the returned EarningsSummary contains beyond one field. An agent would struggle to invoke this tool correctly without further guidance.

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

  Parameters2/5

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

  Schema description coverage is 0% and the description does not compensate. It only hints at 'date window', 'programme', and 'status' but does not explain key parameters like to/from format, limit/cursor pagination, minAgeDays/maxAgeDays meaning, or valid status values. The agent cannot reliably infer parameter semantics from this description.

  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 tool 'Summarise earnings on financeAds across a date window, with breakdowns by programme and by transaction status.' This is a specific verb+resource+scope, and it distinguishes itself from siblings like list_transactions (which provides raw records) and get_programme (which returns programme details).

  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?

  It explicitly says 'Use this when the user wants a single-figure answer plus context' and suggests pairing with list_transactions for drill-down. This provides clear context and an alternative, though it does not explicitly state 'do not use for transaction-level detail'.

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

• affiliate_financeads_list_programmesA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the return type (array of Programme records) and the dual scope (joined or available), but does not mention authentication requirements, pagination behavior, or any default filtering/sorting. Useful but incomplete for a list 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?

  Three sentences, each earning its place: main action, usage triggers, and return value/related tools. No redundant phrasing, front-loaded with the primary purpose.

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

  Completeness2/5

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

  For a tool with 6 undocumented parameters and no output schema, the description is too sparse. It covers purpose and usage well but omits parameter meanings and behavioral details (pagination, status values), making it incomplete for reliable invocation.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description provides no guidance on the six parameters (limit, cursor, offset, search, status, categories). The agent cannot infer how to filter or paginate from the description, leaving a significant gap.

  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 tool lists affiliate programmes on financeAds, specifying scope ('joined' or 'available to join'). It provides concrete example user queries ('which merchants am I working with?'), distinguishing it from similar list_programmes tools for other networks.

  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?

  Explicitly tells when to use it via example user phrasings and 'wants a partner inventory'. It also suggests paired tools (get_programme, list_transactions) for related tasks, which guides selection against alternatives.

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

• affiliate_flipkart_list_programmesA
  3.7/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 burden. It discloses the return type (array of Programme records) and that it includes both joined and available programmes, but lacks details on pagination, filtering behavior, or side effects, which are relevant given the cursor and limit parameters.

  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?

  Three sentences, each adding value: purpose, example queries, and related tool recommendations. Front-loaded and concise with no redundancy.

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

  Completeness2/5

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

  With 6 parameters, no schema descriptions, no output schema, and no annotations, the description is insufficient for correct invocation. It covers purpose and usage but leaves parameter behavior and response structure underspecified, which is critical for a tool with filter and pagination options.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description does not mention any of the six parameters (limit, cursor, offset, search, status, categories). The agent receives no guidance on how to use filters, pagination, or search, leaving parameter semantics entirely undocumented.

  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 tool lists affiliate programmes on Flipkart Affiliate, with the specific scope of what the publisher has joined or can join. It distinguishes from siblings like get_programme (single record retrieval) and list_transactions (activity), making its 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 Guidelines5/5

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

  The description provides explicit example queries ('which merchants am I working with?', 'what programmes do I have on Flipkart Affiliate?') and recommends pairing with get_programme and list_transactions, giving clear when-to-use guidance and indicating alternatives.

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

• affiliate_howl_get_earnings_summaryA
  3.7/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 the return type ('Returns an EarningsSummary including oldestUnpaidAgeDays') which adds useful behavioral context. It does not mention side effects, authentication, or rate limits, but the summarization semantics imply a read-only 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 three sentences, each earning its place: purpose, usage scenario with example, and return/drill-down hint. It is front-loaded with the primary function and contains no redundant filler.

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

  Completeness2/5

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

  Despite good purpose and usage clarity, the description does not explain the semantics of many parameters (paginated cursor, age filters, limit) and offers no output schema or detailed return structure. With 8 optional parameters and no annotations, the agent is left without critical invocation details.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate, but it only hints at a few parameters (date window, status, programmeId) while leaving limit, cursor, maxAgeDays, and minAgeDays unexplained. With 8 parameters, this is insufficient for the agent to understand how to populate or combine them.

  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 ('Summarise'), a clear resource ('earnings on Howl'), and explicit scope ('across a date window, with breakdowns by programme and by transaction status'). It also distinguishes itself from the sibling list_transactions by framing the output as a 'single-figure answer plus context'.

  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?

  It provides explicit usage guidance: 'Use this when the user wants a single-figure answer plus context' with a concrete example. It also points to list_transactions as an alternative for drilling down, which clarifies when to use the sibling tool. However, it stops short of fully listing exclusion criteria.

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

• affiliate_howl_list_programmesA
  3.7/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 behavioral transparency burden. It does disclose the return type ('Returns an array of Programme records') and the dual scope (joined or available to join), but does not mention pagination, filtering behavior, authentication requirements, or how to control the joined vs. available distinction—leaving gaps the agent must infer.

  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 three sentences, front-loads the core action, and every sentence adds value: purpose, usage examples, and tool pairing. There is no redundancy or filler.

  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 6 optional parameters and no annotations or output schema, the description is incomplete. It lacks parameter semantics, pagination details, and an explanation of how filters like status and categories affect results. The return type is noted, but the tool's full behavior is not covered well enough for reliable invocation.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description provides no explanation for any of the six parameters (limit, cursor, offset, search, status, categories). With low schema coverage, the description was expected to compensate but does not mention a single parameter, forcing the agent to guess their meaning and format.

  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 tool 'List affiliate programmes the publisher has joined on Howl (or which are available to join)', using a specific verb and resource with the Howl network explicitly named. It distinguishes from sibling list_programmes by network and provides concrete example user queries, making its purpose unmistakable.

  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 gives explicit when-to-use guidance: 'Use this when the user asks...' followed by three example queries. It also explains natural tool pairings ('pairs naturally with get_programme for drill-down and list_transactions for activity'), which helps the agent select complementary tools.

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

• affiliate_impact-advertiser_list_media_partnersA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description must disclose behavior. It does state that the tool returns MediaPartner records with 'normalised status', adding a useful detail. However, it does not mention whether the operation is read-only, any authentication requirements, or pagination/rate-limit behavior.

  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 three sentences, front-loaded with the core action and use cases, and includes practical query examples. No redundant wording, though the last sentence about pairing with get_programme_performance is useful guidance rather than filler.

  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 description gives enough context for tool selection and mentions the return type and a complementary tool, but it lacks parameter semantics, pagination behavior, and the meaning of 'normalised status'. Without annotations or an output schema, these gaps remain.

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

  Parameters2/5

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

  Schema description coverage is 0%. The description does not explain any of the six parameters (brand, limit, cursor, offset, search, status), leaving the required 'brand' and optional filters undocumented. The only implicit hint is 'brand's programme', which is insufficient.

  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 verb ('List') and specific resource ('media partners (publishers) running on the brand's programme at Impact (advertiser)'). It also distinguishes from the many sibling list_programmes tools by specifying the Impact advertiser context and the 'media partners' focus.

  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 explicit trigger examples ('who is promoting us on Impact?', 'which publishers are active?') and recommends pairing with get_programme_performance for deeper analysis. However, it does not explicitly mention when not to use this tool or alternative list tools.

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

• affiliate_impact-advertiser_list_transactionsA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description must carry behavioral disclosure. It adds value by noting that returned records include a derived ageDays field and that the tool provides transactions rather than aggregate totals. However, it omits pagination behavior, default date-window handling, or any prerequisites (e.g., authentication/brand setup), which are relevant for a tool with 10 parameters.

  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 three focused sentences: core action, usage examples, and return behavior with a complementary-tool link. Every sentence earns its place, and the most important information is front-loaded.

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

  Completeness2/5

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

  The tool has a large parameter surface (10 params), no output schema, and no annotations. The description gives purpose clarity but only partial parameter coverage and a minimal return description. An agent would likely struggle to invoke this correctly for edge cases like pagination, age filters, or cursor-based traversal without additional information.

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

  Parameters2/5

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

  Schema coverage is 0% across 10 parameters, so the description must compensate. It clarifies the window (from/to), programme (programmeId), and status examples, but leaves brand, limit, cursor, offset, minAgeDays, and maxAgeDays semantically unexplained. The required 'brand' parameter is not described at all, creating a substantial gap for correct invocation.

  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 opens with a specific verb+resource ('List affiliate transactions') and scopes it to Impact advertiser, explicitly naming statuses (earned, pending, reversed, paid). It also includes natural-language triggers ('what did I earn last month?') that distinguish this from sibling summary 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 gives concrete when-to-use examples and names get_earnings_summary as a complementary tool for aggregate totals. It does not state explicit when-not-to-use conditions (e.g., for publisher-side transactions or when aggregates are required), so it falls short of the most explicit standard.

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

• affiliate_indoleads_generate_tracking_linkA
  3.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions 'Returns a TrackingLink' but doesn't say whether this is a read-only operation, if authentication is required, what side effects exist, or how errors are handled. 'Generate' implies a creation-like action, but no caution or prerequisites are disclosed.

  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 exactly three sentences with no filler. It front-loads the main function, then adds a use-case statement, and finishes with a return type and pairing advice. Every sentence earns its place.

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

  Completeness3/5

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

  For a simple 2-parameter tool, the description covers the essential purpose, use case, and return type. However, it omits important context like authentication requirements (sibling verify_auth implies authentication is needed), error behavior, and details about the TrackingLink return structure since there is no output schema. This is a moderate gap.

  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 0% description coverage, so the description must compensate. It maps 'programme' to programmeId and 'destination URL' to destinationUrl, adding semantic context. The tip to confirm programmeId via list_programmes also gives practical parameter guidance. However, it doesn't explain URL format, encoding, or possible validation issues, so it only partially compensates.

  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 'Generate a tracking link on Indoleads for a given programme and destination URL,' using a specific verb and resource. It explicitly names the platform (Indoleads), distinguishing it from the many other network-specific generate_tracking_link sibling 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?

  It provides explicit when-to-use guidance: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also adds a practical pairing instruction: 'pair with list_programmes to confirm the programmeId before calling.' While it doesn't explicitly mention when not to use alternatives, the context is clear enough.

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

• affiliate_kwanko-advertiser_list_clicksA
  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 full responsibility for behavioral disclosure. It discloses that the tool 'Returns Click records' and mentions optional filtering, but it omits details such as pagination behavior, default time windows for 'recent', and any authentication requirements. This is acceptable but leaves gaps for a full understanding.

  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, immediately stating the purpose and usage context. It is concise, front-loaded, and every sentence earns its place without redundancy. The structure flows logically from action to intent to companion tool.

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

  Completeness2/5

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

  The tool has 7 parameters, 1 required, no annotations, and no output schema. The description provides purpose and usage but omits critical operational context such as required parameters, pagination, default date ranges, and return record structure. For a tool with this complexity, the description is incomplete and leaves significant gaps for an agent to invoke it correctly.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate but only vaguely mentions 'filtered by programme and date'. It does not explain the required 'brand' parameter, the meaning of 'cursor' and 'offset' for pagination, or the format of 'from' and 'to'. The description provides minimal parameter-level insight, failing to clarify the 7-parameter 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 clearly states the tool's function: 'List recent affiliate clicks on Kwanko (advertiser)'. It specifies the resource (affiliate clicks), the network (Kwanko), and the perspective (advertiser), distinguishing it from sibling tools like affiliate_kwanko_list_clicks. The optional filtering by programme and date further clarifies scope.

  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 strong usage context by stating 'Use this for traffic-side debugging' and gives concrete example questions ('are my links being clicked at all?'). It also suggests pairing with list_transactions to compare clicks vs conversions, which names an alternative. However, it does not explicitly state when not to use this tool versus other click-listing tools.

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

• affiliate_leaddyno_generate_tracking_linkA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It states the output ('Returns a TrackingLink') and hints at a precondition (confirm programmeId via list_programmes), which gives some behavioral context. However, it does not disclose whether the operation has side effects on LeadDyno, requires specific auth, or is idempotent, so it is only minimally transparent.

  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 three sentences and front-loaded: action, usage context, return value plus workflow hint. Every sentence adds value without padding.

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

  Completeness2/5

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

  Despite no annotations and no output schema, the description omits the required 'brand' parameter and provides only a minimal return type ('TrackingLink') without structure. The workflow hint mitigates but does not fill the gaps, making the description insufficient for reliable invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must explain parameters. It implicitly covers programmeId and destinationUrl ('given programme and destination URL') and advises confirming programmeId with list_programmes, but it never mentions the required 'brand' parameter, leaving its semantics entirely unexplained.

  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 'Generate' with resource 'tracking link' on 'LeadDyno', clearly distinguishing it from sibling generate_tracking_link tools for other networks. It also specifies the inputs ('programme and destination URL') and the user intent ('share an affiliate link to a specific product or page on a merchant they have joined').

  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?

  Provides explicit when-to-use context: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also instructs to 'pair with list_programmes to confirm the programmeId before calling,' giving a workflow prerequisite. However, it does not explicitly state when not to use it or name alternative tools, so it's not a 5.

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

• affiliate_leaddyno_list_programmesA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It discloses that both joined and available programmes are included and that an array of Programme records is returned, but it does not cover pagination, rate limits, auth, or filter meaning.

  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?

  Three sentences: main action, example intents, and output/complement tools. Front-loaded and every sentence adds value without redundancy.

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

  Completeness2/5

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

  Although purpose and return type are clear, the seven-parameter schema remains unexplained and there is no output schema. For a tool with 7 params at 0% schema coverage, the description is incomplete for selecting and invoking correctly.

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

  Parameters2/5

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

  Schema descriptions are 0% covered, and the description adds no parameter explanations. Required 'brand' and optional filters (status, search, categories, pagination) remain undefined, forcing the agent to guess.

  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 ('list'), resource ('affiliate programmes on LeadDyno'), and scope ('joined or available to join'). It distinguishes from sibling network tools by naming LeadDyno and from other LeadDyno tools by listing programmes specifically.

  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?

  Explicit use-case examples are provided ('which merchants am I working with?', 'what programmes do I have on LeadDyno?'). It also suggests complementary tools (get_programme, list_transactions) for drill-down and activity, though it doesn't explicitly state when not to use alternatives.

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

• affiliate_monetizze_list_programmesA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden, but it only discloses that the tool lists programmes (joined or available) and returns an array. It does not clarify pagination behavior, authentication requirements, or how the joined/available distinction is controlled, leaving important behavioral details unspecified. The added nuance about 'available to join' is useful but not fully explained.

  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 three sentences and gets straight to the point, front-loading the action and scope. It includes useful examples and relational context without padding, making it efficient.

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

  Completeness2/5

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

  Despite the absence of both annotations and an output schema, the description only gives a minimal return-type hint ('array of Programme records') and omits explanations for pagination/filtering parameters. The joined/available ambiguity is also unresolved, leaving significant gaps for a 6-parameter tool.

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

  Parameters1/5

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

  The description offers no guidance on the six schema parameters (limit, cursor, offset, search, status, categories) despite 0% schema coverage. None of these are mentioned, so the agent must infer their meaning from names alone, which is insufficient for correct invocation.

  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 tool lists affiliate programmes on Monetizze, including both joined and available ones. It names Monetizze explicitly, distinguishing it from the many sibling list_programmes tools, and references companion tools for drill-down and activity, reinforcing its purpose.

  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?

  It provides explicit trigger phrases ('which merchants am I working with?', 'what programmes do I have on Monetizze?') and states it is for a partner inventory. It also points to get_programme and list_transactions as related tools, effectively signaling when to use them instead.

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

• affiliate_mrge_list_clicksA
  3.7/5.0
  Behavior2/5

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

  No annotations provided, so description carries full burden. It does not disclose pagination behavior, default date range for 'recent', authentication requirements, or rate limits. 'Returns Click records' is functional but not behavioral; lacks detail about cursor/offset/limit semantics.

  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?

  Three sentences, front-loaded with the action. Each sentence adds value: purpose, usage examples, and cross-reference to list_transactions. No wasted words.

  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 6-parameter tool with no output schema and no annotations, the description leaves critical gaps: pagination params unexplained, no return structure beyond 'Click records', no mention of sorting or default ranges. Incomplete for correct invocation.

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

  Parameters2/5

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

  With 0% schema coverage, description must explain all parameters. It mentions 'programme' and 'date' (matching programmeId and to/from) but says nothing about limit, cursor, or offset. Date format and optionality are unspecified.

  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?

  Description clearly states 'List recent affiliate clicks on mrge, optionally filtered by programme and date' — specific verb, resource, and scope. It distinguishes from siblings by focusing on clicks and explicitly pairing with list_transactions for conversion comparison.

  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?

  Explicitly says 'Use this for traffic-side debugging' with concrete example questions, and names the complementary tool list_transactions for click-vs-conversion analysis. This gives clear when-to-use guidance and an alternative.

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

• affiliate_partnerize-advertiser_get_programme_performanceA
  3.7/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It indicates a read operation via 'Fetch' and mentions the return type, but omits critical behavior such as pagination (despite limit/cursor/offset params), default date ranges, rate limits, or any side effects. No statement confirms it is read-only beyond the verb, leaving the agent to guess operational details.

  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?

  Three tightly written sentences. The first sentence states the core functionality with metrics, the second gives concrete use cases, and the third specifies return type and companion tools. No redundancy, front-loaded with purpose, and every sentence earns its place.

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

  Completeness2/5

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

  For a tool with 8 parameters, no annotations, and no output schema, the description is incomplete. It does not explain parameter semantics, pagination behavior, or the fields inside ProgrammePerformanceRow. While it gives usage examples and companion tools, an agent would lack crucial details for correct invocation and result interpretation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It only vaguely references 'by date' (to/from) and 'per-publisher' (publisherId) and the need to discover publisher ids via list_media_partners. It does not explain the meaning or usage of brand, programmeId, limit, cursor, or offset. The description adds minimal value beyond what the parameter names already imply.

  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 ('Fetch') and clearly defines the resource: per-publisher performance for the brand's programme at Partnerize, listing the metrics (clicks, conversions, gross sale, commission) and granularity (by date). It distinguishes itself from sibling tools by focusing on the per-publisher rollup, and the example queries further clarify its exact purpose.

  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?

  Explicitly states when to use this tool with example user queries ('how is each publisher performing...', 'show me the top-earning partners last month') and provides alternatives/companions: list_media_partners for publisher ids and list_transactions for transaction-level drill-down. This gives the agent clear selection and exclusion criteria.

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

• affiliate_partnerize-advertiser_list_transactionsA
  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 burden. It discloses that the tool returns Transaction records including derived ageDays and lists statuses, which is useful behavioral context. However, it does not mention pagination behavior, default date ranges, or read-only safety, so some transparency 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.

  Conciseness4/5

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

  The description is three sentences, front-loaded with the primary purpose, and includes example queries and a pairing suggestion. It is efficient but could be slightly tightened without losing helpful examples.

  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 a 10-parameter schema, no annotations, and no output schema, the description provides a good high-level overview but lacks details on required parameters, date formats, and full return structure. It covers core use cases well but leaves gaps for an agent to correctly set all parameters or interpret complete output.

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

  Parameters2/5

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

  Schema description coverage is 0% for 10 parameters, and the description compensates only partially. It mentions "within a window" (from/to), "specific programme" (programmeId), and statuses (earned/pending/reversed/paid) for the status field, but fails to explain the required brand parameter, limit/cursor/offset pagination, or minAgeDays/maxAgeDays semantics.

  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 tool lists affiliate transactions (commissions earned, pending, reversed, or paid) on Partnerize (Advertiser), specifying the resource and scope. It distinguishes itself from sibling tools by naming the network and advertiser perspective, and from other list_* tools by focusing on transactions.

  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 explicitly provides when-to-use scenarios with example user queries like "what did I earn last month?" and mentions pairing with get_earnings_summary for aggregate totals. It does not explicitly state when-not-to-use or alternative tools for other actions, but the guidance is clear and context-rich.

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

• affiliate_partnerstack-advertiser_list_media_partnersA
  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 burden of behavioral disclosure. It mentions returning MediaPartner records with normalised status, which adds some value, and 'List' implies a safe read operation. However, it does not disclose pagination behavior, authentication requirements, rate limits, or other side effects, leaving 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 two sentences long, front-loaded with the main action, and every sentence contributes value: the first defines purpose, the second covers usage cues and a complementary tool reference. There is no wasted wording or redundancy.

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

  Completeness2/5

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

  Given the tool's complexity (6 parameters, no annotations, no output schema), the description is incomplete. It covers purpose and use cases but fails to explain pagination (cursor, limit, offset), status/search filtering, and return-value details beyond 'normalised status'. An agent would lack critical operational context.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description does not explain any of the 6 parameters. It only refers to 'the brand's programme' without elaborating on the required 'brand' parameter, and completely omits guidance on limit, cursor, offset, search, or status. This is a severe deficiency for such a parameterized tool.

  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 tool's function: listing media partners (publishers) running on the brand's programme at PartnerStack (advertiser). It uses a specific verb+resource+platform combination and distinguishes itself from sibling list_media_partners tools by naming PartnerStack, making its 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 Guidelines5/5

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

  The description provides explicit usage guidance with example user queries ('who is promoting us on PartnerStack?', 'which publishers are active?') and directly recommends pairing with the matching get_programme_performance tool for per-publisher performance, effectively differentiating when to use this tool versus an alternative.

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

• affiliate_partnerstack_list_clicksA
  3.7/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 some burden. It does state the return type ('Click records') and indicates a read-only, recent-scoped operation, but omits pagination behavior, default date ranges, auth requirements, and details about what Click records contain.

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

  Conciseness5/5

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

  The description is three sentences, each earning its place: purpose, usage context, and return plus companion sibling. It is front-loaded and free of filler, with the examples adding practical texture without bloating the length.

  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?

  With no output schema, no annotations, and 6 undocumented parameters, the description is not complete enough for reliable invocation. It explains why to use the tool but not enough about how to configure filters/pagination or what the returned Click records include.

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

  Parameters2/5

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

  With 6 parameters and 0% schema description coverage, the description only generically mentions 'programme' and 'date' filters, never explicitly naming programmeId, from, to, or explaining cursor/offset/limit. This partially compensates but leaves most parameter semantics undocumented.

  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 ('List') and resource ('recent affiliate clicks on PartnerStack') with optional filters, clearly stating what the tool does. It also distinguishes itself from siblings by emphasizing traffic-side debugging and explicitly contrasting with list_transactions for clicks vs conversions.

  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?

  It gives explicit use cases for traffic-side debugging with concrete examples ('are my links being clicked at all?', 'where is traffic going on PartnerStack?'). It also recommends pairing with list_transactions for conversion comparison, but it does not state explicit 'when not to use' exclusions.

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

• affiliate_partnerstack_list_programmesA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses the scope (joined vs available) and return type (array of Programme records), but does not mention pagination behavior, authentication requirements, rate limits, or how the status/categories filters affect results. These are meaningful behavioral gaps for a listing 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?

  Three sentences efficiently pack in the action, user query examples, and related tool pairings without waste. Each sentence adds distinct value: what it does, when to use it, and what it returns/links to.

  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?

  With 6 parameters, no annotations, and no output schema, the description is operationally incomplete. It covers purpose well but omits parameter semantics, response structure details (beyond 'array'), and behavior around filtering or pagination, leaving substantial ambiguity for an agent.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must compensate. However, it provides no explanation of any of the 6 parameters (limit, cursor, offset, search, status, categories), leaving the agent with only raw types and no semantic guidance.

  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 tool lists affiliate programmes on PartnerStack, explicitly naming the network and distinguishing between programmes the publisher has joined and those available to join. This differentiates it from the many sibling list_programmes tools for other networks.

  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 trigger phrases ('which merchants am I working with?', 'what programmes do I have on PartnerStack?') and suggests companion tools (get_programme for drill-down, list_transactions for activity), giving concrete guidance on when to use this tool and how it fits into workflows.

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

• affiliate_post-affiliate-pro_list_clicksA
  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 burden of disclosing behavior. It states that it 'Returns Click records' and focuses on 'recent' clicks, which is useful. However, it does not mention pagination behavior, required authentication, or rate limits, and it does not explain that 'brand' is a required parameter. The read-only nature is implied by 'List' but not explicitly stated. Overall, it adds some context but leaves important behavioral details undisclosed.

  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 concise and well-structured: three short sentences, front-loaded with the purpose, followed by usage examples and a pointer to a related tool. Every sentence earns its place with useful information and no fluff.

  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 has 7 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the required 'brand' parameter, the format for date ranges, or the pagination mechanism. While it gives strong usage context, it lacks the essential operational details needed for an agent to invoke the tool correctly without guessing.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It vaguely references 'programme and date' filters, which likely map to 'programmeId' and 'from/to', but it does not explain the required 'brand' parameter or the pagination parameters (limit, cursor, offset). With 7 parameters and no schema descriptions, the tool provides far too little parameter-level guidance.

  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 tool's function: 'List recent affiliate clicks on Post Affiliate Pro'. It uses a specific verb ('List') and resource ('affiliate clicks on Post Affiliate Pro'), and distinguishes itself from sibling tools by naming the platform and contrasting with 'list_transactions' (used for conversions).

  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 explicit usage context: 'Use this for traffic-side debugging' with concrete example questions. It also suggests pairing with 'list_transactions to compare clicks vs conversions', which indicates an alternative/complementary tool. However, it does not explicitly state when NOT to use it, so it falls just short of a 5.

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

• affiliate_profitshare_list_transactionsA
  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 behavioral burden and adds useful context: it returns Transaction records with a derived ageDays field and supports window/programme filtering. Yet it omits operational details such as auth requirements, pagination defaults, ordering, or behavior when no parameters are supplied.

  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 compact and front-loaded with the core action, followed by concrete usage examples and a useful output hint. Every sentence adds value, with no fluff or repetition.

  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 complexity (9 params, no annotations, no output schema), the description is not complete enough. It doesn't define the Transaction record structure beyond ageDays, pagination behavior, date formats, or status value enumerations, leaving significant ambiguity for correct invocation and result interpretation.

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

  Parameters2/5

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

  Schema coverage is 0% across 9 parameters, and the description only hints at from/to ('within a window'), programmeId ('for a specific programme'), and status ('earned, pending, reversed, or paid'). Pagination parameters (limit/cursor/offset) and age-day filters (minAgeDays/maxAgeDays) are left unexplained, so the description doesn't sufficiently compensate for the sparse 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 identifies a specific verb and resource: 'List affiliate transactions... on Profitshare' and enumerates the status categories (earned, pending, reversed, paid). It clearly differentiates from sibling tools like list_clicks or get_earnings_summary by focusing on transaction records and scoping filters (window/programme).

  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?

  Provides explicit user-intent triggers ('what did I earn last month?', 'what's still pending?') and recommends pairing with get_earnings_summary for aggregate totals. However, it does not explicitly state when not to use this tool (e.g., for clicks or aggregate-only queries), so it lacks full exclusionary guidance.

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

• affiliate_refersion_generate_tracking_linkA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description must carry the behavioral burden. It discloses the return type (TrackingLink) and implies a prerequisite (valid programmeId), but does not mention authentication, side effects, or error conditions. Some value is added, but significant transparency 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.

  Conciseness4/5

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

  Three sentences, all relevant, with the action front-loaded. The usage sentence is slightly redundant with the first, but the return-type and prerequisite tip add value. Efficient overall.

  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 simple 3-param tool, the description gives purpose, a use case, and return type. However, missing brand explanation, no mention of auth verification, and no output schema mean the description is not fully complete for invocation. Adequate but with clear gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must clarify all parameters. It only covers programmeId and destinationUrl implicitly; brand is never mentioned or explained. No formats, constraints, or value examples are provided.

  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 action (generate a tracking link), the system (Refersion), and the inputs (programme and destination URL). It also provides a use-case scenario, distinguishing it from sibling network-specific 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?

  Provides explicit 'Use this when' context and advises pairing with list_programmes to confirm the programmeId. It doesn't explicitly name alternatives, but the 'on Refersion' phrasing plus sibling names make the network boundary clear.

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

• affiliate_refersion_list_clicksA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description must convey behavior. It indicates the tool returns Click records and supports optional filtering by programme and date, which implies a read-only listing operation. However, it does not disclose pagination, default date ranges, auth requirements, or error behavior, which is insufficient for a no-annotation 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?

  Two sentences, front-loaded with the primary purpose and followed by usage context. Every sentence earns its place, and the structure is clean and efficient.

  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 7 parameters, no output schema, and no annotations, the description is too thin: it doesn't explain pagination, return format details, or required brand semantics. It's adequate for a simple listing but lacks essential context for correct invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must explain the parameters. It covers the programme and date filters but ignores the required 'brand' parameter and the pagination params (limit, cursor, offset). The description adds some meaning for 3 of 7 parameters but leaves the rest unexplained.

  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 tool lists recent affiliate clicks on Refersion, with optional filters. It specifies the resource (Refersion clicks) and verb (List), and the mention of Refersion plus the comparison to list_transactions distinguishes it from the many sibling list_clicks tools for other networks.

  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 explicitly says 'Use this for traffic-side debugging' and gives example questions, providing clear context for when to use. It also suggests pairing with list_transactions to compare clicks vs conversions, which gives a complementary alternative. However, it doesn't explicitly state when not to use it or mention other Refersion tools.

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

• affiliate_rewardful_list_transactionsA
  3.7/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 returns Transaction records including derived ageDays and supports filtering by window/programme, which adds useful behavioral context. However, it does not explicitly state that this is a read-only operation, nor does it mention pagination behavior, rate limits, or authentication requirements, leaving some ambiguity.

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

  Conciseness5/5

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

  The description is three sentences, front-loaded with the primary purpose and scope, followed by usage examples and return-value details. Every sentence adds value, with no filler or redundancy. It is well-structured and easy to scan.

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

  Completeness2/5

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

  For a tool with 10 parameters, no output schema, and no annotations, this description is incomplete. It does not explain all parameters, pagination, or error/edge cases. It also lacks details about the return format beyond a brief mention of Transaction records and ageDays, making it insufficient for fully informed invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for the undocumented parameters. It implicitly covers from/to via 'within a window', programmeId via 'specific programme', status via the status list, and minAgeDays/maxAgeDays via 'derived ageDays'. But it does not explain limit, cursor, offset, or provide formats or allowed values for parameters, leaving many gaps.

  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 it lists affiliate transactions on Rewardful, with specific statuses (earned, pending, reversed, paid) and supports filtering by date window or programme. It distinctly names the resource as 'affiliate transactions' and the platform as 'Rewardful', making it easy to differentiate from sibling tools for other networks or 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?

  Provides explicit example user queries ('what did I earn last month?', 'what's still pending?') that map directly to when this tool should be used. It also mentions pairing with get_earnings_summary for aggregate totals, indicating a complementary relationship. However, it does not explicitly exclude alternatives like list_clicks, though the examples make the intended use clear.

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

• affiliate_shareasale_list_programmesA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that it returns 'an array of Programme records' and notes the dual scope of 'joined' or 'available to join' programmes. However, it does not mention potential side effects (none expected for a list), auth requirements, pagination behavior, or how the 'status' parameter affects results, leaving gaps for a safe agent invocation.

  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 three sentences, front-loaded with the primary action and followed by usage examples and related tools. It is compact and avoids excessive detail, though the phrase 'affiliate programmes' slightly repeats the tool name. Overall, it earns its place without 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?

  For a list tool with no output schema and no parameter docs, the description covers the return type and usage context, and points to sibling tools. However, it omits parameter semantics and pagination details, which are necessary for full autonomous invocation. The completeness is adequate but not thorough.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must explain the six parameters (limit, cursor, offset, search, status, categories). It provides no parameter-level details; the only hint is the mention of 'joined or available,' which vaguely relates to 'status.' This is insufficient for an agent to correctly construct queries.

  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 tool's function: 'List affiliate programmes the publisher has joined on ShareASale (or which are available to join).' This provides a specific verb and resource, and distinguishes it from siblings by naming ShareASale and publisher context. Example queries further clarify the intended use.

  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?

  Explicit when-to-use guidance is given: 'Use this when the user asks "which merchants am I working with?", "what programmes do I have on ShareASale?", or wants a partner inventory.' It also names complementary tools: 'pairs naturally with get_programme for drill-down and list_transactions for activity,' which helps an agent choose between alternatives.

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

• affiliate_shopmy_generate_tracking_linkA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It mentions the return type (TrackingLink) but does not disclose side effects, authentication needs, URL constraints, or error behavior. For a link-generation tool, this lack of behavioral context is a notable gap.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the action, then usage, return type, and a practical pairing tip. No redundant wording; every sentence adds value.

  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 tool with only two params and no output schema, the description covers the basics: what it does, when to use it, and the return type. But it lacks details on URL formats, invalid inputs, or authentication requirements, making it merely adequate rather than thorough.

  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 0% and the schema only provides names and types. The description adds context by referring to 'programme' and 'destination URL,' and hints at how to obtain programmeId (via list_programmes). However, it doesn't specify formats, required URL encoding, or other validation rules, leaving the agent to infer.

  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?

  Clearly states 'Generate a tracking link on ShopMy for a given programme and destination URL' and mentions it returns a TrackingLink. The explicit 'on ShopMy' and the verb 'generate' distinguish it from sibling generate_tracking_link tools for other networks.

  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?

  Provides usage context: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' Also advises pairing with list_programmes to confirm the programmeId. However, it doesn't name alternatives or explicit when-not-to-use cases.

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

• affiliate_skimlinks_list_transactionsA
  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 burden of disclosure. It reveals that the tool returns Transaction records with a derived ageDays field and supports filtering by date/programme/status. However, it does not explicitly state whether authentication is required, pagination behavior, or any side effects, leaving some gaps in behavioral 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 three sentences, front-loaded with the core purpose, then usage triggers, and finally output details and a pairing suggestion. Every sentence adds value with no redundancy or filler.

  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 complexity (9 params, no schema descriptions, no output schema, no annotations), the description is too high-level. It provides a good overview and examples but does not cover parameter usage details, pagination, error conditions, or the full return structure, making it insufficient for reliable invocation in edge cases.

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

  Parameters2/5

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

  The schema has 0% description coverage with 9 parameters, so the description must compensate. It indirectly references 'window' (from/to), 'specific programme' (programmeId), and statuses (status), and mentions ageDays (minAgeDays/maxAgeDays). However, it ignores limit, cursor, offset, and does not explain parameter formats or default behavior, leaving most parameters undocumented.

  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 tool lists affiliate transactions with specific statuses (earned, pending, reversed, paid) on Skimlinks, and can filter by date window or programme. This verb+resource+scope is specific and distinguishes it from sibling tools like list_clicks or get_earnings_summary.

  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 explicit example user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') that indicate when to use this tool. It also suggests pairing with get_earnings_summary for aggregate totals, offering a complementary alternative, though it does not explicitly state when to use other list tools like list_clicks.

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

• affiliate_tradedoubler-advertiser_list_clicksA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosing behavior. It states the tool returns Click records and optionally filters by programme/date, but it does not mention pagination (cursor/offset), rate limits, authentication requirements, or what 'recent' means in terms of default date ranges. This leaves notable gaps for a read 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 three sentences, each serving a purpose: stating the function, providing a use case, and noting the return type plus a complementary tool. It is concise, front-loaded, and free of filler.

  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 no output schema and 7 parameters, the description is incomplete. It does not explain the required 'brand' parameter, pagination via cursor/offset, or how to specify date ranges. It also does not mention whether the returned Click records include necessary fields for debugging. The description is adequate for a high-level understanding but insufficient for accurate invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It only hints at parameter meanings via 'programme and date' (mapping to programmeId and from/to), but leaves the required 'brand', 'limit', 'cursor', and 'offset' unexplained. The description does not clarify that 'brand' is mandatory or describe how filters interact.

  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 action ('List recent affiliate clicks'), the resource ('Tradedoubler (Advertiser)'), and the optional filters ('programme and date'). It also provides example use cases, making the tool's purpose unambiguous and distinct from sibling tools like list_transactions or list_programmes.

  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 explicitly says to use this for traffic-side debugging with concrete example questions ('are my links being clicked at all?'). It also recommends pairing with list_transactions to compare clicks vs conversions, but does not explicitly mention when not to use it or name alternatives like the non-advertiser Tradedoubler list_clicks.

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

• affiliate_tradedoubler-advertiser_list_media_partnersA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden for behavioral disclosure. It mentions that the tool returns MediaPartner records with normalised status, which is useful, but it does not explicitly state that the operation is read-only, mention pagination behavior, auth requirements, or potential side effects. This is a moderate disclosure for a list 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 three sentences with no fluff. The first sentence states the core purpose, the second provides usage examples, and the third covers return type and a pairing suggestion. Every sentence earns its place and key information is front-loaded.

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

  Completeness2/5

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

  The tool has six parameters, no output schema, and no annotations, but the description only addresses the brand parameter and vaguely mentions return records. It lacks coverage of pagination (limit, cursor, offset), filtering (search, status), and the meaning of 'normalised status', making it incomplete for reliable agent invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It only clarifies the 'brand' parameter implicitly via 'brand's programme' but provides no explanation for 'limit', 'cursor', 'offset', 'search', or 'status'. This leaves most parameters semantically opaque.

  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 that the tool lists media partners (publishers) running on the brand's programme at Tradedoubler (Advertiser). It uses a specific verb ('List') and identifies the resource and network, distinguishing it from sibling list_media_partners tools for other networks.

  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 concrete example user queries ('who is promoting us...', 'which publishers are active on our programme?') and recommends pairing with the matching get_programme_performance tool for deeper analysis. However, it does not explicitly state when not to use this tool or list alternatives, so it stops short of a 5.

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

• affiliate_tradedoubler-advertiser_list_transactionsA
  3.7/5.0
  Behavior3/5

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

  The description discloses return content ('Returns Transaction records including derived ageDays') and the ability to filter by time/programme. However, with no annotations provided, it does not explicitly state that the operation is read-only, nor does it mention pagination behavior, auth requirements, or rate limits. Some behavioral context is given, but it is not comprehensive.

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

  Conciseness5/5

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

  Description is three sentences, about 70 words, with the main purpose first, followed by usage examples, then return info. Each sentence provides distinct value without redundancy. It is concise and well-structured for quick scanning.

  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 complexity (10 params, no annotations, no output schema), the description lacks critical details such as required parameters, valid status values, pagination handling, and date format expectations. It provides a good high-level summary but is insufficient for an agent to invoke the tool correctly without additional assumptions.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate for all 10 parameters. It only hints at time window and programme filtering, and indirectly references ageDays, but leaves required brand, status, limit, cursor, offset, maxAgeDays, minAgeDays, and programmeId semantics unexplained. This is insufficient for a tool with this many parameters.

  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 tool lists affiliate transactions with statuses (commissions earned, pending, reversed, paid) on Tradedoubler (Advertiser). It specifies the scope (within a window or for a specific programme), which differentiates it from sibling tools like get_earnings_summary (aggregates) and list_clicks (clicks). This is a specific verb+resource+scope combination.

  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?

  Provides explicit example queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') to guide when to use this tool. It mentions pairing with get_earnings_summary for aggregate totals, offering complementary context, but does not explicitly state when not to use this tool versus other alternatives (e.g., list_clicks).

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

• affiliate_tradedoubler_list_clicksA
  3.7/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 clicks are 'recent,' that filtering is optional, and that it returns Click records. However, it doesn't explain pagination behavior, date format expectations, default limits, or confirm it's a read-only operation beyond the verb 'list.'

  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 compact three-sentence structure: function/scope, usage examples, and return/pairing advice. Every sentence adds value, and the main purpose is front-loaded.

  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 no annotations, no output schema, and 6 parameters, the description is incomplete. It covers purpose and usage but omits critical operational details like pagination parameters, date formats, default behavior, and the structure of Click records. The agent cannot confidently handle edge cases or construct complex queries.

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

  Parameters2/5

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

  With 0% schema description coverage, the description must compensate but only hints at 'programme and date' (programmeId, from/to). It does not explain 'limit,' 'cursor,' 'offset,' or the format for 'from'/'to' strings, leaving the agent without needed guidance for pagination and optional parameters.

  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 'List recent affiliate clicks on Tradedoubler, optionally filtered by programme and date.' This provides a specific verb, resource, and scope. It also mentions the return type ('Click records') and differentiates from transaction tools by framing it as traffic-side debugging.

  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 explicitly gives usage context: 'Use this for traffic-side debugging' with concrete example questions, and suggests pairing with 'list_transactions to compare clicks vs conversions.' It lacks an explicit 'when not to use' statement but the guidance is otherwise strong.

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

• affiliate_tradedoubler_list_programmesA
  3.7/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 it returns 'an array of Programme records' and covers both joined and available programmes, but omits details on pagination behavior, authentication, rate limits, or default filtering. This is a read-only list, so less disclosure is needed, but some behavioral context is still missing.

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

  Conciseness5/5

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

  The description is three sentences long, front-loaded with the core action, and includes only high-value information: purpose, example queries, and related tools. No fluff or redundant details.

  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?

  Purpose and usage are well covered, but the tool has 6 parameters with zero schema descriptions, no annotations, and no output schema. The description fails to explain parameter semantics or return value structure beyond 'array of Programme records', leaving the agent under-informed for actual invocation.

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

  Parameters1/5

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

  Schema description coverage is 0%, so the description must compensate, but it never mentions any of the six parameters (limit, cursor, offset, search, status, categories). The agent is left without guidance on how to filter, paginate, or interpret the meaning of status/categories, making parameter usage completely opaque.

  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+resource+scope: 'List affiliate programmes the publisher has joined on Tradedoubler (or which are available to join)'. It clearly distinguishes itself from sibling list_programmes tools by naming Tradedoubler, and from get_programme by being a list operation.

  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 trigger examples ('which merchants am I working with?', 'what programmes do I have on Tradedoubler?') and names complementary tools (get_programme for drill-down, list_transactions for activity). This gives the agent clear when-to-use guidance and alternatives.

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

• affiliate_tradetracker_list_transactionsA
  3.7/5.0
  Behavior3/5

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

  Without annotations, the description carries full burden. It discloses that the tool returns Transaction records with a derived ageDays field, implying read-only behavior. But it does not mention pagination, rate limits, auth requirements, or any side effects. There are clear gaps in behavioral disclosure.

  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?

  Three sentences, front-loaded with the core action, then examples and a pairing note. No fluff; each sentence adds value.

  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?

  With 9 parameters, no output schema, and no annotations, the description should explain parameter semantics and return structure. It gives only the high-level purpose and an ageDays hint, leaving agents to guess about pagination, status values, and defaults. This is incomplete for safe autonomous invocation.

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

  Parameters2/5

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

  Coverage is 0% and the description only hints at 'within a window' (from/to) and 'specific programme' (programmeId). It fails to explain status, limit, cursor, offset, minAgeDays, maxAgeDays, or their interactions. For a 9-parameter tool, this is insufficient.

  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 action ('List affiliate transactions'), the network ('TradeTracker'), and the scope ('within a window or for a specific programme'). It also enumerates transaction statuses and provides example user queries, distinguishing it from sibling tools like list_clicks and get_earnings_summary.

  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 explicit triggers: 'Use this when the user asks...' with concrete examples. It also suggests pairing with get_earnings_summary for aggregate totals, implying a distinction between detailed transactions and summaries. However, it does not explicitly exclude other alternatives like list_clicks, so it falls short of a full when-not.

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

• affiliate_travelpayouts_generate_tracking_linkA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only mentions 'Returns a TrackingLink' and does not explain side effects, permissions, rate limits, or failure modes. The validation hint about list_programmes implies potential failure with bad programmeId but does not explicitly state consequences.

  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?

  Three sentences, all information-dense. The purpose, usage condition, and workflow hint are front-loaded with no filler.

  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 only two parameters and no output schema, but the description still omits details like the structure of the returned TrackingLink and error handling. The pairing hint with list_programmes provides some contextual completeness, but behavioral and output details are thin.

  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 has zero description coverage, so the description should clarify parameter meaning. It maps 'programme' to programmeId and 'destination URL' to destinationUrl, and the instruction to 'pair with list_programmes to confirm the programmeId' adds semantic value for that parameter. However, destinationUrl lacks format or constraints, leaving a gap.

  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 opens with a specific verb and resource: 'Generate a tracking link on Travelpayouts for a given programme and destination URL.' This clearly identifies the platform and inputs, distinguishing it from sibling generate_tracking_link tools for other networks. The use-case sentence reinforces the purpose.

  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 second sentence explicitly states when to use it: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to validate programmeId, which is a helpful workflow guideline. However, it does not specify when not to use it or name alternative tools.

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

• affiliate_travelpayouts_list_clicksA
  3.7/5.0
  Behavior2/5

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

  No annotations exist, so the description carries the full burden of behavioral disclosure. It states that the tool returns Click records and results are 'recent' and filterable, but it does not disclose pagination behavior, default date ranges, authentication requirements, rate limits, or ordering. 'List' implies read-only, but this is not made explicit.

  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, front-loaded with the action and filters, then followed by a concrete use case and a sibling pairing. Every sentence earns its place with no filler or redundancy.

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

  Completeness2/5

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

  With no output schema, no annotations, and a 6-parameter schema at 0% description coverage, the description must compensate heavily. It covers purpose and high-level output, but omits pagination, date formats, parameter specifics, and authentication needs, making it insufficient for fully confident invocation.

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

  Parameters2/5

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

  Schema description coverage is 0% and none of the six parameters have descriptions. The description contributes the concepts of 'programme' and 'date' filters, which map to programmeId and from/to, but it leaves limit, cursor, and offset unexplained, and does not clarify formats or acceptable values.

  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 opens with a specific action and resource: 'List recent affiliate clicks on Travelpayouts', and notes optional filters by programme and date. This clearly identifies what the tool does and distinguishes it from sibling tools like list_transactions and list_programmes.

  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?

  It explicitly says to use this for 'traffic-side debugging' and gives concrete example questions ('are my links being clicked at all?', 'where is traffic going on Travelpayouts?'). It also recommends pairing with list_transactions to compare clicks vs conversions, which is clear guidance on alternatives and complementary usage.

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

• affiliate_tune_get_earnings_summaryA
  3.7/5.0
  Behavior3/5

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

  Since no annotations are present, the description carries the full burden. It reveals the return type includes oldestUnpaidAgeDays and describes the summary nature, implying no side effects. However, it does not explicitly state read-only behavior, authentication requirements, or any limitations such as pagination or data retention, leaving important behavioral gaps.

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

  Conciseness5/5

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

  The description is concise at three sentences, front-loaded with the core purpose, and includes a useful example plus complementary tool guidance. Every sentence provides distinct value with no redundancy.

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

  Completeness2/5

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

  With 8 parameters, no annotations, and no output schema, the tool is moderately complex. The description only partially covers parameters and provides minimal context on return structure. It does not explain pagination (cursor/limit), date filters (maxAgeDays/minAgeDays), or expected input formats, making it insufficient for confident invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It loosely references date window (to/from), programme (programmeId), and status, but does not explain limit, cursor, maxAgeDays, minAgeDays, or their relationships. Most parameters remain semantically opaque despite the description's general hints.

  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 tool's function: summarising earnings on TUNE over a date window with breakdowns by program and transaction status. This distinguishes it from sibling tools like list_transactions and other networks' get_earnings_summary. The verb 'summarise' and the resource 'earnings on TUNE' are specific and unambiguous.

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

  Usage Guidelines4/5

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

  Explicit guidance is provided: 'Use this when the user wants a single-figure answer plus context', with a concrete example. It also names list_transactions as a complement for drilling into records, which serves as an alternative. However, there is no explicit when-not or exclusion, so it does not fully meet the 5-level criterion.

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

• affiliate_value-commerce-advertiser_list_programmesA
  3.7/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the burden. It discloses the return type ('array of Programme records') and hints that the listing may include both joined and available programmes, but it does not clarify the joined/available scope, nor does it mention auth, pagination, or read-only nature. This is partial but not comprehensive 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?

  Three sentences, front-loaded with the action verb, and all content is relevant. Example queries and pairing notes are useful, and there is no filler or repetition beyond the necessary '(advertiser)' qualifier.

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

  Completeness2/5

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

  Despite having 7 parameters, no output schema, no annotations, and no parameter descriptions, the description is brief and omits parameter semantics, pagination behavior, and filtering capabilities. It includes usage context and return type but is insufficient for an agent to correctly invoke this tool with all parameters.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description provides no semantic guidance for the 7 parameters. The required 'brand' parameter is never explained, and pagination/filter parameters (limit, cursor, offset, search, status, categories) are ignored. The description fails to compensate for the missing schema descriptions.

  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 action ('List affiliate programmes') on a specific resource (ValueCommerce advertiser) and includes example user queries. It distinguishes from sibling tools by explicitly naming the platform and mentioning complementary tools (get_programme, list_transactions), though the 'joined vs available to join' phrasing introduces slight ambiguity.

  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 trigger phrases ('which merchants am I working with?', 'what programmes do I have on ValueCommerce (advertiser)?') and indicates when to use the tool. It also names natural pairings with get_programme for drill-down and list_transactions for activity, which guides tool selection.

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

• affiliate_webgains-advertiser_get_earnings_summaryA
  3.7/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full burden. It does disclose that it returns an EarningsSummary including oldestUnpaidAgeDays and that results can be broken down by programme and status, which is useful. But it says nothing about auth, read-only nature, pagination behavior (despite limit/cursor params), or error semantics, so it's a 3.

  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?

  Two sentences, no fluff, front-loaded with purpose. It packs a lot of useful info without wasted words.

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

  Completeness2/5

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

  For a tool with 9 parameters, no annotations, and no output schema, the description is thin. It covers the main purpose and one return field, but misses parameter documentation, pagination, and required params. An agent would likely need to guess or leave out crucial parameters like brand.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate. It explains the date window (from/to), programme and status filters implicitly, but the required 'brand' parameter is not mentioned, and limit/cursor/maxAgeDays/minAgeDays are left unexplained. This leaves the agent unable to correctly populate 4 of 9 parameters from the description, so a 2.

  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 opens with 'Summarise earnings on Webgains (advertiser) across a date window, with breakdowns by programme and by transaction status,' which clearly identifies the action, resource, and scope. The parenthetical '(advertiser)' distinguishes this from the non-advertiser webgains variant, and the mention of breakdowns sets expectations. A 5 is warranted.

  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?

  It explicitly says 'Use this when the user wants a single-figure answer plus context' with a concrete example, which is a clear usage guideline. It also recommends pairing with 'list_transactions to drill into the underlying records,' naming an alternative tool. However, it doesn't explicitly state when to prefer list_transactions over this or what not to use it for, so a 4.

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

• affiliate_webgains-advertiser_list_transactionsA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It discloses the return includes Transaction records with derived ageDays and scoping by date/programme. However, it omits pagination/limit/offset behavior, authentication needs, and read-only status. The added context is useful but partial.

  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 sentences, front-loaded with purpose, then usage triggers and return info. It is efficient and avoids fluff, though it could be organized with structured param hints.

  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 10-param tool with no output schema and no annotations, the description covers common use cases and mentions derived ageDays. But it fails to explain pagination, all parameter semantics, or output structure details, leaving gaps for complex queries.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must explain the 10 parameters. It covers status types and window/programme concepts, but leaves from/to formats, limit/cursor/offset, maxAgeDays/minAgeDays, brand, and pagination semantics unexplained. Compensation is insufficient for the number of parameters.

  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 'List affiliate transactions... on Webgains (advertiser)' with statuses (earned, pending, reversed, paid) and scope (window or programme). This verb+resource+scope is highly specific and distinguishes it from publisher tools and other network transaction 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?

  It provides explicit use-case triggers ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and suggests pairing with get_earnings_summary for aggregates. It does not explicitly say when not to use it (e.g., for publisher data), but the examples and advertiser naming make selection clear.

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

• affiliate_2performant_list_programmesA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It implies a read-only action ('has joined') and states the return shape ('array of Programme records'), but does not disclose pagination behavior, default limit, filtering semantics, authentication requirements, or potential side effects. This adds some context but leaves significant behavioral details undisclosed.

  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 three sentences and every sentence earns its place: first states the core action, second gives user-intent triggers, third gives output and integration hints. It is front-loaded with the main verb and free of fluff.

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

  Completeness3/5

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

  The tool has 6 optional parameters, no output schema, and no annotations. The description gives a useful overview, return type, and sibling pairings, but lacks parameter guidance, return field details, and auth/pagination context. It is adequate for a simple list tool but leaves clear gaps for correct invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not explain any of the 6 parameters (limit, cursor, offset, search, status, categories). It only vaguely implies filtering via 'has joined (or available to join)', but does not map this to the status parameter or any other. With low schema coverage, the description fails to compensate.

  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 verb and resource: 'List affiliate programmes' for the publisher on 2Performant. It distinguishes from siblings by naming the network in the tool name and in the description, and adds scope nuance ('has joined... or which are available to join'). It also explicitly mentions the return type ('array of Programme records').

  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?

  Provides explicit when-to-use scenarios with example user queries ('which merchants am I working with?', 'what programmes do I have on 2Performant?', 'wants a partner inventory'). It also mentions natural pairings with get_programme and list_transactions, which helps an agent choose between tools, though it does not explicitly state when not 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.

• affiliate_accesstrade_list_programmesA
  3.8/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It discloses a key nuance: the tool lists both programmes the publisher has joined and those available to join. It also states the return type (array of Programme records). However, it doesn't mention pagination behavior, auth requirements, or other safety details, though the list nature implies read-only 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 compact and front-loaded: the first sentence states the core action, and the second adds use cases, return type, and related tools. No unnecessary words 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?

  The description covers purpose, use cases, return type, and complementary tools, which is good for a list operation. However, given the 6 optional parameters and lack of output schema/annotations, it should explain filtering and pagination semantics to be fully complete. The omission of parameter details is a significant gap.

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

  Parameters1/5

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

  The input schema has 6 parameters with no descriptions (0% coverage), and the description provides no explanation of limit, cursor, offset, search, status, or categories. The description fails to compensate for the schema's lack of parameter semantics, leaving the agent without guidance on how to use these optional filters.

  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 tool lists affiliate programmes on AccessTrade, specifying both joined and available programmes. It includes concrete example user queries and distinguishes it from other network-specific list_programmes tools. The verb 'List' and resource 'affiliate programmes' are specific and unambiguous.

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

  Usage Guidelines4/5

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

  The description provides explicit when-to-use guidance with example user intents ('which merchants am I working with?', 'what programmes do I have on AccessTrade?'). It also mentions complementary tools (get_programme, list_transactions) for drill-down and activity, though it doesn't explicitly state when not 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.

• affiliate_adservice_list_clicksA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It discloses that it returns Click records and mentions optional filters, but it does not mention pagination behavior, default date range limits, authentication requirements, or that it is a read-only operation (though 'list' implies this). It provides some behavioral context, but not the depth expected for an unannotated 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?

  Three sentences, front-loaded with the main function, then a practical use case, then return type and a pairing suggestion. Every sentence earns its place with no redundancy or filler.

  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 tool with 6 parameters, no annotations, and no output schema, the description covers the core purpose and use case but omits important details like parameter formats, pagination mechanics, and the structure of Click records. It is adequate for a basic understanding but not fully complete for a complex 6-parameter tool.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It clarifies 'programme and date' which likely maps to programmeId and from/to, but the other parameters (limit, cursor, offset) are left completely unexplained. The description adds only partial meaning for 2 of 6 parameters, leaving the agent to guess the format and semantics of the pagination fields.

  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 names the exact action ('List recent affiliate clicks'), the network ('Adservice'), and the scope ('optionally filtered by programme and date'). It clearly distinguishes from sibling tools like list_transactions by positioning it for traffic-side debugging, and the pairing hint with list_transactions reinforces its unique role.

  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 explicitly states when to use it ('traffic-side debugging') with concrete examples, and suggests pairing with list_transactions for clicks vs conversions. It does not explicitly say 'don't use this for conversions', but the pairing instruction implies that distinction. The guidance is clear enough for an agent to choose this tool over alternatives.

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

• affiliate_adservice_list_programmesA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It does disclose the return type ('array of Programme records') and the joined/available distinction, which is useful. However, it omits pagination behavior, authentication requirements, or how status filtering affects results, leaving significant behavioral aspects unstated.

  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, front-loaded with the primary action and scope, followed by concrete usage examples and companion tool links. Every sentence adds value with no redundancy.

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

  Completeness3/5

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

  The tool has 6 parameters, no output schema, and no annotations, so the description must carry the burden. It provides strong purpose and usage context, but lacks parameter semantics and edge-case details, making it only partially complete for an agent to invoke the tool without further guessing.

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

  Parameters2/5

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

  Schema description coverage is 0% and the description does not mention any of the six parameters (limit, cursor, offset, search, status, categories). While the parameter names are somewhat self-explanatory, no allowed values, formats, or semantics are provided, and the description does nothing to compensate for the schema gap.

  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 tool lists affiliate programmes on Adservice, specifying both 'joined' and 'available to join' scopes. It uses a specific verb+resource+platform structure and naturally distinguishes itself from the many other network-specific list_programmes siblings.

  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?

  Explicit usage triggers are provided via example user queries ('which merchants am I working with?', 'what programmes do I have on Adservice?') and related tools (get_programme, list_transactions) are named for drill-down and activity. However, it doesn't explicitly state when not to use this tool or point to alternatives for other networks, so it falls short of a 5.

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

• affiliate_affise_list_clicksA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description correctly identifies the operation as listing clicks and states the return type as 'Click records.' It does not disclose pagination behavior, the meaning of 'recent,' time-range defaults, or auth/read-only context, which are important for a read tool lacking annotation support.

  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?

  Three sentences, front-loaded with the core action, then a concrete use case, and a sibling pointer. Every sentence earns its place and the example questions make the tool's purpose immediately understandable.

  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 tool with 6 parameters and no output schema, the description covers the high-level purpose and return type but omits pagination semantics, date format details, and a fuller description of Click records. It is sufficient for basic selection but not fully complete for robust invocation.

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

  Parameters2/5

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

  Input schema coverage is 0%, and the description only maps 'programme and date' to programmeId and from/to. It says nothing about limit, cursor, or offset, leaving pagination semantics and parameter formats to be guessed.

  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 opens with 'List recent affiliate clicks on Affise, optionally filtered by programme and date,' naming a specific action, resource, and scope. It clearly distinguishes this from the Affise list_transactions sibling and other network-specific click 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?

  It gives an explicit use case: 'Use this for traffic-side debugging' with concrete example questions, and recommends pairing with list_transactions for clicks-vs-conversions comparison. However, it never explicitly states when not to use it or when to prefer list_transactions alone.

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

• affiliate_afilio_list_clicksA
  3.8/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 burden. It states 'Returns Click records' and mentions optional filtering by programme and date, but does not disclose pagination behavior, default time windows, authentication requirements, or any side effects. For a read-only list operation, this is somewhat adequate but lacks depth.

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

  Conciseness5/5

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

  The description is two sentences long, front-loaded with the core function and augmented with a use case. Every word earns its place; no fluff or repetition.

  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 6 parameters, no output schema, and no annotations, the description provides the essential purpose and use case but omits return structure, pagination details, and parameter semantics. It is not complete enough for a fully autonomous agent to invoke with confidence across all parameters.

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

  Parameters2/5

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

  The input schema has 6 parameters with 0% description coverage, and the description only indirectly covers programmeId and date filters via 'optionally filtered by programme and date.' It does not explain 'limit', 'cursor', 'offset', or 'to'/'from' syntax. This leaves a significant gap for parameter understanding.

  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 tool's function: 'List recent affiliate clicks on Afilio, optionally filtered by programme and date.' It uses a specific verb ('List') and resource ('affiliate clicks on Afilio'), and differentiates itself from sibling tools like list_transactions by mentioning 'pair with list_transactions to compare clicks vs conversions.'

  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 specifies when to use the tool: 'Use this for traffic-side debugging — e.g. "are my links being clicked at all?" or "where is traffic going on Afilio?"' It also recommends pairing with list_transactions, providing clear context. It does not explicitly list when not to use it, but the use cases are well-defined.

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

• affiliate_amazon-creators_list_clicksA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the transparency burden. It discloses that it returns Click records and supports optional programme/date filtering, but it omits details about pagination behavior, default date ranges, or authentication requirements. This is adequate but has clear 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?

  The description is three concise sentences, each earning its place: the action and filters, the use case, and the return type with a pairing suggestion. No fluff 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?

  The tool has six parameters, no annotations, and no output schema, so the description must do substantial work. It covers the core purpose, filters, and return type, but misses essential details about pagination parameters and output structure, leaving the description only partially complete.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for all six parameters. It only vaguely implies the meaning of programmeId and date filters (to/from) via 'filtered by programme and date', leaving limit, cursor, and offset completely unexplained. This is insufficient for an agent to use pagination correctly.

  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 tool lists recent affiliate clicks on Amazon Creators, with a specific verb (List) and resource (clicks). It distinguishes itself from sibling tools like list_transactions by focusing on the traffic side, making its 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 Guidelines4/5

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

  The description explicitly says to use it for traffic-side debugging with concrete example questions, which is strong contextual guidance. It also suggests pairing with list_transactions for clicks vs. conversions, but it does not explicitly state when not to use it or name a direct alternative, so it stops short of a full 5.

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

• affiliate_awin-advertiser_get_programme_performanceA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention authentication requirements, side-effect safety, pagination behavior, or data update cadence. The only behavioral hint is that it 'Returns ProgrammePerformanceRow records', which is minimal.

  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 three sentences, front-loaded with the core purpose, followed by usage examples, then return type and related tools. Every sentence earns its place, and there is minimal 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?

  With 8 parameters, no output schema, and no annotations, the description is not fully complete. It covers what and when, but lacks parameter/return structure details. However, it is more helpful than most similar tools, making it adequate but with clear gaps.

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

  Parameters2/5

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

  The schema has 8 parameters with no descriptions (0% coverage), and the description only hints at date and publisher filtering ('by date', 'per-publisher'). It does not explain required 'brand', 'programmeId', pagination via 'limit'/'cursor'/'offset', or how 'from'/'to' interact.

  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 a specific action ('Fetch per-publisher performance') with a defined resource (brand's programme at Awin), and lists concrete metrics (clicks, conversions, gross sale, commission). It also provides example user queries that distinguish this tool from siblings like list_transactions and get_earnings_summary.

  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?

  It explicitly says 'Use this when...' and gives real-world user phrasings. It also differentiates from alternatives by suggesting pairings with list_media_partners (for publisher ids) and list_transactions (for transaction-level drill-down), making the when-to-use/not-use context clear.

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

• affiliate_awin-advertiser_list_clicksA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of disclosing behavior. It correctly implies a read-only operation by using 'List' and stating 'Returns Click records', which is helpful. However, it does not explain pagination behavior (cursor/offset), default date ranges, or response structure, leaving gaps in behavioral understanding.

  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 three compact sentences, front-loaded with the primary action and filters. Every sentence earns its place by adding use-case context or pairing guidance. It is neither verbose nor under-specified.

  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 no output schema, no annotations, and 7 parameters, the description provides the core purpose and a useful pairing hint, but lacks details on pagination, date range semantics, or required parameters. It is adequate for a simple list tool but not fully complete for a robust agent decision.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It adds meaning for 'programme' (programmeId) and 'date' (from/to), but does not explain 'brand' (required), 'limit', 'cursor', or 'offset'. For a tool with 7 parameters, this is insufficient guidance for correct invocation.

  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 tool's function: 'List recent affiliate clicks on Awin (advertiser)' with specific filter options (programme, date). It distinguishes itself from sibling tools by explicitly noting the advertiser perspective and framing the use case around traffic-side debugging. The examples ('are my links being clicked at all?') further clarify intent.

  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 a clear use case ('traffic-side debugging') and complementary tool ('pair with list_transactions to compare clicks vs conversions'), which helps the agent choose when to use it. It lacks explicit when-not-to-use guidance or direct alternatives, but the context is strong enough to avoid misuse.

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

• affiliate_awin-advertiser_list_media_partnersA
  3.8/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 the tool returns 'MediaPartner records with normalised status', providing some return-type context. However, it does not mention pagination behavior, authentication requirements, rate limits, or what 'normalised status' entails, leaving significant behavioral gaps for a list 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 two sentences: a purpose statement with example queries, then a return-type note and a cross-reference to a complementary tool. It is front-loaded with the most critical information and contains no fluff or redundant details.

  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 description covers the core use case and return type, and even suggests a related tool for further depth. However, with 6 parameters, no output schema, and no annotations, the overall context is incomplete—especially around pagination, filtering, and parameter formats. It is adequate but not thorough for a tool with this complexity.

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

  Parameters2/5

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

  Schema description coverage is 0%, yet the description only implicitly references the required 'brand' parameter and says nothing about limit, cursor, offset, search, or status. While parameter names are somewhat self-explanatory, the description fails to compensate for the low coverage, leaving the agent without guidance on how to use optional parameters like 'search' or 'status'.

  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 opens with a specific verb+resource ('List the media partners (publishers) running on the brand's programme at Awin (advertiser)'), clearly distinguishing from sibling tools by naming the network and perspective. It also provides concrete example queries ('who is promoting us on Awin', 'which publishers are active on our programme?') that reinforce the exact purpose.

  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 explicitly states when to use the tool ('Use this when the user asks... or wants an outbound roster') and suggests pairing with the matching get_programme_performance tool for deeper analysis. It does not explicitly contrast with sibling network-specific list_media_partners tools, but the network qualifier in the description and tool name makes the context clear enough.

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

• affiliate_awin_get_programme_detailsA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description must disclose behavior on its own. It states that the tool returns 'the detailed programme envelope with raw Awin data preserved,' giving some transparency about the output format. However, it does not mention authentication requirements, potential errors, or any side effects, though the 'Fetch' verb implies a read-only 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 three sentences with each earning its place: what it does, when to use it, and what it returns. No fluff or repetition, and it is well-structured for quick scanning.

  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 (2 params, no output schema, no annotations), and the description covers purpose, usage, and return envelope. However, it is incomplete because it omits the 'relationship' parameter semantics and provides only a vague description of the return format ('raw Awin data preserved'), leaving some ambiguity for an agent.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It explains 'advertiserId' as 'a specific advertiser ID' but does not mention the 'relationship' parameter at all, leaving its meaning and impact on the fetch undocumented. This is a significant gap given the parameter is optional and has an enum.

  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 ('Fetch') and resource ('Awin programme details'), clearly scoped to a specific advertiser ID. It also enumerates the exact content (description, KPI, deeplink status, valid domains, commission range), which differentiates it from generic list or get tools and from siblings targeting other networks.

  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 explicit usage context: 'Use this before promoting a merchant when the user needs description, KPI, deeplink status, valid domains, and commission range.' This clearly states when to invoke the tool, though it does not explicitly mention when not to use it or name alternatives.

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

• affiliate_awin_get_transactions_by_idA
  3.8/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 states that it 'Returns matching transaction rows and can include basket products when Awin exposes them,' which discloses the return type and a conditional behavior. However, it does not mention error handling, rate limits, or explicitly confirm the read-only nature (though 'fetch' 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.

  Conciseness5/5

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

  The description is only two sentences, front-loaded with the action and purpose, with no redundant phrasing. Every sentence earns its place by covering what the tool does, when to use it, and what it returns.

  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 tool with no output schema and no annotations, the description covers purpose, usage context, and a high-level return description, but leaves gaps on timezone semantics, exact response structure, and edge cases. It is adequate for a known-transaction lookup but not fully comprehensive.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for parameter meaning. It clarifies that IDs are 'numeric transaction IDs,' which adds context beyond the schema's string-or-number union, but it does not explain the 'timezone' parameter at all and only vaguely gestures at 'showBasketProducts' by mentioning basket products. Key parameters remain under-documented.

  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 opens with a specific verb+resource ('Fetch individual Awin transactions by numeric transaction IDs') that clearly states what the tool does and distinguishes it from broader list_transactions siblings. It also identifies the exact use case, making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description explicitly guides when to use the tool: 'when investigating a known transaction from a report, support ticket, or previous list_transactions result.' This provides clear context, though it does not explicitly name alternative tools or state when not to use it.

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

• affiliate_awin_list_commission_groupsA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that the tool returns commission group codes, names, rate values, conditions, and raw Awin data, which is useful. However, it does not mention any auth requirements, pagination, or data scope limitations, leaving some behavioral context implicit.

  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 compact (two sentences) and front-loaded with the core action and resource. It includes a use-case hint and return summary without unnecessary fluff, making it easy to parse quickly.

  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?

  While the tool is not complex, the absence of an output schema and annotations combined with undocumented parameters means the description must cover more ground. It explains the return structure briefly but leaves gaps around effectiveDate behavior and extraConditionsDetails, which are nontrivial for an agent to infer.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not compensate by explaining the parameters. It only indirectly references advertiserId via 'advertiser' and does not clarify the role of effectiveDate or extraConditionsDetails, which are essential for correct invocation.

  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 ('List') and identifies the unique resource ('commission groups and rates') for an Awin advertiser. It clearly distinguishes this from sibling tools like list_commission_sharing_rules or list_transactions by focusing on commission group data.

  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 a clear 'when to use' context: deciding which products, customer types, or tracked parts are worth promoting. It does not explicitly mention when not to use it or name alternatives, so it misses the highest bar, but the guidance is actionable.

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

• affiliate_cake_generate_tracking_linkA
  3.8/5.0
  Behavior2/5

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

  With no annotations provided, the description must fully disclose behavioral traits. It mentions the return type (TrackingLink) and that it 'generates' a link, but it does not explain side effects, authentication requirements, rate limits, reversibility, or what happens with invalid inputs. The guidance to confirm programmeId hints at failure behavior but does not disclose it directly.

  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 only two sentences long, front-loaded with the primary purpose, and includes practical usage and return information. Every sentence adds value with no redundancy or filler.

  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 tool with two simple string parameters, no output schema, and no annotations, the description covers the essential purpose, usage, return type, and a key prerequisite. It is complete enough for an agent to select and invoke the tool correctly for its primary use case, though it could mention authentication prerequisites or error handling for full completeness.

  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 only names and types for programmeId and destinationUrl with zero coverage. The description adds some meaning by explaining that programmeId should be confirmed via list_programmes and that destinationUrl should be a product/page URL on the merchant's site. Still, it does not fully compensate for the lack of schema descriptions, such as URL format expectations or potential constraints.

  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 action (generate), the resource (tracking link on CAKE), and the key inputs (programme and destination URL). It also explains the use case (sharing an affiliate link to a specific product or page), which distinguishes it from other network-specific tracking link 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 explicitly says when to use the tool ('when the user wants to share an affiliate link to a specific product or page on a merchant they have joined') and provides a clear prerequisite ('pair with list_programmes to confirm the programmeId before calling'). However, it does not explicitly state when not to use it or list alternative tools for other networks, so it stops short of a perfect score.

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

• affiliate_cake_get_earnings_summaryA
  3.8/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 burden. It discloses that the tool returns an EarningsSummary including oldestUnpaidAgeDays, which adds value. However, it does not state whether this is a read-only operation, any authentication requirements, or pagination behavior, leaving gaps in behavioral 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 three sentences, front-loaded with the core purpose, includes a concrete example, and mentions the return type and pairing suggestion. Every sentence earns its place with no fluff.

  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 8 parameters, no annotations, and no output schema, the description provides a basic understanding but lacks details on return fields and advanced parameters like limit/cursor. It is adequate for simple invocations but not fully complete for complex usage.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It mentions 'date window' (for from/to), 'programme' (programmeId), and 'transaction status' (status), but fails to explain limit, cursor, maxAgeDays, minAgeDays, or their types/formats. Partial compensation only.

  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 tool's function: 'Summarise earnings on CAKE across a date window, with breakdowns by programme and by transaction status.' This is a specific verb+resource+scope, and it distinguishes itself from sibling tools like list_transactions by emphasizing the summary nature and mentioning CAKE specifically.

  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?

  It explicitly says 'Use this when the user wants a single-figure answer plus context', providing clear usage context. It also suggests pairing with list_transactions to drill into underlying records, which helps the agent choose between this and alternative tools. Does not mention exclusions for other tools, but the guidance is sufficient.

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

• affiliate_cj-advertiser_generate_tracking_linkA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden for behavioral disclosure. It adds value by stating the return type ('Returns a TrackingLink') and a prerequisite ('pair with list_programmes to confirm the programmeId'). However, it does not disclose whether authentication is required, potential side effects, or failure behavior, 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 two sentences, front-loaded with the primary action, and every sentence earns its place. It is concise, free of fluff, and ends with a practical tip. This is an ideal structure for quick agent comprehension.

  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 3-parameter tool with no output schema and no annotations, the description is moderately complete. It covers purpose, usage context, return type, and a prerequisite. However, it omits details about the brand parameter, authentication expectations, and error scenarios, making it only partially complete for an agent that needs full context.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It explains 'programme' and 'destination URL' which map to programmeId and destinationUrl, but the 'brand' parameter is entirely unexplained. The description adds partial meaning for two of three parameters, but the missing brand leaves a significant gap.

  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 action ('Generate a tracking link'), the specific resource ('on CJ Affiliate (advertiser)'), and the inputs ('for a given programme and destination URL'). It also differentiates this tool from the regular CJ affiliate tool by explicitly noting the 'advertiser' role, and from similar tools by naming the network.

  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?

  Provides a clear when-to-use scenario: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also gives actionable guidance to pair with list_programmes to confirm the programmeId. However, it does not explicitly mention alternatives (e.g., the non-advertiser variant) or exclusions, so it falls short of a 5.

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

• affiliate_cj-advertiser_list_clicksA
  3.8/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 read operation ('List'), returns Click records, and supports optional filtering. However, it does not explain pagination behavior (cursor/offset), default date ranges, or authentication requirements, which are relevant for a list tool with 7 parameters.

  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, front-loading the core purpose and adding usage context and return type. Every sentence adds value without redundancy, and it is appropriately sized for the tool's complexity.

  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 tool with 7 parameters and no annotations or output schema, the description covers purpose, filters, usage, and return type, which is valuable. However, it does not mention required brand, pagination, or date format, leaving the tool incomplete for an agent to invoke correctly without further inference.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It mentions 'filtered by programme and date' (mapping to programmeId and to/from), but it omits the required 'brand' parameter and fails to explain pagination parameters (limit, cursor, offset). This leaves significant gaps for correct invocation.

  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 ('List') and resource ('recent affiliate clicks on CJ Affiliate (advertiser)'), clearly distinguishing it from the publisher-facing CJ list_clicks tool. It also mentions optional filtering by programme and date, which aligns with the schema fields.

  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 usage context: 'Use this for traffic-side debugging' with concrete example questions. It also recommends pairing with list_transactions for click-vs-conversion comparison. However, it does not explicitly state when not to use this tool or mention the alternative CJ (publisher) list_clicks tool.

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

• affiliate_commission-factory-advertiser_generate_tracking_linkA
  3.8/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 behavioral burden. It discloses that the tool 'Returns a TrackingLink' and suggests confirming programmeId beforehand, which is useful context. However, it does not state whether the operation has side effects, requires special authentication beyond the advertiser context, or has any rate limits/error conditions; for a generation tool this is a moderate gap.

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

  Conciseness5/5

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

  The description is three sentences and front-loads the core action in the first sentence. Every sentence adds value: action, use case, return value, and a prerequisite tip; there is no redundancy or fluff.

  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 simple 3-parameter tool with no annotations and no output schema, the description covers the purpose, use case, return type, and a prerequisite, but it omits parameter semantics for brand and does not address error handling or auth requirements. This makes it functional but not fully complete.

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

  Parameters2/5

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

  Schema coverage is 0% and the description only mentions 'programme' and 'destination URL,' which maps to programmeId and destinationUrl but leaves 'brand' completely unexplained. It does give a hint about programmeId via the list_programmes pairing advice, but fails to add semantics for brand or the expected format of destinationUrl, so it does not compensate for the missing schema descriptions.

  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 explicitly states 'Generate a tracking link on Commission Factory (advertiser) for a given programme and destination URL,' which names a specific verb and resource. It also scopes the tool to the advertiser variant of Commission Factory, distinguishing it from the many sibling generate_tracking_link tools for other networks and from the non-advertiser Commission Factory variant.

  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 says 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined,' which clearly identifies the use case. It also advises pairing with list_programmes to confirm programmeId before calling, but it does not explicitly name alternatives or when not to use this tool, so it falls short of a 5.

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

• affiliate_commission-factory-advertiser_list_transactionsA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that it returns Transaction records including derived ageDays and implies read-only via 'List', but does not mention pagination behavior, authentication requirements, rate limits, or error conditions, leaving some behavioral aspects unspecified.

  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 three sentences with no filler. It front-loads the core purpose, then adds example queries and return details, making it efficient 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?

  For a tool with 10 parameters and no output schema, the description provides useful purpose, use cases, and return type, but it omits pagination semantics, the meaning/format of the required brand parameter, and details on how age filters interact with ageDays. It is adequate for basic selection but not fully complete for complex invocations.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It conceptually covers window (from/to), specific programme (programmeId), and status values, but the required brand parameter is not explained, and limit/cursor/offset/minAgeDays/maxAgeDays are left entirely to the schema, which has no descriptions. This leaves many parameters under-specified.

  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 action ('List affiliate transactions'), the resource ('Commission Factory (advertiser)'), and the scope (statuses, window, specific programme). It distinguishes from sibling tools by specifying the advertiser variant and listing concrete transaction states, making the purpose unambiguous.

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

  Usage Guidelines4/5

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

  The description gives explicit example user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and recommends pairing with get_earnings_summary for aggregate totals. It provides clear when-to-use guidance but does not explicitly contrast with the non-advertiser variant or other network tools.

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

• affiliate_coupang-partners_list_clicksA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that the tool returns Click records and supports optional programme/date filters. However, it doesn't mention pagination behavior, date range semantics, rate limits, or auth requirements, leaving gaps for a list 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?

  Three compact sentences: the first states action and filters, the second gives a concrete usage scenario, the third describes the return type and useful pairing. Every sentence earns its place with no redundant filler.

  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 six-parameter tool with no output schema and no annotations, the description provides a clear purpose, use cases, and return type, but omits pagination parameters, date format details, and behavioral caveats. It's adequate for basic invocation but leaves meaningful gaps for advanced usage.

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

  Parameters2/5

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

  Schema coverage is 0% and the description only hints at programme and date filtering. The six schema parameters (to, from, limit, cursor, offset, programmeId) are not individually explained; pagination tokens (cursor/offset) and date formats are left entirely undocumented. The names help but add limited semantic value.

  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 starts with a specific verb-resource pair: 'List recent affiliate clicks on Coupang Partners'. It also names optional filters (programme and date) and clearly distinguishes from sibling tools like list_transactions and get_programme.

  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?

  It provides an explicit use case ('traffic-side debugging') and example questions, plus a complementary pairing with list_transactions to compare clicks vs conversions. It doesn't name exclusions or alternatives, but the context is clear enough for an agent to decide when to invoke it.

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

• affiliate_coupang-partners_list_transactionsA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the full burden of behavioral disclosure. It adds useful context by stating that the tool 'Returns Transaction records including derived ageDays', which indicates an enriched return format. It also notes the scope of filtering ('within a window or for a specific programme'). However, it does not disclose pagination behavior, authentication requirements, rate limits, or the read-only nature of the operation explicitly, which would be valuable given the absence of 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 two sentences, front-loaded with the action and resource. The first sentence defines the purpose and scope, the second provides usage examples and a pairing tip. No word is wasted, and each sentence contributes valuable information. The structure is highly efficient and easy to parse.

  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 (9 parameters, no output schema, no annotations), the description provides only partial completeness. It covers the main use cases, return type, and a derived field, but does not explain pagination, default behavior, or many parameter semantics. For a list tool with rich filtering options, this is sufficient for basic usage but not for advanced or edge-case queries.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It implicitly covers a few parameters: 'within a window' suggests from/to date ranges, 'for a specific programme' points to programmeId, and the statuses mentioned map to the status parameter. It also references derived ageDays, which relates somewhat to min/maxAgeDays. However, 9 parameters exist and most (limit, cursor, offset, minAgeDays, maxAgeDays) are not mentioned or explained, leaving significant gaps for an agent to invoke the tool correctly.

  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 tool's purpose with a specific verb ('List') and resource ('affiliate transactions on Coupang Partners'). It enumerates the transaction statuses handled (commissions earned, pending, reversed, or paid) and distinguishes its scope ('within a window or for a specific programme'). The examples of user questions make the purpose immediately understandable, and the note to pair with get_earnings_summary for aggregate totals differentiates it from a closely related sibling tool.

  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 explicitly says 'Use this when the user asks...' with three concrete example questions, providing clear context for when to invoke this tool. It also mentions pairing with get_earnings_summary for aggregate totals, which serves as a guideline for when to use a complementary tool. However, it does not explicitly state when not to use this tool or name alternatives like list_clicks, so it falls short of full exclusionary guidance.

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

• affiliate_daisycon-advertiser_list_media_partnersA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the transparency burden. It discloses that the tool returns MediaPartner records with normalised status and describes the result as an outbound roster. However, it omits important behavioral details like pagination behavior, filtering semantics (status/search), authentication requirements, and error cases, leaving gaps in what the agent should expect.

  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 concise and well-structured, front-loading the core action, then providing user-facing examples and tool-pairing guidance. Every sentence contributes value without redundancy or unnecessary detail.

  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 moderately complex (6 parameters, no output schema, no annotations). The description gives a solid high-level picture and usage context, but it lacks parameter explanations, output format details, and pagination/status behavior, which are necessary for fully autonomous invocation in varied situations.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for parameter meanings. It only implicitly references the 'brand' parameter through 'brand's programme' and gives no explanation of limit, cursor, offset, search, or status. Parameter names are somewhat self-explanatory, but the lack of specificity (e.g., valid status values, how search works) falls short of full compensation.

  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 identifies the tool's function: listing media partners (publishers) for a brand's Daisycon advertiser programme. It uses a specific verb ('List') with a specific resource, and distinguishes itself from sibling tools by specifying the Daisycon advertiser context and the media partner entity.

  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 explicit usage triggers with example user queries ('who is promoting us...', 'which publishers are active...') and suggests pairing with get_programme_performance for deeper analysis. It does not explicitly state when not to use the tool, but the positive use cases and complementary tool reference provide clear guidance.

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

• affiliate_daisycon_generate_tracking_linkA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose side effects and behavior. It only adds 'Returns a TrackingLink' and a prerequisite, but fails to mention auth requirements, whether generation is idempotent, or any error/edge-case behavior. This is a significant gap for a mutation-like 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?

  Three sentences with zero fluff: action/inputs, usage trigger, and return value with prerequisite. Each sentence contributes meaning, making it well-structured and appropriately sized.

  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 low-complexity tool with two string parameters, the description covers purpose, when to use it, return type, and a prerequisite (list_programmes). It lacks details like auth/validation rules, but the essential selection/invocation info is present. The absence of an output schema is partially offset by the 'Returns a TrackingLink' note.

  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 has 0% parameter description coverage, so the description must compensate. It maps the two parameters conceptually: 'programme and destination URL' correspond to programmeId and destinationUrl. However, it provides no format, example values, or constraints, only basic semantic mapping.

  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 it 'Generate a tracking link on Daisycon for a given programme and destination URL' – a specific verb, resource, and network. This clearly distinguishes it from sibling generate_tracking_link tools for other networks.

  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?

  It provides explicit when-to-use criteria: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also recommends pairing with list_programmes to confirm the programmeId, though it doesn't explicitly state when not to use or alternatives.

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

• affiliate_digistore24_generate_tracking_linkA
  3.8/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 discloses the return type ('Returns a TrackingLink') but says nothing about authentication requirements (verify_auth exists as a sibling), potential side effects, or error behavior. For a tool that may require valid credentials or create a persistent link, this gap is significant.

  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?

  Three sentences cover purpose, usage, and a relevant pairing hint without any redundancy. The critical information 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 simple two-parameter tool, the description covers the operation, when to use it, and the return type. Missing are auth context and more detail on the TrackingLink structure (no output schema), but overall it is sufficiently complete for its simplicity.

  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 0% schema description coverage, the description must compensate for both parameters. It labels them as 'programme' and 'destination URL' and hints at confirming programmeId via list_programmes, but it does not explain formats, URL validation, or where destinationUrl comes from. This is partial compensation at best.

  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 specific action ('Generate a tracking link on Digistore24') with the platform explicitly named, distinguishing it from the many sibling generate_tracking_link tools for other networks. It also specifies the inputs ('for a given programme and destination URL').

  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: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to confirm programmeId, offering a concrete prerequisite. However, it does not explicitly mention alternatives or when not 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.

• affiliate_ebay_list_programmesA
  3.8/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 burden. It reveals the tool is read-oriented by using 'List' and states it returns an array of Programme records. However, it does not disclose authentication requirements, pagination behavior, rate limits, or other side-effect information that an agent might need.

  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 concrete usage examples and related-tool references. It is three concise sentences with no filler or redundant restatement of the tool name.

  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?

  Covers the essential purpose, scope, return type, and common usage contexts, which is good for a simple list tool. However, it omits parameter semantics and pagination expectations, and with no output schema or annotations, the overall picture is incomplete for an agent needing to invoke it with the right filters.

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

  Parameters2/5

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

  Six parameters exist with 0% schema description coverage, and the description does not explain limit, cursor, offset, search, status, or categories. The property names offer some self-evident meaning, but the description adds no value to parameter understanding, failing to compensate for the lack of schema 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 clearly states the tool lists affiliate programmes on eBay Partner Network, specifying scope ('publisher has joined' or 'available to join'). It distinguishes from sibling list_programmes tools by explicitly naming the network and giving example user queries.

  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?

  Provides explicit 'Use this when' guidance with realistic user phrases and names related tools (get_programme, list_transactions) for drill-down and activity. It lacks explicit when-not-to-use instructions for other network-specific list_programmes tools, but the context is clear.

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

• affiliate_effiliation_list_clicksA
  3.8/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 burden. It discloses that this is a read-only list operation, supports optional filters, and returns Click records. However, it doesn't mention pagination behavior, default date ranges, or rate limits. For a simple list tool, this is adequate but not deeply transparent.

  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?

  Three concise sentences: what the tool does, when to use it, and what it returns paired with a related tool. No filler or repetition; every sentence earns its place.

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

  Completeness3/5

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

  With 6 optional parameters, no output schema, and no annotations, the description gives the core use case and return type but leaves gaps around pagination, date formatting, and exact parameter semantics. It's reasonably complete for the stated debugging purpose but not fully self-sufficient.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate. It names two filter dimensions ('programme and date') which map to programmeId and from/to, but it doesn't explain pagination parameters (limit, cursor, offset) or their types/constraints. The description adds some value but leaves most parameters unexplained.

  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 ('List'), names the resource ('affiliate clicks on Effiliation'), and mentions filtering by programme/date. It distinguishes itself from other network-specific list_clicks tools by explicitly naming Effiliation and suggesting pairing with list_transactions.

  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?

  It clearly positions the tool for traffic-side debugging with concrete example questions ('are my links being clicked at all?', 'where is traffic going on Effiliation?'). It also recommends pairing with list_transactions for clicks-vs-conversions analysis, providing a complementary alternative. It lacks explicit exclusions or when-not-to-use guidance, but the context is clear.

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

• affiliate_ehub_list_programmesA
  3.8/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 transparency burden. It discloses the return type ('Returns an array of Programme records') and includes the behavior of listing 'available to join' programmes. However, it does not mention whether the operation is read-only, any auth requirements, pagination behavior, or potential side effects. This is a moderate level of disclosure, leaving important behavioral aspects unaddressed.

  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 three sentences, front-loaded with the core action, then provides usage triggers, and ends with output and related tools. Every sentence contributes meaningful information with no redundancy or fluff. It is efficiently structured for quick comprehension.

  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 description explains what the tool does, when to use it, and what it returns, which is adequate for a simple list operation. However, given the complexity of six parameters with no documentation, no output schema, and no annotations, the description is incomplete for advanced usage. It lacks details on pagination, filtering, and the structure of 'Programme records', leaving meaningful gaps for an agent to invoke the tool correctly in nuanced scenarios.

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

  Parameters2/5

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

  The schema contains six parameters (limit, cursor, offset, search, status, categories) with zero descriptions (schema description coverage 0%). The description does not explain any parameter semantics, such as how to paginate, format filters, or what values 'status' and 'categories' accept. The names are somewhat self-explanatory, but without explicit guidance, an agent cannot reliably construct correct queries. The description adds no parameter value, thus failing to compensate for the schema's lack of detail.

  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 tool's purpose: 'List affiliate programmes the publisher has joined on eHUB (or which are available to join).' It identifies a specific verb (list), a resource (affiliate programmes on eHUB), and the scope (joined or available). This distinguishes it from sibling tools by network (eHUB) and clarifies the primary function.

  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 explicit usage context: 'Use this when the user asks "which merchants am I working with?", "what programmes do I have on eHUB?", or wants a partner inventory.' It also suggests complementary tools ('pairs naturally with get_programme for drill-down and list_transactions for activity'). However, it does not state when not to use the tool or explicitly contrast it with alternatives, so it falls short of a 5.

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

• affiliate_everflow-advertiser_generate_tracking_linkA
  3.8/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 the return type ('Returns a TrackingLink') and implies the outcome of generating a link. However, it does not mention side effects, authentication requirements, or potential errors. The tip about confirming programmeId hints at a validation dependency but does not elaborate.

  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 three sentences with no unnecessary verbiage. It front-loads the core action, then adds usage context, and ends with a practical tip. Each sentence earns its place and contributes clear value.

  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 simple generation tool, the description covers its purpose and usage well, and the output type is stated. However, it omits the 'brand' parameter entirely and provides no detail on the TrackingLink format or any prerequisites beyond confirming programmeId. Given the lack of schema descriptions and annotations, this is a noticeable gap in completeness.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate for missing parameter documentation. It addresses programmeId and destinationUrl implicitly as inputs, but the 'brand' parameter is never mentioned or explained. With three required parameters and no schema descriptions, leaving one fully unexplained is a significant gap.

  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 tool's function: generating a tracking link on Everflow (Advertiser) using a given programme and destination URL. It distinguishes itself from sibling tools by explicitly naming the Everflow (Advertiser) platform and the use case of sharing an affiliate link to a specific product or page.

  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 explicitly states when to use it: when the user wants to share an affiliate link to a product or page on a merchant they have joined. It also provides a concrete recommendation to pair with list_programmes to confirm the programmeId before calling. It does not explicitly mention when not to use it, but the use case is clear and distinct.

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

• affiliate_everflow-advertiser_list_media_partnersA
  3.8/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 like returning 'MediaPartner records with normalised status' and describes an 'outbound roster', but it omits details such as pagination behavior, default limits, or authentication requirements. This is some value but not comprehensive.

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

  Conciseness5/5

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

  Three focused sentences: purpose, usage triggers, and return/pairing. The description is front-loaded with the key action, contains no fluff, and every sentence earns its place.

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

  Completeness3/5

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

  The description covers purpose and usage well and hints at output format, but given the absence of output schema, annotations, and schema parameter descriptions, it leaves parameter semantics and pagination behavior under-specified. It is adequate for tool selection but not fully complete for invocation.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It only implicitly references 'brand' (via 'brand's programme') and hints at 'status' through 'normalised status', but limit, cursor, offset, and search are entirely unexplained. This leaves a significant gap for a tool with 6 parameters.

  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 opens with a specific verb and resource: 'List the media partners (publishers) running on the brand's programme at Everflow (Advertiser).' This clearly distinguishes it from siblings like list_programmes or get_programme_performance. It also provides example user queries, reinforcing the tool's exact scope.

  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 explicitly states when to use the tool: 'Use this when the user asks...' and gives concrete query phrasings. It also recommends pairing with get_programme_performance for per-publisher performance. However, it does not explicitly mention when not to use it or alternative tools for other needs.

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

• affiliate_firstpromoter_generate_tracking_linkA
  3.8/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 disclosure. It does state the return type and a prerequisite (confirming programmeId), but it doesn't clarify side effects, authentication needs, or whether this call persists anything. The added context is useful but not comprehensive, so a 3 reflects that it goes beyond a bare statement but still lacks key behavioral traits.

  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, front-loaded with the core action, and includes only relevant usage and workflow guidance. No filler or redundant phrasing.

  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?

  This is a low-complexity tool with 3 required params, no annotations, and no output schema. The description covers the primary purpose, usage scenario, return type, and a helpful prerequisite, but it misses brand parameter meaning and any behavioral caveats. For a simple tool it is mostly adequate but has clear gaps.

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

  Parameters2/5

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

  The schema has no descriptions (0% coverage), so the description must compensate. It explains 'programme' and 'destination URL' in prose, which maps to programmeId and destinationUrl, but the required 'brand' parameter is entirely unexplained. The pairing advice adds meaning for programmeId, but the overall compensation is incomplete with one of three params unaddressed.

  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 'Generate a tracking link on FirstPromoter for a given programme and destination URL,' identifying the action, resource, and inputs. It also specifies the return type ('Returns a TrackingLink') and distinguishes itself from sibling tools by naming FirstPromoter. This is a specific, non-tautological description.

  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?

  It explicitly says 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined,' providing a clear trigger scenario. It also advises pairing with list_programmes to confirm the programmeId, which is an actionable alternative/companion guideline, though it doesn't explicitly list when-not-to-use cases.

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

• affiliate_flipkart_list_transactionsA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It discloses that it returns Transaction records with a derived ageDays field, implying a read-only list operation. However, it does not mention pagination behavior, auth requirements, rate limits, or what happens when no records match, which are important for a 9-parameter list 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 three sentences, front-loaded with the primary purpose, and every sentence adds value: purpose, usage examples, and return details/pairing. There is no redundant fluff or repetition of schema/name.

  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 description covers the core purpose, use cases, and return value (Transaction records with ageDays). It also suggests a complementary tool. However, it lacks details on pagination (cursor/limit), age-based filtering (maxAgeDays/minAgeDays), and how to handle large result sets, which are relevant for a list operation with no output schema or annotations.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It hints at date range (window), programme filtering, and statuses (pending, reversed, paid), which map to some parameters like to/from, programmeId, and status. However, it does not explain limit, cursor, offset, maxAgeDays, or minAgeDays, leaving the majority of parameters undocumented. This is a significant gap for a tool with 9 parameters.

  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 ('List') and resource ('affiliate transactions') on Flipkart Affiliate, and explicitly names the transaction statuses (commissions earned, pending, reversed, or paid). It distinguishes from sibling tools like list_clicks and get_earnings_summary by focusing on transaction records, and the tool name includes 'flipkart' to differentiate from other networks.

  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 concrete user query examples ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and clearly indicates the tool's scope (within a window or for a specific programme). It also suggests pairing with get_earnings_summary for aggregate totals, but does not explicitly mention when NOT to use it (e.g., for clicks) or name alternative tools for similar purposes.

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

• affiliate_growsurf_generate_tracking_linkA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It states the return type (TrackingLink) and a precondition (confirm programmeId via list_programmes), but it does not disclose whether the operation mutates state, requires auth, or what error behavior to expect. This is moderate transparency for a link generation 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 concise, containing three sentences that each add value: what it does, when to use, and a return/precondition hint. It is well-structured and free of fluff.

  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 simple generation tool, the description covers the core purpose, usage, and return type. However, with no output schema and a required 'brand' parameter left unexplained, plus no detail on error behavior or the TrackingLink structure, it is not fully complete. It 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.

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate. It partially covers programmeId (by advising to confirm via list_programmes) and destinationUrl (implied by 'destination URL'), but it does not explain the 'brand' parameter at all, which is required and otherwise undocumented. This leaves a significant semantic gap.

  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 tool generates a tracking link on GrowSurf for a given programme and destination URL. It uses a specific verb (generate) and resource (tracking link), and the GrowSurf network name distinguishes it from siblings.

  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?

  It provides explicit when-to-use guidance: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also recommends pairing with list_programmes to confirm the programmeId, which gives a usage hint. However, it does not explicitly state when not to use the tool or mention alternatives for other networks.

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

• affiliate_hotmart_list_clicksA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It notes data recency ('recent'), optional filters, and that it returns Click records. However, it does not explain pagination behavior, date range semantics, or authentication requirements, which are important for a no-annotation 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?

  Three short sentences front-load the purpose, then provide use case and return type. Every sentence adds value; no redundancy or fluff.

  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 description covers primary purpose and use cases but omits important operational details: pagination, date formats, and the shape of Click records (no output schema). For a 6-param tool with no annotations, this is adequate but not complete.

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

  Parameters2/5

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

  The schema has 6 parameters with zero descriptions. The description only clarifies that filtering by 'programme' and 'date' is possible, mapping to programmeId and to/from. It does not explain limit/cursor/offset, despite these being standard pagination names. The description only partially compensates for the 0% 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 clearly states it lists recent affiliate clicks on Hotmart, optionally filtered by programme and date. It names the specific resource (affiliate clicks) and platform, distinguishing it from transactions and other Hotmart 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?

  It explicitly provides use cases for traffic-side debugging with example questions, and recommends pairing with list_transactions to compare clicks vs conversions. It lacks an explicit 'when not to use' statement, but the guidance is clear and actionable.

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

• affiliate_impact-advertiser_generate_tracking_linkA
  3.8/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 does reveal the return type ('Returns a TrackingLink') and hints at a precautionary step (confirming programmeId), which is useful. However, it does not mention authentication requirements, potential side effects, failure modes, or rate limits, leaving a noticeable gap for a tool with no annotation support.

  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 three concise sentences with no wasted words. It front-loads the main action, then provides usage context, and finally a return type plus a practical pairing hint. Every sentence 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.

  Completeness3/5

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

  Given the tool has 3 required parameters, no output schema, and no annotations, the description is adequate but not complete. It covers the return type, usage context, and a validation tip, but the unexplained 'brand' parameter and lack of behavioral details (auth, errors) leave clear gaps. It is a minimum-viable description for a simple generator tool.

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

  Parameters2/5

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

  The schema description coverage is 0%, so the description must compensate for all three parameters. It indirectly explains 'programmeId' and 'destinationUrl' via 'given programme and destination URL' and the note about confirming programmeId, but it completely omits 'brand'—a required parameter. This leaves the agent uncertain about what value to supply for 'brand', making the description insufficient for correct invocation.

  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 action: 'Generate a tracking link on Impact (advertiser) for a given programme and destination URL.' This is a specific verb+resource combination that distinguishes the tool from other generate_tracking_link siblings by specifying the network (Impact) and role (advertiser).

  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 a clear when-to-use instruction: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also includes a practical prerequisite: 'pair with list_programmes to confirm the programmeId before calling.' However, it does not explicitly state when not to use this tool or name alternative tools, so it falls short of a 5.

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

• affiliate_impact_list_transactionsA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the transparency burden. It discloses that results are Transaction records with a derived ageDays field and that filtering is by window or programme. It does not mention pagination behavior, authentication requirements, rate limits, or any error handling, which would improve transparency for a 9-parameter 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?

  Three sentences, front-loaded with the action, followed by concrete use cases and a pointer to the summary tool. No redundant information or filler.

  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 one-network list tool with 9 optional parameters and no output schema, the description gives enough purpose and usage context to select the tool, and it names the output type. But it omits pagination details (cursor/offset/limit), parameter semantics for the age filters, and any response structure, so agents may mis-specify filters.

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

  Parameters2/5

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

  The input schema has 0% parameter description coverage. The description helps with some parameters: 'within a window' implies the to/from pair, 'specific programme' implies programmeId, and the listed statuses (pending, reversed, paid) map to status. However limit, cursor, offset, maxAgeDays, minAgeDays are left unexplained, and the derived ageDays hint doesn't clarify the min/max age filter semantics.

  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 opens with 'List affiliate transactions (commissions earned, pending, reversed, or paid) on Impact within a window or for a specific programme.' This provides a specific verb, resource, and scope, and names the network. It also distinguishes from related listing tools by focusing on transactions and referencing get_earnings_summary for aggregates.

  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?

  It provides explicit natural-language triggers: 'Use this when the user asks "what did I earn last month?", "what's still pending?", or "show me reversed sales".' It also points to get_earnings_summary as a companion for aggregate totals, giving an alternative. However it doesn't explicitly state when to use the alternative instead of this tool.

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

• affiliate_involve-asia_list_programmesA
  3.8/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 transparency burden. It conveys that the tool returns an array of Programme records and hints at both joined and available programmes, but it does not disclose pagination behavior, filtering semantics, or whether authentication is required. This is adequate but leaves several behavioral aspects unstated.

  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 compact and well-structured: a single purpose sentence, followed by usage examples and complementary tool references. Every clause earns its place, with no redundancy or filler. It is front-loaded with the action and network, making it easy to scan.

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

  Completeness3/5

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

  The tool has six optional parameters, no output schema, and no annotations, so the description must cover a lot. It covers purpose, example queries, return type, and relationships to related tools, but it omits parameter semantics, pagination, and clarity on the 'available to join' ambiguity. The description is sufficient for a basic understanding but leaves notable gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate by explaining the parameters. It does not mention any of the six parameters (limit, cursor, offset, search, status, categories) or how they might be used. The description adds no semantic meaning beyond the bare schema, failing to bridge the coverage gap.

  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 clear, specific action: 'List affiliate programmes the publisher has joined on Involve Asia (or which are available to join).' It names the exact network, distinguishes the tool from sibling list_programmes for other networks, and clarifies scope (joined vs. available). It also differentiates from get_programme and list_transactions by mentioning pairing, making sibling differentiation explicit.

  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 concrete example user queries ('which merchants am I working with?', 'what programmes do I have on Involve Asia?') and pairs the tool with get_programme and list_transactions, offering clear context for when to use it. It lacks an explicit 'when not to use' or direct comparison to alternative list tools, so it stops short of a 5.

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

• affiliate_kwanko-advertiser_generate_tracking_linkA
  3.8/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 notes that the tool 'Returns a TrackingLink' and implies a prerequisite (valid programmeId). However, it does not disclose potential error conditions, authentication requirements, or side effects (e.g., whether the link is saved/created server-side). For a simple link-generation action, this is adequate but not rich.

  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 three sentences, front-loaded with the primary action in the first sentence. Every sentence earns its place: purpose, usage context, return type, and a workflow hint. No redundant or vague filler.

  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 3-param tool with no output schema and no annotations, the description covers the core purpose, when to use, return type, and a prerequisite step. However, it leaves the 'brand' parameter undefined and does not mention error handling or any required authentication. This makes it usable but not fully self-sufficient.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It adds meaning for 'programmeId' (via 'programme' and 'confirm the programmeId') and 'destinationUrl' (via 'destination URL'), but the 'brand' parameter is entirely unexplained. No formats, defaults, or examples are given, leaving a significant gap for one required parameter.

  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 tool's function: 'Generate a tracking link on Kwanko (advertiser) for a given programme and destination URL.' The verb 'generate' plus the resource 'tracking link' and the network context ('Kwanko (advertiser)') make it specific and distinguish it from sibling tools for other networks or the non-advertiser Kwanko variant. The use case sentence reinforces the purpose.

  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 explicitly states when to use it: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also provides a workflow tip: 'pair with list_programmes to confirm the programmeId before calling.' However, it does not explicitly name alternatives or exclusions, such as the non-advertiser Kwanko generate_tracking_link variant.

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

• affiliate_kwanko-advertiser_list_media_partnersA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that the tool returns MediaPartner records with normalised status, which is useful behavioral context. However, it omits details on pagination, filtering behavior, or any operational constraints, leaving 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 three sentences, each add value: the core purpose, example triggers, and return type with cross-tool pairing. It is front-loaded and free of 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?

  For a tool with 6 parameters, no output schema, and no annotations, the description provides solid usage context and return type but is incomplete for parameter construction. It does not explain the optional parameters or pagination, so an agent would need external knowledge to invoke it fully.

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

  Parameters1/5

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

  Schema description coverage is 0%, and the description provides almost no parameter-level guidance. It mentions the brand's programme but does not explain the brand parameter, nor does it describe limit, cursor, offset, search, or status. The agent is left without meaning for any parameter beyond the implied brand context.

  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 tool's function: listing media partners (publishers) on the brand's Kwanko programme. It includes specific example user queries and distinguishes itself from the related get_programme_performance tool, making its 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 Guidelines5/5

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

  Explicit when-to-use guidance is provided via example queries ('who is promoting us on Kwanko (advertiser)?', 'which publishers are active on our programme?'). It also directs pairing with get_programme_performance for per-publisher performance, effectively indicating an alternative tool for that use case.

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

• affiliate_leaddyno_list_transactionsA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral burden. It discloses that the tool returns Transaction records including derived ageDays, and mentions scoping (window/programme). However, it doesn't explicitly state pagination behavior, authentication requirements, or that it's a read-only operation. The verb 'list' implies non-mutating, but richer disclosure would be better.

  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, front-loaded with the action and scope, then gives usage examples, return information, and a pairing recommendation. Every sentence earns its place with 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 tool's complexity (10 params, no annotations, no output schema), the description provides purpose, usage triggers, and return shape, but omits parameter semantics, pagination behavior, and an explicit list of valid status values. It is sufficient for tool selection but may not fully support autonomous invocation without inspecting the schema.

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

  Parameters2/5

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

  The schema has 10 parameters with no descriptions (0% coverage). The description hints at 'within a window' (from/to), 'specific programme' (programmeId), and statuses (status), but it does not explain brand, limit, cursor, offset, minAgeDays, or maxAgeDays. For a 10-parameter tool, this is insufficient compensation for the low 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 ('List'), names the resource ('affiliate transactions'), enumerates the statuses (earned, pending, reversed, paid), identifies the platform (LeadDyno), and states the scoping options (within a window or for a specific programme). This clearly differentiates it from sibling tools for other networks and from get_earnings_summary.

  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 explicit usage triggers: "Use this when the user asks 'what did I earn last month?', 'what's still pending?', or 'show me reversed sales'". It also recommends pairing with get_earnings_summary for aggregate totals. It doesn't explicitly name exclusions among the many sibling list_transactions tools, but the network-specific name and triggers make the context clear.

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

• affiliate_levanta_generate_tracking_linkA
  3.8/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 transparency burden. It discloses the return type ('Returns a TrackingLink') and implies a prerequisite (programmeId must be confirmed via list_programmes). However, it omits auth requirements, error behavior, side effects, and rate limits, which are relevant for a tool call.

  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 three sentences, front-loaded with the core action, and every sentence provides useful information. There is no fluff 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?

  The tool is simple with only 2 required params and no output schema. The description covers purpose, when to use, return type, and a prerequisite, which is good. However, the lack of parameter-level detail and any network-specific caveats prevents it from being fully complete.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It mentions 'programme and destination URL', which essentially restates the parameter names without adding constraints, formats, or examples. The only added semantic is the hint to confirm programmeId via list_programmes, which is minimal.

  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 action: 'Generate a tracking link on Levanta for a given programme and destination URL.' It uses a specific verb and resource, and explicitly names Levanta, distinguishing it from the many sibling generate_tracking_link tools for other networks.

  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?

  Provides clear context: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to confirm the programmeId, but does not explicitly state when not to use this tool or list alternative networks.

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

• affiliate_netrefer_list_clicksA
  3.8/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 burden of behavioral disclosure. It correctly implies a read-only operation via 'List' and notes that it returns Click records. However, it omits details on pagination behavior, the definition of 'recent', and any rate limits or auth requirements. These are useful behavioral traits not disclosed.

  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 concise, consisting of two sentences that front-load the main purpose. The example debugging questions and the pairing with list_transactions add meaningful context without unnecessary fluff. Every sentence earns its place.

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

  Completeness3/5

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

  Given the tool's complexity (6 optional parameters, no output schema, no annotations), the description covers the core purpose, use case, and return type. However, it lacks details on parameter formats, pagination expectations, and exact response structure, which are important for correct invocation. It is adequate but not fully complete.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It mentions 'optionally filtered by programme and date', which hints at programmeId and from/to parameters, but it does not explain limit, cursor, or offset. With 6 parameters and no schema descriptions, this partial coverage leaves significant ambiguity for pagination and other controls.

  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 tool lists recent affiliate clicks on NetRefer, with optional filters by programme and date. It distinguishes itself from siblings by specifying the resource (clicks) and network (NetRefer), and explicitly mentions returning Click records, setting it apart from transaction-focused 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 provides clear usage context: 'Use this for traffic-side debugging' with concrete examples like 'are my links being clicked at all?' It also recommends pairing with list_transactions to compare clicks vs conversions, which guides complementary use. However, it does not explicitly state when not to use this tool or name alternatives like list_transactions as a replacement.

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

• affiliate_offer18_list_programmesA
  3.8/5.0
  Behavior3/5

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

  No annotations are present, so the description must disclose behavioral traits itself. It mentions that the tool returns 'an array of Programme records' and covers joined/available programmes, but does not explain pagination, authentication needs, or how 'available to join' is determined. This is some transparency but not comprehensive.

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

  Conciseness5/5

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

  The three sentences are compact and front-loaded, covering purpose, usage triggers, and return/companion info without redundancy. Each sentence earns its place, making it an appropriately sized description.

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

  Completeness3/5

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

  The tool has six optional parameters, no output schema, and no annotations, but the description omits parameter semantics, pagination behavior, and authentication context (notably a sibling verify_auth tool exists). While the purpose is clear, the description is incomplete for the tool's complexity.

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

  Parameters2/5

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

  With 0% schema description coverage and six parameters, the description needed to explain parameter meanings but does not. It only gives the tool's purpose and never mentions limit, cursor, offset, search, status, or categories. The schema alone provides names/types but no semantics, so the description adds no parameter value.

  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 'List affiliate programmes the publisher has joined on Offer18 (or which are available to join)', providing a specific verb and resource scope. It includes example user queries that clarify intent, and the mention of 'Offer18' distinguishes it from sibling list_programmes tools for other networks.

  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 explicit trigger phrases ('which merchants am I working with?', 'what programmes do I have on Offer18?', 'wants a partner inventory') and identifies companion tools (get_programme, list_transactions). It lacks explicit 'when not to use' exclusions, but the network-specific scope serves as implicit guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_optimise-media_get_earnings_summaryA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description must carry the burden of behavioral disclosure. It does mention the return type (EarningsSummary) and a specific field (oldestUnpaidAgeDays), which adds value. However, it doesn't state whether the operation is read-only, how date windows are handled, or any pagination/side-effect behavior, leaving gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences with a clear front-loaded purpose, usage guidance, and return-value note. It is tight and each sentence earns its place, though one additional clause about age filters could improve it without being verbose.

  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?

  With 8 parameters, no schema descriptions, and no output schema, the description leaves significant gaps. It doesn't document pagination or age filters, doesn't explain default ranges, and only mentions one return field. While it provides purpose and usage, it is not complete for an agent to correctly invoke the tool with all options.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It implicitly covers the date window (from/to), programmeId, and status, but gives no explanation for limit, cursor, maxAgeDays, or minAgeDays. The output mention of oldestUnpaidAgeDays does not illuminate these input parameters.

  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 tool summarises earnings on Optimise Media across a date window, with breakdowns by programme and transaction status. This distinguishes it from other network-specific earnings summary tools and from list_transactions, which is explicitly positioned as the drill-down companion.

  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?

  It explicitly says 'Use this when the user wants a single-figure answer plus context' and gives a concrete example. It also names list_transactions as the tool to pair with for underlying records, providing clear guidance on when to use this tool versus an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerize-advertiser_verify_authA
  3.8/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. It discloses that the tool calls a minimal authenticated endpoint, returns a structured response ({ok:true, identity?} or {ok:false, reason}), and implies non-mutating behavior through 'verify'. This gives a clear behavioral profile, though it doesn't explicitly state side-effect freeness or permission requirements.

  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, front-loaded with the main purpose, followed by usage timing and return values. Every sentence earns its place, and there is no redundant or vague content.

  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 description covers purpose, when to use, return shape, and a related tool, which is good for a minimal verification tool. However, the total omission of the sole 'brand' parameter leaves a significant gap: the agent cannot invoke the tool correctly without understanding what 'brand' means. The lack of an output schema is partially mitigated by the inline return description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single required parameter 'brand' is completely unexplained in both the description and the schema (schema coverage 0%). The description does not mention 'brand' at all, so an agent has no basis to know what values are valid or what the parameter refers to, which is a critical gap for a tool with only one parameter.

  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 the specific verb 'Verify' and clearly identifies the resource as 'configured credentials for Partnerize (Advertiser)'. It also explains the method ('calling a minimal authenticated endpoint') and distinguishes itself from siblings by naming the network and advertiser variant, which is reinforced by 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 explicitly states when to use the tool: at the start of a session, after rotating keys, or when another operation returns an auth error. It also suggests pairing with affiliate_run_diagnostic for a full health check, which serves as an alternative/companion. However, it does not explicitly differentiate when to use this over the non-advertiser sibling affiliate_partnerize_verify_auth.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnero_generate_tracking_linkA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of disclosing behavior. It does reveal the return type ('Returns a TrackingLink') and the dependency on confirming programmeId via list_programmes, which is useful. However, it does not mention potential side effects, error conditions, authentication requirements, or whether the link generation is stateless or persists anything. This is moderate transparency but not rich.

  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 three sentences, front-loaded with the purpose, then usage guidance, then return/prerequisite. Every sentence adds useful information without fluff or repetition. It is concise 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?

  The tool is simple (three string params, no output schema), and the description covers purpose, return type, and a prerequisite. However, it lacks explanation of the 'brand' parameter and does not describe the TrackingLink structure or any failure modes. For a straightforward tool, this is adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must explain all parameters. It does give context for programmeId and destinationUrl (programme and destination URL), and the pairing hint clarifies programmeId. But the 'brand' parameter is never mentioned or explained, leaving a required field ambiguous. This is a clear gap in parameter semantics.

  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 tool's action ('Generate a tracking link on Partnero') and its key inputs (programme and destination URL). It distinguishes itself from sibling generate_tracking_link tools by explicitly naming Partnero, and the return type is mentioned. This is a specific, unambiguous statement of purpose.

  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 use case: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also recommends pairing with list_programmes to confirm the programmeId, which is practical guidance. However, it does not explicitly state when not to use this tool versus alternatives for other networks, so it stops short of a full when/when-not breakdown.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnero_get_programme_performanceA
  3.8/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 mentions the return type (ProgrammePerformanceRow records) and metrics, but does not disclose behavior around pagination (cursor/offset), date formats, filtering defaults, or any preconditions or side effects. For a read operation it's adequate but not deep.

  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, front-loaded with the core purpose, then usage examples, then output type and related tools. Every sentence adds value and there is no wasted wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 8 parameters, no annotations, and no output schema, the description provides moderate context: use cases, related tools, and output record type. However, it lacks parameter semantics, pagination details, and a fuller explanation of the return structure, leaving an agent with gaps for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only hints at date filtering ('by date') and publisher IDs (via list_media_partners). It does not explain the required 'brand' parameter, nor programmeId, limit, cursor, offset, or the format of from/to. With 8 parameters, this is a significant gap that the description does not compensate for.

  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 tool fetches per-publisher performance for a Partnero programme, listing specific metrics (clicks, conversions, gross sale, commission) and date-scoping. This distinguishes it from siblings like get_programme or list_transactions, and the verb 'fetch' + resource 'per-publisher performance' is specific.

  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?

  It provides explicit example user queries ('how is each publisher performing on Partnero?', 'show me the top-earning partners last month') and says to pair with list_media_partners for publisher IDs and list_transactions for drill-down. This gives clear when-to-use context, though it doesn't explicitly state when not to use or name alternative aggregate tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnero_list_clicksA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  There are no annotations, so the description carries the full burden. It discloses that the tool returns Click records and can be filtered, and suggests a read-only list operation. However, it does not mention pagination behavior, date format, required brand parameter, or any potential side effects or authentication needs. This is adequate but has clear 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?

  The description is three sentences long, front-loaded with the core purpose, then usage guidance, then return/alternative. Every sentence adds value, and there is no filler or repetition. It is appropriately concise and 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?

  The tool has 7 parameters, 1 required, no output schema, and no annotations. The description covers the main use case and mentions returns, but it leaves out the meaning of the required `brand` parameter and how pagination works. It also does not elaborate on the structure of Click records. Given the moderate complexity and lack of schema descriptions, the description is helpful but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for the 7 parameters. It only briefly mentions 'optionally filtered by programme and date', which partially explains `programmeId` and `from`/`to`, but it does not explain the required `brand` parameter or the pagination params (`limit`, `cursor`, `offset`). This is a significant gap in parameter understanding.

  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 clear action and resource: 'List recent affiliate clicks on Partnero'. It distinguishes from siblings by specifying the network (Partnero) and the object type (clicks), and provides concrete usage examples. This clearly differentiates it from list_transactions and other network-specific 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 explicitly says 'Use this for traffic-side debugging' and gives example questions, which tells when to use it. It also points to a complementary tool: 'pair with list_transactions to compare clicks vs conversions.' However, it doesn't explicitly state when not to use it, so it stops short of a full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerstack-advertiser_list_clicksA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry the burden. It states it returns Click records and mentions optional filters, but lacks details on pagination (cursor/offset/limit), default date range, and required brand. The read-only nature is implied by 'List', but more behavioral context would improve clarity.

  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?

  Two sentences efficiently front-load the action and filters, then provide concrete use cases and return type. There is no filler or redundant information.

  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 description gives a clear high-level purpose and return type, sufficient for selecting the tool, but lacks parameter detail (especially required brand) and pagination behavior. The absence of an output schema makes the minimal 'Click records' return statement less complete, though the pairing suggestion adds valuable context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only mentions 'programme and date' filters, leaving brand, limit, cursor, and offset unexplained. The required 'brand' parameter is not mentioned, which is a significant gap for correct invocation.

  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 tool 'List recent affiliate clicks on PartnerStack (advertiser), optionally filtered by programme and date', providing a specific verb, resource, and scope. The '(advertiser)' suffix and traffic-side context distinguish it from sibling list_clicks 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?

  It gives explicit use cases for traffic-side debugging with example questions and suggests pairing with list_transactions to compare clicks vs conversions. However, it does not mention alternatives like the non-advertiser PartnerStack variant, so exclusions are implicit rather than explicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_pepperjam_list_transactionsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations exist, so the description carries the burden. It does disclose that the tool returns Transaction records including a derived ageDays field, which is useful. However, it omits any discussion of pagination, rate limits, authentication expectations, or how multiple filters interact (e.g., whether status accepts an array of values). For a read-only list tool, the disclosure is adequate but not thorough.

  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 three concise sentences. The first front-loads the core purpose, the second provides actionable usage examples, and the third mentions key return information and a useful sibling. Every sentence contributes value with no redundancy or fluff.

  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 tool with 9 parameters, no annotations, and no output schema, the description gives a solid high-level overview but lacks detailed parameter guidance, filtering combinations (e.g., status as array), pagination behavior, and any caveats about data retention or default time windows. It is sufficient for a simple use case but incomplete for complex or nuanced requests.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for all 9 parameters. It only vaguely references 'window' and 'programme' and lists status values without mapping them to the actual from/to/status/programmeId parameters. It does not explain limit, cursor, offset, or min/maxAgeDays semantics. This leaves significant ambiguity for an agent trying to construct valid arguments.

  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?

  Clearly states the tool lists affiliate transactions on Pepperjam with status categories (earned, pending, reversed, or paid) and supports filtering by time window or programme. The mention of pairing with get_earnings_summary distinguishes it from a sibling tool, and the name itself disambiguates from other networks.

  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?

  Explicitly gives example user queries ('what did I earn last month?', 'what's still pending?') and recommends pairing with get_earnings_summary for aggregate totals. However, it does not explicitly state when not to use this tool (e.g., for click data) or contrast with other transaction-list tools beyond the summary, so it falls just short of full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_post-affiliate-pro_verify_authA
  3.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description discloses the call's nature (minimal authenticated endpoint), return shape ({ok:true, identity?} or {ok:false, reason}), and complementary diagnostic tool. This adds valuable behavioral context beyond the bare 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 only two sentences—one for purpose and one for usage—with no wasted words. It is front-loaded with the primary action and provides operational guidance efficiently.

  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 description covers purpose, use cases, and return values thoroughly, but completely omits the required 'brand' parameter. Given the schema provides no description, this is a significant gap that prevents the agent from using the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The sole required parameter 'brand' has no schema description and the description does not mention it at all. With 0% schema coverage, the agent is left without any guidance on what value to provide for this required parameter.

  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 tool verifies configured credentials for Post Affiliate Pro via a minimal authenticated endpoint. This is a specific verb+resource that distinguishes it from other network-specific verify_auth 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?

  Explicitly describes when to use: at the start of a session, after rotating keys, or when another operation returns an auth error. It also suggests pairing with affiliate_run_diagnostic for a full health check, though it does not explicitly state when not to use the tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_refersion_list_media_partnersA
  3.8/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 does disclose that the tool returns 'MediaPartner records with normalised status,' which is useful context. However, it does not mention whether this is a safe read operation, authentication requirements, rate limits, pagination behavior, or any side effects. For a simple list tool, the return-type disclosure is meaningful, but the lack of safety/pagination detail keeps it at a mid score.

  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 three sentences with no filler: it fronts the action, gives usage examples, and then states return type and a pairing recommendation. Every sentence earns its place and the structure is easy to scan.

  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 output schema, the description correctly mentions the return type ('MediaPartner records with normalised status') and adds a complementary tool reference. However, it does not explain the six parameters in the schema, nor pagination/cursor behavior, leaving gaps for a 6-parameter list tool. The description is adequate for basic invocation but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must explain parameters to compensate. It does not. The parameters brand, limit, cursor, offset, search, and status are only given by name; the description doesn't specify that brand is required, what format it should take, or how search/status filters behave. The names are somewhat self-evident, but without explicit semantics the agent may fail to construct valid calls.

  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 opens with a specific action and resource: 'List the media partners (publishers) running on the brand's programme at Refersion.' It provides concrete user-phrase examples ('who is promoting us on Refersion?') and clearly distinguishes this from general list tools by naming Refersion and media partners. This fully clarifies what the tool does and differentiates it from siblings.

  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?

  It explicitly states when to use this tool with example queries ('Use this when the user asks...') and names a complementary tool ('pair with the matching get_programme_performance tool'). It does not explicitly say when NOT to use it (e.g., other networks), but the Refersion-specific context and pairing direction provide strong usage guidance. A small exclusion note would make it a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_refersion_list_transactionsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses that it returns Transaction records including derived ageDays, but does not explicitly state read-only behavior, auth requirements, pagination, or rate limits. The listing nature implies safety but lacks explicit detail.

  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 three sentences, front-loaded with the primary action, and each sentence adds value: action/scope, usage examples, and return/pairing info. Slightly detailed but not excessive.

  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 complexity (10 params, no output schema, no annotations), the description should explain more. It covers usage and return but lacks parameter meanings, pagination details, required field clarification, and response structure beyond 'Transaction records including ageDays'.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate for 10 parameters. It mentions window (from/to), specific programme (programmeId), and statuses (status), but omits the required 'brand' parameter entirely and doesn't cover pagination (limit, cursor, offset) or age filters (minAgeDays/maxAgeDays).

  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 it lists affiliate transactions on Refersion, specifies statuses (earned, pending, reversed, paid), and scopes to a time window or specific programme. It distinguishes itself from siblings by naming Refersion and pairing with get_earnings_summary for aggregates.

  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?

  Explicit usage examples are provided ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and the description guides toward get_earnings_summary for aggregate totals, setting clear boundaries vs alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_rewardful_list_clicksA
  3.8/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 does state that the operation lists recent clicks (implying a read operation) and returns Click records, which is useful. However, it does not disclose pagination behavior, rate limits, date format expectations, or authentication requirements, leaving the agent with gaps in understanding the tool's runtime 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 three sentences: the first states the function, the second gives usage context with examples, and the third mentions the return type and a complementary tool. Each sentence adds unique value with no redundancy or fluff, and the key action is front-loaded.

  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 description covers the core purpose and return type, which is helpful. However, with 7 parameters, no annotations, no output schema, and no parameter descriptions, it leaves significant gaps around pagination, date semantics, and the required brand field. It is a reasonable baseline but not comprehensive enough for a tool with this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It mentions 'programme' and 'date' filters, which likely map to programmeId and from/to, but it does not explain the remaining pagination parameters (limit, cursor, offset) or the required brand parameter. The schema provides only names, not types or descriptions, so the agent cannot confidently construct correct calls for all parameters.

  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 opens with 'List recent affiliate clicks on Rewardful' which clearly identifies the action (list), resource (clicks), and platform (Rewardful), distinguishing it from sibling list_clicks tools for other networks. It further specifies optional filters for programme and date, making the purpose immediately unambiguous.

  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 explicitly states 'Use this for traffic-side debugging' with concrete diagnostic examples like 'are my links being clicked at all?' and 'where is traffic going on Rewardful?'. It also advises pairing with list_transactions to compare clicks vs conversions, offering clear usage context. However, it does not explicitly mention when not to use it or alternative list_clicks tools for other networks.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_scaleo_list_programmesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the full burden. It discloses the return type ('an array of Programme records') and the scope (joined or available to join). However, it omits pagination behavior (despite cursor/offset/limit params), auth requirements, and any side effects. This is adequate for a simple list operation but not richly transparent.

  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?

  Three sentences with front-loaded purpose, example queries, return type, and companion tool references. Every sentence contributes meaningfully, with no redundancy or filler.

  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 tool with 6 optional params and no output schema, the description covers purpose, usage examples, and return shape. It also mentions the joined/available distinction. However, it lacks parameter semantics and pagination details, leaving the agent under-informed for advanced filtering or paginated requests. Sufficient for tool selection but not full invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for missing parameter documentation. It does not explain any of the six parameters (limit, cursor, offset, search, status, categories). While the parameter names are somewhat self-explanatory, the description adds no semantic value beyond the schema fields.

  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 opens with a specific verb and resource: 'List affiliate programmes the publisher has joined on Scaleo (or which are available to join).' It clearly distinguishes from sibling list_programmes tools by naming Scaleo and clarifying scope (joined vs available). It also references companion tools (get_programme, list_transactions), further differentiating its role.

  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?

  Provides explicit example user queries ('which merchants am I working with?', 'what programmes do I have on Scaleo?') and suggests natural pairings with get_programme for drill-down and list_transactions for activity. It does not explicitly state when not to use the tool, but the context and examples make the intended usage clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_skimlinks_get_earnings_summaryA
  3.8/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 burden. It discloses the return type (EarningsSummary) and the presence of oldestUnpaidAgeDays, which gives useful behavioral context. However, it does not disclose any limitations, auth requirements, or whether the date range is mandatory, leaving some opacity for a non-annotated read 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 three concise sentences with the core purpose first, followed by usage context and return information. 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?

  For a summary tool with no output schema, the description provides good high-level context, including the return content and a companion tool. But the lack of parameter explanations and no mention of defaults or required fields makes it incomplete for correct invocation with 8 parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has zero descriptions for its 8 properties, and the description only implicitly covers from/to (date window), status (transaction status), and programmeId (programme). Parameters like limit, cursor, maxAgeDays, and minAgeDays remain unexplained, so the description does not compensate for the low 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 clearly states the tool summarizes Skimlinks earnings over a date range with breakdowns by programme and status, using the specific verb 'Summarise' and identifying the resource and scope. It also distinguishes this network-specific tool from the many sibling get_earnings_summary tools by naming Skimlinks.

  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?

  It explicitly says 'Use this when the user wants a single-figure answer plus context' and provides an example. It also instructs to 'pair with list_transactions to drill into the underlying records,' showing when a complementary tool is appropriate. It does not explicitly state when not to use the tool, but the guidance is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_skimlinks_list_clicksA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of behavioral disclosure. It mentions return type ('Click records') and optional filtering, but leaves 'recent' undefined and doesn't discuss auth requirements, pagination behavior, or default time windows.

  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: the first states the core purpose and filters, the second adds use-case context and a sibling-tool pairing. Every sentence provides value with no fluff.

  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 description is adequate for selecting the tool but incomplete for invocation: it lacks semantics for pagination parameters, leaves 'recent' vague, and there's no output schema to clarify the Click record structure. The use-case examples help, but key execution details are missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only clarifies programme and date filters (programmeId, from, to). The pagination parameters (limit, cursor, offset) are left entirely unexplained, which is a significant gap given the low 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 explicitly names the action 'List recent affiliate clicks on Skimlinks', identifies the resource, and mentions optional filters (programme and date). This distinguishes it from sibling tools like list_transactions and other network-specific list_clicks 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?

  It provides clear context by stating this is for 'traffic-side debugging' with concrete example questions, and explicitly recommends pairing with list_transactions. However, it doesn't mention when not to use this tool or list alternative tools beyond list_transactions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_sovrn-commerce_list_clicksA
  3.8/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. The word 'list' implies a read-only operation and 'recent' hints at time scoping, but it does not disclose pagination behavior, authentication needs, or rate limits. It is adequate but not rich in behavioral detail.

  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 three sentences, front-loaded with the purpose, then usage context, then return type. Every sentence earns its place and there is no redundancy or filler.

  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 description gives strong purpose and usage guidance, and mentions 'Returns Click records' as a return hint. However, with 6 parameters, no output schema, and no annotations, the agent lacks details on parameter formats, defaults, pagination, and the structure of Click records. The description is good but not fully complete for a tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for the 6 undocumented parameters. It only mentions filtering by 'programme and date' (likely programmeId and from/to), but it does not explain limit, cursor, offset, or their usage. This is a significant gap.

  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 it lists recent affiliate clicks on Sovrn Commerce with optional programme/date filters. The verb 'list' plus the specific resource 'recent affiliate clicks on Sovrn Commerce' makes the purpose unambiguous and distinguishes it from sibling list_clicks tools for other networks.

  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 explicitly frames when to use the tool: 'Use this for traffic-side debugging' with concrete example questions. It also recommends pairing with list_transactions to compare clicks vs conversions, giving helpful context. It does not explicitly state when not to use it, but the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_sovrn-commerce_list_transactionsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden for behavioral disclosure. It mentions that the tool returns Transaction records including derived ageDays and supports filtering by status and programme, but it does not disclose pagination behavior, side effects (likely none as it lists), or rate limits. This is adequate but lacks in-depth 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 concise and well-structured: the first sentence states purpose, the second gives concrete usage examples, and the third describes return type and a companion tool. No wasted words, and it is front-loaded with the most important information.

  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 (9 parameters, no output schema, no annotations), the description covers the primary use cases and return type but lacks critical details like date format, status allowed values, pagination behavior, and how ageDays filtering works. It is not fully complete for an agent to invoke correctly without further inference.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate for parameter meanings. It hints at 'window' (from/to), 'specific programme' (programmeId), and status examples (status), but does not explain limit, cursor, offset, minAgeDays, or maxAgeDays. With 9 parameters, this is insufficient to guide correct invocation.

  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 tool lists affiliate transactions on Sovrn Commerce, with specific mention of statuses (commissions earned, pending, reversed, or paid) and filtering by time window or programme. This distinguishes it from sibling list_transactions tools for other networks by naming the specific network and scope.

  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 explicit example user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') that indicate when to use the tool. It also guides pairing with get_earnings_summary for aggregate totals, which serves as an alternative for a different need, though it does not explicitly state when not 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.

• affiliate_tapfiliate_generate_tracking_linkA
  3.8/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 the return type ('Returns a TrackingLink') and hints at a prerequisite (confirm programmeId), but it does not mention authentication requirements (e.g., verify_auth sibling), whether the link is persistent, or any side effects. This is adequate but not rich, especially for a tool that creates an external resource.

  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 three sentences, front-loaded with the core action, and every sentence adds value: what it does, when to use it, and what it returns with a useful pairing tip. There is no redundancy or filler.

  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 relatively simple 3-parameter tool, the description covers the main action, usage context, and return type, but lacks parameter-level detail (especially 'brand') and does not advise checking authentication via the existing verify_auth sibling. Given the presence of many sibling generate_tracking_link tools, this is functional but not fully contextual.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does little to explain the parameters. It references 'programme and destination URL' which maps to programmeId and destinationUrl, but completely omits mention of the 'brand' parameter, its purpose, or acceptable values. This leaves a required parameter semantically unexplained.

  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 verb and resource: 'Generate a tracking link on Tapfiliate for a given programme and destination URL.' This distinguishes it from sibling tools like list_programmes or verify_auth, and the network name in the tool title (tapfiliate) is echoed in the description, making its specific 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly gives when to use it: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to confirm the programmeId, which adds actionable sequencing. However, it does not mention alternatives or exclusions, so it falls short of providing full when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tolt_generate_tracking_linkA
  3.8/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 behavioral burden. It discloses the return type (TrackingLink) and a prerequisite (confirm programmeId via list_programmes), but it does not clarify whether the operation has side effects, requires auth, or how errors are surfaced. This is minimal but non-tautological.

  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?

  Two sentences, front-loaded with the core action, and no filler. The return-type and pairing guidance are compact and earn their place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 3-parameter generation tool, the description provides a clear purpose, usage context, return type, and a helpful pairing hint. However, the missing 'brand' parameter explanation and lack of explicit alternatives or error behavior leave some gaps, especially given no annotations or output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It explains programme and destination URL but omits the third required parameter 'brand' entirely. It also doesn't provide formats or constraints for programmeId or destinationUrl beyond the schema's type declarations.

  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 opens with a specific action ('Generate a tracking link on Tolt') and names the key inputs (programme and destination URL). It clearly differentiates from the many sibling network-specific generate_tracking_link tools by specifying Tolt, and the use case for sharing affiliate links is explicit.

  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?

  It states when to use the tool ('when the user wants to share an affiliate link to a specific product or page on a merchant they have joined') and provides a preparatory step (pair with list_programmes to confirm programmeId). It doesn't explicitly exclude other networks, but the Tolt-specific naming makes the context clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tolt_get_earnings_summaryA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the burden. It discloses the return type EarningsSummary and mentions the oldestUnpaidAgeDays field, plus the read-only nature of summarization. However, it does not detail potential pagination, rate limits, or any side effects, leaving some behavioral aspects undisclosed.

  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 three sentences long, front-loaded with the main purpose, and includes a useful example and drill-down hint without any fluff. Every sentence adds value, from the summary definition to the return field mention to the pairing suggestion.

  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 9 parameters, no annotations, and no output schema, the description provides high-level context and one return field but leaves significant gaps: parameter semantics, default behavior, edge cases, and full response structure. It is minimally adequate for a simple summary tool but not rich enough for complex filtering scenarios.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not explain any of the 9 parameters. It vaguely alludes to a 'date window' and 'breakdowns by programme and status', but fails to define required brand or any filters like status, programmeId, maxAgeDays, or cursor. This leaves the agent to infer parameter meanings from names alone.

  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 tool summarizes earnings on Tolt with breakdowns by programme and transaction status. It uses specific verbs and resource scope, and the 'single-figure answer plus context' phrasing distinguishes it from transaction-level tools like list_transactions.

  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?

  Provides an explicit usage case: 'when the user wants a single-figure answer plus context' along with a concrete example. Also recommends pairing with list_transactions for deeper drill-down, which serves as guidance on alternatives. Does not explicitly state when not to use, but the guidance is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tolt_list_clicksA
  3.8/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 burden of behavioral disclosure. It states 'Returns Click records' and implies read-only behavior via 'List', but does not disclose pagination behavior, date range defaults, or whether auth is handled. The description adds context but lacks detail on important behavioral traits.

  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 three sentences, front-loaded with the main action, followed by concrete use cases and a pairing suggestion. No redundant information or fluff.

  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 7 parameters, no output schema, and no annotations, the description provides a reasonable overview of purpose and use case, but leaves gaps in parameter semantics and pagination. It is complete enough for tool selection but not fully for reliable invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It mentions 'filtered by programme and date', mapping to programmeId and from/to, but does not explain required brand, or pagination params (limit, cursor, offset). With 7 params and only partial coverage, the description is insufficient for correct invocation.

  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 tool lists recent affiliate clicks on Tolt, with optional filters. It uses a specific verb ('List') and resource ('affiliate clicks on Tolt'), distinguishes it from sibling tools for other networks, and includes concrete debugging examples like 'are my links being clicked at all?'.

  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?

  It explicitly says to use for traffic-side debugging and provides example questions. It also recommends pairing with list_transactions to compare clicks vs conversions, which is useful context. However, it does not explicitly say when not to use this tool or mention alternatives other than list_transactions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradedoubler_list_transactionsA
  3.8/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 burden of disclosing behavior. It adds useful context by stating that it returns Transaction records including a derived ageDays field. However, it does not mention pagination behavior (cursor/offset/limit), default time window, or any prerequisites such as authentication, which are relevant for safe and effective use.

  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, front-loaded with the core action and followed by concrete usage triggers and return-value context. Every clause serves a purpose with no redundancy or filler.

  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 description covers the primary use cases and return format, but given the tool has 9 parameters, no output schema, and no annotations, it leaves gaps in pagination semantics and full parameter behavior. It is serviceable for common 'what did I earn' queries but not fully complete for advanced filtering or large-result handling.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It does clarify the status and date-range/programme filtering concepts ('pending', 'reversed', 'paid', 'within a window', 'specific programme'), which partially maps to status, from/to, and programmeId. However, key parameters like limit, cursor, offset, minAgeDays, and maxAgeDays are not explained, leaving the agent without guidance on pagination and age-based filters.

  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 verb ('List'), the resource ('affiliate transactions'), and the network ('Tradedoubler'). It enumerates the statuses covered (earned, pending, reversed, paid) and the filtering dimensions (window or specific programme), distinguishing it from related sibling tools like list_clicks and get_earnings_summary.

  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 explicit user-intent triggers such as 'what did I earn last month?' and 'what's still pending?', which is strong usage guidance. It also recommends pairing with get_earnings_summary for aggregate totals, offering a complementary alternative. However, it does not explicitly state when not to use this tool (e.g., for clicks or aggregate-only queries), so it stops short of full exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradetracker_list_programmesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the behavioral transparency burden. It discloses that the tool returns 'an array of Programme records' and includes both joined and available-to-join programmes, which is useful. However, it does not mention pagination behavior, filtering semantics, authentication, or rate limits, leaving significant behavioral details undisclosed.

  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 three sentences, front-loaded with the core purpose, followed by usage guidance and related-tool pairings. There is no fluff; every sentence adds value.

  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 description adequately covers the tool's high-level purpose and return type, and suggests related tools for drill-down. However, with no output schema and no annotations, it lacks crucial invocation details such as parameter semantics, pagination, and filtering behavior, making it only partially complete for correct tool usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers 0% of parameter descriptions, and the description does not explain any of the six parameters (limit, cursor, offset, search, status, categories). It provides only high-level context about the result set (joined/available programmes), not meaning for any specific parameter, so it fails to compensate for the low 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 clearly identifies the tool's function: 'List affiliate programmes the publisher has joined on TradeTracker (or which are available to join).' It names the network (TradeTracker), the resource (affiliate programmes), and distinguishes itself from sibling get_programme/list_transactions tools by describing the list scope and explicit user queries.

  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 explicit usage triggers, quoting user questions like 'which merchants am I working with?' and says to use it for a partner inventory. It also mentions complementary tools (get_programme for drill-down, list_transactions for activity), though it doesn't state explicit when-not conditions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tune_list_transactionsA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry the transparency burden. It discloses that the tool returns Transaction records including derived ageDays, and implies read-only behavior. However, it does not mention pagination behavior, default limits, authentication needs, or any edge cases like empty results.

  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?

  Two concise, front-loaded sentences that efficiently deliver purpose, examples, and a companion tool reference. No wasted words.

  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 tool with 9 parameters and no output schema, the description covers core purpose, usage signals, and return type, but lacks details on pagination, date formats, and parameter behavior. It is adequate for a simple list use case but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It hints at from/to and programmeId via 'within a window or for a specific programme' and status via the listed statuses, but leaves limit, cursor, offset, minAgeDays, maxAgeDays unexplained. The meaning of derived ageDays is partially covered.

  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 verb 'List' with the resource 'affiliate transactions' on TUNE, and specifies the scope (window or specific programme) and statuses covered (earned, pending, reversed, paid). This distinguishes it from sibling network-specific list_transactions 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?

  Provides explicit example user queries ('what did I earn last month?', 'what's still pending?') and recommends pairing with get_earnings_summary for aggregate totals. However, it does not mention when not to use it (e.g., for clicks) or name alternatives beyond the companion summary tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_value-commerce_get_earnings_summaryA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It adds useful detail: returns an EarningsSummary including oldestUnpaidAgeDays, and describes scope/breakdowns. However, it does not disclose read-only status, default behavior, pagination, or edge cases such as missing date ranges, which leaves some behavioral ambiguity for an 8-parameter 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 two sentences, front-loaded with the verb and resource, and includes an example plus a sibling pairing. Every sentence earns its place with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 8 parameters, no annotations, no output schema, and 0% schema description coverage, the description is not complete enough. It covers the core use case and return field but omits details for 4 parameters, pagination, date formats, and any caveats, leaving the agent to guess on important invocation details.

  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 0%, so the description must compensate. It indirectly explains the date window (to/from), programme breakdown (programmeId), and status breakdown (status). However, it leaves limit, cursor, maxAgeDays, and minAgeDays unexplained, so parameter semantics are only partially covered.

  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 opens with a specific verb+resource ('Summarise earnings on ValueCommerce') and clearly states scope ('across a date window') and breakdown dimensions ('by programme and by transaction status'). It distinguishes this from sibling tools by naming ValueCommerce and focusing on summary rather than raw transaction listing.

  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?

  Explicitly states when to use: 'Use this when the user wants a single-figure answer plus context', with a concrete example. It also points to list_transactions for drill-down, providing a clear complementary alternative. It does not explicitly state when not to use, but the context is strong enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_value-commerce_list_clicksA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description bears the full burden. It discloses that the tool 'Returns Click records' and is used for debugging, giving some behavioral context. However, it lacks details on pagination (limit/cursor/offset behavior), the meaning of 'recent' (default time window), or any authentication/permission requirements. This is a small but meaningful gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is exactly two sentences: the first is action-oriented and front-loaded with the main function; the second provides use-case context and a pointer to a related tool. There is no redundancy or filler, every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 6 parameters and no output schema, the description gives a clear purpose, a practical use case, and the return type (Click records), but omits important details about pagination semantics and parameter-specific behavior. It is more complete than a bare one-liner but leaves clear gaps that could impact correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It maps 'programme' and 'date' to the corresponding parameters (programmeId, from/to), which explains two of the six params. But it omits limit, cursor, and offset entirely, and gives no details on parameter formats or constraints. The compensation is partial and insufficient for a low-coverage 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 ('List'), a specific resource ('recent affiliate clicks on ValueCommerce'), and states the optional filtering dimensions (programme and date). It distinguishes itself from sibling tools by naming the network (ValueCommerce) and the record type (clicks), separating it from list_transactions and similar tools for other networks.

  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 explicitly states when to use the tool: 'Use this for traffic-side debugging — e.g. "are my links being clicked at all?" or "where is traffic going on ValueCommerce?".' It also recommends pairing with list_transactions to compare clicks vs conversions, which implies a comparison use case. However, it does not explicitly mention when not to use this tool or alternative tools for other networks, so it misses the 'exclusion' part for a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_webgains-advertiser_list_clicksA
  3.8/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 burden of behavioral disclosure. It mentions 'Returns Click records' and 'recent', but does not disclose pagination behavior (despite limit/cursor/offset params), auth requirements, or the exact meaning of 'recent'. It also does not explicitly state that brand is required, which is a potential behavioral gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, with three sentences each serving a purpose: action+scope, use cases, and return type+pairing suggestion. It is front-loaded and contains no filler, earning a top score.

  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 (7 params, no output schema, no annotations), the description is moderately complete. It explains the tool's purpose and return type but misses details on required parameters, pagination behavior, and date format. The sibling context is large, but the description adequately differentiates Webgains from other networks.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, yet the description only partially compensates. It mentions 'optionally filtered by programme and date' (programmeId, from/to), but does not explain the required 'brand' parameter, nor the pagination parameters (limit, cursor, offset). With 7 parameters and 1 required, a stronger description is needed to clarify parameter roles.

  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 tool lists recent affiliate clicks on Webgains (advertiser), identifying both the platform and the advertiser scope. It also distinguishes from siblings by mentioning optional filtering by programme and date, and by naming the Webgains network explicitly.

  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 explicit use cases for traffic-side debugging with concrete examples ('are my links being clicked at all?', 'where is traffic going on Webgains?'). It also suggests pairing with list_transactions to compare clicks vs conversions, which implies an alternative/complement. However, it does not explicitly state when not to use this tool versus other list_clicks variants.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_webgains-advertiser_list_media_partnersA
  3.8/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 transparency burden. It discloses the return shape ('MediaPartner records with normalised status') and the listing nature of the operation, but omits pagination behavior, auth requirements, rate limits, and explicit read-only confirmation beyond the word 'List'.

  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 compact and front-loaded. Every clause earns its place: it explains the purpose, provides usage examples, states the return type, and suggests a partnering tool—all without unnecessary filler.

  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?

  It covers the core listing purpose, usage, return type, and teams well with the performance tool. However, with six parameters, no output schema, and no annotations, the description still leaves gaps around parameter semantics and output structure, making it only partially complete for fully autonomous invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% with 6 parameters, and the description only semantically enriches 'brand' and 'status' (e.g., 'running on the brand's programme', 'normalised status'). The pagination parameters (limit, cursor, offset) and search are left undefined, so the description does not adequately compensate for the missing schema descriptions.

  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: 'List the media partners (publishers) running on the brand's programme at Webgains (advertiser).' It clearly differentiates from sibling list_media_partners tools by naming the network and advertiser context, and it distinguishes itself from performance tools by offering pairing guidance.

  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?

  It provides explicit trigger phrases and use cases ('who is promoting us on Webgains?', 'which publishers are active on our programme?', 'wants an outbound roster'). It doesn't explicitly state when not to use the tool or name exclusion alternatives, but the concrete examples are strong enough to guide routing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_yieldkit_list_programmesA
  3.8/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the read-only nature implicitly through 'List', states the return type as 'an array of Programme records', and clarifies the dual scope of joined/available programmes. It does not mention pagination, authentication, or rate limits, but for a simple list operation this is acceptable partial disclosure.

  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?

  Three sentences, each earning its place: first states the action, second gives usage triggers, third describes the return and related tools. No fluff.

  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 description gives the essential behavior and return type, which is useful given no output schema. However, with 6 parameters and no schema descriptions, it omits guidance on how to use pagination/filtering and how to interpret 'available to join' results. This is adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the tool description does not discuss any of the 6 parameters. The parameter names (limit, cursor, offset, search, status, categories) are only nominally descriptive, leaving ambiguity about expected values and their interaction (e.g., allowed status values, whether categories combine). The description should have compensated, but it does not.

  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 the specific verb 'List' and identifies the resource as 'affiliate programmes the publisher has joined on Yieldkit (or which are available to join)', clearly distinguishing this from sibling network-specific list_programmes tools. The inclusion of example user queries ('which merchants am I working with?') further grounds the purpose.

  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?

  It explicitly states 'Use this when the user asks...' and provides three concrete phrasings, giving clear when-to-use conditions. The mention of 'pairs naturally with get_programme for drill-down and list_transactions for activity' points to alternative tools for complementary tasks. However, it does not explicitly contrast with other networks' list_programmes tools, so a small gap remains.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_2performant_generate_tracking_linkA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does state that the tool 'Returns a TrackingLink' and advises confirming the programmeId, which gives some insight into prerequisites and output. However, it does not disclose whether the operation is read-only or modifies state, nor does it mention authentication requirements or error behaviors. For a generate function, this is adequate but not richly transparent.

  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 three sentences, front-loaded with the primary action, followed by usage context and a return/guidance note. Every sentence earns its place, and there is no redundant information. It is concise while covering key aspects in a logical order.

  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, but the lack of annotations and an output schema means the description needs to provide more. It explains what it does, when to use it, and the return type, which is good. However, the 'TrackingLink' return value is not explained, and there is no mention of potential errors or URL constraints. This leaves gaps for an agent to fully anticipate the outcome, making it complete enough for basic use but not comprehensive.

  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 has no descriptions for the two parameters (0% coverage), so the description must compensate. It mentions 'given programme and destination URL,' which maps to programmeId and destinationUrl, and advises confirming the programmeId. This adds basic meaning, but it does not explain expected formats or constraints. The tip about list_programmes partially compensates for the missing schema but does not fully clarify parameter semantics.

  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 tool's purpose: 'Generate a tracking link on 2Performant for a given programme and destination URL.' This is a specific verb+resource combination that distinguishes it from sibling tools like list_programmes or verify_auth. The additional context about sharing affiliate links to specific products/pages reinforces its unique role.

  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 explicitly says 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined,' providing clear when-to-use direction. It also suggests pairing with list_programmes to confirm the programmeId, which is a useful preparatory step. However, it does not explicitly mention when not to use this tool (e.g., for other networks or for listing transactions), leaving some ambiguity among the many sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_accesstrade_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It adds useful context about the return shape ('EarningsSummary including oldestUnpaidAgeDays') and clarifies it produces an aggregate rather than raw transactions. However, it omits behavioral details like pagination (despite cursor/limit params), date-window semantics, or any auth/rate-limit info, leaving moderate 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?

  The description is two sentences, front-loaded with the core purpose and immediately followed by usage guidance. Every clause adds value: the example clarifies use cases, and the 'pair with list_transactions' is actionable. No fluff or repetition.

  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 8 parameters with no schema descriptions, no annotations, and no output schema, the description needs to cover much more. It only hints at parameter semantics and gives one return field (oldestUnpaidAgeDays) without explaining the full EarningsSummary structure or how pagination/limits behave. This leaves agents without enough context to confidently invoke or interpret results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only implicitly references a few parameters ('date window' suggests from/to, 'by programme' → programmeId, 'by transaction status' → status). It does not explicitly describe any parameter, their formats, defaults, or relationships, and ignores limit, cursor, maxAgeDays, and minAgeDays entirely, failing to compensate for the lack of schema descriptions.

  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 ('Summarise') with a clear resource ('earnings on AccessTrade') and scope ('across a date window', 'breakdowns by programme and by transaction status'). It distinguishes itself from sibling tools like list_transactions by explicitly stating this is for a 'single-figure answer plus context' and even names the return type (EarningsSummary).

  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?

  It provides an explicit usage trigger: 'Use this when the user wants a single-figure answer plus context', with a concrete example. It also directs to an alternative/pairing: 'pair with list_transactions to drill into the underlying records', clearly indicating when not to use this tool alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_accesstrade_list_transactionsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description must carry the full burden. It adds useful behavioral details: returns Transaction records, includes derived ageDays, and covers four statuses. However, it does not disclose pagination behavior (limit/cursor), default sort order, error handling, or whether all statuses are returned by default. It gives some transparency but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each with a clear purpose: definition, usage triggers, and return/complement info. It is front-loaded with the core function and contains no filler. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 9 parameters, no output schema, and no annotations, the description is too sparse. It provides a high-level purpose and one return detail (ageDays), but omits essential contextual information for an agent to invoke the tool correctly: date format, pagination mechanics, status enum values, default behavior, and output structure. The agent would need significant additional inference to use all parameters properly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 9 parameters with 0% description coverage. The description only vaguely hints at parameters: 'within a window' implies from/to, 'specific programme' implies programmeId, and the status list implies the status parameter. It does not explain limit, cursor, offset, minAgeDays, maxAgeDays, or the format expected for date strings. This is insufficient compensation for the low 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 clearly states the tool's function with a specific verb and resource: 'List affiliate transactions (commissions earned, pending, reversed, or paid) on AccessTrade'. It distinguishes itself from siblings by referencing transaction statuses and by explicitly recommending get_earnings_summary for aggregate totals, making it clear this tool is for itemized transaction records.

  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 triggers with concrete example queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and names get_earnings_summary as a complementary tool for aggregate totals, effectively guiding the agent on when to use this versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_admitad_list_transactionsA
  3.9/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 the tool returns 'Transaction records including derived ageDays' and scopes to a date window or programme, but does not mention authentication requirements, pagination behavior, or rate limits. The 'List' verb implies read-only, but this is not explicitly stated.

  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 three sentences with no redundant wording. It front-loads the core action and object, then provides usage examples and pairing guidance in a compact structure.

  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 9 parameters, no annotations, and no output schema, the description covers the main use case and examples but omits pagination semantics, date format requirements, and authentication prerequisites. It provides enough for straightforward queries but falls short of full completeness for the parameter-heavy schema.

  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 has 9 parameters with 0% schema description coverage, so the description must compensate. It maps 'within a window' to from/to, 'for a specific programme' to programmeId, and 'commissions earned, pending, reversed, or paid' to status, plus 'ageDays' to min/maxAgeDays. However, it leaves limit, cursor, offset, and exact status enum values unexplained.

  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 the specific verb 'List' with resource 'affiliate transactions' and scopes it to 'on Admitad within a window or for a specific programme.' It also enumerates transaction types (commissions earned, pending, reversed, or paid), clearly distinguishing it from sibling list_clicks/list_programmes 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?

  It explicitly states 'Use this when the user asks...' and gives three concrete example queries. It also suggests pairing with get_earnings_summary for aggregate totals, providing complementary context. However, it does not explicitly exclude other alternatives like list_clicks for non-transaction data.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adservice_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the full disclosure burden. It reveals that the return includes an EarningsSummary with oldestUnpaidAgeDays, and 'summarise'/'get' implies a read-only operation, but it does not specify data freshness, defaults, or whether the date window is inclusive. It adds some behavioral context but leaves many assumptions implicit.

  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 three tight sentences, front-loaded with the core action, a usage tip, and a pairing suggestion. Every sentence contributes without filler, redundancy, or repetition of the schema fields.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 8 parameters, no output schema, and no annotations, the description covers the core purpose and a usage scenario but omits critical invocation details such as pagination (cursor/limit), age filters, and response behavior beyond a single field. An agent would likely struggle with complex or non-default queries.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 8 parameters with zero descriptions, and the description only loosely references a 'date window' (presumably from/to), 'programme' (programmeId), and 'status' (status). It does not explain limit, cursor, maxAgeDays, minAgeDays, value formats, or optionality, forcing the agent to guess how to construct a valid request.

  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 opens with 'Summarise earnings on Adservice across a date window, with breakdowns by programme and by transaction status', which clearly states the tool's function with a specific verb and resource. This distinguishes it from sibling list/get tools for other networks and from the adservice list_transactions tool that it explicitly recommends for drilling into details.

  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?

  It explicitly says 'Use this when the user wants a single-figure answer plus context' and gives a concrete example ('total earnings in Q1 with status split'). It also recommends pairing with list_transactions to drill into underlying records, providing clear when-to-use and when-to-use-alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adtraction_list_clicksA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must convey behavioral traits. It mentions it 'Returns Click records' and implies a read-only listing, but does not disclose pagination behavior, default time window, or auth requirements. It adds some context beyond the schema but leaves important operational details unspecified.

  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 three sentences, each adding value: purpose, usage guidance, and return type. It is front-loaded with the primary action and contains no unnecessary words or repetition.

  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 no output schema, no annotations, and 6 parameters, the description is incomplete. It covers the basic purpose and use case, but lacks details on pagination (cursor/offset), date format, default filtering behavior, and exact return structure ('Click records' is vague). An agent would likely need additional clarification to use the tool fully.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must explain the parameters. It mentions 'optionally filtered by programme and date', covering programmeId and from/to, but does not explain limit, cursor, or offset. With 6 parameters, this is insufficient compensation for the missing schema descriptions.

  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 action: 'List recent affiliate clicks on Adtraction', with a specific resource and optional filters. It also distinguishes the tool from siblings by naming Adtraction and providing concrete use cases, e.g., checking if links are being clicked.

  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?

  It explicitly tells when to use the tool: 'Use this for traffic-side debugging' with example queries, and recommends pairing with 'list_transactions' for comparing clicks vs conversions. This provides clear context and a complementary alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adtraction_list_transactionsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations exist, so the description carries the burden of behavioral disclosure. It does reveal that the tool returns Transaction records including a derived ageDays field, which is useful. However, it does not mention pagination behavior (cursor/offset), any rate limits, or authentication requirements, leaving significant gaps for a tool with no 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 three sentences, each serving a distinct purpose: defining the tool, giving trigger examples, and noting return value and complementary tool. No filler or repetition; it is front-loaded with the core action and scope.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no annotations and no output schema, the description must supply substantial context. It covers the key usage scenarios, the return record type, and a companion tool, but it does not explain pagination, default date ranges, or how the 9 parameters work together. For a list operation with many unclear parameters, it is adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has zero description coverage across 9 parameters. The description partially compensates by implying from/to as a date window, programmeId as a specific programme filter, and the status parameter via the listed commission states. It also hints at minAgeDays/maxAgeDays through the derived ageDays field, but it leaves limit, cursor, and offset unexplained.

  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 action ('List affiliate transactions'), the specific network ('on Adtraction'), and the scope ('within a window or for a specific programme'). It also enumerates the statuses covered (commissions earned, pending, reversed, or paid), which distinguishes it from sibling tools like list_clicks or get_earnings_summary.

  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?

  Explicit use cases are provided ('what did I earn last month?', 'what's still pending?', 'show me reversed sales'), giving clear context for when to invoke this tool. It also recommends pairing with get_earnings_summary for aggregate totals, which names an alternative and helps the agent decide between tools, though it stops short of saying when not to use this one.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_affilae_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries full burden. It adds value by disclosing the return type ('EarningsSummary including oldestUnpaidAgeDays'), but it does not mention any side effects, pagination behavior, or limitations. The read-only nature is implied but not explicitly stated.

  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 three sentences, front-loaded with purpose, then usage guidance, then return-type hint. Every sentence earns its place with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite having 8 parameters and no output schema or annotations, the description does not explain key parameters like cursor, limit, maxAgeDays, or minAgeDays, nor does it provide a full picture of the return structure. The agent is left without enough information to use the tool correctly in edge cases or pagination scenarios.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It maps 'date window' to from/to, 'breakdowns by programme' to programmeId, and 'transaction status' to status, but leaves limit, cursor, maxAgeDays, and minAgeDays completely unexplained. With 8 parameters, this is insufficient for an agent to invoke correctly without guessing.

  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 tool's function with specific verbs and scope: 'Summarise earnings on Affilae across a date window, with breakdowns by programme and by transaction status.' It also distinguishes from the sibling list_transactions tool by noting it gives a 'single-figure answer plus context' and suggesting pairing for drilling into records.

  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?

  Explicit guidance is provided: 'Use this when the user wants a single-figure answer plus context' with an example. It also names the alternative tool ('pair with list_transactions to drill into the underlying records'), making when-to-use and when-not-to-use clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_affilae_list_clicksA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It discloses that the tool returns Click records and supports filtering, but it does not explain pagination behavior, date range semantics, or whether any side effects exist. The word 'list' implies a read operation, but no explicit safety or behavioral details are given.

  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, front-loaded with the main action, and includes useful usage examples and a pairing suggestion. Every sentence earns its place with no fluff or repetition of schema information.

  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 tool with 6 parameters, no annotations, and no output schema, the description provides good purpose and usage context but leaves important gaps: pagination/date format details, default range, and output structure. It is adequate for a simple read tool but not 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 0%, so the description must compensate. It maps 'programme' and 'date' to likely parameters (programmeId, from/to), which helps. However, it does not explain the meaning or usage of limit, cursor, or offset, and does not specify date formats or constraints. Some value added, but incomplete.

  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 tool lists recent affiliate clicks on Affilae, with optional filtering by programme and date. This is a specific verb+resource+scope that distinguishes it from other sibling tools (e.g., list_transactions, get_earnings_summary) and from other networks' list_clicks 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 explicitly says 'Use this for traffic-side debugging' and gives concrete example questions ('are my links being clicked at all?', 'where is traffic going on Affilae?'). It also suggests pairing with list_transactions to compare clicks vs conversions, providing a clear alternative/complementary tool. No explicit when-not guidance, but the context is strong.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_affise_list_transactionsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden for behavioral disclosure. It implies a read-only operation through the verb 'List' and describes the return type ('Transaction records including derived ageDays'). However, it does not mention authentication requirements, pagination behavior, rate limits, or any side effects. The added detail about derived ageDays is useful but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact (two sentences) and front-loaded with the core action and scope. Each sentence contributes value: the first defines what the tool does, and the second provides usage examples and a complementary tool. 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.

  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 (9 params, no output schema, no annotations), the description is incomplete. It explains the return type at a high level ('Transaction records including derived ageDays') and mentions date/programme filtering, but it lacks information about pagination (limit/cursor/offset), date format expectations, or the full transaction record structure. It is adequate for basic use but leaves important gaps for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for parameter meaning. It provides some semantics: 'within a window' implies from/to, 'specific programme' maps to programmeId, and the status values (earned, pending, reversed, paid) correspond to the status parameter. However, it does not explain limit, cursor, offset, minAgeDays, or maxAgeDays, leaving significant gaps for a 9-parameter tool.

  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 tool's purpose: 'List affiliate transactions (commissions earned, pending, reversed, or paid) on Affise within a window or for a specific programme.' It identifies the specific resource (Affise transactions), the action (list), and the scope (date window or programme), distinguishing it from other network-specific list_transactions tools by naming 'Affise'.

  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 explicit usage examples: 'Use this when the user asks "what did I earn last month?", "what's still pending?", or "show me reversed sales".' It also suggests pairing with get_earnings_summary for aggregate totals, giving clear context on when to use this tool. However, it does not explicitly state when not to use it or name an alternative, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It discloses that the tool returns an EarningsSummary including oldestUnpaidAgeDays, which is useful. However, it does not explicitly state that this is a read-only operation, nor does it explain behavior when date parameters are omitted or whether auth is required. Some behavioral context is present but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each with a distinct purpose: what, when, and output/companion. Information is front-loaded and no words are wasted. It is well-structured for an agent to parse.

  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?

  With 8 parameters, no annotations, and no output schema, the description needs to provide substantial guidance. It covers the tool's purpose and high-level behavior but omits crucial parameter semantics and output structure details. Given the complexity, the description is not complete enough for reliable invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It only loosely maps to 4 of 8 parameters: date window (from/to), programme breakdown (programmeId), and status split (status). No details are given for limit, cursor, maxAgeDays, minAgeDays, or date formats. This leaves the majority of parameters unexplained.

  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 'summarise' with resource 'earnings on Awin' and scope 'across a date window', with breakdowns by programme and status. It distinguishes from siblings by naming Awin and contrasting with list_transactions. This is a clear, unambiguous purpose.

  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?

  Explicitly states 'Use this when the user wants a single-figure answer plus context' and gives an example. Also directs users to 'pair with list_transactions to drill into the underlying records', which provides an alternative. This is clear when-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin_list_transactionsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries full burden. It discloses the returned data (Transaction records with derived ageDays) and the filtering options (window, programme, status), but does not mention pagination behavior (cursor/offset), rate limits, or any side effects. 'List' implies read-only, but an explicit no-mutation statement is absent.

  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 three sentences and front-loaded: purpose first, then usage triggers, then return details and a complementary tool. Every sentence adds value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has 9 parameters, no annotations, and no output schema, the description is incomplete. It lacks explanation of pagination (cursor/offset), the meaning of age-based filters (minAgeDays/maxAgeDays), and the exact structure of Transaction records beyond ageDays. The pair-with note helps but does not fill these gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for parameter meaning. It adds interpretation for 'within a window' (from/to), 'specific programme' (programmeId), and statuses (status), but leaves limit, cursor, offset, maxAgeDays, and minAgeDays unexplained. With 9 parameters, this is insufficient 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 clearly states the tool lists affiliate transactions on Awin, explicitly naming the statuses (commissions earned, pending, reversed, or paid). It distinguishes itself from related tools like get_earnings_summary by noting it returns individual Transaction records rather than aggregate totals.

  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?

  Usage is explicitly guided with example user queries: 'what did I earn last month?', 'what's still pending?', or 'show me reversed sales'. It also recommends pairing with get_earnings_summary for aggregate totals, which provides an alternative/complement for a different use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_commission-factory-advertiser_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry the transparency burden. It discloses the return type ('Returns an EarningsSummary including oldestUnpaidAgeDays') and aggregation behavior, but does not mention prerequisites, data freshness, or any side effects. This is adequate for a basic read-only summarization tool, but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences front-load the purpose, then provide usage guidance and a pointer to the related list_transactions tool. No redundant information; every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 9 parameters, no output schema, and no annotations. The description provides the core purpose and a hint at the return object, but leaves significant gaps: it fails to explain the required brand parameter or the alternative age-based filters. An agent would struggle to correctly set non-obvious parameters like maxAgeDays or understand pagination via cursor. The mention of list_transactions is helpful but insufficient for full invocation confidence.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage and 9 parameters. The description only maps 'date window' to from/to and 'breakdowns' to programmeId/status. It does not explain the required 'brand' parameter, nor limit, cursor, maxAgeDays, minAgeDays, which remain ambiguous without schema descriptions. This is insufficient compensation for the coverage gap.

  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 tool's function: 'Summarise earnings on Commission Factory (advertiser) across a date window, with breakdowns by programme and by transaction status.' This specific verb+resource+scope distinguishes it from sibling tools like list_transactions and other networks' earnings summaries.

  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?

  Explicitly states when to use it: 'Use this when the user wants a single-figure answer plus context — e.g. total earnings in Q1 with status split.' It also points to an alternative: 'pair with list_transactions to drill into the underlying records,' which is exactly the kind of when-to-use vs alternatives guidance the rubric rewards.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_commission-factory-advertiser_list_clicksA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses that it 'Returns Click records' and implies a read-only operation, but it does not explain pagination behavior, data freshness ('recent' is vague), or authentication requirements. It adds some context about filtering but lacks deeper disclosure of what happens or how data is scoped.

  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 three sentences with the action and filters in the first sentence, usage context in the second, and return type plus companion tool in the third. Every sentence provides value, and it is front-loaded with the core action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 7 parameters, no output schema, and no annotations, yet the description is relatively short. It covers purpose, use case, and return type, but omits the required 'brand' parameter and does not explain pagination or Click record fields, leaving the agent to guess. It is adequate but with clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds meaning for 'programme' and 'date' (programmeId and from/to), but does not mention the required 'brand' parameter or the pagination parameters (limit, cursor, offset). This partial guidance helps but leaves key parameters undocumented.

  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 lists 'recent affiliate clicks on Commission Factory (advertiser)' with optional filters, which is a specific verb+resource+scope. The '(advertiser)' qualifier helps distinguish it from the publisher-side tool, though it does not explicitly name a sibling alternative.

  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 explicitly says 'Use this for traffic-side debugging' and gives concrete example questions, which clearly defines when to use it. Additionally, it explicitly recommends pairing with 'list_transactions', naming a specific sibling tool for comparison.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_commission-factory_list_transactionsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses that the return includes Transaction records with a derived ageDays field, which is valuable. However, it does not mention pagination behavior, default date handling, or authentication requirements, leaving notable 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?

  The description is compact and well-structured: the first sentence gives action and scope, the second provides usage triggers, and the third describes return shape and a companion tool. Every sentence earns its place with no repetition of schema details.

  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 9 parameters, no output schema, and no annotations, the description must be comprehensive. It covers core purpose, main filters, and output type, but omits pagination semantics, default date ranges, and parameter formats, leaving an agent partially unguided.

  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 0%, so the description must compensate. It adds meaning to from/to via 'within a window', programmeId via 'specific programme', status via the listed statuses, and minAgeDays/maxAgeDays via 'derived ageDays'. But it does not explain limit, cursor, or offset, so the compensation is incomplete.

  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 it lists affiliate transactions on Commission Factory, enumerates the statuses (earned, pending, reversed, paid), and notes filtering by window or programme. This directly distinguishes it from siblings like list_programmes, list_clicks, and get_earnings_summary.

  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?

  It gives explicit example user queries that should trigger this tool, such as 'what did I earn last month?' and 'what's still pending?', and recommends pairing with get_earnings_summary for aggregate totals. It does not explicitly state when not to use it, so it misses a full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_coupang-partners_get_earnings_summaryA
  3.9/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 burden for behavioral disclosure. It does disclose the return type (EarningsSummary) and a specific field (oldestUnpaidAgeDays), and indicates summary granularity. However, it omits behavioral details around pagination (schema includes cursor and limit, which is unreconciled with the 'single-figure' claim), authentication requirements, and default date handling. This partial disclosure is adequate but not rich.

  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, front-loaded with the primary action and immediately followed by usage guidance and return information. There is no filler or redundancy; every sentence earns its place. This is a model of concise, structured tool documentation.

  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 8 parameters, no output schema, and no annotations, the description is insufficiently complete. It explains the summary use case and one return field, but does not state required inputs, default behavior, or how cursor/limit/age filters operate. An agent would need to guess critical invocation details, making the description incomplete for this complexity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It vaguely references 'date window' (from/to), 'programme' (programmeId), and 'transaction status' (status), but leaves limit, cursor, maxAgeDays, and minAgeDays entirely unexplained. It does not clarify whether from/to are required or how age filters relate to the date window. The description adds only partial semantics for a minority of the 8 parameters.

  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 verb and resource: 'Summarise earnings on Coupang Partners'. It differentiates from sibling tools by naming the network (Coupang Partners) and the aggregation function, explicitly distinguishing from list_transactions by mentioning 'single-figure answer plus context'. The inclusion of breakdowns by programme and transaction status further specifies the tool's scope.

  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 guidance: 'Use this when the user wants a single-figure answer plus context', and directs the agent to pair it with list_transactions for drilling into underlying records. This clearly indicates when to use the tool versus alternatives and names a complementary tool, meeting the highest bar for usage guidelines.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_daisycon-advertiser_list_clicksA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the transparency burden. It states 'Returns Click records' and the 'list' verb implies a read-only operation, but it doesn't disclose pagination behavior, date range semantics, authentication requirements, or rate limits. This is an adequate but not rich behavioral disclosure.

  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, front-loaded with the primary purpose, followed by usage guidance and a cross-reference. Every sentence earns its place with no redundant or vague filler.

  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?

  With 7 parameters, no parameter descriptions in the schema, and no output schema, the description is incomplete. It doesn't explain the required 'brand' parameter or pagination-related parameters (limit, cursor, offset), and only vaguely mentions date/programme filtering. The description is not sufficient for an agent to correctly invoke all aspects of the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only vaguely mentions 'filtered by programme and date.' It fails to explain the meaning or purpose of brand (which is required), limit, cursor, offset, or how the date parameters map. The description does not compensate for the 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 clearly states the tool lists recent affiliate clicks on Daisycon (advertiser), with optional filters for programme and date. It distinguishes itself from the publisher-side sibling by explicitly identifying the advertiser context.

  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?

  Explicitly directs use for traffic-side debugging with concrete example questions ('are my links being clicked at all?', 'where is traffic going?'). It also suggests pairing with list_transactions to compare clicks vs conversions, offering an alternative and complement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_digistore24_list_transactionsA
  3.9/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 return records include derived ageDays and clarifies the scope parameters, but it does not mention pagination behavior, default date range handling, or authentication requirements. For a read-only listing tool this is acceptable but not richly transparent.

  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?

  Three dense sentences, front-loaded with the core purpose and followed by use-case examples and a pairing suggestion. No filler or redundant repetition of schema information.

  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 core purpose and common use cases are covered, but with 9 parameters, no schema descriptions, and no output schema, the description omits pagination details, date formats, and age filter semantics. It is adequate for typical intent but not fully complete for an agent needing to invoke all parameters correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for the 9 parameters. It interprets 'window' (from/to), 'specific programme' (programmeId), and status categories, but leaves limit, cursor, offset, maxAgeDays, and minAgeDays unexplained. Partial compensation for the schema gap.

  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 tool lists affiliate transactions on Digistore24, enumerating status types (earned, pending, reversed, paid) and scope (window, programme). This verb+resource+platform combination distinguishes it from many sibling list_transactions tools for other networks.

  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?

  It provides explicit user query examples ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and recommends pairing with get_earnings_summary for aggregate totals, giving clear situational guidance. However, it does not explicitly mention when not to use this tool or name alternative network-specific transaction listers.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_ebay_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It discloses the return type ('EarningsSummary including oldestUnpaidAgeDays') and mentions breakdowns, but does not discuss pagination, default date behavior, or potential side effects. The read-only nature is implied but not explicitly stated.

  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 3 sentences, front-loaded with the core purpose, then usage example, then return type and relationship to list_transactions. Every sentence adds value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the complexity (8 optional parameters, no annotations, no output schema), the description covers the primary use case and return type but omits details about parameter semantics, optionality, and pagination. The agent might not know whether from/to are truly optional or how maxAgeDays/minAgeDays behave.

  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 has 0% description coverage and 8 parameters. The description adds meaning to some parameters via phrases like 'across a date window' (to/from) and 'breakdowns by programme and by transaction status' (programmeId/status), but it does not explain limit, cursor, maxAgeDays, or minAgeDays, leaving gaps.

  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 tool's function: 'Summarise earnings on eBay Partner Network across a date window, with breakdowns by programme and by transaction status.' It distinguishes from sibling list_transactions by positioning itself as a summary tool and explicitly suggesting pairing with list_transactions for drill-down.

  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?

  Provides explicit when-to-use guidance: 'Use this when the user wants a single-figure answer plus context — e.g. "total earnings in Q1 with status split".' It also mentions an alternative ('pair with list_transactions to drill into the underlying records'), though it does not explicitly say when not 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.

• affiliate_eduzz_generate_tracking_linkA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description must carry the behavioral disclosure. It states 'Returns a TrackingLink' (a return type) and implies a safe generation operation, but it does not explicitly mention whether this is read-only, requires authentication, or has side effects. The reference to confirming programmeId via list_programmes adds some behavioral context, but the safety profile is incomplete.

  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 three sentences, each earning its place: action, use case, and additional guidance (return type and pairing with list_programmes). It is front-loaded with the primary action and contains no redundant or irrelevant information.

  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 simple two-parameter tool, the description covers the main purpose, usage scenario, and a recommendation to verify programmeId. However, with no output schema and no annotations, it leaves gaps: it does not explain the structure of the returned TrackingLink, potential errors, or any prerequisites beyond joining the merchant. This is adequate but not thorough for a production agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It identifies the two inputs as 'programme' and 'destination URL,' which maps to programmeId and destinationUrl. However, it does not clarify the format or constraints of these parameters (e.g., URL structure, where to find programmeId beyond the hint to use list_programmes). The basic meaning is conveyed, but not enough to fully replace schema descriptions.

  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 tool's action: 'Generate a tracking link on Eduzz for a given programme and destination URL.' It specifies the resource (Eduzz tracking link) and the key inputs, distinguishing it from other network-specific generators. The added use-case context ('when the user wants to share an affiliate link to a specific product or page') reinforces its purpose and aligns with the tool's 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 provides a clear scenario for use: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also recommends pairing with list_programmes to confirm programmeId, which is practical guidance. It doesn't explicitly mention when not to use it or compare to alternatives, but the context is sufficient for a distinct tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_eduzz_get_earnings_summaryA
  3.9/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 the tool returns an EarningsSummary including oldestUnpaidAgeDays and positions it as a summary rather than a raw list. However, it does not disclose pagination behavior, how limit/cursor affect results, or any filtering semantics beyond date and status/programme, leaving significant behavioral gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the action, and every sentence adds value: the action, the when-to-use guidance, and the return/companion pairing. There is no redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This tool has 8 parameters, no schema descriptions, no annotations, and no output schema. The description covers the core use case and one return field, but it does not explain several important parameters (limit, cursor, maxAgeDays, minAgeDays), does not describe the full structure of EarningsSummary, and omits any mention of pagination or result format. For such a parameter-rich tool, this is insufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It maps 'date window' to from/to and mentions breakdowns by programme and status, which likely correspond to programmeId and status parameters. However, it leaves limit, cursor, maxAgeDays, and minAgeDays completely unexplained, and does not clarify whether these parameters filter the summary or the breakdowns.

  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 the specific verb 'Summarise earnings' with the resource 'on Eduzz' and clearly states the date window and breakdowns by programme and transaction status. It distinguishes itself from sibling tools like list_transactions by focusing on a single-figure summary rather than raw records.

  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 explicitly says 'Use this when the user wants a single-figure answer plus context' and provides an example ('total earnings in Q1 with status split'). It also names an alternative, 'pair with list_transactions to drill into the underlying records', giving clear guidance on when to use this tool versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_eduzz_list_clicksA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full transparency burden. It discloses that the tool returns Click records and that filters are optional, but it omits pagination behavior, default date-range semantics, ordering, auth requirements, and rate-limit 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?

  Three sentences: purpose first, then use cases, then return type and sibling pairing. Every sentence contributes useful information without redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and no annotations, the description is reasonably helpful but incomplete. It names Click records and the list_transactions pairing, but it does not explain pagination parameters, default recency window, or any return-field details, leaving operational gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It adds meaning by saying results are 'optionally filtered by programme and date,' which maps to programmeId and from/to, but it does not describe limit, cursor, offset, or date formats, leaving significant parameter ambiguity.

  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?

  Description opens with a specific verb and resource: 'List recent affiliate clicks on Eduzz.' It names the optional filters (programme and date) and distinguishes itself from transaction-focused siblings by explicitly pairing with list_transactions to compare clicks vs. conversions.

  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 says 'Use this for traffic-side debugging' and provides concrete example questions, giving clear when-to-use context. It also mentions pairing with list_transactions, but it does not explicitly state when not to use this tool or exclude alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_ehub_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the return type ('Returns an EarningsSummary including oldestUnpaidAgeDays') and hints at the summary-level nature, but it does not explicitly state that this is a read-only operation, mention authentication requirements, or describe any side effects. Some context is added, but significant safety/behavioral detail is missing.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with an embedded example and a pairing suggestion. It is front-loaded with the core purpose and contains no filler. Every sentence provides useful context, 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?

  Given the tool complexity (8 parameters, no output schema, no annotations), the description is too sparse. It mentions a return object and pairing, but does not explain the full output structure, parameter semantics, or edge cases like whether from/to are required. An agent would lack sufficient information to use this tool reliably beyond a basic summary request.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not compensate adequately. It vaguely references 'date window' (likely to/from) and 'programme' and 'transaction status' breakdowns, but it does not explain the meaning or format of 8 parameters (including limit, cursor, maxAgeDays, minAgeDays, programmeId, status). This is insufficient for an agent to correctly construct invocations with proper parameter values.

  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 tool's function: 'Summarise earnings on eHUB across a date window, with breakdowns by programme and by transaction status.' It specifies a specific verb ('Summarise'), a resource ('earnings on eHUB'), and distinguishes itself from list_transactions by indicating it provides a summary rather than individual records. The tool name and description align with the sibling pattern for earnings summary tools.

  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 gives explicit when-to-use guidance: 'Use this when the user wants a single-figure answer plus context — e.g. "total earnings in Q1 with status split"' and suggests pairing with list_transactions for drill-down. This provides a clear use case and an alternative for more detailed exploration, satisfying the requirement for explicit usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_everflow-advertiser_list_transactionsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries full burden. It discloses that it returns Transaction records with derived ageDays and supports window/programme filtering, but it does not mention pagination behavior, rate limits, authentication requirements, or that it is a read-only operation (likely implied by 'list'). The description adds some context but lacks important behavioral details for a 10-parameter 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 exactly two sentences, front-loading the core purpose and then providing usage examples and pairing advice. Every clause earns its place with no redundant filler or repetition of schema information.

  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 complexity of 10 parameters, no annotations, and no output schema, the description provides useful context (usage examples, return type, derived field) but remains incomplete. It fails to explain the required brand parameter, date format conventions, or pagination, which are essential for correct invocation. It is more complete than minimal descriptions but still leaves significant gaps for an agent to fill.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It meaningfully explains the 'window' (from/to), 'specific programme' (programmeId), and statuses, but does not mention the required 'brand' parameter or the pagination parameters (limit, cursor, offset). It also does not explain minAgeDays/maxAgeDays, though it references derived ageDays. Overall, it adds partial semantics but leaves many parameters underspecified.

  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 tool lists affiliate transactions on Everflow (Advertiser) with specific statuses (earned, pending, reversed, paid) and filtering by window or programme. It distinguishes itself from sibling tools like affiliate_everflow_list_transactions by explicitly indicating the 'Advertiser' scope, and from get_earnings_summary by noting it returns Transaction records, not aggregates.

  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?

  It provides concrete example user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and recommends pairing with get_earnings_summary for aggregate totals. However, it does not explicitly mention alternatives for other data types (e.g., list_clicks) or the non-advertiser variant, leaving some ambiguity for an agent deciding between tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_firstpromoter_list_clicksA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of behavioral disclosure. It reveals the return type ('Returns Click records') and confirms it is a list operation, implying read-only behavior. However, it does not mention pagination behavior, default date ranges, or authentication requirements, leaving some transparency 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?

  The description is concise at three sentences, each serving a distinct purpose: the main action, the usage context with examples, and the return type with a pairing suggestion. It is front-loaded with the core function and contains no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite the strong usage guidance, the description is incomplete for a tool with 7 parameters and no output schema. It omits the only required parameter (brand), does not explain parameter semantics for cursor/offset/limit, and only vaguely describes return data as 'Click records'. This would likely leave the agent unable to invoke the tool correctly without external knowledge.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% for 7 parameters. The description merely states 'optionally filtered by programme and date' without mapping to specific parameter names (e.g., programmeId, from, to). It also fails to mention the required 'brand' parameter or explain the purpose of cursor, offset, and limit, leaving the agent without sufficient guidance.

  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 'List recent affiliate clicks on FirstPromoter' with a specific verb and resource, and mentions optional filters for programme and date. It also distinguishes itself from sibling list_transactions by explicitly referencing 'clicks vs conversions', making its 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit usage direction: 'Use this for traffic-side debugging' with concrete example questions like 'are my links being clicked at all?' and 'where is traffic going?'. It also recommends pairing with list_transactions for comparison, which serves as a clear alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_flexoffers_list_clicksA
  3.9/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 adds 'recent' and 'Returns Click records' but does not disclose pagination behavior, default time windows, date formats, or authentication requirements. This is partial but not comprehensive behavioral disclosure.

  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, front-loaded with purpose. Every clause earns its place: purpose, usage context, return type, and pairing advice. No unnecessary wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is acceptable for a simple list tool but lacks specifics on pagination parameters, default date range, and return field details. Given no output schema and 0% param descriptions, more detail would be needed for fully informed usage. It is adequate but with clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It clarifies that filters by 'programme and date' (mapping to programmeId and from/to), but leaves limit, cursor, and offset unexplained. It adds some meaning but does not fully cover all six parameters.

  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 'List recent affiliate clicks on FlexOffers, optionally filtered by programme and date' with a specific verb and resource. It distinguishes from siblings by naming FlexOffers and mentioning pairing with list_transactions, making its scope explicit.

  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?

  Provides concrete when-to-use context ('traffic-side debugging') and examples ('are my links being clicked at all?'). It names list_transactions as a complementary tool but does not explicitly state when not 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.

• affiliate_flipkart_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must disclose behavior itself. It adds value by mentioning the return type (EarningsSummary) and the field oldestUnpaidAgeDays. However, it does not state whether this is a read-only operation, nor mention pagination, timezone handling, or any side effects. For a summary tool this is a moderate disclosure.

  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 only two sentences, front-loaded with the primary action and followed by a usage example. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 8 parameters, no annotations, and no output schema, a complete description would need to explain parameter semantics and the return structure. While the purpose and usage are clear, the lack of parameter details and the partial return description leave an agent guessing about pagination and age filters. This is a significant gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% and the description does not define any of the 8 parameters. It loosely implies 'from'/'to' via 'date window,' 'programmeId' via 'breakdowns by programme,' and 'status' via 'transaction status,' but completely leaves limit, cursor, maxAgeDays, minAgeDays unexplained. This is insufficient for an agent to correctly populate parameters.

  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 core function: 'Summarise earnings on Flipkart Affiliate across a date window, with breakdowns by programme and by transaction status.' It uses a specific verb and resource, and the Flipkart naming distinguishes it from the many sibling get_earnings_summary tools.

  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?

  It explicitly identifies the right context: 'Use this when the user wants a single-figure answer plus context' and advises pairing with list_transactions for deeper investigation. This provides clear when-to-use guidance and an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_growsurf_list_media_partnersA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses return type ('MediaPartner records with normalised status') but does not mention side-effect safety, auth requirements, pagination behavior, or what 'normalised status' entails. For a read-only list operation this is less critical than a mutation, but key operational details remain unspecified.

  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 three sentences with no filler. It front-loads the core action, then gives usage examples, and finally states the return value and related tool. Every sentence contributes useful information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 6 parameters, no output schema, and no annotations, the description only covers high-level purpose and a few usage examples. It omits pagination semantics, allowed status values, search behavior, and any error/preconditions. The pairing hint is useful but the overall context is insufficient for robust autonomous invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It clarifies that 'brand' is the brand's programme and mentions 'normalised status', but provides no explanation for limit, cursor, offset, search, or status parameters. An agent would not know valid status values or how search/pagination behave, making correct invocation difficult.

  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 opens with a specific verb and resource: 'List the media partners (publishers) running on the brand's programme at GrowSurf.' It clearly differentiates from sibling tools like list_programmes and get_programme by focusing on media partners/publishers, and includes concrete example user queries that map to the tool's purpose.

  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?

  Explicit usage triggers are provided: 'Use this when the user asks "who is promoting us on GrowSurf?", "which publishers are active on our programme?", or wants an outbound roster.' It also names a complementary tool ('pair with the matching get_programme_performance tool') for further drilling, effectively indicating an alternative for deeper analysis.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_hotmart_list_programmesA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It discloses the return type (an array of Programme records) and the scope (joined vs available), but it does not mention pagination behavior, authentication requirements, or any side effects. For a read-only list tool, this is adequate but lacks depth.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences with clear front-loading: purpose first, then example queries, then return type and related tools. Every sentence adds distinct value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers core purpose and usage examples but completely omits parameter semantics, pagination behavior, and output details (no output schema). With 6 filter parameters and no schema descriptions, the tool is under-specified for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% — none of the 6 parameters (limit, cursor, offset, search, status, categories) are described in the schema, and the description does not explain any of them. An agent would have no idea how to use filters like status or categories, leaving a significant gap.

  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 verb 'List' and the specific resource 'affiliate programmes the publisher has joined on Hotmart (or which are available to join)', distinguishing it from other networks' list_programmes tools and from get_programme. It also provides concrete example queries that reinforce the purpose.

  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?

  It explicitly says when to use the tool with example user queries ('which merchants am I working with?', 'what programmes do I have on Hotmart?') and mentions alternatives: get_programme for drill-down and list_transactions for activity. This gives clear guidance on when not to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_howl_list_transactionsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It discloses that the return includes Transaction records with a derived ageDays field, and implies status filtering. However, it does not mention pagination, default window behavior, authentication requirements, or ordering, leaving significant behavioral aspects undocumented.

  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?

  Three tight sentences: purpose, usage examples, and return/pairing note. No repetition of schema details or filler language. Front-loaded with the action verb.

  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?

  With 9 parameters, no annotations, and no output schema, the description is insufficient for an agent to invoke the tool correctly in all cases. It lacks parameter formats, defaults, pagination handling, and output structure details beyond 'Transaction records including derived ageDays'. The guidance is useful for basic queries but incomplete for a complex tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, and the description only indirectly references 'window' (likely from/to), 'specific programme' (programmeId), and statuses. It does not explain the purpose of limit, cursor, offset, minAgeDays, or maxAgeDays, leaving a large portion of the 9-parameter schema ambiguous.

  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 ('List') with a clear resource ('affiliate transactions') and scope ('on Howl'), and enumerates statuses (commissions earned, pending, reversed, or paid) and filter dimensions (window, specific programme). It distinguishes the tool from siblings by explicitly naming the Howl network and providing usage examples.

  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?

  Provides explicit when-to-use guidance with concrete user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and directs pairing with get_earnings_summary for aggregate totals, effectively indicating when this tool is not sufficient on its own.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_impact_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations exist, so the description carries the burden. It adds value by revealing a specific return field (oldestUnpaidAgeDays) and clarifying the output type (EarningsSummary). However, it does not disclose default behavior for missing parameters, pagination semantics, or any potential side effects, leaving gaps for an 8-parameter 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?

  Three sentences, no redundancy. The description leads with the core function, then usage guidance, then a return value detail. Every sentence serves a purpose and the structure is highly scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite a clear core use case, the tool has 8 parameters with zero schema descriptions, no annotations, and no output schema. The description only discloses one return field and does not cover pagination, filtering semantics, or parameter formats, which is insufficient for reliable agent invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It only implicitly maps 'date window' to from/to, 'programme' to programmeId, and 'status' to status. Parameters such as limit, cursor, maxAgeDays, minAgeDays, and to/from formats are unexplained, making it hard for an agent to correctly populate them.

  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 a specific verb ('Summarise earnings') on a specific resource ('Impact') with clear scope parameters (date window, breakdowns by programme and status). It distinguishes this tool from siblings by naming the network ('Impact') and from transaction-level tools by emphasizing a 'single-figure answer plus context'.

  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?

  Explicitly states when to use: 'when the user wants a single-figure answer plus context' with a concrete example ('total earnings in Q1 with status split'). It also names the companion tool 'list_transactions' for deeper drilling, providing clear guidance on alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_indoleads_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It adds useful context by mentioning the return type EarningsSummary and the oldestUnpaidAgeDays field. However, it does not discuss any side effects, auth requirements, rate limits, or edge cases, leaving the behavioral profile mostly implicit.

  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 concise, front-loaded, and every sentence earns its place: purpose, usage, and return/drill-down guidance. It includes a concrete example without unnecessary padding.

  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 has 8 parameters, no annotations, and no output schema, the description leaves major gaps. It does not explain how from/to relate to minAgeDays/maxAgeDays, how pagination (limit/cursor) works, or whether parameters are mutually exclusive. The description is adequate for simple use but incomplete for robust selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% and the description only loosely references date window (from/to), programme (programmeId), and status. It fails to explain limit, cursor, maxAgeDays, minAgeDays, and the exact meaning of status values or date formats. With 8 parameters, this is insufficient compensation.

  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 tool summarizes earnings on Indoleads across a date window with breakdowns by programme and transaction status, using a specific verb and resource. It distinguishes itself from sibling summary tools for other networks and from Indoleads' list_transactions by focusing on aggregation.

  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?

  It explicitly says to use when the user wants a single-figure answer plus context, giving an example. It also recommends pairing with list_transactions to drill into underlying records, effectively naming an alternative and providing guidance on when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_indoleads_list_transactionsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It adds some behavioral context by stating the return type ('Transaction records including derived ageDays') and the types of statuses included. However, it does not disclose pagination behavior, default date ranges, authentication requirements, or what happens when no filters are provided—significant gaps for a listing 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?

  Three sentences, each with clear value: the first defines the action and scope, the second provides concrete use cases, and the third specifies the return type and suggests a complementary tool. No wasted words, well-front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 8 optional parameters, no annotations, and no output schema, so the description needs to cover a lot. It addresses the core purpose, usage examples, and return type, but leaves out critical operational details like pagination, default behavior when no params are given, and date format expectations. It is adequate for a simple list scenario but has clear gaps for a parameter-rich 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 coverage is 0%, so the description must compensate. It does explain the meaning of key parameters indirectly: 'within a window' maps to from/to, 'specific programme' to programmeId, and the list of statuses to the status parameter. The mention of 'derived ageDays' hints at minAgeDays/maxAgeDays. However, limit, cursor, and exact date formats are left unexplained, so compensation is only partial.

  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 verb 'List' and the resource 'affiliate transactions' on Indoleads, with explicit filtering options (time window, specific programme). It distinguishes itself from sibling tools like list_clicks and get_earnings_summary by naming the exact resource and providing example user queries that map to this tool.

  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 concrete when-to-use examples ('what did I earn last month?', 'what's still pending?') and explicitly recommends pairing with get_earnings_summary for aggregate totals, which names an alternative. It does not explicitly state when not to use it (e.g., for clicks), but the examples and context make the intended usage clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_leaddyno_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry the burden of behavioral disclosure. It does add useful context about the return value (EarningsSummary including oldestUnpaidAgeDays) and implies a read-only summary operation, but it does not explicitly state safety profile, authorization needs, pagination behavior, or effects of parameters like maxAgeDays/minAgeDays. It is not misleading, but the disclosures are minimal.

  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 compact and front-loaded with the primary purpose, followed by usage guidance, return information, and a pairing suggestion. Every sentence contributes value. The example is concrete and the structure is easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 9 parameters, no output schema, and no annotations, so the description needs to be comprehensive. It covers the core purpose, usage context, a return field, and points to a related tool. However, it omits details about many parameters, full output shape, and any potential limitations, making it adequate but not 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 0%, so the description must compensate. It does clarify key parameters: 'date window' maps to from/to, 'by programme' maps to programmeId, and 'by transaction status' maps to status. However, it leaves limit, cursor, maxAgeDays, minAgeDays, and brand semantics unexplained. With 9 parameters, this partial coverage is insufficient to earn a higher score.

  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 tool's function with a specific verb ('Summarise earnings on LeadDyno') and resource, including scope (date window, breakdowns by programme and transaction status). It also differentiates from sibling tools by naming LeadDyno and specifying the breakdown dimensions, making it unmistakable among the many get_earnings_summary variants.

  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?

  It gives explicit usage context: 'Use this when the user wants a single-figure answer plus context' with a concrete example. It also names a complementary tool (list_transactions) for drilling into records. However, it does not explicitly state when NOT to use this tool or exclude alternatives, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_levanta_list_transactionsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full transparency burden. It adds value by disclosing the returned record type (Transaction), the derived ageDays field, and the status categories. However, it omits pagination behavior, default date-window handling, auth prerequisites, and date format details, which are relevant for a list operation with cursor/limit/offset params.

  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 compact and front-loaded: it states the core behavior first, then adds usage cues and output hints. Every sentence earns its place without redundancy or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 9 optional parameters, no annotations, and no output schema, so the description needs to be more exhaustive. It covers purpose, usage, and a key derived field, but it omits pagination, default window behavior, auth expectations, and a fuller sense of the returned records. It is useful but not fully complete for this complexity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds meaning for the window (from/to), specific programme (programmeId), and status values (earned/pending/reversed/paid). However, it does not explain pagination params (limit/cursor/offset) or the semantics of minAgeDays/maxAgeDays beyond the implied ageDays mention, leaving major gaps.

  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 ('List affiliate transactions') with a clear resource ('on Levanta'), and further scopes by status, time window, or programme. It distinguishes from siblings like get_earnings_summary and list_clicks by focusing on transaction records and mentioning pair usage.

  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?

  It explicitly says 'Use this when' with concrete user queries, and suggests pairing with get_earnings_summary for aggregate totals. It does not explicitly state when not to use it or contrast with list_clicks, but the context is clear enough for an agent to choose it appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_linkconnector_list_clicksA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full responsibility for behavioral disclosure. It reveals it's a read operation ('List'), specifies the output ('Returns Click records'), and provides context via the traffic-debugging use case. However, it omits important operational behaviors like pagination (cursor/offset/limit), date format expectations, or what 'recent' means in terms of a default time window.

  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 three concise sentences, front-loaded with the core purpose. Every sentence adds value: purpose, use case with examples, and output/complement. 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?

  The description provides the essential purpose, use case, filter hints, and a relationship to list_transactions, which is helpful. However, with no annotations and no output schema, it leaves gaps around pagination parameters (cursor, offset, limit) and the structure of Click records. For a moderately complex tool with six optional parameters, this is a meaningful omission.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds meaning for 'programme and date' (mapping to programmeId, from, to), clarifying they are filter parameters. But it completely omits limit, cursor, and offset, leaving the agent without guidance on how to paginate or control the result size. This partial coverage earns a mid-range score.

  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 tool's function: 'List recent affiliate clicks on LinkConnector, optionally filtered by programme and date.' This is a specific verb+resource+scope statement that distinguishes it from sibling tools like list_transactions and other network-specific list_clicks tools. The mention of 'recent' and filtering adds precision.

  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 explicit use cases ('traffic-side debugging', 'are my links being clicked at all?') and suggests pairing with list_transactions to compare clicks vs conversions, which identifies an alternative/complement. It does not explicitly state when NOT to use it, but the context effectively implies when list_transactions would be more appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_lomadee_generate_tracking_linkA
  3.9/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 does add 'Returns a TrackingLink' and a prerequisite to confirm programmeId, which is useful. However, it does not disclose authentication requirements, error behavior, or other side effects, leaving some transparency 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?

  The description is three sentences, all information-dense and front-loaded with the action. Every sentence adds value: purpose, usage context, return type, and a prerequisite. No fluff or repetition.

  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 tool with no output schema or annotations, the description covers the core purpose, usage context, return value, and a required prerequisite. It lacks additional context like authentication or error handling, but these may be less critical given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for the schema's bare strings. It only refers to 'given programme and destination URL' without adding details about ID format, URL constraints, or examples. This falls short of what an agent needs to correctly populate the parameters.

  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 it generates a tracking link on Lomadee for a programme and destination URL. This distinguishes it from other network-specific generate_tracking_link tools in the sibling list, and the verb 'generate' plus resource 'tracking link' is specific.

  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?

  It provides explicit when-to-use guidance: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to confirm the programmeId. However, it does not explicitly mention when not to use it or name alternative tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_monetizze_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of behavioral disclosure. It adds useful context: returns an EarningsSummary with oldestUnpaidAgeDays, and implies a read-only aggregation ('summarise'). However, it does not explicitly state that it is read-only, nor does it mention authentication requirements, rate limits, or edge cases like date window defaults or empty results.

  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 concise and well-structured: two sentences that front-load the purpose, then provide usage context and a cross-reference. Every sentence adds value, including an example and the return field mention.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 8 parameters, no required fields, no output schema, and no annotations. The description gives an overview but fails to explain return structure beyond one field, parameter semantics for filtering, pagination behavior, or the meaning of maxAgeDays/minAgeDays. This is insufficient for confident invocation without additional assumptions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It hints at date window (from/to), programme (programmeId), and status (status), but leaves five other parameters (limit, cursor, maxAgeDays, minAgeDays) unexplained. The description does not clarify how these parameters affect the summary, especially pagination and age-based filters.

  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 tool's function: 'Summarise earnings on Monetizze across a date window, with breakdowns by programme and by transaction status.' It uses a specific verb (summarise), identifies the resource (earnings on Monetizze), and distinguishes itself from sibling tools like list_transactions by emphasizing the summary/aggregate nature.

  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?

  Explicit guidance is provided: 'Use this when the user wants a single-figure answer plus context' and 'pair with list_transactions to drill into the underlying records.' This clearly states when to use this tool versus alternatives, including a concrete example.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_offer18_generate_tracking_linkA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description is the sole source of behavioral info. It discloses the return type ('Returns a TrackingLink') and a prerequisite (confirm programmeId via list_programmes), but does not mention authentication needs, side effects, or error behavior. This is moderate transparency but leaves gaps expected for an external API call.

  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?

  Three sentences with the core action front-loaded. No redundant filler; each sentence adds a new piece of information (what it does, when to use, and how to prepare).

  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 2-parameter tool with no output schema, the description covers the expected inputs, the prerequisite for obtaining a programmeId, and the return type. It is not overburdened by complexity, but lacks details on error conditions and URL formatting. Overall it is sufficient to guide an agent through correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description mentions 'programme' and 'destination URL' which map to the two parameters, but these are nearly identical to the parameter names (programmeId, destinationUrl). With 0% schema description coverage, it should add more semantic detail such as the format of destinationUrl or what a valid programmeId looks like. It does not go beyond what the parameter names already imply.

  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?

  Clearly states it 'Generate a tracking link on Offer18 for a given programme and destination URL.' Names the specific platform (Offer18) and the action, distinguishing it from sibling generate_tracking_link tools for other networks. Also explains the end-user goal: 'to share an affiliate link to a specific product or page on a merchant they have joined.'

  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?

  Provides explicit guidance: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also recommends pairing with a sibling tool: 'pair with list_programmes to confirm the programmeId before calling,' which tells the agent how to obtain a valid parameter. It does not explicitly exclude cases, but the context is sufficient for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_offer18_list_transactionsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries full burden. It discloses that the tool returns Transaction records including derived ageDays, which is useful. However, it does not mention whether the operation is read-only, any default date ranges, pagination behavior, or permission requirements. The description adds some behavioral context but lacks comprehensive disclosure.

  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 three sentences, front-loading the core action, then providing usage examples, and finally return details and pairing. Every sentence adds value without verbosity; the structure is logical and scannable for an agent.

  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 9 optional parameters, no output schema, and no annotations, the description provides a solid overview but omits key details like pagination, parameter formats, and edge cases. It explains the return type and use cases, but for a tool with this complexity, a complete description would need to cover more parameter behavior and response defaults.

  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 has 9 parameters with 0% coverage, so the description must compensate. It implicitly covers 'from'/'to' via 'within a window', 'programmeId' via 'specific programme', and 'status' via the status list. However, it does not explain limit, cursor, offset, maxAgeDays, or minAgeDays, leaving these opaque. The description adds meaning for some parameters but not all.

  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 tool's function: 'List affiliate transactions... on Offer18' with specific status categories (earned, pending, reversed, paid) and filtering by time window or programme. This distinguishes it from sibling list_transactions tools by naming Offer18 and enumerating exactly what transaction states are included, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit usage guidance is given via example user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and a complementary tool is named ('pair with get_earnings_summary for aggregate totals'). However, it does not explicitly state when NOT to use this tool (e.g., for clicks), leaving a slight gap in exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerize_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It discloses key behavioral aspects such as the return of an EarningsSummary, the inclusion of oldestUnpaidAgeDays, and the aggregate nature vs. list_transactions. However, it omits details about pagination, date format requirements, or whether authentication is needed, leaving some behavioral gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences with no waste. It front-loads the purpose, provides a usage example, and ends with a useful pairing note. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 8 parameters, no output schema, and no annotations. The description covers the core purpose, use case, a return field, and a sibling relationship, but it leaves the output structure vague and does not address all parameters (e.g., limit, cursor) or edge cases. This makes it viable but not 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?

  With 8 parameters and 0% schema description coverage, the description adds meaning for date window (from/to), programme breakdown (programmeId), and status split (status), plus hints about age via oldestUnpaidAgeDays. However, limit and cursor are not explained, and date formats are unspecified, so parameter semantics are only partially compensated.

  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 ('Summarise earnings') with a clear resource (Partnerize) and scope (date window, breakdowns by programme and transaction status). It also distinguishes itself from sibling list_transactions tools by emphasizing a single-figure answer with context.

  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 explicitly states when to use the tool ('Use this when the user wants a single-figure answer plus context') and gives a concrete example. It also names list_transactions as the complement for drilling into underlying records, but it does not explicitly state when not 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.

• affiliate_partnerize_list_transactionsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry behavioral detail. It reveals that records include derived ageDays and appear to be read-only (listing), but it doesn't mention pagination behavior, default date ranges, status value formats, or authentication requirements. Some value beyond schema, but not deep.

  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?

  Three sentences: purpose, usage examples, and return/complement. Front-loaded and every sentence earns its place. No redundancy or filler.

  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 9 parameters and no output schema or annotations, the description covers the core semantics and return shape (Transaction records with ageDays), but it omits pagination, defaults, and detailed parameter syntax. It's useful but not fully complete for complex invocations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It does explain 'window' (from/to), 'programme' (programmeId), and statuses (pending/reversed/paid), and references ageDays. However, pagination parameters (limit, cursor, offset) and minAgeDays/maxAgeDays are not described, leaving several parameters ambiguous.

  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?

  Description clearly states 'List affiliate transactions... on Partnerize' with a specific verb and resource, and enumerates statuses (earned, pending, reversed, paid) and scope (window or programme). This distinguishes it from the many sibling list_transactions tools for other networks.

  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?

  Provides explicit use cases: 'what did I earn last month?', 'what's still pending?', or 'show me reversed sales'. Also recommends pairing with get_earnings_summary for aggregate totals, offering complementary guidance, though it doesn't explicitly state when not 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.

• affiliate_partnerstack_generate_tracking_linkA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses that the tool returns a TrackingLink and emphasizes confirming programmeId first, which provides some behavioral context. However, it does not mention authentication requirements, potential errors, side effects, or link format details. It is adequate but not rich.

  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 three sentences, concise and front-loaded. The first sentence states the action and inputs, the second gives usage context, and the third notes the return type and prerequisite. No redundant wording.

  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 tool with only two simple required parameters, the description covers the essential selection criteria, usage scenario, return type, and a key prerequisite. It does not describe error cases or output structure in detail, but given the low complexity, it is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It references 'programme and destination URL' but only at a high level, mirroring the parameter names without adding format, constraints, or examples. The instruction to confirm programmeId adds a little guidance, but overall the parameters remain underspecified.

  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 'Generate a tracking link on PartnerStack for a given programme and destination URL', naming the specific action, platform, and key inputs. It distinguishes from sibling tools by explicitly naming PartnerStack and referencing affiliate link sharing.

  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 explicitly states when to use: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also provides a practical directive to 'pair with list_programmes to confirm the programmeId before calling.' It lacks explicit alternatives or when-not-to-use, but the context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerstack_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must disclose behavioral traits. It mentions the return type (EarningsSummary including oldestUnpaidAgeDays) and the breakdown dimension, but does not mention auth requirements, pagination behavior, or what the summary object structurally contains beyond one field. This provides some context but leaves 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?

  Two sentences, each with clear value: the first defines the action and breakdowns, the second gives usage guidance, an example, return info, and a pairing suggestion. 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 tool has 8 parameters and no output schema, the description explains the core purpose and gives a usage example, but lacks details on parameter formats (e.g., date window syntax, status values) and the full return shape. It is adequate for tool selection but not fully complete for invocation without additional inference.

  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 0%, so the description must compensate. It explains 'date window' (from/to), 'transaction status' (status), and 'programme' (programmeId), but leaves limit, cursor, maxAgeDays, minAgeDays unexplained. Partial compensation only.

  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 precisely states what the tool does: 'Summarise earnings on PartnerStack across a date window, with breakdowns by programme and by transaction status.' It clearly names the platform, the resource (earnings), and the action (summarise), and differentiates itself from sibling tools like list_transactions by noting it provides a single-figure answer with context.

  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 explicitly says 'Use this when the user wants a single-figure answer plus context', providing a clear trigger condition with an example. It also recommends pairing with list_transactions for deeper detail. However, it does not explicitly state when not to use it, so it falls short of a full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerstack_list_transactionsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It clearly indicates a read-only list operation and mentions the derived ageDays field in return records. However, it does not disclose pagination behavior, rate limits, or what happens with large result sets, which are relevant for a list 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 two concise sentences, front-loaded with the primary verb and resource, and every clause adds meaningful context (statuses, filters, usage examples, pairing). No wasted words.

  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?

  Despite having no output schema and nine parameters, the description offers a reasonable overview but lacks details on return fields (only mentions ageDays), pagination, and parameter semantics for pagination/age filters. It is adequate for basic use but incomplete for complex queries.

  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 0%, so the description must compensate. It explains 'window' (implying from/to), 'specific programme' (programmeId), and statuses that map to the status parameter. But it does not explain limit, cursor, offset, minAgeDays, or maxAgeDays, leaving many parameters underspecified.

  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 tool lists affiliate transactions on PartnerStack, with specific statuses (earned, pending, reversed, paid) and filtering by window or programme. This distinguishes it from sibling tools like get_earnings_summary and list_clicks.

  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?

  It provides explicit example user queries ('what did I earn last month?') and recommends pairing with get_earnings_summary for aggregates, which gives clear when-to-use guidance. However, it does not explicitly exclude other tools like list_clicks, though the examples imply the appropriate scope.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_pepperjam_list_clicksA
  3.9/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 burden but only states that it lists recent clicks and returns click records. It doesn't describe pagination behavior, default date ranges, or any side effects. The schema hints at pagination through cursor/offset/limit, but the description itself doesn't add this context. It's not misleading, but it's minimal.

  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 three sentences with no redundancy. It front-loads the core function, gives practical use cases, and closes with return type and a pairing recommendation. Every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has six optional parameters and no output schema. The description covers the core purpose and use case but omits details about pagination, default behaviors, and the structure of click records. While it's competently written for a simple list tool, the lack of parameter and return details makes it only partially complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It mentions filtering by 'programme and date', which covers programmeId, from, and to, but it doesn't explain the pagination parameters (limit, cursor, offset) or the exact date format. This is a partial compensation, leaving some parameters undocumented.

  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 clear action ('List recent affiliate clicks on Pepperjam'), specifies the resource (affiliate clicks on Pepperjam), and notes optional filters. It also provides example use cases ('are my links being clicked at all?') and distinguishes the tool from transaction listings by recommending pairing with list_transactions.

  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 explicitly says 'Use this for traffic-side debugging' and gives concrete example questions, which tells the agent when to use it. It also recommends pairing with list_transactions to compare clicks vs conversions. However, it doesn't explicitly state when not to use it, so it falls short of a perfect 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_post-affiliate-pro_generate_tracking_linkA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the return type ('Returns a TrackingLink') and hints at the need for a valid programmeId by advising to confirm it via list_programmes. However, it does not mention side effects, error handling, authentication requirements, or behavior on invalid input, so transparency is only partial.

  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?

  Three concise sentences, each with a distinct purpose: what it does, when to use it, and what it returns plus a prerequisite. No redundant or filler language, making it easy to parse.

  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 description covers the core purpose, usage scenario, return type, and a prerequisite, but the missing explanation for 'brand' is a significant gap, especially since all parameters are required and there is no output schema. Without knowing what 'brand' represents, an agent may not be able to invoke the tool correctly. Overall, it is adequate but not complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds meaning for programmeId (confirm via list_programmes) and destinationUrl (explicitly called 'destination URL'), but the required 'brand' parameter is not explained at all, leaving an important parameter ambiguous.

  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 action ('Generate'), the resource ('a tracking link on Post Affiliate Pro'), and the key parameters ('given programme and destination URL'). It distinguishes itself from sibling generate_tracking_link tools by naming the specific platform, 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says when to use the tool ('when the user wants to share an affiliate link to a specific product or page on a merchant they have joined') and recommends pairing with list_programmes to confirm the programmeId. However, it does not mention when not to use it or provide alternatives, leaving a small gap for full guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_rakuten_list_transactionsA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses that the tool returns Transaction records including a derived ageDays field and supports date-window or programme filtering. However, it does not mention pagination, default limits, authentication needs, or read-only nature, leaving some behavioral traits uncovered.

  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?

  Three sentences, each adding unique value: purpose and scope, example queries, and return type plus a pairing guideline. No redundancy or filler; fully front-loaded.

  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 9-parameter tool with no output schema and no annotations, the description covers core functionality, examples, and the derived ageDays field. However, it leaves pagination parameters, date format, and full response structure undocumented, which are gaps given the tool's complexity.

  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 has 0% description coverage, but the description adds meaning by mapping key concepts: date windows (from/to), programme filtering (programmeId), and statuses (earned, pending, reversed, paid). It does not explain limit, cursor, offset, or min/maxAgeDays explicitly, so parameter coverage remains partial.

  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 tool lists affiliate transactions on Rakuten Advertising, with specific statuses (earned, pending, reversed, paid) and filtering options (window or programme). It distinguishes from sibling tools like list_clicks and get_earnings_summary by focusing on transactions and even suggests pairing with the summary tool.

  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 explicit example queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and recommends pairing with get_earnings_summary for aggregate totals. It lacks an explicit 'when not to use' statement, but the provided context strongly signals appropriate usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_refersion_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must disclose behavioral traits itself. It mentions the return value ('Returns an EarningsSummary including oldestUnpaidAgeDays'), which gives useful outcome context. However, it does not explicitly state that the operation is read-only, nor does it mention auth requirements, rate limits, or any potential side effects. For a summary tool this is adequate but not exhaustive.

  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?

  Three sentences, each serving a distinct purpose: what it does, when to use it, and what it returns with a cross-reference. Front-loaded with the core action and free of fluff or repetition.

  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 description captures the main use case well but is incomplete for a tool with 9 parameters, no annotations, and no output schema. It omits nearly all parameter semantics except the three main breakdowns, and only mentions one return field despite the complexity. The agent would still be uncertain about required fields, pagination behavior, and filtering options.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It explains the date window (from/to), programme breakdown (programmeId), and status split (status), but leaves the required 'brand' parameter, pagination controls (limit, cursor), and age filters (maxAgeDays, minAgeDays) undocumented. This is a significant gap for a 9-parameter tool.

  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 opens with 'Summarise earnings on Refersion', which is a specific verb+resource combination. It clearly differentiates from sibling tools by mentioning breakdowns by programme and status, and explicitly references pairing with list_transactions for drill-down, setting it apart from the transaction-level tool.

  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?

  Explicitly states 'Use this when the user wants a single-figure answer plus context' and provides a concrete example ('total earnings in Q1 with status split'). It also names the alternative for deeper analysis ('pair with list_transactions to drill into the underlying records'), giving clear when-to-use and when-to-use-something-else guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_refersion_get_programme_performanceA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description is the only source for behavioral context. It discloses the return type (ProgrammePerformanceRow records) and implies aggregation by date/publisher. However, it does not mention pagination (despite limit/cursor/offset params), authentication requirements, or how the metrics are calculated. While it adds some value, the burden on the description without annotations is only partially met.

  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 three sentences: a concise definition, usage triggers, and a pointer to related tools. It is front-loaded with the core purpose and contains no redundant phrases or noise.

  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?

  With 8 parameters, no output schema, and no annotations, the description is too thin to fully guide an agent. It omits parameter details, pagination handling, and return field descriptions. Although it gives a useful overview, it does not provide enough operational detail for a tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 0% description coverage, so the description must compensate. It loosely ties 'brand's programme' to the brand parameter and suggests date/publisher context, but it does not explain the format or semantics of from/to, programmeId, publisherId, limit, cursor, or offset. The description adds minimal meaning beyond the bare 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 opens with a specific verb and resource: 'Fetch per-publisher performance for the brand's programme at Refersion' and enumerates metrics (clicks, conversions, gross sale, commission) and date granularity. It distinguishes from sibling tools like list_transactions and get_programme by focusing on the per-publisher rollup.

  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 explicitly states when to use the tool with natural-language examples ('how is each publisher performing on Refersion?', 'show me the top-earning partners last month'). It also references companion tools: 'pair with list_media_partners to discover publisher ids and list_transactions for transaction-level drill-down', which signals when to use alternatives for deeper detail.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_rewardful_generate_tracking_linkA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It adds value by stating 'Returns a TrackingLink' and advising to confirm programmeId via list_programmes. However, it does not disclose whether the operation has side effects (e.g., creates a record on Rewardful), requires authentication, or handles errors. The return type is named but not detailed, which is a moderate gap given no 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 three tight sentences, each providing distinct value: action, usage scenario, and return/prerequisite. It is front-loaded with the core purpose and wastes no words.

  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 tool with three required parameters, no annotations, and no output schema, the description covers the main purpose, a usage context, the return type, and a prerequisite. However, the brand parameter is left undefined, and the TrackingLink return type is not detailed. Overall, it is sufficiently complete for a simple link generation tool, with only minor gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero descriptions, so the description must compensate. It mentions 'programme' (programmeId) and 'destination URL' (destinationUrl), but the 'brand' parameter is completely unexplained. Since all three parameters are required and the schema provides no meanings, this omission leaves the agent guessing about a required input. The description also gives no format or validation hints for the mentioned parameters.

  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 action ('Generate a tracking link'), the resource ('on Rewardful'), and the key inputs ('programme and destination URL'). It also mentions the return type, which helps distinguish it from other network-specific tools. The description differentiates from siblings by specifying 'on Rewardful'.

  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 explicit usage context: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also provides a prerequisite by suggesting pairing with list_programmes to confirm the programmeId. However, it does not explicitly name alternatives or when not to use this tool, but the 'on Rewardful' phrasing implicitly distinguishes it from sibling network tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tapfiliate_list_clicksA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses that it returns Click records and supports optional filtering, but does not explain pagination, date range interpretation, auth requirements, or rate limits. 'Recent' is vague.

  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 with no filler. It front-loads the core purpose, then adds usage guidance and output type efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This 7-parameter tool has no annotations and no output schema, yet the description only covers purpose, basic filters, and the return type. It fails to explain the required brand parameter or pagination semantics, leaving the agent under-informed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It only explains 'programme and date' filters (mapping to programmeId, from, and to), but omits the required 'brand' parameter and says nothing about limit, cursor, or offset.

  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 verb+resource: 'List recent affiliate clicks on Tapfiliate.' It also distinguishes from siblings by framing it as traffic-side debugging and explicitly referencing list_transactions for conversion comparison.

  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?

  It provides explicit usage context ('traffic-side debugging') with concrete example questions ('are my links being clicked at all?') and recommends pairing with list_transactions to compare clicks vs conversions. This clearly tells the agent when 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.

• affiliate_tolt_list_transactionsA
  3.9/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 return information (Transaction records including derived ageDays) and notes filtering options, but it does not mention pagination, default time window, sorting, or authentication requirements. This is adequate but leaves room for more 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 three sentences, front-loaded with the primary purpose, then usage triggers, then return details and a pairing suggestion. Every sentence provides distinct value and there is no filler or repetition.

  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 complexity (10 parameters, no output schema, no annotations), the description covers the main use case and return shape but omits critical operational details like pagination behavior, parameter formats, required brand handling, and default window semantics. This is insufficient for reliable invocation without additional information.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for explaining all 10 parameters. It maps high-level concepts to some parameters: 'window' hints at from/to, 'specific programme' hints at programmeId, and status examples map to the status field. However, it does not explain required 'brand', pagination parameters (limit, cursor, offset), or age-day filters (minAgeDays, maxAgeDays), leaving many parameters under-documented.

  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 starts with 'List affiliate transactions' on Tolt, explicitly naming the resource (transactions) and platform (Tolt), and scopes it by window or programme. It also mentions specific statuses (commissions earned, pending, reversed, paid) and distinguishes itself from aggregate tools by recommending pairing with get_earnings_summary.

  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 gives concrete example user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') that signal when to use this tool. It also explicitly recommends pairing with get_earnings_summary for aggregate totals, effectively directing users away from using this tool for aggregated data.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradedoubler-advertiser_list_programmesA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of behavioral disclosure. It does reveal that the return is an array of Programme records and that results may include joined or available programmes. However, it omits important behavioral traits such as pagination semantics, filtering behavior, and whether the operation is read-only or requires specific auth, which are not covered by 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 three sentences, front-loaded with the core purpose, followed by usage triggers and complementary tools. Every sentence provides distinct value with no redundancy or filler.

  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 has 7 parameters, no output schema, and no annotations, the description is incomplete. It does not explain the meaning of the required 'brand' parameter, nor does it describe output structure beyond 'an array of Programme records'. It covers when to use the tool but not the operational details needed to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for parameter meaning, but it does not. It mentions no parameter except by implication via 'brand' in the required fields, and leaves limit, cursor, offset, search, status, and categories unexplained. The self-evident names provide minimal guidance, but 'brand' is ambiguous, and the description fails to clarify how filtering or pagination works.

  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 tool lists affiliate programmes for Tradedoubler (Advertiser), differentiating it from the sibling tradedoubler_list_programmes via the '(Advertiser)' qualifier. It provides concrete example user queries and a specific verb-resource pairing ('List affiliate programmes'), making the tool's scope unambiguous.

  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 explicitly states when to use the tool ('Use this when the user asks...') and gives example phrasings. It also suggests complementary tools (get_programme for drill-down, list_transactions for activity), providing clear guidance on workflow integration and alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradetracker_generate_tracking_linkA
  3.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full burden for behavioral disclosure, but only says 'Returns a TrackingLink' without mentioning side effects, auth requirements, rate limits, or whether this creates a persistent resource. The operation's safety profile is unclear for an agent.

  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?

  Two sentences, front-loaded with the core purpose, and every sentence earns its place. No filler or redundancy; the use case and pairing hint are valuable additions.

  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 simple two-parameter tool, the description provides core purpose and usage context. However, it omits the authentication prerequisite (common across sibling networks) and gives no detail on the shape or nature of the TrackingLink return value, leaving gaps for an agent to infer safely.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description should compensate. It does reference both parameters ('given programme and destination URL') which matches the schema, but adds no format details, constraints, or examples beyond the parameter names themselves.

  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 'Generate a tracking link on TradeTracker for a given programme and destination URL' with a specific verb and resource, distinguishing it from sibling tools by network and action. It also specifies the exact inputs, making the purpose unmistakable.

  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?

  Explicitly says to use when 'the user wants to share an affiliate link to a specific product or page on a merchant they have joined' and recommends pairing with list_programmes to confirm the programmeId before calling. This provides clear context and a specific alternative/preparatory step.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_travelpayouts_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations exist, so the description carries the burden. It adds useful behavioral context by revealing the return type (EarningsSummary) and a specific field (oldestUnpaidAgeDays), but it does not explicitly declare read-only behavior, authentication needs, or how filters like age/date boundaries affect the query.

  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?

  Three sentences, front-loaded with the core purpose, and no redundant wording. Every sentence earns its place: purpose, usage, and a useful return insight.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite a well-articulated purpose, the description omits explanations for half the parameters, offers only a partial return structure, and lacks essential context like pagination behavior and required fields. With no annotations, no output schema, and 0% schema description coverage, this is a significant gap for an 8-parameter tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must explain parameters. It maps the date window (from/to), programme breakdown (programmeId), and status (status), but leaves limit, cursor, maxAgeDays, and minAgeDays completely unexplained. The agent is left guessing about a large portion of the input 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 clearly states the tool summarizes Travelpayouts earnings over a date window with breakdowns by programme and status, distinguishing it from list_transactions by the 'single-figure answer plus context' framing. The verb 'Summarise' plus the specific resource and scope make the purpose unmistakable.

  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?

  It explicitly says 'Use this when the user wants a single-figure answer plus context' and suggests pairing with list_transactions for drill-down. This is direct, actionable guidance on when to select this tool over alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_travelpayouts_list_programmesA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden. It discloses the return type ('array of Programme records') and the scope (joined vs. available to join), but does not mention pagination behavior, auth requirements, or how the optional filters affect results. For a simple list operation this is adequate but not rich.

  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 three sentences, leads with the core purpose, then usage triggers, then return format and companion tools. Every sentence adds value with no waste or 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?

  For a tool with six optional parameters and no output schema, the description covers purpose, user intent, return format, and related tools. However, it omits details about the Programme record structure and parameter semantics, which would improve completeness. Still, it provides enough for basic selection and invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% and the description makes no mention of limit, cursor, offset, search, status, or categories. While parameter names are self-explanatory, the description does not add meaning beyond the raw schema, failing to compensate for the lack of property descriptions.

  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+resource ('List affiliate programmes') and clearly scopes it to Travelpayouts. It distinguishes from sibling list_programmes tools by network and includes example user queries that make the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit trigger phrases ('which merchants am I working with?', 'what programmes do I have on Travelpayouts?') and suggests pairing with get_programme and list_transactions. It lacks explicit exclusions for when not to use it (e.g., other networks), but the context is strong.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tune_list_programmesA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of behavioral disclosure. It does state the return type ('array of Programme records') and scope (joined or available), but omits details about pagination, filtering behavior, authentication requirements, or potential edge cases, which are relevant given the multiple parameters.

  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 concise and well-structured: three sentences covering purpose, usage examples, and return type/related tools. Every sentence provides value, with the core purpose front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite clear purpose and usage, the tool has six undocumented parameters, no annotations, and no output schema. The description does not convey parameter semantics or behavioral details like pagination and filtering, making it insufficient for fully correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. However, it does not explain any of the six parameters (limit, cursor, offset, search, status, categories) or how they map to the two modes (joined vs. available). The mention of 'joined' and 'available' is an implicit hint but not explicitly tied to a parameter.

  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 tool's function: 'List affiliate programmes the publisher has joined on TUNE (or which are available to join).' It uses a specific verb ('List') and resource ('affiliate programmes') with an explicit platform (TUNE) and scope, which distinguishes it from sibling list_programmes tools for other networks.

  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 when-to-use guidance with example user queries ('which merchants am I working with?', 'what programmes do I have on TUNE?') and mentions complementary tools (get_programme for drill-down, list_transactions for activity), effectively signaling when alternatives should be used.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_webgains_get_earnings_summaryA
  3.9/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations exist, so the description carries the full burden. It discloses a return field ('oldestUnpaidAgeDays') and implies a read-only summarization, but it does not detail pagination, authentication needs, or explicitly state it is non-destructive. The return type mention adds some value but leaves 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?

  The description is two sentences, front-loaded with purpose, and every sentence adds value. It is concise without being terse, covering purpose, use case, return type, and a hint at complementary tools.

  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?

  With 8 parameters, no output schema, and no annotations, the description is not sufficient. It provides only vague parameter hints and partial return structure, leaving the agent uncertain about pagination, defaults, and the full response shape.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only hints at date window, programme, and status, which map to 'from/to', 'programmeId', and 'status'. It fails to explain 'limit', 'cursor', 'maxAgeDays', and 'minAgeDays', so the agent lacks the semantics for over half the parameters.

  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 identifies the tool as summarizing earnings on Webgains, with a specific verb ('Summarise') and resource ('earnings'), and distinguishes it from sibling tools by mentioning breakdowns by programme and status. It also aligns with the tool name, providing enough detail to differentiate from 'list_transactions'.

  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?

  Explicitly states when to use it: 'when the user wants a single-figure answer plus context', with a concrete example. It also suggests pairing with 'list_transactions' for deeper drill-down, giving clear context on the complementary alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_2performant_list_clicksA
  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 the read-only nature ('List') and return type ('Returns Click records'), which is useful. However, it omits pagination behavior (cursor/limit/offset), the default time window implied by 'recent,' and any auth prerequisites.

  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?

  Three well-structured sentences: core purpose first, then concrete use-case examples, then return-type and cross-tool guidance. Every sentence earns its place with 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?

  With no output schema or annotations, the description must cover a lot. It succeeds on use-case guidance and naming return records, but leaves gaps on pagination mechanics, date format, and what fields a 'Click record' contains. It is adequate for deciding whether to call, but incomplete for correct invocation with all six parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds conceptual meaning for programme and date filtering (programmeId, from/to) but gives no format or syntax details. The pagination parameters (limit, cursor, offset) are entirely unexplained in both the schema and the description.

  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+resource: 'List recent affiliate clicks on 2Performant' and adds scope with 'optionally filtered by programme and date.' It clearly distinguishes itself from the many sibling list_* tools by naming the network (2Performant) and from 2Performant's own list_programmes/list_transactions tools by targeting the click resource.

  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?

  Explicit guidance is provided: 'Use this for traffic-side debugging' with concrete example questions ('are my links being clicked at all?'). It also names an alternative/complement: 'pair with list_transactions to compare clicks vs conversions,' which tells the agent when to use a different tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_accesstrade_generate_tracking_linkA
  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 a prerequisite ('pair with list_programmes to confirm the programmeId') and mentions the return type ('Returns a TrackingLink'). However, it doesn't state whether the operation has side effects, requires specific auth, or handles errors. This is moderate transparency but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the primary action, followed by usage context, return type, and a workflow tip. No redundant words. Every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 2-parameter tool with no output schema, the description is quite complete: it states what it does, when to use it, a prerequisite, and the return type. It doesn't cover error scenarios, but that's likely acceptable given the tool's simplicity. The mention of 'merchant they have joined' adds useful context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It names the parameters in prose ('programme and destination URL') but adds little beyond the schema field names. The pairing instruction for programmeId is useful, but destinationUrl semantics are not elaborated (e.g., format, whether it must be a valid URL). Partial compensation.

  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 tool's action: 'Generate a tracking link on AccessTrade for a given programme and destination URL.' This is a specific verb+resource+scope that distinguishes it from sibling tools for other networks. It also adds the use case 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.'

  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?

  Provides clear when-to-use context: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to confirm the programmeId before calling. While it doesn't explicitly list when-not-to-use or alternatives, the context is clear and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adcell_list_transactionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations exist, so the description carries the burden. It adds useful context: returns Transaction records with derived ageDays and supports status filtering. However, it does not mention pagination, auth requirements, rate limits, or side effects, leaving some behavioral gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, all relevant: purpose, usage triggers, and return/pairing hints. It is concise with no fluff, though the second sentence is a bit dense with embedded quotes.

  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 9-parameter tool with no output schema or annotations, the description gives a good high-level overview and common use cases, but it lacks details on pagination (cursor/offset/limit), age filters, and parameter syntax. It is adequate for basic queries but not fully complete for advanced usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It explains from/to as a 'window', programmeId as a 'specific programme', and status via examples. But it omits limit, cursor, offset, maxAgeDays, and minAgeDays, which are not self-explanatory.

  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?

  Clearly states the tool lists affiliate transactions on Adcell with statuses (earned, pending, reversed, paid) and supports time-window or programme filtering. It distinguishes itself from sibling tools like get_earnings_summary by noting it returns individual records rather than aggregates.

  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?

  Explicitly gives example user queries ('what did I earn last month?', 'what's still pending?') and recommends pairing with get_earnings_summary for aggregate totals. This provides clear when-to-use context and names an alternative tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_addrevenue_get_earnings_summaryA
  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 the return type (EarningsSummary) and a notable field (oldestUnpaidAgeDays), but does not explicitly state whether the operation is read-only, mention pagination behavior, or note any authentication requirements. The 'Summarise' verb implies non-mutating, but this is not made explicit.

  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 three sentences, front-loading the purpose, then usage guidance, then output/pairing. It is efficient and avoids redundancy, making it easy for an agent 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?

  Given the tool's complexity (8 optional parameters, no output schema, no annotations), the description is incomplete. It covers the main use case and one output field, but does not explain pagination, age filtering, default behavior when no parameters are passed, or the full response structure. This leaves the agent with significant uncertainty.

  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 8 parameters and 0% schema coverage, the description must compensate. It maps 'date window' to to/from, 'programme' to programmeId, and 'status' to status, covering the core concepts. However, it does not explain limit, cursor, maxAgeDays, or minAgeDays, leaving a significant portion of the parameters undocumented.

  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 tool summarises earnings on Addrevenue across a date window with breakdowns by programme and transaction status. It distinguishes itself from sibling tools like list_transactions and list_clicks by explicitly focusing on aggregate summary rather than individual records.

  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 explicitly says 'Use this when the user wants a single-figure answer plus context' and gives a concrete example. It also mentions pairing with list_transactions to drill into underlying records, which provides an alternative when more detail is needed.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_admitad-advertiser_list_clicksA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of disclosing behavior. It states it returns Click records and optionally filters, but doesn't disclose pagination behavior (cursor/offset), default date range for 'recent', or explicitly confirm read-only safety. The verb 'List' implies read-only, but specifics like response structure are absent.

  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?

  Three sentences, each adds value: the action/filters, the use case, and the return type with a cross-tool hint. No redundant or vague fluff.

  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?

  While the description gives a clear use case and return type, it omits essential context for the required brand parameter, pagination semantics, and how 'recent' is defined. Given no annotations and no output schema, the description leaves several operational details uncovered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It only mentions 'programme and date' filters, corresponding to programmeId, from, and to, but leaves the required brand parameter and pagination parameters (limit, cursor, offset) unexplained. This is insufficient for a 7-parameter tool.

  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 tool lists recent affiliate clicks on Admitad for advertisers, with optional filters. It specifies the resource (clicks), platform (Admitad), and perspective (advertiser), distinguishing it from publisher-level listing tools like affiliate_admitad_list_clicks. The use-case examples reinforce its purpose.

  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?

  It explicitly says to use it for traffic-side debugging ('are my links being clicked at all?') and directs pairing with list_transactions to compare clicks vs conversions, implicitly distinguishing it from transaction listing tools. This gives the agent clear when-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_admitad-advertiser_list_media_partnersA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations exist, so the description carries the full burden. It discloses that the tool returns 'MediaPartner records with normalised status' and implies a read-only listing operation. However, it does not mention authentication needs, rate limits, pagination behavior, or any potential side effects, leaving notable gaps for a no-annotation 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 three sentences, each earning its place: purpose, usage triggers, and complementary pairing. No filler or redundancy; well front-loaded with the core action.

  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 6-parameter tool with no output schema and no annotations, the description provides a solid overview but leaves gaps. It doesn't explain any parameter semantics, return fields beyond 'normalised status', or error/pagination behavior. It is minimally viable but not comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description fails to compensate. It only implicitly ties 'brand' to 'the brand's programme' and gives no meaning for limit, cursor, offset, search, or status. This is a significant omission for a 6-parameter tool.

  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 opens with a specific verb+resource: 'List the media partners (publishers) running on the brand's programme at Admitad (advertiser).' It includes concrete example queries and clearly differentiates from sibling tools by naming the Admitad advertiser context.

  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?

  Explicit guidance is provided: 'Use this when the user asks...' with three typical phrasings. It also references the complementary tool 'get_programme_performance' and suggests pairing, which helps the agent decide when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_admitad-advertiser_verify_authA
  4/5.0
  Behavior4/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 the exact return format ({ok:true, identity?} or {ok:false, reason}) and characterizes the call as 'minimal authenticated endpoint', implying a lightweight, read-only operation. However, it does not explicitly state side effects or permissions, which is a minor gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences with clean front-loading: purpose, usage contexts, and return behavior. There is no redundant information and every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers purpose, usage, and return format well for a simple verify operation, but the complete omission of the required 'brand' parameter is a significant gap that prevents it from being fully self-sufficient. Without annotations or an output schema, the description should have compensated by explaining the parameter.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description completely omits any mention of the sole required parameter 'brand'. With 0% schema description coverage, the agent has no guidance on what value to provide or how it relates to the credentials being verified. This is a critical gap.

  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 ('Verify') and identifies the exact resource ('configured credentials for Admitad (advertiser)') and method ('calling a minimal authenticated endpoint'). This clearly distinguishes it from sibling verify tools for other networks and from affiliate_run_diagnostic.

  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?

  Explicitly specifies when to use: at the start of a session, after rotating keys, or when another operation returns an auth error. It also recommends pairing with affiliate_run_diagnostic for a full health check, which defines scope boundaries and alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_admitad_generate_tracking_linkA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the full burden. It discloses the return type (TrackingLink) and implies a prerequisite (joined merchant). However, it does not explain potential errors, authentication requirements, or whether the link generation has side effects. The description adds some context but is not deeply transparent.

  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?

  Three sentences, front-loaded with the core action, followed by usage context and a practical tip. Every sentence earns its place with no fluff or repetition. The structure is clean and easily scannable.

  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 tool with no output schema and no annotations, the description covers the essential selection and invocation context: what it does, when to use it, what it returns, and a workflow tip. It lacks error-handling or parameter-format details, but these are not critical for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description mentions 'programme and destination URL,' which maps directly to the parameters. It does not elaborate on formats or where programmeId comes from beyond a vague pairing hint. The parameter names are self-explanatory, but the description adds minimal semantic value.

  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 action ('Generate a tracking link on Admitad') with specific inputs (programme and destination URL). It distinguishes the tool from sibling network-specific generators by naming Admitad and mentions the return type (TrackingLink). This is specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context for when to use: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to confirm the programmeId. It does not explicitly mention alternatives or exclusions, but the use case is distinct.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_admitad_get_earnings_summaryA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the full burden. It discloses the return type (EarningsSummary) and a specific field (oldestUnpaidAgeDays), and implies a read-only aggregation, but does not mention auth, pagination, rate limits, or how limit/cursor affect the summary.

  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 three focused sentences: purpose, usage scenario, and pairing advice. Each sentence provides distinct value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 8 optional parameters, no annotations, and no output schema, the description is incomplete. It does not explain the full parameter set, the complete return shape beyond one field, or pagination semantics, leaving significant gaps for an agent to reliably invoke the 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?

  The schema has 8 parameters with 0% coverage, and the description adds meaning for the date window (from/to), status breakdown (status), and programme (programmeId). However, limit, cursor, maxAgeDays, and minAgeDays remain unexplained, offering only partial compensation for the missing schema descriptions.

  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 verb 'Summarise earnings' with the resource 'Admitad' and a date-window scope, plus breakdowns by programme and status. This distinguishes it from sibling list_transactions and other network summary tools.

  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?

  Explicitly provides when-to-use guidance: 'Use this when the user wants a single-figure answer plus context' and suggests pairing with list_transactions for deeper detail through 'pair with list_transactions to drill into the underlying records.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adrecord_list_clicksA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of behavioral disclosure. It mentions that the tool returns Click records and is intended for traffic-side debugging, but it does not disclose important behavioral traits like pagination behavior, default date ranges, or whether the operation is read-only. While listing is inherently a read operation, more detail would be needed for full 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 three sentences long and front-loaded with the core purpose. Each sentence adds value: purpose, use case, and return value/complementary tool. No wasted words or redundant repetitions.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 6 parameters, no output schema, and no annotations, so the description needs to cover the essentials. It provides purpose and usage context but leaves out parameter semantics and behavioral details like pagination and defaults. For a list tool, this is partially complete but has clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It only vaguely mentions filtering by 'programme and date,' which maps to programmeId and from/to, but it does not explain limit, cursor, offset, or the exact format/meaning of these parameters. Given 6 parameters and no schema descriptions, this is insufficient for an agent to construct correct invocations.

  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 tool lists recent affiliate clicks on Adrecord with optional filtering by programme and date. It explicitly names the resource (clicks) and platform (Adrecord), distinguishing it from sibling tools like list_transactions by focusing on traffic-side data.

  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 concrete use cases ('are my links being clicked at all?', 'where is traffic going on Adrecord?') and explicitly recommends pairing with list_transactions to compare clicks vs conversions. This gives clear guidance on when to use this tool and even names a complementary alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adtraction-advertiser_get_programmeA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It discloses that this is a fetch/read operation ('Fetch') and that it returns a single Programme with specific fields (commission, status, advertiser URL). However, it does not mention authentication requirements, error behavior when the id is not found, or the role of the brand parameter, leaving some behavioral ambiguity.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences with the core purpose front-loaded. Each sentence earns its place—first states what it does, second gives usage context and return info. No filler.

  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 simple fetch tool with 2 required params and no output schema, the description covers the main purpose, return type, and workflow pairing with list_programmes. However, it omits explanation of the 'brand' parameter and any error/edge-case behavior, so it is not fully complete for an agent to invoke confidently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must clarify parameters. It clarifies 'programmeId' as 'network programme id', but says nothing about 'brand', a required parameter. The agent is left guessing what 'brand' means or how it relates to the Adtraction advertiser context, so the description only partially compensates for missing schema descriptions.

  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 action: 'Fetch a single programme on Adtraction (advertiser) by its network programme id.' It clearly identifies the resource, network variant, and lookup key. It also distinguishes itself from list_programmes by scoping to a single record, and the '(advertiser)' qualifier separates it from the publisher-side programme tool.

  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?

  Explicit usage guidance is provided: 'Use this when you already know the programme id and need its full record.' It also gives an alternative: 'pair with list_programmes when you need to discover the id first,' which tells the agent when not to use this tool and what to use instead.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adtraction_list_programmesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description must carry the full transparency burden. It clarifies the scope (joined or available programmes) and return type (array of Programme records), which is useful. However, it omits whether the operation is read-only, pagination behavior, or rate limits, leaving gaps in behavioral disclosure.

  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?

  Three sentences, each earning its place: first states the core function, second gives concrete use cases, third notes return type and related tools. The structure is front-loaded and free of 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?

  For a tool with 6 optional parameters, no annotations, and no output schema, the description provides a useful high-level overview and names the return type, but it lacks parameter semantics, pagination guidance, and any detail on the Programme record structure. It is enough for selection but not for fully informed invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema lists six parameters (limit, cursor, offset, search, status, categories) with 0% description coverage, and the tool description does not explain any of them. The phrase 'joined or available' hints at possible status filtering but never explicitly maps to the status parameter. The description fails to compensate for the low 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 opens with a specific verb and resource: 'List affiliate programmes the publisher has joined on Adtraction (or which are available to join).' It clearly distinguishes this from sibling list_programmes tools by naming the Adtraction network and from get_programme by its listing scope. Example user queries reinforce the purpose.

  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 trigger phrases ('which merchants am I working with?', 'what programmes do I have on Adtraction?') and tells the agent when to pair with get_programme for drill-down and list_transactions for activity, effectively naming alternatives. This gives clear when-to-use and when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_affilae_generate_tracking_linkA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description is the only source of behavioral disclosure. It adds a return type hint ('Returns a TrackingLink') and a prerequisite ('pair with list_programmes'), but it does not mention side effects, authentication needs, or error behavior. This is useful but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise, front-loaded sentences with no filler. Each sentence contributes: the action, the use case, and the operational prerequisite.

  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 two-parameter generation tool with no output schema, the description covers the purpose, usage context, return type, and a prerequisite. It doesn't show an example or detail the contents of the TrackingLink, but it is largely complete for its simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for the bare string parameters. It clarifies that programmeId should be confirmed via list_programmes and identifies destinationUrl as the link target. However, it doesn't explain URL format requirements or any constraints on the parameters.

  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 opens with 'Generate a tracking link on Affilae', which clearly states the action, the platform, and the resource. It distinguishes this tool from sibling network-specific tracking link tools by naming Affilae explicitly.

  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?

  It explicitly states when to use: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to confirm the programmeId. It doesn't explicitly name alternative tools to avoid, so it falls just short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_affiliate-future_generate_tracking_linkA
  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 discloses the return type ('Returns a TrackingLink') and hints at failure prevention ('confirm the programmeId before calling'), but does not mention side effects, authentication requirements, or error behavior. This is adequate but not rich.

  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?

  Three sentences, each with clear value: action, usage context, return type and prerequisite. No redundant phrasing or filler. Front-loaded with the core purpose.

  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 two-parameter tool with no output schema, the description covers the core action, when to use, return type, and a key integration step (list_programmes). It is reasonably complete for an agent to select and invoke the tool, though it omits details like authentication or link formatting.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It identifies both parameters ('programme' and 'destination URL') and connects programmeId to list_programmes for lookup. However, it adds no format, constraints, or examples, leaving gaps for an agent needing precise input semantics.

  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 ('Generate'), resource ('tracking link on Affiliate Future'), and inputs ('given programme and destination URL'). It clearly distinguishes from sibling tools by naming the Affiliate Future network and is unambiguous about its function.

  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?

  Explicitly states when to use ('when the user wants to share an affiliate link to a specific product or page on a merchant they have joined') and provides a practical prerequisite ('pair with list_programmes to confirm the programmeId before calling'). It lacks explicit when-not-to-use or alternative tool mentions, but the context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_affise_generate_tracking_linkA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of behavioral disclosure. It does mention 'Returns a TrackingLink' and advises confirming the programmeId, which sets expectations for the output and a precondition. However, it doesn't discuss potential side effects, authorization requirements, or error behavior if the programmeId is invalid, leaving some ambiguity for a generation 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 two sentences with no filler. It front-loads the core action, then adds usage context and a workflow tip, earning its length.

  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 tool with no output schema or annotations, the description covers purpose, when to use it, the return type, and a prerequisite. It doesn't go into error handling or the exact format of the returned link, but those are less critical for a straightforward generation task. The mention of 'TrackingLink' partially compensates for the missing output schema.

  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 0%, so the description must compensate. It names both parameters ('programmeId' and 'destinationUrl') and explains their roles in the first sentence. It also provides guidance for programmeId ('pair with list_programmes to confirm...'). However, it doesn't specify parameter formats (e.g., URL format for destinationUrl) or why both are required, which would be helpful.

  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 opens with 'Generate a tracking link on Affise for a given programme and destination URL', which specifies a clear action, resource, and network. It distinguishes this tool from the many sibling generate_tracking_link tools for other networks by explicitly naming Affise.

  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 states when to use it: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also gives a practical workflow hint: 'pair with list_programmes to confirm the programmeId before calling.' However, it doesn't explicitly mention when not to use it or alternative tools beyond the implicit network distinction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_afilio_generate_tracking_linkA
  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 does disclose that a TrackingLink is returned and hints at a prerequisite (confirming programmeId), but it doesn't mention potential side effects (e.g., whether it creates a persistent link), auth requirements, or error behavior. This is a gap for a tool that 'generates' something.

  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?

  Three sentences, no wasted words. The first sentence states the core function, the second provides the trigger context, and the third gives a practical prerequisite tip. Information is front-loaded and each sentence 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 a simple 2-parameter schema with no output schema and no annotations, the description covers the essentials: what it does, when to use it, what it returns, and a key prerequisite. It doesn't discuss error cases or auth, but for such a simple tool the description is reasonably 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 coverage is 0% and the schema only lists type 'string' for both parameters. The description adds semantic meaning by stating these are 'programme' and 'destination URL', and clarifies the destination URL is for 'a specific product or page'. However, it doesn't explain URL formats, programmeId format, or how to obtain/validate them beyond the pairing hint. This partially compensates but isn't complete.

  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 ('Generate') and clearly identifies the resource ('tracking link on Afilio') and the key inputs ('programme and destination URL'). It distinguishes this tool from the many sibling generate_tracking_link tools by naming the network (Afilio) and the exact use case.

  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 explicitly states when to use it ('when the user wants to share an affiliate link to a specific product or page') and provides a clear workflow hint ('pair with list_programmes to confirm the programmeId'). It doesn't explicitly mention when not to use it, but the context is clear enough.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_afilio_get_earnings_summaryA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description bears the full burden. It discloses the return type (EarningsSummary), mentions oldestUnpaidAgeDays, and implies a read-only operation. However, it does not disclose pagination behavior (despite limit/cursor params), date handling, or auth requirements, which are meaningful gaps for a tool with no structured metadata.

  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?

  Three sentences, front-loaded with the core purpose, followed by usage guidance and return/pairing hints. Every sentence adds information with no redundancy or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 8 parameters, no output schema, and no annotations, the description is incomplete. It explains the primary use case and return highlight but leaves parameter semantics (especially pagination and age filters) and the full response structure undocumented. The agent cannot reliably determine how to set all parameters or interpret the full output.

  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 0% schema description coverage, the description must clarify parameters. It does imply the roles of from/to (date window), status (status breakdown), and programmeId (programme breakdown), but it leaves limit, cursor, minAgeDays, and maxAgeDays unexplained. Partial compensation is provided, but not sufficient for all 8 parameters.

  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 tool summarizes earnings on Afilio across a date window with breakdowns by programme and status. It provides a concrete usage example and distinguishes itself from list_transactions by focusing on a single-figure answer with context.

  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?

  Explicitly states when to use this tool ('when the user wants a single-figure answer plus context') and names a sibling tool (list_transactions) as the alternative for drilling into underlying records. This gives clear selection criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_afilio_list_transactionsA
  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 discloses that it returns Transaction records including derived ageDays, which is useful, but it does not describe pagination behavior, default limits, authentication requirements, or other side effects. It adds some behavioral context but lacks depth.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the action and scope, and includes use-case examples and return details. Every sentence adds value with no 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?

  Despite having 9 parameters and no annotations or output schema, the description covers the primary user intent, specifies the return type (Transaction records with ageDays), and points to a complementary tool. It lacks exhaustive parameter explanations but is reasonably complete for a list operation.

  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 0%, so the description must compensate. It gives meaning to key parameters by mentioning 'within a window' (from/to), 'specific programme' (programmeId), and statuses (status). The mention of derived ageDays hints at minAgeDays/maxAgeDays. However, pagination parameters (limit, cursor, offset) are not explained, leaving several parameters underspecified.

  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 the specific verb 'List' and clearly identifies the resource as 'affiliate transactions on Afilio', with scope 'within a window or for a specific programme'. It also enumerates transaction statuses (earned, pending, reversed, paid), which distinguishes it from related tools like list_clicks and get_earnings_summary.

  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 explicit example user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and recommends pairing with get_earnings_summary for aggregate totals. However, it does not explicitly state when not to use the tool or mention alternatives like list_clicks.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_avantlink_list_programmesA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses that the tool can return programmes the publisher has joined or which are available to join, and that it returns an array of Programme records. However, it does not mention pagination behavior, default sorting, or what happens with the 'status' parameter. The transparency is partial, so a score of 3 is appropriate.

  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 three sentences, all of which carry meaningful information. It is front-loaded with the primary purpose and includes usage triggers and related-tool context without fluff. No wasted words.

  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 no output schema and no annotations, the description would need to provide more detail to be complete. It states the return type and mentions the dual nature (joined vs available), but it omits how the optional parameters affect results, what the default response looks like, and any limits or pagination. It is functional but not fully complete for a 6-parameter list tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for the 6 parameters. It does not explain 'limit', 'cursor', 'offset', 'search', 'status', or 'categories' beyond what their names imply. The phrase 'available to join' hints at status filtering but is not explicit. This is a significant gap, so parameter semantics are weak.

  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 tool lists affiliate programmes on AvantLink that the publisher has joined or is available to join. It uses a specific verb 'List' and identifies the resource (affiliate programmes on AvantLink), distinguishing it from sibling list_programmes for other networks. Example user queries are provided, making the purpose unmistakable.

  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 explicitly says 'Use this when the user asks...' and provides concrete example phrases. It also directs to related tools: 'pairs naturally with get_programme for drill-down and list_transactions for activity', effectively indicating when to use alternatives. This is clear usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin-advertiser_generate_tracking_linkA
  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 mentions the return type ('Returns a TrackingLink') and implies a prerequisite (the merchant must have been joined), but does not describe side effects, authorization requirements, rate limits, or quota consumption (notable given the sibling get_link_builder_quota). This adds some value but leaves significant context unaddressed.

  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 concise and front-loaded: it states the action, the usage trigger, the return type, and a practical prerequisite in three sentences. No wasted words or redundant restating of the tool name.

  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 three-string-parameter tool with no output schema, the description covers the essential aspects: what it does, when to use it, what it returns, and how to ensure a correct programmeId. The only significant omission is the meaning of the 'brand' parameter, but the overall context is sufficient for basic correct 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?

  The input schema provides no description for any of the three parameters (0% schema coverage), so the description must compensate. It clarifies programmeId ('confirm the programmeId before calling') and destinationUrl ('specific product or page'), but the 'brand' parameter is entirely unexplained, leaving a clear gap. The guidance for two of three parameters keeps this above a 2.

  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 action ('Generate a tracking link'), the target resource ('Awin (advertiser)'), and the inputs ('for a given programme and destination URL'). It distinguishes itself from sibling tracking-link tools by specifying the advertiser role and network, avoiding confusion with publisher-side or other-network 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 provides explicit guidance on when to use this tool: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also recommends pairing with list_programmes to confirm the programmeId. However, it does not explicitly mention alternatives or exclusions, stopping short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin_download_product_feedA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the behavioral disclosure burden. It transparently discloses that the tool returns an 'actionable not-enabled envelope' with endpoint shape, credentials, and next steps, making clear it does not actually download files. It lacks explicit details about auth requirements or side effects, but the core non-fetching behavior is well communicated.

  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?

  Three sentences, front-loaded with the essential purpose, no unnecessary detail. Each sentence adds value: what it does, when to use it, and what it returns.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, the description partially explains the return value (not-enabled envelope with endpoint shape, credentials, next steps), which is useful. However, it omits any explanation of how parameters influence the outcome, so the tool is not fully invocable based on the description alone.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% and the description does not explain the four parameters (format, locale, vertical, advertiserId). The enum for format is present in the schema but its practical meaning is not clarified, leaving the agent unable to reason about correct values or whether parameters are required.

  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 it returns implementation status rather than performing a download, naming the specific repo context. It distinguishes itself from sibling tools like affiliate_awin_list_product_feeds by focusing on status/implementation rather than listing feeds.

  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?

  Explicitly states when to use: when a user asks to download an Awin product feed and needs to know why the PR does not fetch large files yet. This gives clear context, though it doesn't name alternative tools for actually listing or downloading feeds.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin_report_application_resultA
  4/5.0
  Behavior1/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description directly contradicts the readOnlyHint annotation. It states 'records a verified or verify_failed audit line', which is a write operation, yet the annotation declares readOnlyHint=true. The description also asserts 'no state change', but recording an audit line is inherently a state change. This is a serious inconsistency that misleads agents about side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is dense but well-structured: first sentence gives the purpose, followed by usage condition, behavioral scope, parameter requirements, and a key constraint. Every sentence earns its place, and no filler or redundant content exists.

  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 description provides comprehensive guidance for a tool with no output schema and no nested objects: purpose, when to call, parameter semantics, and side-effect boundaries. However, the contradiction regarding 'records' vs. 'no state change' introduces ambiguity, making it not fully trustworthy in its current form.

  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?

  Schema description coverage is 0%, so the description must compensate. It lists required parameters (brand, advertiserId, programmeName, verified) and optional note, and thoroughly explains the verified parameter semantics (true when pending/joined, false otherwise). The identifier parameters are self-explanatory from their names, so the added value is sufficient.

  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 tool records the observed outcome of a previously emitted Awin programme-application handoff, using specific verbs ('Record', 'records') and a specific resource ('Awin programme-application handoff'). It also distinguishes itself from siblings by noting it only records an audit line and does nothing else.

  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?

  Explicit guidance is given: call after the consumer carries out the handoff and revisits the verify target, with verified=true when the relationship reads pending or joined, and verified=false otherwise. It also provides negative guidance ('Never records applied/succeeded') and clarifies it is not for initiating handoffs or making network calls.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin_submit_proof_of_purchase_transactionA
  4/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. It discloses the critical read-only behavior ('without writing transactions', 'never submits live orders') and adds a notable behavioral trait: it 'Returns an activation-gated envelope', indicating conditional behavior based on activation. This exceeds a minimal safety disclosure, but it leaves the term 'activation-gated envelope' undefined and omits auth or rate-limit details.

  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 three concise sentences, front-loaded with the core action ('Return the current...'), followed by usage context and a behavioral guarantee. Each sentence earns its place with no redundancy or filler, making it highly efficient.

  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 2 parameters, no annotations, and no output schema, the description covers the usage context and read-only/activation behavior, but it is incomplete for correct invocation: it does not explain what dryRun or advertiserId do, nor what the 'activation-gated envelope' contains. It is adequate for tool selection but insufficient for confident parameter construction.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage, and the description does not explain either parameter (dryRun, advertiserId) at all. It does not clarify the purpose or expected format of these parameters, which is a significant omission given the schema provides only types. The description's read-only emphasis indirectly suggests dryRun is not for a real submission, but that does not add semantic meaning to the parameters themselves.

  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 tool returns 'the current Awin Proof of Purchase implementation status without writing transactions', specifies the resource (Awin Proof of Purchase implementation) and distinguishes it from an actual submission tool by saying 'never submits live orders'. This is a specific verb+resource+scope statement that effectively differentiates it from the name's implication.

  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 explicitly says 'Use this when a user asks about CLO or proof-of-purchase order submission and needs activation requirements', providing a clear trigger context. It also states the tool 'never submits live orders', implying when not to use it for actual submissions, though it does not name a specific alternative sibling tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_build_brand_snapshotA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses important behavioral traits: it 'persist[s] it locally' (a side-effect), it is 'count-honest' about partial pulls and never totals incomplete data, and it specifies data provenance (clicks from advertiser performance, commission split from transactions). It also notes a prerequisite. This is substantial transparency, though it stops short of describing error handling or return format details.

  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 three sentences, each carrying substantive information: purpose and side-effect, data source and honesty behavior, and usage context. It is dense but not bloated, and it front-loads the primary action. No wasted words, though a slight simplification could improve scannability.

  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 tool with no annotations and no output schema, the description is remarkably complete. It explains the aggregation window, data sources, local persistence, honesty about partial pulls, its role in the product, and a prerequisite. The main gap is the lack of explanation for 'networks' and 'timezone' parameters, and no mention of the return shape, but overall it gives a strong contextual picture.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It indirectly explains 'brand' ('Pull one brand's affiliate performance'), but the 'networks' parameter is not explained beyond implying bound networks, and 'timezone' is never mentioned. The description thus adds minimal meaning beyond the bare parameter names, leaving two of three parameters semantically underdefined.

  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+resource: 'Pull one brand's affiliate performance... normalise it... persist it locally, and return the snapshot.' It also distinguishes itself from related tools by noting that 'CSV export and the AI-action bundle are separate tools,' and mentions the time windows and data sources, making its 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool: it 'powers the free tables' and explicitly calls out that CSV export and AI-action bundle are separate tools. It also includes a prerequisite ('Requires the brand to be bound to advertiser-side networks...'). However, it does not explicitly contrast with the many per-network query tools or give a 'when not to use' beyond the separation from CSV/AI tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_cj-advertiser_get_programmeA
  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 does convey read-only behavior through the verb 'Fetch' and states the return type ('Returns a single Programme'), but it does not disclose authentication requirements, error behavior, or any potential side effects. It is adequate but not rich on 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 three sentences, front-loaded with the core action, and every sentence earns its place. It is concise, scannable, and avoids redundancy with the schema.

  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 only two parameters and no output schema, but the description's coverage is incomplete: it names the return type but not its structure, ignores the required brand parameter, and does not mention error handling. It is sufficient for a basic understanding but not fully self-contained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It explains that programmeId is the network programme id, but it entirely omits the required brand parameter, leaving its meaning and relationship to the network unclear. This is a significant gap for an agent trying to invoke the tool correctly.

  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 tool fetches a single programme on CJ Affiliate (advertiser) by its network programme id. It distinguishes itself from list_programmes and other sibling tools by specifying the exact scope (single record by id) and the kind of data returned (commission, status, advertiser URL).

  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 explicitly says when to use this tool: 'when you already know the programme id and need its full record'. It also provides an alternative: 'pair with list_programmes when you need to discover the id first', giving clear guidance for a common decision point.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_cj-advertiser_list_media_partnersA
  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 states that it returns MediaPartner records with normalized status, which adds useful behavioral context. However, it does not disclose pagination behavior, authentication requirements, or any edge cases. The read-only nature is implied but not explicitly confirmed.

  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?

  Three concise, front-loaded sentences with no fluff. The purpose, use cases, return type, and a pairing suggestion are packed efficiently. Each sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the core purpose, examples, return type, and a companion tool, which is adequate for a simple list operation. However, with no output schema and no annotations, missing details like pagination mechanics, status normalization values, and parameter semantics leave notable gaps that an agent would need to infer.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate, but it does not explain any of the six parameters. While parameter names (brand, limit, cursor, offset, search, status) are somewhat self-explanatory, 'brand' and 'status' values remain ambiguous, and the description only indirectly references 'brand' through 'brand's programme.' This is minimal compensation for a schema with no descriptions.

  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 a specific action ('List the media partners (publishers) running on the brand's programme') and explicitly names the resource and context (CJ Affiliate advertiser). It also differentiates from sibling tools by referencing the network and advertiser perspective, and includes concrete example user queries.

  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?

  Provides explicit usage triggers: when the user asks who promotes the brand, which publishers are active, or wants an outbound roster. It also names a complementary tool (get_programme_performance) for deeper per-publisher performance, which is a clear alternative/companion workflow.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_cj_generate_tracking_linkA
  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 burden. It discloses the return type ('Returns a TrackingLink') and hints at a prerequisite (confirm programmeId), but it does not mention authentication requirements, failure modes, or whether the operation has side effects. This is partial but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences: the first states the core function, the second provides usage context, and the third gives return type and a prerequisite. It is front-loaded, without unnecessary words.

  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 tool with two parameters and no annotations, the description covers the action, use case, return value, and a helpful prerequisite. It lacks only minor details like auth requirements and specific URL requirements, but is otherwise complete for 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 0% and there are no parameter descriptions, so the description must compensate. It names both parameters ('programme' and 'destination URL') and suggests how to obtain a valid programmeId, but it does not explain URL format constraints or provide any additional syntax details. This is adequate but not thorough.

  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 action ('Generate a tracking link'), the platform ('CJ Affiliate'), and the inputs ('programme and destination URL'). It distinguishes this from sibling tools by naming the specific network and the use case.

  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?

  It explicitly says 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined', providing a clear scenario. It also advises pairing with list_programmes to confirm the programmeId, acting as a workflow guideline. However, it doesn't explicitly mention alternatives or when not to use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_cj_list_clicksA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of disclosing behavior. It correctly implies read-only operation via 'List' and notes the return type ('Click records'). However, it does not mention auth requirements, default date ranges, pagination behavior, or any other limits—leaving key behavioral aspects undisclosed.

  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 compact—two sentences total—and front-loaded with the core function, followed by usage guidance and a cross-reference to a related tool. Every sentence adds value; there is no redundancy or filler.

  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 simple read-only list operation, the description covers purpose, usage, and return type. However, the 6-parameter schema with 0% coverage, plus the absence of an output schema, means the agent still lacks important details about filtering syntax, pagination, and result structure. The pairing suggestion helps but does not fill these gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema description coverage is 0%, so the description must compensate. It only vaguely mentions 'filtered by programme and date' but does not explicitly name or explain the parameters 'programmeId', 'from', 'to', or the pagination parameters 'limit', 'cursor', 'offset'. This leaves the agent guessing about parameter formats and behavior.

  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 clear verb ('List') and resource ('recent affiliate clicks on CJ Affiliate') and immediately distinguishes itself from network-specific siblings by naming CJ. It also provides concrete use-case examples ('are my links being clicked at all?'), making the tool's purpose immediately obvious.

  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?

  It explicitly says when to use the tool ('traffic-side debugging') and gives example queries. It also references an alternative/complementary tool ('pair with list_transactions to compare clicks vs conversions'), clearly steering the agent on how to combine tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_clickbank_generate_tracking_linkA
  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 does disclose the return type ('Returns a TrackingLink') and suggests a validation step for the programmeId. However, it does not mention authentication requirements, error conditions, or whether the operation has side effects like link persistence or quota usage.

  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 three sentences, front-loaded with the primary action and resource. Every sentence contributes: purpose, usage context, return type, and prerequisite. There is no fluff or 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?

  For a simple two-parameter tool with no output schema, the description is fairly complete: it provides the use case, return type, and a prerequisite validation step. It lacks some details about URL format or auth verification, but the sibling verify_auth and list_programmes tools help fill those gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage, so the description must compensate. It names both parameters ('programme' and 'destination URL') and adds useful guidance that programmeId should be confirmed via list_programmes. However, it does not provide formats, examples, or constraints for destinationUrl, leaving gaps that the bare schema cannot fill.

  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 action ('Generate a tracking link'), the resource ('on ClickBank'), and the required inputs ('programme and destination URL'). It also distinguishes this tool from siblings by naming the ClickBank network and specifying the exact scenario for sharing an affiliate link.

  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 explicitly states when to use it: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also gives a concrete prerequisite by pairing with list_programmes to confirm programmeId. It does not mention explicit alternatives or when-not-to-use, but the context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_commission-factory-advertiser_list_media_partnersA
  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 burden. It reveals that results are MediaPartner records with normalised status, which is useful. However, it does not mention pagination behavior, authentication requirements, rate limits, or the meaning of 'normalised status' values. The read-only nature is implied by the name but not explicitly stated.

  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 concise (three sentences) and well-structured: it front-loads the purpose, then provides concrete usage triggers, and ends with return details and a related tool. Every sentence earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers purpose, usage examples, return type, and a related tool, making it useful for basic invocation. However, it lacks parameter semantics and behavioral details like pagination or status filtering, which are important given there is no output schema or annotations to fill the gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does little to explain the parameters. 'brand' is only implicitly referenced as 'brand's programme', and 'status' is hinted by 'normalised status', but limit, offset, cursor, and search are not mentioned at all. The description adds minimal meaning beyond the schema's bare parameter names.

  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 tool lists media partners (publishers) for a brand's programme at Commission Factory (advertiser), with a specific verb ('List'), resource ('media partners'), and scope ('brand's programme'). It also mentions the return type and a distinctive trait ('normalised status'), making it easily distinguishable from sibling network-specific list_media_partners tools.

  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?

  Explicit usage guidance is provided with example user queries ('who is promoting us...', 'which publishers are active...') and the outbound roster use case. It also recommends pairing with get_programme_performance for deeper analysis, giving clear context on when to use this tool and what to use alongside it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_commission-factory-adv_get_programme_performanceA
  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 the rollup nature, the metrics, and the return type (ProgrammePerformanceRow), which is useful context. However, it does not mention pagination behavior, parameter interactions (e.g., whether publisherId is required/filters, programmeId usage), or any auth requirements. For a read-only reporting tool, this is moderate but not exhaustive 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 well-structured: a lead action sentence with metrics, followed by concrete use-case examples, and a closing sentence on return type and related tools. Every sentence adds distinct value, and the length is appropriate for the information conveyed.

  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 description adequately covers the core purpose, usage, and return type, but leaves important operational details undocumented: how programmeId or publisherId filters results, pagination via cursor/offset/limit, date range semantics, and the exact fields in ProgrammePerformanceRow. Given the lack of an output schema and the 8 parameters, these gaps prevent full operational clarity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for the 8 parameters. It only indirectly hints at a few: 'brand' is the required parameter, 'by date' implies from/to, and 'per-publisher' implies publisherId. It does not explain programmeId, limit, cursor, offset, or the format of from/to. This is insufficient for a tool with this many parameters.

  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 tool fetches per-publisher performance for the brand's programme at Commission Factory (advertiser), listing the specific metrics (clicks, conversions, gross sale, commission) and the date dimension. It further distinguishes itself from siblings by explicitly naming the network, advertiser perspective, and the rollup nature (per-publisher).

  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 use cases: 'how is each publisher performing on Commission Factory?', 'show me the top-earning partners last month', and 'wants the per-publisher rollup'. It also names alternatives: list_media_partners for discovering publisher ids and list_transactions for transaction-level drill-down, making the choice between tools clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_commission-factory_generate_tracking_linkA
  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 of disclosing behavioral traits. It does mention that it returns a TrackingLink and hints that programmeId should be verified beforehand, but it does not disclose authentication requirements, failure modes, or whether this is a pure generation operation with no side effects. This is a notable gap for a tool with no annotation safety hints.

  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 three sentences that are front-loaded with the core action, then provide usage timing, return type, and a pairing instruction. Every sentence earns its place, with no repetition or filler.

  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-string-parameter tool with no output schema and no annotations, the description covers the essential dimensions: what it does, when to use it, what it returns, and a critical prerequisite. It could be more complete by noting authentication prerequisites or error behavior, but it is adequate for selection and basic invocation.

  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 only defines two string fields with no descriptions, and schema description coverage is 0%, so the description must compensate. It successfully maps 'programme' to programmeId and 'destination URL' to destinationUrl, and adds the insight that programmeId should be confirmed via list_programmes before calling. This adds meaningful semantics beyond the bare 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 the specific verb 'Generate' with a clear resource ('tracking link on Commission Factory') and names the two inputs ('programme and destination URL'). It distinguishes itself from sibling generate_tracking_link tools by explicitly naming the network, Commission Factory.

  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?

  It provides clear usage context: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to confirm the programmeId, which is a helpful prerequisite. It does not explicitly state exclusions or alternatives for other networks, but the Commission Factory scoping is implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_commission-factory_list_clicksA
  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 returns Click records and supports filtering by programme/date, but it does not explain what 'recent' means, how pagination works via limit/cursor/offset, or any authentication requirements. Adequate but incomplete.

  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 three sentences long, front-loaded with the action, then provides use cases and pairing guidance. Each sentence adds value, and there is no redundancy or fluff.

  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 there are no annotations, no output schema, and six undocumented parameters, the description is helpful but not complete. It covers the core purpose and usage well, but lacks details on pagination and parameter formats, which are essential for a tool with this much schema ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It only mentions 'filtered by programme and date', which maps roughly to programmeId and from/to, but leaves limit, cursor, and offset completely unexplained. The description only partially compensates for the lack of schema descriptions.

  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 'List recent affiliate clicks on Commission Factory' with optional programme and date filtering, providing a specific verb, resource, and scope. It also distinguishes itself from sibling tools by framing it as traffic-side debugging and explicitly contrasting with list_transactions.

  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?

  It explicitly states when to use the tool: for traffic-side debugging, with concrete example questions. It also names a complementary tool, 'list_transactions', and suggests pairing them to compare clicks vs conversions, giving clear usage context and an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_commission-factory_list_programmesA
  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 transparency burden. It discloses the return type ('array of Programme records'), but does not mention pagination behavior, default sorting, or the relationship between the 'joined' vs 'available to join' scope and the status parameter. This is not misleading but leaves notable behavioral gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the main action, followed by usage examples and return/pairing info. Every sentence serves a purpose with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the core what and when, and mentions the return format, which is useful given no output schema. However, it omits pagination details, filtering semantics, and the handling of the 'available to join' vs 'joined' distinction, leaving the tool partially incomplete for a complex listing operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not explain any of the six parameters (limit, cursor, offset, search, status, categories). The mention of 'joined' and 'available to join' hints at the status parameter but does not explicitly connect them, leaving parameter meanings underspecified.

  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 tool lists affiliate programmes on Commission Factory for the publisher, using specific verbs ('List') and resources ('affiliate programmes'). It differentiates from siblings by specifying the publisher perspective and network name, and includes example user queries that reinforce its purpose.

  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 gives explicit usage guidance: 'Use this when the user asks...' with concrete example queries, and names complementary tools (get_programme, list_transactions) for drill-down and activity, making it clear when to choose this tool instead of alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_connexity_list_clicksA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations are absent, so the description carries the burden. It discloses that it returns Click records and that clicks are 'recent', but does not state auth requirements, rate limits, or pagination behavior. The read-only nature is implied by 'list' but not explicitly declared.

  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?

  Three sentences, front-loaded with purpose, followed by concrete use cases and a complementary tool. Every sentence earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  No annotations or output schema. The description provides purpose, use cases, and return type, but omits pagination semantics, parameter details, and any behavioral caveats. Adequate for simple use but not fully complete for autonomous invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 0% description coverage. The description mentions 'filtered by programme and date', which maps to programmeId and from/to, but does not explain limit, cursor, or offset. Partial compensation for the 0% coverage is insufficient for 6 parameters.

  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 'List recent affiliate clicks on Connexity, optionally filtered by programme and date' – a specific verb, resource, and scope. It clearly distinguishes from sibling list_transactions by naming the traffic-side debugging purpose and specifying Connexity.

  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?

  Explicitly says 'Use this for traffic-side debugging' and gives example questions like 'are my links being clicked at all?'. It also directs to 'pair with list_transactions to compare clicks vs conversions', naming the complementary alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_coupang-partners_list_programmesA
  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 adds useful behavioral context (lists joined/available programmes, returns an array of Programme records) but does not disclose pagination behavior, authorization requirements, or potential side effects. For a simple list operation, this is adequate but not thorough.

  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 three concise sentences, front-loaded with the core action, then usage examples, then return type and related tools. Every sentence adds value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 6 parameters, no output schema, and no annotations, so the description needs to cover more ground. It covers usage triggers and related tools well, but lacks parameter guidance and details about the returned Programme records' structure or pagination behavior. It is functional but incomplete for a fully informed agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% (no descriptions in the input schema), so the description must compensate. It does not explain any of the six parameters (limit, cursor, offset, search, status, categories) beyond their names and types in the schema. No guidance on how to use status or categories, which may have specific allowed values.

  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 tool lists affiliate programmes on Coupang Partners, with a specific verb ('List') and resource ('affiliate programmes on Coupang Partners'). It also provides example user queries, distinguishing it from the many other network-specific list_programmes tools.

  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 explicitly tells when to use this tool (e.g., 'which merchants am I working with?') and pairs it with get_programme for drill-down and list_transactions for activity, implicitly guiding when not to use it. This is strong, actionable guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_daisycon-advertiser_generate_tracking_linkA
  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 transparency burden. It states the return type ('Returns a TrackingLink') and the condition 'merchant they have joined' (implying advertiser auth), but does not disclose potential side effects, authentication requirements, rate limits, or error behavior. Moderate but not rich.

  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?

  Three well-structured sentences: action, usage context, return value/prerequisite. No filler, front-loaded with the primary verb and resource.

  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 simplicity and lack of output schema/annotations, the description covers purpose, usage, return type, and a prerequisite. The unexplained `brand` parameter is a notable gap for a required field, but overall the description is fairly self-sufficient.

  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 has 3 params with 0% description coverage. The description mentions 'programme and destination URL', covering programmeId and destinationUrl, and advises confirming programmeId via list_programmes. However, the required `brand` parameter is never explained, leaving a significant gap.

  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 action: 'Generate a tracking link on Daisycon (advertiser)' with specific inputs 'programme and destination URL'. This distinguishes it from the publisher-side `affiliate_daisycon_generate_tracking_link` by explicitly naming the advertiser context.

  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?

  Provides clear usage context: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also gives a practical prerequisite: 'pair with list_programmes to confirm the programmeId before calling.' Lacks explicit when-not-to-use exclusions, but the context is sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_digistore24_list_programmesA
  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 burden. It discloses that the result includes both joined and available-to-join programmes and returns an array of Programme records. However, it does not mention pagination behavior, authentication requirements, or rate limits, leaving some behavioral context unstated.

  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?

  Two sentences pack the action, use cases, and related tools without waste. Each sentence adds information relevant for selection and invocation.

  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 6-parameter list tool with no output schema or annotations, the description covers purpose, example trigger phrases, and return type, but omits parameter semantics and detailed behavioral notes, leaving moderate gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% and the description provides no meaning for limit, cursor, offset, search, status, or categories. The agent must infer filter and pagination semantics from parameter names alone, which is insufficient for six parameters.

  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 'List affiliate programmes the publisher has joined on Digistore24 (or which are available to join)', giving a specific verb and resource. It distinguishes from sibling tools by mentioning get_programme for drill-down and list_transactions for activity.

  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?

  Explicitly says 'Use this when the user asks...' with concrete example queries, and notes that it 'pairs naturally with get_programme for drill-down and list_transactions for activity', providing clear usage boundaries and alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_ebay_generate_tracking_linkA
  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 adds useful behavioral context by stating 'Returns a TrackingLink' and advising to confirm programmeId via list_programmes. However, it does not disclose authentication requirements, potential side effects, error conditions, or validation rules for the destination URL, leaving gaps for an agent.

  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 three concise, information-dense sentences. It front-loads the core purpose, then gives usage context and return/prerequisite info without any redundancy or wasted words.

  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 tool with no output schema and no annotations, the description covers the essential aspects: what it does, when to use it, and a key preparatory step (confirm programmeId). It falls short only by not addressing error handling or validation details, but it is largely complete for its level of complexity.

  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 0% schema description coverage, the description must compensate. It names both parameters ('programme and destination URL') and gives semantic meaning to programmeId by recommending confirmation via list_programmes. However, it does not specify formats, constraints, or how the destination URL should be structured (e.g., full URL with scheme), so parameter semantics remain under-specified.

  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: 'Generate a tracking link on eBay Partner Network for a given programme and destination URL.' It clearly distinguishes this from the many sibling generate_tracking_link tools for other networks by naming eBay Partner Network, and it identifies the key inputs (programme and destination URL).

  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?

  It provides clear when-to-use guidance: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also gives a helpful prerequisite: 'pair with list_programmes to confirm the programmeId before calling.' However, it does not explicitly mention when not to use it (e.g., for other networks), though the tool name itself implies eBay-specific usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_ebay_list_clicksA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Since no annotations are provided, the description carries the burden of behavioral disclosure. It does state that the tool 'Returns Click records' and mentions optional filters, but it does not disclose pagination behavior, date format expectations, or whether the operation requires specific authentication. This leaves some ambiguity for a list tool with multiple parameters.

  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 three sentences with no filler. It front-loads the core purpose, provides concrete use-case examples, and ends with a useful pairing suggestion. Every sentence contributes actionable information, making it an exemplar of concise writing.

  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 tool with 6 parameters and no output schema, the description gives enough high-level context for basic selection but lacks details on parameter formats, default date ranges, pagination semantics, or return field structure. It is sufficient for a straightforward list tool but not fully complete for an agent needing precise invocation details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, and the description only loosely references 'filtered by programme and date', which maps to programmeId, from, and to. The pagination parameters (limit, cursor, offset) and other options are not mentioned or contextualized, so the agent receives minimal guidance beyond the raw schema names.

  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 tool's function with a specific verb and resource: 'List recent affiliate clicks on eBay Partner Network'. It also distinguishes this tool from siblings by explicitly mentioning 'traffic-side debugging' and the optional filters by programme and date, which separates it from list_transactions and other network-specific tools.

  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 context: 'Use this for traffic-side debugging' with concrete examples like 'are my links being clicked at all?'. It also recommends pairing with list_transactions to compare clicks vs conversions, effectively guiding the agent on when to prefer this tool over transaction-oriented alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_effiliation_get_earnings_summaryA
  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 does disclose that the tool returns an EarningsSummary with oldestUnpaidAgeDays and mentions the pairing with list_transactions, which adds some behavioral context. However, it does not state whether the operation is read-only, mention any permissions or rate limits, or clarify how the date window or status filtering affects results. The absence of annotations makes this only minimally adequate.

  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 long, front-loads the core purpose and output, includes a concrete example, and provides cross-referencing guidance. Every sentence earns its place with no redundancy or filler.

  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 8 parameters, no output schema, and no annotations, the description covers about half the parameter semantics and provides some output context (EarningsSummary, oldestUnpaidAgeDays). It also explains the relationship with list_transactions. However, it leaves gaps around pagination, age filters, and full output structure, making it only partially complete for a tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It implicitly maps 'date window' to from/to, and 'breakdowns by programme and status' to programmeId and status. However, it does not explain limit, cursor, maxAgeDays, or minAgeDays, leaving 5 of 8 parameters semantically unclear. The names alone are insufficient for correct invocation, especially age filters and pagination.

  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 tool 'summarises earnings on Effiliation across a date window' with breakdowns by programme and transaction status. It distinguishes this from the sibling list_transactions by explicitly positioning it as a summary tool for single-figure answers, and the example ('total earnings in Q1 with status split') makes the output concrete.

  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 explicitly says to use this tool when the user wants a single-figure answer plus context, and names list_transactions as the complementary tool for drilling into underlying records. This provides clear when-to-use and alternative guidance, matching the high bar set in calibration examples.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_ehub_generate_tracking_linkA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  There are no annotations, so the description carries the full burden of behavioral disclosure. It does add useful context by stating 'Returns a TrackingLink' and implying a validation prerequisite via the list_programmes pairing. Still, it omits any mention of authentication requirements, side effects, rate limits, or failure behavior, leaving important behavioral aspects undocumented.

  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 exactly two sentences, with no redundant phrases. The first sentence states the core action, and the second adds use case and prerequisite guidance. Every word earns its place; it is front-loaded and highly readable.

  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 tool with two parameters and no output schema, this description is quite complete: it covers purpose, use case, return type, and a crucial prerequisite. Gaps include a lack of explicit exclusions, no mention of auth verification (despite the sibling affiliate_ehub_verify_auth tool), and no error behavior. Still, it provides enough context for an agent to invoke the tool correctly in most scenarios.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It maps the two parameters to 'programme' and 'destination URL' and recommends confirming the programmeId via list_programmes, which gives practical meaning beyond the bare schema. However, it does not provide formats, constraints, or examples for either parameter, so it only partially compensates for the missing schema descriptions.

  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 opens with 'Generate a tracking link on eHUB for a given programme and destination URL,' clearly specifying the action (generate), resource (tracking link on eHUB), and inputs (programme and destination URL). The additional sentence explains the exact user scenario ('share an affiliate link to a specific product or page on a merchant they have joined'), which distinguishes this tool from other generate_tracking_link tools for different networks and from other ehub operations.

  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 an explicit when-to-use statement: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also gives a concrete companion-tool recommendation: 'pair with list_programmes to confirm the programmeId before calling.' However, it does not mention when not to use this tool or identify alternative generate_tracking_link tools, so it falls short of full exclusions/alternatives guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_everflow_list_transactionsA
  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 returns Transaction records including derived ageDays, which is useful behavioral context. However, it does not mention pagination behavior, authentication requirements, or default date-range handling, leaving some transparency gaps for a list 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 two sentences, front-loaded with the core action, and every sentence adds value: the first defines scope, the second gives usage examples and a pairing recommendation. There is zero redundancy or filler.

  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 9 optional parameters, no annotations, and no output schema, the description is moderately complete. It covers key aspects (purpose, statuses, date window, return records) but omits pagination behavior, default window semantics, and parameter-specific format details. It is adequate for a basic list tool but not fully comprehensive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It implicitly covers 'from', 'to', 'programmeId', and 'status' via phrases like 'within a window', 'specific programme', and listing statuses (earned, pending, reversed, paid). However, it provides no guidance for limit, cursor, offset, maxAgeDays, or minAgeDays, leaving over half the parameters unexplained.

  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 tool's function: 'List affiliate transactions (commissions earned, pending, reversed, or paid) on Everflow within a window or for a specific programme.' It uses a specific verb ('List') and resource ('affiliate transactions'), scopes it to Everflow, and includes example user queries that ground the purpose. This distinguishes it from sibling tools like list_clicks or get_earnings_summary.

  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 explicitly says 'Use this when the user asks...' and provides concrete examples ('what did I earn last month?', 'what's still pending?', 'show me reversed sales'). It also directs pairing with get_earnings_summary for aggregate totals, giving clear guidance on when to use this tool versus an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_firstpromoter_list_media_partnersA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry the disclosure burden. It adds that it 'Returns MediaPartner records with normalised status' and implies a read-only list operation, but does not explain pagination, authentication, or any side effects. This is adequate but not rich 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?

  Three concise sentences, each earning its place: purpose, usage examples, and return/pairing guidance. Front-loaded and free of fluff.

  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 description covers purpose, usage, return type, and complementary tool, but omits parameter semantics and any behavioral details like default ordering or result limits. For a 6-parameter tool with no annotations or output schema, it falls short of fully equipping an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It implies 'brand' via 'brand's programme' but leaves limit, cursor, offset, search, and status entirely unexplained. An agent would struggle to know valid values for status or pagination semantics from the description alone.

  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 'List the media partners (publishers) running on the brand's programme at FirstPromoter', using a specific verb and resource. It also provides example user queries, distinguishing it from sibling tools like list_programmes. The network scope is explicitly noted.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit usage triggers are given: 'Use this when the user asks "who is promoting us on FirstPromoter?", "which publishers are active on our programme?", or wants an outbound roster.' It also directs pairing with get_programme_performance for per-publisher performance, clarifying when a complementary tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_firstpromoter_verify_authA
  4/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. It discloses that the tool calls a minimal authenticated endpoint (implying a non-destructive read-only operation) and details the response format as {ok:true, identity?} or {ok:false, reason}. While it doesn't discuss side effects, the nature of a verification endpoint makes this reasonably transparent.

  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 three sentences, each earning its place: purpose, usage triggers, and return shape plus a pairing suggestion. It is front-loaded, concise, and free of fluff.

  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 description covers purpose, usage, and return shape, which is good for a simple tool, but the required 'brand' parameter is entirely unexplained, and there is no output schema to fill the gap. This prevents the description from being fully complete for reliable invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only required parameter 'brand' is completely undocumented in both the schema (no description) and the tool description (no mention). With 0% schema coverage, the description must compensate but does not, leaving the agent with no guidance on what 'brand' means or how to populate it.

  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 tool verifies FirstPromoter credentials via a minimal authenticated endpoint, distinguishing it from sibling auth verification tools for other networks. It also mentions the return shape, reinforcing the purpose with a specific verb and resource.

  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?

  It explicitly gives usage scenarios: at the start of a session, after rotating keys, or after an auth error, and suggests pairing with affiliate_run_diagnostic for a full health check. This provides clear when-to-use context and points to a complementary alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_flipkart_list_clicksA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description must convey safety and behavioral traits itself. It states that it returns Click records and positions itself as a read-only debugging list operation, but it does not disclose pagination behavior, authentication requirements, rate limits, or the definition of 'recent'. This leaves significant gaps in behavioral 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 two sentences, front-loaded with the core action, followed by targeted usage context and a sibling reference. Every sentence earns its place with no filler or repetition.

  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 no annotations, no output schema, and 6 schema-only parameters, the description covers the primary use case and return type ('Click records') but lacks parameter semantics for pagination, detailed output structure, and any auth/prerequisite context. It is adequate for high-level selection but not sufficient for fully-informed invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate by explaining the 6 parameters. It only mentions 'programme and date' (programmeId, from, to) and entirely omits limit, cursor, and offset. The meaning of date ranges (format, inclusivity) and pagination controls is left to the schema's bare names, which is insufficient for correct invocation.

  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 opens with 'List recent affiliate clicks on Flipkart Affiliate, optionally filtered by programme and date' – a specific verb and resource that clearly distinguishes it from sibling list_transactions and list_programmes tools. It also explicitly names complementary tool list_transactions, reinforcing its unique role in the affiliate ecosystem.

  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?

  Explicitly directs when to use: 'Use this for traffic-side debugging' with concrete example questions like 'are my links being clicked at all?' and 'where is traffic going?'. It also names sibling list_transactions as a complementary tool for comparing clicks vs conversions, giving clear context and an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_hotmart_get_earnings_summaryA
  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 burden. It discloses that the tool returns an EarningsSummary including oldestUnpaidAgeDays, and implies aggregation via 'single-figure answer.' However, it does not mention authentication requirements, date-window limits, or whether historical data is mutable. There is no contradiction, but richer behavioral context (e.g., timezone/currency assumptions) would be expected for zero 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?

  Two sentences, both purposeful. The first states the core function; the second provides usage context, an example, return-field information, and a pointer to a sibling tool. No filler or repetition.

  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 description gives a good high-level understanding and connects to list_transactions, but with 8 parameters and no output schema, it omits important operational details like pagination behavior, default date range, and meaning of maxAgeDays/minAgeDays. It is adequate for basic use but not fully complete for advanced invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% for 8 parameters, so the description must compensate. It adds meaning for 'date window' (from/to), 'programme' (programmeId), and 'status' (status), but leaves limit, cursor, maxAgeDays, and minAgeDays unexplained. This is insufficient for an 8-parameter tool with zero schema descriptions.

  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 opens with a specific verb and resource: 'Summarise earnings on Hotmart across a date window, with breakdowns by programme and by transaction status.' It clearly distinguishes this summary tool from sibling list_transactions and list_programmes tools by emphasizing aggregate output and specific breakdowns.

  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?

  Explicitly states when to use: 'Use this when the user wants a single-figure answer plus context — e.g. "total earnings in Q1 with status split".' It also names an alternative for deeper detail: 'pair with list_transactions to drill into the underlying records.' This is clear usage guidance vs alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_howl_generate_tracking_linkA
  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 of behavioral disclosure. It does add useful context—'Returns a TrackingLink' and the recommendation to confirm programmeId via list_programmes—but it does not disclose whether the operation has side effects, requires authentication (e.g., via verify_auth), or how errors are handled, leaving some gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences covering what it does, when to use it, and its return value plus a key prerequisite. Every sentence earns its place, with no filler or repetition.

  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?

  As there is no output schema, the description appropriately mentions the return type ('Returns a TrackingLink'). It covers the core action, use case, and a necessary pairing with list_programmes. However, it omits authentication steps (e.g., verify_auth) and error behavior, which are minor gaps for a simple two-parameter 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?

  The input schema has no parameter descriptions (0% coverage), so the description must compensate. It references 'a given programme and destination URL', and specifically instructs to confirm programmeId with list_programmes, adding some meaning beyond the bare parameter names. However, it does not provide format constraints or detailed semantics for destinationUrl.

  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 'Generate a tracking link on Howl for a given programme and destination URL', specifying the exact action, platform (Howl), and inputs. It distinguishes itself from sibling generate_tracking_link tools by naming the network and the two key parameters, and also explains the use case for sharing an affiliate link.

  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 explicitly says 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined' and advises pairing with list_programmes to confirm the programmeId. This gives clear when-to-use context and a prerequisite, though it does not explicitly mention alternatives or when-not-to-use cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_howl_list_clicksA
  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 must disclose behavior. It states it returns Click records and mentions optional filters, but does not explain pagination behavior (limit/cursor/offset), default time ranges, or auth requirements. It implies a read-only operation via 'List' but could be more explicit.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, front-loaded with the main action, followed by use case and output/pairing guidance. Every sentence adds value and there is no fluff.

  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 description covers purpose, filters, return type, and a pairing suggestion. However, it lacks details on pagination parameters and the shape of Click records (since no output schema exists). It is adequate for a simple list tool but leaves some gaps in a fully self-contained description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With schema description coverage at 0%, the description must compensate. It adds meaning for programme and date filters, but does not explain limit, cursor, offset, or how they interact. Five of six parameters remain undocumented, leaving significant ambiguity.

  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 action: 'List recent affiliate clicks on Howl' with optional filters. It distinguishes itself from sibling tools by explicitly naming Howl and provides a concrete use case ('traffic-side debugging').

  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?

  It explicitly says when to use it ('Use this for traffic-side debugging') with example questions, and suggests pairing with list_transactions to compare clicks vs conversions, giving clear context relative to a related tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_impact-advertiser_get_earnings_summaryA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  It mentions the return type ('Returns an EarningsSummary including oldestUnpaidAgeDays') and breakdown granularity, but does not disclose whether it is read-only, authentication needs, or pagination behavior. With no annotations provided, the description carries the full burden and only partially discloses behavioral traits.

  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 three sentences long, with each sentence earning its place: purpose, usage guidance with example, and return/pairing hint. It is concise and front-loaded, with no redundant content.

  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 (9 parameters, no output schema, no annotations), the description provides a good high-level overview but leaves many parameter meanings and output fields unspecified. The mention of oldestUnpaidAgeDays is helpful but insufficient for full completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has zero descriptions for its 9 parameters, and the description only implicitly covers date window (from/to), programmeId, and status. It lacks explanation for required parameter brand, limit, cursor, maxAgeDays, and minAgeDays, so it does not sufficiently compensate for the 0% 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 clearly identifies the tool as summarizing earnings for Impact (advertiser) across a date window, with breakdowns by programme and transaction status. It distinguishes this from sibling tools like affiliate_impact_get_earnings_summary and list_transactions by specifying '(advertiser)' and the summary nature.

  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 explicitly states when to use it ('Use this when the user wants a single-figure answer plus context') and provides a concrete example query. It also recommends pairing with list_transactions for deeper detail, indicating an alternative/complementary tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_impact-advertiser_list_clicksA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of behavioral disclosure. It states the return type ('Click records') and implies a read-only list operation, but does not explicitly mention safety/rules, pagination behavior, or data freshness limits. It adds some context but leaves gaps for a tool with zero annotation support.

  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 three sentences with no filler. Each sentence earns its place: the first states the function, the second provides use-case guidance, and the third covers return type and a pairing suggestion. Well-structured and front-loaded with the essential verb and resource.

  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 description gives useful context (traffic-side debugging, return type, pairing suggestion) but omits details about required parameters, pagination, and output shape. With no output schema and incomplete parameter coverage, the agent may face ambiguity when invoking the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% and the description mentions only 'programme and date' as filters, which loosely maps to programmeId and from/to. The required 'brand' parameter and pagination parameters (limit, cursor, offset) are not explained. Given the 7 parameters and no schema descriptions, the description fails to adequately compensate for the missing parameter semantics.

  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 tool lists recent affiliate clicks on Impact (advertiser), with optional programme and date filters. It uses a specific verb+resource and distinguishes itself from siblings by explicitly naming the advertiser scope and Impact network, avoiding confusion with other list_clicks tools.

  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?

  It provides explicit usage context: 'Use this for traffic-side debugging' with concrete examples like 'are my links being clicked at all?'. It also recommends pairing with list_transactions to compare clicks vs conversions, giving clear guidance on when and how to use the tool alongside alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_indoleads_list_clicksA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden but only discloses that it returns Click records and supports filtering. It does not mention pagination behavior, date format expectations, or auth requirements, which would be useful for an agent to know before calling. However, it does add some behavioral context beyond the schema by explaining the tool's purpose and return type.

  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 three sentences long, front-loaded with the core action, then gives concrete use cases, and ends with return type and companion tool. Every sentence adds value without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 6 parameters with no output schema and no annotations, so a complete description should cover filtering, pagination, and return structure. It covers the primary use case and filters but omits pagination semantics and details about what a Click record contains. It is adequate for a simple list tool but has clear gaps in parameter and return documentation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It explains programme filtering ('programme') and date filtering ('date') which map to programmeId and to/from, but it does not explain limit, cursor, or offset. Since four of six parameters are pagination-related and remain undocumented, the description only partially compensates for the missing schema descriptions.

  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 tool lists recent affiliate clicks on Indoleads with optional programme and date filters. It uses the specific verb 'List' and identifies the resource 'affiliate clicks on Indoleads', distinguishing it from siblings like list_transactions and list_programmes.

  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?

  It provides explicit use cases for traffic-side debugging with concrete example questions ('are my links being clicked at all?' or 'where is traffic going on Indoleads?'). It also names an alternative/complementary tool, list_transactions, for comparing clicks vs conversions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_involve-asia_generate_tracking_linkA
  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 states that the tool 'Returns a TrackingLink,' which is useful, and mentions the prerequisite of confirming the programmeId. However, it does not disclose whether the tool requires authentication, whether it creates a persistent resource, or any side effects. For a link generation tool, this is a moderate gap, though the key behavior is at least stated.

  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 three sentences long and front-loaded with the core action. Each sentence adds value: the function, the use case, and the return value/prerequisite. There is no redundant information, 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.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with two string parameters and no output schema, the description is relatively complete. It covers what the tool does, when to use it, what it returns, and a critical prerequisite (confirming programmeId). The only notable omission is the lack of explicit authentication guidance, but the network-specific naming and sibling verify_auth tools provide indirect context. Overall, it gives an agent enough to select and invoke the tool correctly in most cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for explaining the parameters. It identifies the two inputs as 'a given programme and destination URL,' and the instruction to pair with list_programmes adds practical meaning to the programmeId parameter. However, it does not elaborate on the expected format or constraints for destinationUrl, nor does it explicitly define programmeId beyond the name. The compensation is partial but not comprehensive.

  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 tool's function: 'Generate a tracking link on Involve Asia for a given programme and destination URL.' It uses a specific verb and resource, and explicitly names the network (Involve Asia), distinguishing it from the many other generate_tracking_link tools for different networks. The use case for affiliate link sharing is also specified.

  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 says 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined,' providing clear contextual guidance. It also advises pairing with list_programmes to confirm the programmeId before calling, which is a explicit prerequisite. It doesn't explicitly state when not to use other networks' tools, but the 'on Involve Asia' qualifier makes this evident from the sibling context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_kwanko-advertiser_get_programmeA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that it 'Returns a single Programme' and lists some fields, which implies a read operation. However, with no annotations, it does not address error behavior (e.g., not found), authentication needs, or why the required `brand` parameter is necessary, leaving some behavioral aspects opaque.

  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 composed of two sentences, with the first front-loading the primary action and the second adding usage context and return type. Every word adds value; there is no redundant content.

  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 description covers the main action, when to use it, and the return type, and even references list_programmes for discovery. However, the unexplained `brand` parameter and lack of error behavior leave notable gaps, especially given the absence of annotations and output schema.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description clarifies that `programmeId` is the 'network programme id', but it never mentions the equally required `brand` parameter. With 0% schema description coverage, the description was expected to compensate for the schema's silence, and failing to explain one of only two required parameters is a major gap.

  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 tool's specific verb and resource: 'Fetch a single programme on Kwanko (advertiser) by its network programme id.' It also names the return fields (commission, status, advertiser URL), which sets it apart from sibling list/get tools and clarifies its narrow scope.

  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 explicitly says when to use the tool: 'Use this when you already know the programme id' and provides an alternative: 'pair with list_programmes when you need to discover the id first.' This gives clear when-to-use and alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_kwanko_list_clicksA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It discloses that the tool returns Click records and supports filtering, but lacks details on pagination behavior, default date windows, or authentication. It doesn't contradict annotations, but adds only moderate 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?

  Two sentences with front-loaded purpose and tight usage guidance. No fluff 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?

  The description covers purpose, usage, and return type, but given 6 parameters and no output schema, it leaves pagination semantics and click record fields unexplained. 'Recent' is ambiguous, and no default or range context is provided. It's adequate but with clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only indirectly maps 'programme' to programmeId and 'date' to from/to. It does not explain limit, cursor, or offset, which are key pagination parameters. The description adds minimal semantic value beyond the schema's bare names.

  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 tool lists recent affiliate clicks on Kwanko, with optional filtering by programme and date. The verb 'List' and specific resource 'affiliate clicks on Kwanko' distinguish it from transaction-listing siblings like affiliate_kwanko_list_transactions.

  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?

  Provides explicit use cases ('traffic-side debugging') and concrete example questions, and names a complementary tool (list_transactions) for comparing clicks vs conversions. This gives clear when-to-use guidance and an alternative pairing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_leaddyno_get_programme_performanceA
  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 does disclose that the tool returns ProgrammePerformanceRow records and lists included metrics, and 'Fetch' implies a read operation. However, it does not mention authentication needs, date parameter behavior, pagination, or any side effects, which is a gap for a tool with no structured annotation safety info.

  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 three sentences, each adding value: the first defines the scope and metrics, the second provides concrete usage examples, and the third explains the return type and complementary tools. It is compact, front-loaded, and free of filler.

  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 there is no output schema and no annotations, the description should compensate heavily. It does mention the return type and relationships to sibling tools, but it omits parameter semantics, pagination, date handling, and the optionality of fields like programmeId and publisherId. This makes the tool only partially self-explanatory for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description provides only minimal parameter hints: 'by date' alludes to from/to, and 'pair with list_media_partners to discover publisher ids' hints at publisherId. It does not explain brand, programmeId, limit, cursor, offset, or their defaults/relationships. With 8 parameters, this is insufficient to guide correct invocation.

  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 tool fetches per-publisher performance for a brand's programme at LeadDyno, naming specific metrics (clicks, conversions, gross sale, commission) and date scope. It distinguishes itself from sibling tools by explicitly mentioning 'per-publisher' rollup and naming the LeadDyno network, and does not confuse with list_transactions or get_earnings_summary.

  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 gives explicit when-to-use examples ('how is each publisher performing on LeadDyno?', 'show me the top-earning partners last month') and clarifies the tool is for per-publisher rollup. It also suggests pairing with list_media_partners for publisher IDs and list_transactions for drill-down, which provides clear alternatives and integration context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_leaddyno_list_clicksA
  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 must carry the full burden. It does disclose that the tool 'Returns Click records' and implies a read-only operation via 'List', but it omits behavioral details such as pagination behavior ('cursor', 'offset'), date range interpretation, or any rate limits. The 'recent' timeframe is vaguely defined, leaving gaps in behavioral 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 three sentences, front-loaded with the core action, followed by usage examples and return type. Every sentence serves a distinct purpose — no fluff or repetition. It is concise yet informative.

  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 simple list tool, the description covers purpose, filtering options, return type, and use cases. However, with 7 parameters, no annotations, and no output schema, it leaves out essential context like pagination parameters and exact date format semantics. It is adequate for basic usage but incomplete for complex queries involving 'cursor'/'offset' or full parameter understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description is the only source of parameter meaning. It mentions 'optionally filtered by programme and date', which maps to 'programmeId' and 'from'/'to', but the required 'brand' parameter is left unexplained, and 'limit', 'cursor', and 'offset' are not mentioned at all. The description provides minimal parameter insight and does not compensate for the schema's lack of 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 starts with a specific verb and resource: 'List recent affiliate clicks on LeadDyno', clearly distinguishing this from sibling tools like list_transactions and other networks' list_clicks. It also mentions optional filtering by programme and date, which further pinpoints the tool's scope.

  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?

  It explicitly states when to use the tool: 'Use this for traffic-side debugging' with concrete example questions. It also provides an alternative/complementary tool: 'pair with list_transactions to compare clicks vs conversions', giving clear usage context and a named sibling for differentiation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_levanta_list_programmesA
  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 must carry the burden. It discloses the return type (array of Programme records) and scope (joined/available), but lacks explicit read-only confirmation, pagination behavior, or auth requirements. For a list operation, this is adequate but not rich.

  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?

  Two dense sentences front-load the core function, provide example queries, and mention related tools. Every word earns its place with no fluff.

  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?

  Covers usage scenarios and return type, but with 6 undocumented parameters and no annotations, it leaves gaps around pagination, filtering, and output details. It is minimally viable but incomplete for full agent autonomy.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has 6 parameters with 0% description coverage. The description does not explain limit, cursor, offset, search, status, or categories, forcing the agent to infer meaning from names alone. The 'joined or available' phrase hints at status but is not explicit.

  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 it lists affiliate programmes on Levanta, with a specific verb 'List' and resource. It also distinguishes between joined and available programmes and contrasts with get_programme and list_transactions siblings.

  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?

  Provides explicit example user queries and recommends pairing with get_programme and list_transactions, giving clear when-to-use guidance and alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_lomadee_list_clicksA
  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 adds useful context (returns Click records, 'recent' implied time scoping, traffic-side debugging) but does not mention pagination behavior (cursor/offset), default limits, date formats, or any auth requirements. The lack of annotation coverage makes this a moderate score.

  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?

  Three sentences, front-loaded with the core action and optional filters, followed by use-case examples and a pairing suggestion. Every sentence earns its place with no fluff or repetition.

  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 description covers the core purpose, gives usage examples, states return type, and suggests a sibling tool. However, it omits pagination parameters (cursor/offset/limit) and does not disclose behavioral details like data freshness windows or sorting. For a tool with 6 params and no annotations, this leaves notable gaps for an agent to use it correctly in complex scenarios.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It maps 'programme' to programmeId and 'date' to from/to, giving meaning to those three parameters. However, limit, cursor, and offset are entirely unexplained, leaving pagination semantics opaque. With 6 parameters and zero schema descriptions, this is insufficient.

  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 verb ('List'), resource ('affiliate clicks on Lomadee'), and optional filters ('programme and date'). It also distinguishes this from transaction tools by framing it as 'traffic-side debugging' and explicitly pairing it with list_transactions.

  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?

  Provides concrete use cases ('are my links being clicked at all?', 'where is traffic going?') and names the alternative tool (list_transactions) for comparing clicks vs conversions. This gives the agent explicit guidance on when to select this tool over siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_monetizze_generate_tracking_linkA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description adds some behavioral context: it returns a TrackingLink and advises confirming the programmeId. It doesn't disclose potential error conditions, auth prerequisites, or side effects, but for a link-generation tool this is reasonably sufficient.

  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?

  Two sentences, every sentence earns its place. The first states the core function, the second provides usage context, return type, and a practical tip. No fluff or 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?

  For a simple two-parameter tool with no output schema, the description covers purpose, usage, return type, and a prerequisite call. It doesn't mention authentication explicitly, but the sibling verify_auth and the pairing advice imply it. Overall, it's quite complete for the tool's simplicity.

  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 0%, so the description must compensate. It mentions 'given programme and destination URL' which maps to the two parameters, and the pairing advice gives meaning to programmeId. However, it doesn't explain acceptable formats or constraints for destinationUrl, leaving some gaps the schema's plain string type doesn't fill.

  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 opens with a specific verb and resource: 'Generate a tracking link on Monetizze for a given programme and destination URL.' It clearly distinguishes this from sibling generate_tracking_link tools by naming Monetizze, and also states the return type (TrackingLink).

  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?

  It provides a clear when-to-use: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also recommends pairing with list_programmes, but doesn't explicitly state exclusions for other networks. However, the name and context make that implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_monetizze_list_clicksA
  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 disclosure burden. It discloses the return type ('Click records') and optional filters, but leaves unspecified the default date window for 'recent', pagination behavior despite the presence of cursor/offset/limit fields, and any authentication or rate-limit requirements. This is useful but incomplete for a read-only list 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?

  Two tightly written sentences front-load the purpose, then add practical use cases and a cross-reference. Every sentence earns its place with no fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 6 undocumented parameters and no output schema, and the description leaves pagination semantics and the meaning of 'recent' unclear. It captures the core purpose and use case well, but is not fully complete for reliable invocation without further clarification.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema-description coverage is 0% and the description must compensate. It maps 'programme' to programmeId and 'date' to from/to, but does not explain limit, cursor, offset, or the expected date format. The pagination parameters remain ambiguous, which is a significant gap for a 6-parameter tool with no other 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 clearly states the verb ('List'), the specific resource ('affiliate clicks on Monetizze'), and the scope ('recent'). It distinguishes the tool from sibling tools by explicitly naming the Monetizze network and contrasting with list_transactions.

  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?

  It provides explicit when-to-use guidance with concrete debugging questions ('are my links being clicked at all?') and recommends pairing with list_transactions to compare clicks vs conversions, which effectively communicates the alternative and complementary use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_monetizze_list_transactionsA
  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 burden. It discloses the return type (Transaction records) and a derived field (ageDays), but does not explicitly state whether the operation is read-only, describe pagination behavior, or note any rate limits or auth requirements. The verb 'list' implies non-mutating, but more disclosure would be needed for a higher score.

  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 three sentences with a clear front-loaded main action, concrete use-case examples, and return/pairing information. Every sentence earns its place with no filler or repetition.

  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 complexity of 9 optional parameters and no output schema or annotations, this description is adequate but incomplete. It explains the core purpose and return type, but does not define date formats, status value handling, pagination defaults, or what happens when no parameters are provided. The pairing note helps, but gaps remain for a fully self-sufficient tool definition.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds meaning for 'within a window' (from/to), 'specific programme' (programmeId), and statuses (pending/reversed/paid), but it does not explain limit, cursor, offset, maxAgeDays, or minAgeDays. With 9 parameters and this low coverage, the description leaves most parameters underspecified.

  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 tool lists affiliate transactions on Monetizze, naming specific statuses (earned, pending, reversed, paid) and filtering by window or programme. This distinguishes it from sibling tools like list_programmes, list_clicks, and get_earnings_summary.

  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?

  Explicitly provides example user queries that should trigger this tool ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and suggests pairing with get_earnings_summary for aggregate totals, which is an alternative-use note.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_mrge_generate_tracking_linkA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden for behavioral disclosure. It mentions the return type ('Returns a TrackingLink') and the need to validate programmeId, but omits auth requirements, error cases, or destination URL format expectations. This is moderate disclosure, but it doesn't contradict annotations since none exist.

  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, front-loaded with the primary action, and every clause earns its place: the action, the use case, the return type, and a prerequisite. No redundant content or filler.

  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 2-parameter tool with no output schema, the description covers the core purpose, use case, return type, and a precondition. It doesn't delve into error handling or the structure of a TrackingLink, but these are less critical for a straightforward link generator. It is reasonably complete for its complexity.

  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 only parameter names and types with 0% coverage, so the description must compensate. It names both parameters ('programme and destination URL') and adds the valuable hint to confirm programmeId via list_programmes, but it does not specify URL format or any constraints beyond what the schema already shows.

  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 a specific action: 'Generate a tracking link on mrge for a given programme and destination URL.' The verb 'generate' and resource 'tracking link' are precise, and the qualifier 'on mrge' distinguishes this from the many sibling generate_tracking_link tools for other networks.

  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?

  It explicitly says 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined,' providing clear context. It also gives a practical prerequisite: 'pair with list_programmes to confirm the programmeId.' However, it doesn't explicitly state exclusions like 'for other networks, use their respective generate_tracking_link tool,' leaving some ambiguity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_netrefer_generate_tracking_linkA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the return value ('Returns a TrackingLink') and a prerequisite (confirm programmeId via list_programmes), but it does not disclose authentication requirements, potential side effects, or error behavior. This is partial transparency, hence a mid-range score.

  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 three sentences, front-loaded with the core purpose, followed by usage and return/prerequisite information. Every sentence contributes unique value with no redundancy or fluff.

  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 tool with 2 straightforward parameters and no output schema, the description is largely complete: it explains what it does, when to use, what it returns, and how to prepare. It could mention error cases or auth requirements, but those are not essential given the simple scope. Overall it is sufficiently complete 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 0%, so the description must compensate. It maps the two parameters implicitly: 'programme' refers to programmeId and 'destination URL' refers to destinationUrl. It adds helpful guidance that the programmeId should be confirmed via list_programmes, but it does not explain the expected format or constraints for destinationUrl. This provides some semantic value but leaves gaps.

  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 action: 'Generate a tracking link on NetRefer for a given programme and destination URL.' It clearly identifies the network (NetRefer) and the output (a TrackingLink), distinguishing it from sibling generate_tracking_link tools for other networks.

  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?

  It explicitly states when to use it: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also recommends pairing with list_programmes to confirm the programmeId, which is a form of companion guidance. However, it does not explicitly mention when not to use it or alternative tools beyond the companion reference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_netrefer_get_earnings_summaryA
  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 burden. It discloses that the tool returns an EarningsSummary including oldestUnpaidAgeDays and implies read-only behavior via 'summarise', but does not detail auth needs, pagination, or potential side effects. Adds some context beyond schema but could be richer.

  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?

  Two sentences that are front-loaded with the main purpose, followed by usage example, a key return field, and pairing advice. Every sentence earns its place, no redundancy or fluff.

  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?

  With 8 parameters, no output schema, and no annotations, the description is too sparse. It only mentions one return field (oldestUnpaidAgeDays) and does not cover pagination (limit, cursor), age filters (minAgeDays, maxAgeDays), or the full EarningsSummary structure. An agent would likely struggle with parameters beyond the basic from/to/status/programmeId.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It maps 'date window' to from/to, 'by programme' to programmeId, and 'by transaction status' to status, but leaves limit, cursor, minAgeDays, and maxAgeDays unexplained. Partial compensation for an 8-parameter tool.

  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 'Summarise earnings on NetRefer' and clearly identifies the resource and scope, including breakdowns by programme and transaction status. This distinguishes it from other networks' earnings summaries and from list_transactions.

  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?

  It explicitly states when to use the tool ('when the user wants a single-figure answer plus context') with a concrete example, and points to list_transactions for drilling into underlying records, thereby naming the alternative tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_offer18_list_clicksA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It states 'Returns Click records' and the verb 'List' implies a read-only operation, but it does not explicitly disclose pagination behavior, authentication needs, or rate limits. The lack of any mention of potential side effects or constraints leaves some ambiguity.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core action, and every sentence provides additional value (use cases, return type, pairing advice). No redundant or filler content.

  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 6 parameters, no output schema, and no annotations, the description covers purpose and use cases well but omits parameter semantics and pagination behavior. The reference to 'recent' clicks and pairing with list_transactions provides partial context, but the description is not sufficiently complete for an agent to fully understand all invocation nuances.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 0% description coverage, so the description must compensate. It only explains the 'programme and date' filters (mapping to programmeId and from/to), while limit, cursor, and offset are completely unexplained. Date format is also unspecified, leaving significant gaps for an agent to invoke the tool correctly.

  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 tool lists recent affiliate clicks on Offer18, optionally filtered by programme and date. It distinguishes itself from siblings by naming the specific network (Offer18) and mentions pairing with list_transactions for comparison, making the purpose unmistakable.

  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?

  It explicitly guides when to use the tool: 'Use this for traffic-side debugging' with concrete example questions, and suggests pairing with list_transactions to compare clicks vs conversions. This gives clear context and a complementary alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_optimise-media_generate_tracking_linkA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description must carry the transparency burden. It discloses the return type ('Returns a TrackingLink') and a prerequisite (confirm programmeId via list_programmes), but it does not mention side effects, authentication requirements, rate limits, or error behavior. The word 'Generate' implies creation, but it lacks detail on whether persistent state is affected.

  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 with no waste. The primary action is front-loaded, followed by usage context and a pairing hint. Every sentence contributes essential information.

  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 lack of annotations and output schema, the description covers the key aspects: what the tool does, when to use it, what it returns, and a key prerequisite. It is sufficient for an agent to select and invoke the tool, but it could be more complete by noting potential errors or authentication needs.

  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 has 0% description coverage, so the description must add meaning. It loosely describes parameters as 'programme and destination URL' and specifically instructs to use list_programmes to confirm programmeId. This adds value beyond the bare parameter names, but it leaves the URL format and ID format underspecified.

  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: 'Generate a tracking link on Optimise Media for a given programme and destination URL.' It clearly identifies the network (Optimise Media), distinguishing it from the many sibling generate_tracking_link tools for other networks (e.g., affiliate_awin_generate_tracking_link).

  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?

  It provides clear usage context: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also references a specific workflow: 'pair with list_programmes to confirm the programmeId before calling,' which guides preparation. However, it does not explicitly state when not to use this tool versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_optimise-media_list_programmesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It discloses that the tool returns an array of Programme records and that it covers both joined and available programmes, which are key behavioral traits. It also implies a read-only list operation without explicit side effects, but it stops short of discussing pagination or authentication requirements.

  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 tight three-sentence paragraph that front-loads the core action and scope. Each sentence adds value: the first states what it does, the second gives usage triggers, and the third describes the return type and related tools. There is no wordiness or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has six optional parameters and no output schema or annotations, so the description needs to provide enough context. It covers the main purpose, return type, and typical use cases, which is useful. However, it omits any explanation of the filtering parameters (search, status, categories) and does not mention pagination, making it incomplete for an agent that needs to construct precise queries.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not compensate by explaining any of the six parameters (limit, cursor, offset, search, status, categories). While parameter names like limit and cursor are self-explanatory, status and categories lack any guidance on allowed values. The description provides no additional meaning beyond the schema, leaving the agent to guess at filter semantics.

  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 tool lists affiliate programmes on Optimise Media, with a specific action verb and resource. It distinguishes the tool by noting it covers both joined and available-to-join programmes, and it pairs with get_programme and list_transactions for related operations. The example user queries further clarify the intended purpose.

  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 explicitly gives example queries and states 'Use this when...' for inventory requests. It also mentions pairing with get_programme for drill-down and list_transactions for activity, which indirectly guides when to use alternatives. However, it does not explicitly exclude other list_programmes tools across networks, but within the Optimise Media context the guidance is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_optimise-media_list_transactionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description must carry the burden. It discloses that the tool returns Transaction records including derived ageDays and lists supported statuses. However, it does not cover pagination behavior, date formats, or any side effects, though listing is inherently safe.

  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?

  Two focused sentences: the first defines the tool's purpose, the second adds example queries, return value, and pairing advice. 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?

  With 9 parameters, no output schema, and no annotations, the description provides a solid conceptual model: what it lists, statuses, example questions, and derived ageDays. It lacks explicit pagination and timezone details, but overall the core usage is well covered.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It maps key parameter groups: 'window' to from/to, 'specific programme' to programmeId, statuses to the status parameter, and ageDays to minAgeDays/maxAgeDays. It omits limit, cursor, and offset, which are standard pagination parameters.

  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 ('List') and resource ('affiliate transactions on Optimise Media'), and scopes to statuses (earned, pending, reversed, paid) within a window or for a programme. It distinguishes from sibling tools by naming the network and by mentioning get_earnings_summary for aggregate totals.

  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?

  Provides concrete example user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and indicates when this tool is appropriate. It also references pairing with get_earnings_summary for aggregate totals, but does not explicitly say 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.

• affiliate_partnerize_generate_tracking_linkA
  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 some burden. It adds useful context that programmeId should be confirmed via list_programmes and states the return type ('Returns a TrackingLink'). However, it does not disclose auth requirements, error behavior on invalid inputs, or whether the operation is read-only vs. state-changing, so behavioral transparency is partial.

  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, front-loads the action and resource, and includes no fluff. Every sentence contributes either purpose, usage context, or a practical preparation step.

  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 2-parameter generation tool, the description covers the action, the use case, and the key prerequisite (validating programmeId). It does not describe error scenarios or output structure, but with no output schema and straightforward parameters, the provided context is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. The description names the two parameters ('programme and destination URL'), but only adds meaningful semantics for programmeId (via the list_programmes pairing hint). It does not provide additional details for destinationUrl beyond its name, leaving the parameter definitions minimally enriched.

  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 ('Generate'), names the resource ('a tracking link on Partnerize'), and specifies the inputs ('programme and destination URL'). It clearly distinguishes from sibling tools for other networks by naming Partnerize, and the phrase 'merchant they have joined' implies publisher-side, differentiating from the advertiser variant.

  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?

  Explicitly states when to use: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also gives an actionable prerequisite: 'pair with list_programmes to confirm the programmeId before calling.' However, it does not explicitly mention the advertiser-side generate_tracking_link as an alternative, so it lacks an explicit when-not or exclusion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerstack-advertiser_generate_tracking_linkA
  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 does reveal the return type ('Returns a TrackingLink') and hints that programmeId should be validated via list_programmes. Yet it omits potential side effects, authentication requirements, error conditions, or whether this is a read-only operation, leaving significant behavioral ambiguity.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is just two sentences, front-loaded with the primary action, and includes practical guidance (when to use, pairing with list_programmes) without any redundancy. Every word earns its place, 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.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple three-parameter tool with no annotations or output schema, the description covers the core action, typical use case, and a key prerequisite. However, the missing explanation of 'brand' and the minimal detail on the returned TrackingLink prevent it from being fully complete. It is close but not perfect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It explains the roles of 'programme' and 'destination URL' (mapping to programmeId and destinationUrl), but it completely fails to mention the required 'brand' parameter. It also provides no format or constraint details for destinationUrl, so parameter semantics are only partially covered.

  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 tool's purpose: 'Generate a tracking link on PartnerStack (advertiser) for a given programme and destination URL.' It includes a specific verb, resource, and inputs, and the '(advertiser)' qualifier distinguishes it from non-advertiser sibling tools like affiliate_partnerstack_generate_tracking_link.

  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 an explicit use case: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to confirm the programmeId, which is helpful workflow guidance. However, it does not explicitly name alternative tools or exclusion criteria, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerstack-advertiser_get_earnings_summaryA
  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 burden. It discloses the return type and a notable field (oldestUnpaidAgeDays), but does not mention authentication, pagination, rate limits, or side effects. It is a reasonable read-only summary, but lacks deeper behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, front-loaded with purpose, then usage and return details. No fluff, every sentence adds value.

  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 description covers the core use case and return type, but with 9 parameters, no output schema, and no annotations, it leaves gaps. It does not explain all parameters or pagination, making it adequate but not fully complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It implicitly covers 'from'/'to' (date window), 'programmeId' (by programme), and 'status' (by status), but leaves 'brand', 'cursor', 'limit', 'minAgeDays', and 'maxAgeDays' unexplained. Given 9 parameters, this is insufficient.

  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 tool summarizes earnings on PartnerStack for advertisers, with breakdowns by programme and status. It uses a specific verb ('summarise') and resource, distinguishing it from sibling list/get tools.

  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?

  It explicitly says 'Use this when the user wants a single-figure answer plus context' and provides an example ('total earnings in Q1 with status split'). It also suggests pairing with list_transactions for deeper analysis, which is clear guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerstack-advertiser_list_transactionsA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of behavioral disclosure. It mentions derived ageDays and filter scopes (window/programme), but does not explicitly state that the operation is read-only, nor does it disclose pagination behavior or potential error conditions. Some useful context is added, but key safety and operational traits are omitted.

  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, front-loaded with the verb and resource. It adds value with status examples, derived fields, and pairing guidance without wasted words.

  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 description gives a clear purpose, usage examples, and return field hints, but with 10 parameters, no output schema, and no annotations, it leaves significant gaps in parameter details and operational behavior. It is adequate for a basic understanding but not fully self-sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must explain the parameters. It only partially covers status, from/to, programmeId, and age-related filters; the required 'brand' parameter and limit/cursor/offset are not explained. With 10 parameters, this is insufficient for correct invocation without external knowledge.

  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 tool lists affiliate transactions with status types (earned, pending, reversed, paid) on PartnerStack (advertiser). It specifies the resource, action, and scope (window or specific programme), and the mention of 'advertiser' helps distinguish it from sibling tools like affiliate_partnerstack_list_transactions.

  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?

  Explicitly provides trigger examples ('what did I earn last month?', 'what's still pending?') and pairs with get_earnings_summary for aggregate totals, which disambiguates from related tools. This gives clear when-to-use context and points to the complementary alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_post-affiliate-pro_list_media_partnersA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that it returns MediaPartner records with 'normalised status,' which adds a behavioral trait beyond a list name. However, with no annotations, it does not address auth requirements, default filtering/pagination behavior, or the meaning of 'normalised status.' The read-only nature is implied by 'List' but not explicitly stated.

  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?

  Three sentences, all information-rich: purpose, usage examples, and pairing guidance. No redundant or filler language; it is front-loaded with the core action.

  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 tool with no output schema or annotations, the description covers purpose, when to use it, and a high-level return trait. However, the lack of parameter descriptions (0% schema coverage) and no output schema leave significant gaps for an agent invoking this tool correctly. The pairing hint partially compensates but does not replace schema-level parameter detail.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It clarifies that `brand` refers to the brand's programme, but it does not explain `limit`, `cursor`, `offset`, `search`, or `status`. The mention of 'outbound roster' suggests an unfiltered list but does not specify how these parameters modify the result.

  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 opens with a specific verb+resource: 'List the media partners (publishers) running on the brand's programme at Post Affiliate Pro.' It clearly distinguishes this from sibling tools (e.g., list_programmes, list_transactions) by naming the resource and network. Example phrasings further reinforce the intent.

  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?

  Explicit usage triggers are given in the form of concrete user questions ('who is promoting us on Post Affiliate Pro?', 'which publishers are active on our programme?'). It also names the complementary tool get_programme_performance and advises pairing it for per-publisher performance, effectively differentiating when to use each.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_rewardful_list_media_partnersA
  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 value by stating 'Returns MediaPartner records with normalised status', which explains the return type and a transformation. However, it does not disclose pagination behavior, default limits, authentication requirements, or the exact meaning of 'normalised status', leaving gaps for a 6-parameter 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 concise and well-structured: it opens with the core purpose, follows with explicit use cases, and ends with return type and a pairing suggestion. Every sentence earns its place, with no repetition or extraneous detail.

  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 complexity (6 parameters, no annotations, no output schema), the description is not fully complete. It briefly notes return records and suggests a complementary tool, but omits essential context about pagination, default values, filtering semantics, and the structure of returned records. It is adequate but has clear gaps for a tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 6 parameters with 0% description coverage, and the description does not meaningfully explain any of them beyond implying 'brand' through 'brand's programme'. It mentions 'normalised status' but that appears to describe output rather than the 'status' input parameter. This leaves the agent without guidance on how to use limit, cursor, offset, search, or status.

  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 'List the media partners (publishers) running on the brand's programme at Rewardful', using a specific verb ('List'), resource ('media partners'), and context ('at Rewardful'). It also distinguishes from other tools by explicitly naming Rewardful and focusing on media partners rather than programmes, transactions, or performance.

  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?

  It explicitly states when to use the tool: 'Use this when the user asks "who is promoting us on Rewardful?", "which publishers are active on our programme?", or wants an outbound roster.' It also provides a complementary alternative: 'pair with the matching get_programme_performance tool on Rewardful to drill into per-publisher performance.' This gives clear usage context and suggests related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_rewardful_verify_authA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description compensates by stating it calls a minimal authenticated endpoint and describing the return shape ({ok:true, identity?} or {ok:false, reason}). It does not explicitly discuss side effects, but 'verify' implies a read-only check, and the return contract is disclosed.

  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, front-loaded with purpose, and includes no irrelevant detail. Every sentence contributes value.

  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 description covers the tool's purpose, usage timing, and return format, but omits the meaning of the sole parameter 'brand', which is essential for correct invocation. Without this, the definition is not fully self-contained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has a required 'brand' parameter with no description, and the tool description does not explain what 'brand' refers to or how to determine its value. With 0% schema description coverage, the description should compensate but does not, leaving the agent to guess.

  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 tool verifies Rewardful credentials via a minimal authenticated endpoint, using a specific verb and resource. It distinguishes itself from sibling verify_auth tools by explicitly naming the network and the lightweight verification approach.

  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 explicitly advises using it at the start of a session, after rotating keys, or when another operation returns an auth error. It also suggests pairing with affiliate_run_diagnostic for a full health check, providing clear context and a named alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_scaleo_get_earnings_summaryA
  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 of behavioral disclosure. It does reveal the return type ('Returns an EarningsSummary including oldestUnpaidAgeDays') and implies a read-only operation via 'Summarise', but it omits details such as pagination behavior (despite limit/cursor parameters), authentication requirements, or any side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences with no wasted words. It front-loads the core purpose, then adds a usage heuristic, and closes with return value and complementary tool. Each sentence contributes useful information.

  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 8 parameters, no output schema, and no annotations, the description covers purpose and usage well but lacks parameter-level detail and a full picture of the return object. It does mention 'oldestUnpaidAgeDays' and the pairing with list_transactions, but an agent would still be uncertain how to set parameters like maxAgeDays/minAgeDays or interpret pagination.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, and the description only indirectly references parameters: 'date window' (from/to), 'programme' (programmeId), and 'status' (status). It does not explain limit, cursor, maxAgeDays, minAgeDays, or how they interact, leaving significant ambiguity for a tool with 8 optional parameters.

  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 ('Summarise') and resource ('earnings on Scaleo') with clear scope ('across a date window') and breakdown dimensions ('by programme and by transaction status'). It clearly distinguishes from sibling tools like list_transactions by focusing on summarized output rather than raw records.

  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?

  It explicitly states when to use the tool ('when the user wants a single-figure answer plus context') with a concrete example ('total earnings in Q1 with status split'), and suggests pairing with list_transactions to drill into details, which names an alternative/complementary tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_scaleo_list_clicksA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  There are no annotations, so the description carries the full burden. It discloses that the tool returns 'Click records' and notes the 'recent' nature of clicks, implying a default time window. However, it does not explain pagination behavior, default date range, or authentication requirements, leaving gaps in behavioral disclosure.

  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 three sentences long, front-loads the action, and includes practical examples and a pairing suggestion. Every sentence adds value; no filler or repetition of schema information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no annotations, no output schema, and 0% parameter descriptions, the description provides some context through use cases and return type, but it lacks details on pagination, default limits, and parameter semantics. The tool is simple, but an agent would need more information to invoke it confidently.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It mentions filtering 'by programme and date', which maps to programmeId and from/to, but it does not explain the purpose or format of limit, cursor, or offset. The meaning of 'recent' and the exact date format are also unspecified.

  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 tool 'List recent affiliate clicks on Scaleo' with a specific verb and resource. It distinguishes from siblings by naming Scaleo and contrasting with list_transactions for clicks vs conversions comparison. Optional filters for programme and date are explicitly mentioned.

  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 explicitly frames the use case as 'traffic-side debugging' and provides concrete example questions like 'are my links being clicked at all?' and 'where is traffic going on Scaleo?'. It also suggests pairing with list_transactions to compare clicks vs conversions, giving clear guidance on when to use the tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_shopmy_list_clicksA
  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 returns Click records and is for debugging, but does not mention read-only behavior, pagination (despite cursor/offset parameters), auth requirements, or side effects. The description adds some behavioral context but lacks important operational details.

  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?

  Three sentences, well-structured: the first states what the tool does, the second provides use cases, and the third covers return type and pairing. Every sentence adds value with no redundancy or filler.

  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 description gives a clear purpose, usage context, and a hint of return type, but given 6 parameters, no output schema, and no annotations, it is not fully complete. It omits pagination behavior, parameter constraints, and detailed return structure, leaving gaps for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only mentions filtering by 'programme and date' (implying programmeId and to/from) but does not explain limit, cursor, offset, or date formats. With 6 undocumented parameters, the description only partially compensates for the missing schema descriptions, leaving pagination semantics unexplained.

  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?

  Description clearly states the tool lists recent affiliate clicks on ShopMy with optional programme/date filtering, using specific verb+resource+scope. It distinguishes from siblings like list_transactions by naming ShopMy and its traffic-side debugging 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?

  Explicitly states use for traffic-side debugging with concrete example questions ('are my links being clicked at all?', 'where is traffic going on ShopMy?'). Also provides alternative pairing with list_transactions to compare clicks vs conversions, which tells the agent when not to use this alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_skimlinks_generate_tracking_linkA
  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 returns a TrackingLink and recommends confirming programmeId first, but it doesn't mention side effects, authentication requirements, error handling, or idempotency. This is adequate but not rich.

  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?

  Two concise sentences with no wasted words. The first sentence states the core function, and the second adds usage guidance and return info. Information is front-loaded and easy to parse.

  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 tool with two parameters and no output schema or annotations, the description covers purpose, when to use, prerequisite, and return type. It's compact but sufficient for a straightforward link-generation tool, though it could hint at what a TrackingLink contains.

  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 no descriptions (0% coverage), so the description must compensate. It names the parameters ('programme and destination URL') and implies that programmeId should be confirmed via list_programmes, but it adds no detail about URL format, validations, or how the TrackingLink is structured.

  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 tool generates a tracking link on Skimlinks for a given programme and destination URL. The verb 'generate' and resource 'tracking link on Skimlinks' are specific, and it distinguishes from sibling tools by naming the Skimlinks network.

  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?

  It says 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined,' giving a clear contextual trigger. It also advises pairing with list_programmes to confirm the programmeId, but it doesn't explicitly mention alternatives or exclusions for other networks.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tapfiliate_get_programme_performanceA
  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 burden. It correctly implies a read-only operation via 'Fetch' and 'Returns', but does not disclose pagination behavior, authentication requirements, or default date ranges. Some context is provided (returns ProgrammePerformanceRow records), but it lacks depth.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the purpose, then usage triggers, then return type and related tools. Every sentence adds value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 8 parameters, no output schema, and no annotations, the description leaves significant gaps: no parameter semantics, no pagination details, and only a vague mention of return records. However, it does provide usage examples and sibling tool relationships, so it is partially complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 8 parameters with 0% description coverage. The description only indirectly refers to date range and publisher filtering, and does not explain key parameters like brand, programmeId, limit, cursor, offset, or how they relate. This is insufficient for an agent to correctly construct a call.

  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 tool fetches per-publisher performance data with specific metrics (clicks, conversions, gross sale, commission) by date, using the verb 'Fetch' and the resource 'brand's programme at Tapfiliate'. This distinguishes it from generic get_programme tools.

  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?

  It explicitly provides example user queries that should trigger this tool, and notes complementary tools (list_media_partners for publisher IDs, list_transactions for drill-down), giving clear guidance on when to use it versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tapfiliate_list_media_partnersA
  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 discloses the return type ('MediaPartner records with normalised status') but omits details about pagination behavior, auth requirements, or potential errors. The addition of 'normalised status' adds some value but is not deeply transparent.

  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: the first states purpose, the second gives usage examples and a pairing recommendation. It is front-loaded, concise, and every sentence earns its place without fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 6 parameters, no output schema, and no annotations. The description covers intent, usage, and return type, but lacks parameter semantics and pagination details. It is reasonably complete for a straightforward list tool but leaves gaps that could confuse an agent on parameter usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It clarifies that 'brand' refers to the programme but does not explain limit, cursor, offset, search, or status parameters. The mention of 'normalised status' gives minimal hint about the status param, but overall the description adds little beyond the raw parameter names.

  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 tool's function: 'List the media partners (publishers) running on the brand's programme at Tapfiliate.' It uses a specific verb and resource, and the network is named in both the tool name and description, distinguishing it from sibling tools for other networks.

  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 example user queries ('who is promoting us on Tapfiliate?', 'which publishers are active on our programme?') and suggests pairing with get_programme_performance for deeper analysis, effectively guiding when to use this tool versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tolt_get_programmeA
  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 transparency burden. It discloses that the tool returns a single Programme with commission, status, and advertiser URL, which is helpful. However, it does not mention potential errors, rate limits, authentication requirements, or explicitly confirm a read-only nature. The simple fetch behavior is transparent enough, but lacks edge-case detail.

  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?

  Two sentences, no filler, front-loaded with the verb and resource. Every sentence earns its place, making it extremely concise 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?

  The tool is a simple 2-parameter read operation, but the missing explanation of 'brand' and the lack of an output schema mean the description must compensate more. It does convey the key return fields, but omits how the brand parameter factors in, leaving the context incomplete for full agent use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description mentions 'programme id' but does not explain the 'brand' parameter at all. With schema description coverage at 0% and two required parameters, the description should clarify both. Only one parameter is implied, leaving the other entirely unexplained, which is a significant gap.

  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 action: 'Fetch a single programme on Tolt by its network programme id.' It specifies the exact resource and scope, and distinguishes itself from sibling tools by mentioning it returns a single Programme and pairing with list_programmes for discovery.

  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?

  Explicit guidance is given: 'Use this when you already know the programme id and need its full record' and 'pair with list_programmes when you need to discover the id first.' This clearly states when to use this tool versus the alternative, fulfilling the dimension perfectly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tolt_get_programme_performanceA
  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 must carry behavioral disclosure. It implies read-only via 'Fetch' and describes the return type, but it omits potential side-effects (none expected), authentication expectations, pagination behavior, and date-range constraints. Given the minimal behavioral complexity, a 3 is appropriate.

  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?

  Three sentences, front-loaded with purpose, metrics, usage triggers, and companion tools. Every sentence adds value with no filler.

  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 tool with 8 parameters and no output schema, the description covers the core purpose and return type but omits parameter semantics, pagination, and filter behavior. It is more complete than a bare fetch, but not fully adequate for complex parameter handling.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description needed to compensate, but it only hints at 'by date' and 'per-publisher' without explaining brand, programmeId, publisherId, limit, cursor, or offset. The required brand parameter is not explicitly documented in the description, leaving parameter semantics largely uncovered.

  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 opens with a specific verb 'Fetch' and clearly identifies the resource (per-publisher performance for the brand's programme at Tolt) plus the exact metrics (clicks, conversions, gross sale, commission). It distinguishes itself from sibling tools by specifying 'per-publisher rollup' and naming the network 'Tolt'.

  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?

  It explicitly states when to use with example user queries ('how is each publisher performing on Tolt?') and gives integration guidance with list_media_partners and list_transactions for drill-down. This provides clear context for selection vs alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tolt_list_media_partnersA
  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 burden. It reveals the return type ('MediaPartner records') and that status is normalized, which is useful. However, it does not explicitly state read-only behavior, pagination details, or authentication requirements, leaving some behavioral transparency 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?

  The description is two sentences, front-loaded with the core purpose, and every sentence adds value. It includes example queries and a pointer to a related tool without any fluff or repetition.

  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 6 parameters, no annotations, and no output schema, the description is somewhat incomplete. It covers purpose, usage, and a brief return type, but omits parameter details, response structure, and pagination behavior. It is adequate but leaves significant gaps for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not explain any of the 6 parameters. It only implies the 'brand' parameter through 'brand's programme', but leaves limit, cursor, offset, search, and status meanings undocumented. The description fails to compensate for the lack of schema descriptions.

  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 action ('List'), the resource ('media partners (publishers)'), and the scope ('on the brand's programme at Tolt'). It distinguishes from siblings by naming the Tolt network and by explicitly pairing with get_programme_performance for a different need.

  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 gives explicit trigger phrases ('who is promoting us on Tolt?', 'which publishers are active on our programme?') and provides a clear context for when to use the tool. It also specifies a complementary tool (get_programme_performance) to drill into performance, offering guidance on alternative/companion usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradedoubler-advertiser_get_earnings_summaryA
  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 the return type ('EarningsSummary including oldestUnpaidAgeDays') and the summary-oriented nature. However, it does not mention authentication, side effects, or limitations, though for a get/summary operation these are somewhat less critical. It adds some behavioral context beyond the name but is not exhaustive.

  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 three sentences, each earning its place: purpose, usage context, and return/pairing guidance. Information is front-loaded, with no filler or repetition of schema details.

  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 (9 parameters, no output schema, no annotations), the description covers purpose, high-level usage, and return type, and suggests pairing with list_transactions. However, it lacks parameter-level detail, especially the required `brand`, and does not explain pagination or filtering options, leaving the agent with gaps in selecting and invoking the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 9 parameters with 0% description coverage, so the description must compensate. It hints at 'date window' (likely from/to), 'programme' (programmeId), and 'transaction status' (status), but it omits the required `brand` and does not explain `limit`, `cursor`, `maxAgeDays`, or `minAgeDays`. This is partial compensation, leaving many parameters ambiguous.

  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 ('Summarise'), names the resource ('earnings on Tradedoubler (Advertiser)'), and specifies scope ('across a date window, with breakdowns by programme and by transaction status'). It clearly distinguishes from sibling earnings summary tools by explicitly noting the Advertiser role.

  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?

  Provides explicit usage context: 'Use this when the user wants a single-figure answer plus context', with a concrete example. Also names an alternative/complement: 'pair with list_transactions to drill into the underlying records', giving clear guidance on when to use this tool vs others.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradedoubler-advertiser_get_programme_performanceA
  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 full transparency burden. It discloses the return type (ProgrammePerformanceRow) and aggregate nature, but does not address pagination/defaults despite cursor/offset params, nor auth/error behavior. It is not misleading, but leaves 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?

  Three sentences: purpose, usage cues, and complement relationships. No redundant text; each sentence adds distinct value, and information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 8 parameters and no output schema, and the description covers result semantics and some use cases, but fails to document parameter semantics and pagination. It partially compensates with examples and metric listing, but remains incomplete for safe autonomous invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not explain any of the 8 parameters. It only hints at date filtering ('by date') and publisher IDs via cross-reference to list_media_partners, leaving brand, programmeId, limit, cursor, offset, and to/from formats undocumented.

  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 opens with a specific action ('Fetch per-publisher performance') and lists exact metrics (clicks, conversions, gross sale, commission) and grouping (by date). It clearly distinguishes from sibling tools like list_transactions and get_earnings_summary through the per-publisher rollup framing.

  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 query examples ('how is each publisher performing', 'show me the top-earning partners last month') and names complementary tools (list_media_partners for publisher IDs, list_transactions for drill-down), giving clear when-to-use and alternative context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradedoubler-advertiser_verify_authA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses the mechanism (minimal authenticated endpoint) and the return format ({ok:true, identity?} or {ok:false, reason}), which gives a good sense of behavior. However, it does not explicitly state whether any side effects are involved, though the verify operation implies a read-only safe check.

  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 concise sentences that front-load the core purpose, then provide usage guidance and return format. Every clause adds value with no redundant content.

  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 return value and usage scenarios are well covered, but the required `brand` parameter is not explained, and there are no annotations to compensate. This is a notable gap for a tool that otherwise is quite complete for a simple verify auth operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The only parameter, `brand`, is required but completely undocumented in both the schema (0% coverage) and the description. The description never mentions the parameter or how to determine its value, leaving the agent without guidance for a required input.

  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 tool verifies Tradedoubler (Advertiser) credentials by calling a minimal authenticated endpoint. It specifies the exact resource and action, and naturally distinguishes itself from sibling verify_auth tools for other networks.

  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?

  Explicitly states when to use the tool: at the start of a session, after rotating keys, or on auth errors. It also mentions pairing with affiliate_run_diagnostic for a full health check, providing a clear complementary alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradedoubler_generate_tracking_linkA
  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 the return type ('Returns a TrackingLink') and hints at a prerequisite (confirm programmeId), but it does not mention authentication requirements, failure modes, or any side effects. This is a moderate amount of behavioral context beyond the 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?

  Three sentences, each earning its place: what it does, when to use it, and the return value plus prerequisite. Information is front-loaded and there is no 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?

  For a simple link-generation tool, the description covers purpose, usage context, return type, and a pairing prerequisite. It does not address error handling or network-specific auth requirements, but the essential context is present and the tool's simplicity limits the need for more.

  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 0% and the description only loosely restates the parameter names ('programme' and 'destination URL'). It adds the semantic tip to 'confirm the programmeId,' which gives some context, but no format, validation, or examples are provided to deepen understanding.

  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?

  Clearly states the action (generate a tracking link), the resource (Tradedoubler), and the inputs (programme and destination URL). It distinguishes from sibling tracking-link tools by naming the network and from list_programmes by its specific function.

  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?

  Explicitly says when to use: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also provides a concrete prerequisite: 'pair with list_programmes to confirm the programmeId before calling.' Lacks an explicit when-not-to-use alternative, but the guidance is strong.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradedoubler_get_earnings_summaryA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description should carry the burden. It discloses the aggregate behavior, return type (EarningsSummary), and a specific field (oldestUnpaidAgeDays), but does not cover auth, pagination, or default date range 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?

  Three sentences, front-loaded with purpose, includes a use-case quote and return hint – no redundant words.

  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 tool with 8 optional params, no annotations, and no output schema, the description covers the core use case and return shape but leaves parameter semantics and default behavior under-specified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%; the description implicitly covers from/to (date window), programmeId (by programme), and status (by status), but says nothing about limit, cursor, maxAgeDays, minAgeDays, or their semantics.

  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 'Summarise' with resource 'earnings on Tradedoubler' and explicit breakdowns by programme and status, clearly distinguishing it from list_transactions and other network-specific summaries.

  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?

  Explicitly says 'Use this when the user wants a single-figure answer plus context' and suggests pairing with list_transactions for drill-down, providing clear usage guidance and an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_value-commerce-advertiser_get_earnings_summaryA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description adds some behavioral context by stating the return value includes 'oldestUnpaidAgeDays' and that it is a summary operation. However, with no annotations provided, the description does not explicitly disclose side-effect safety, authentication requirements, rate limits, or how pagination/filtering behaves (though 'cursor' exists in schema). It partially compensates but leaves 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?

  The description is two sentences, front-loaded with purpose, then usage and output context. No wasted words; every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no annotations and no output schema, the description gives purpose, usage, and a hint about return content, but does not cover parameter details, return structure beyond one field, pagination, or potential errors. It is moderately complete but not self-sufficient for a 9-parameter tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It hints at 'date window' (from/to), 'programme' (programmeId), and 'status' filters, but does not explain limit, cursor, maxAgeDays, minAgeDays, or brand semantics. With 9 parameters, this is insufficient for an agent to correctly construct all arguments.

  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 tool's function: 'Summarise earnings on ValueCommerce (advertiser) across a date window, with breakdowns by programme and by transaction status.' It uses a specific verb ('Summarise') and resource ('earnings on ValueCommerce (advertiser)'), and the network-specific naming distinguishes it from other affiliate earnings summary siblings.

  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?

  Explicit guidance is provided: 'Use this when the user wants a single-figure answer plus context — e.g. "total earnings in Q1 with status split".' It also suggests a complementary tool: 'pair with list_transactions to drill into the underlying records,' which tells the agent when to use this summary vs. a transaction list.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_value-commerce_generate_tracking_linkA
  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 adds valuable context by stating 'Returns a TrackingLink' and recommending to 'pair with list_programmes to confirm the programmeId before calling.' However, it does not disclose potential side effects, authentication prerequisites, error behavior, or constraints on the destinationUrl format. This is a notable gap for a tool that creates a link.

  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 three sentences, all informative with no filler or redundancy. It front-loads the core action and follows with usage context and a supporting tip. Every sentence 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 simple two-parameter tool with no annotations and no output schema, the description covers the essential aspects: what it does, when to use it, return type, and a prerequisite action. The main gap is that 'Returns a TrackingLink' does not describe what a TrackingLink contains or how the agent can use it (e.g., to extract a URL). Still, it is reasonably complete for a straightforward generation 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 0%, so the description must compensate. The description mentions 'programme and destination URL' and explicitly references 'programmeId' in the list_programmes pairing note, which adds meaning beyond the raw schema. However, it does not define the expected format for destinationUrl (e.g., must be a fully-qualified URL) or clarify that programmeId is a network-specific identifier from list_programmes.

  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 tool's action: 'Generate a tracking link on ValueCommerce for a given programme and destination URL.' The verb 'Generate' is specific and the resource 'tracking link on ValueCommerce' distinguishes it from sibling tools targeting other networks. It also clarifies the use case: 'share an affiliate link to a specific product or page on a merchant they have joined.'

  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 a direct usage context: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also gives a sequencing guideline: 'pair with list_programmes to confirm the programmeId before calling.' However, it does not explicitly mention alternatives or exclusions (e.g., 'use other network-specific tools for different networks'), though the ValueCommerce naming partially distinguishes it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_value-commerce_list_transactionsA
  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 transparency burden. It discloses that it returns Transaction records including derived ageDays and supports status filtering, but does not mention pagination behavior, default limits, or authentication requirements.

  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 three sentences, front-loaded with the main verb and resource, includes relevant examples, and ends with a useful pairing suggestion. Every sentence adds value 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 9 parameters, no output schema, and no annotations, the description provides a solid overview of purpose, usage, and return type. It could be more complete by explaining pagination or parameter relationships, but the core context is well covered.

  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 schema description coverage at 0%, the description must compensate. It hints at the 'window' (from/to or min/max age days) and 'programme' (programmeId) and statuses, but does not clarify the difference between from/to and min/maxAgeDays, or the roles of cursor, offset, and limit.

  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 tool lists affiliate transactions on ValueCommerce, with specific statuses (earned, pending, reversed, paid), and scoping by date window or programme. It distinguishes from sibling tools by naming the network and the exact resource type, and provides concrete example queries.

  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?

  Explicit when-to-use guidance is given with example user queries, and it recommends pairing with get_earnings_summary for aggregate totals. It does not explicitly state when not to use this tool, but the guidance is clear enough for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_webgains-advertiser_get_programmeA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses that it returns a single Programme and lists example fields (commission, status, advertiser URL), which is helpful. However, it does not explicitly state read-only safety, error handling, or the role of the brand parameter, leaving gaps in behavioral 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?

  Two sentences with no filler. The main action is front-loaded, usage guidance and alternative are compactly included, and every sentence adds value. Excellent structure.

  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 simple get-by-id tool with no output schema and no annotations, the description covers purpose, when to use, return type, and alternative. However, it omits any explanation of the required brand parameter and does not describe potential error conditions or full return structure, which are meaningful gaps given the minimal schema/annotation context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It explains 'network programme id' for programmeId but completely omits the brand parameter, which is required. The description adds some meaning to one parameter but fails to cover the other, leaving significant ambiguity.

  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 tool fetches a single programme on Webgains (advertiser) by network programme id, using specific verb+resource+identifier. It distinguishes from siblings by explicitly mentioning 'single' and pairing with list_programmes for id discovery.

  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?

  Explicitly states when to use ('when you already know the programme id and need its full record') and names the alternative for discovering the id first ('pair with list_programmes'). This provides clear usage context and differentiation from the obvious list alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_webgains_generate_tracking_linkA
  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 disclosing behavior. It states that the tool 'Returns a TrackingLink' and warns to confirm programmeId via list_programmes, which hints at error potential. However, it does not disclose whether the operation is read-only, whether authentication is required (such as verify_auth), or any rate limits or side effects, leaving important behavioral gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three short sentences: action, use case, and return type with a pairing tip. It is front-loaded with the primary action, every sentence adds value, and there is no unnecessary verbosity or repetition of schema data.

  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 no output schema and no annotations, this description covers the core aspects: what the tool does, when to use it, the return type, and a prerequisite step. The main gap is lack of authentication or error behavior details, but for a two-parameter link-generation tool, it is reasonably 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 has 0% description coverage, so the description is the sole source of parameter meaning. It refers to 'programme and destination URL,' mapping to programmeId and destinationUrl, and the pairing instruction adds context for programmeId. However, it does not specify destinationUrl format (e.g., absolute URL) or explicitly state that programmeId comes from list_programmes, leaving room for ambiguity.

  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 opens with 'Generate a tracking link on Webgains for a given programme and destination URL,' clearly stating the action, target network, and required inputs. It also explains the use case ('when the user wants to share an affiliate link to a specific product or page on a merchant they have joined') and the explicit mention of Webgains distinguishes it from sibling generate_tracking_link tools for other networks.

  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 a clear usage trigger: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also gives a concrete prerequisite/alternative step: 'pair with list_programmes to confirm the programmeId before calling.' However, it does not explicitly state when not to use this tool or mention alternative network-specific tools, though the Webgains label implies this.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_webgains_list_clicksA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Without annotations, the description carries the burden of disclosing behavior. It implies a read-only operation ('List...') and states the return type ('Returns Click records'). However, it does not disclose details like default date ranges, pagination behavior, rate limits, or authentication requirements. This leaves some behavioral traits undocumented, but the core read-only nature is clear.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first states the core function, the second gives usage context and a related tool. Every clause adds value, with no fluff. It is front-loaded and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 6 parameters but no output schema or annotations, and the description omits pagination details and date format semantics. It does cover the purpose, filters, return type, and usage context, but the lack of parameter-level explanation and return structure leaves gaps. Given the complexity of the parameters, a more detailed description is needed for full completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 6 parameters with 0% description coverage. The description mentions 'optionally filtered by programme and date', which maps to programmeId and from/to, but it does not explain limit, cursor, offset, or the exact format for dates. This partial coverage does not fully compensate for the lack of schema descriptions for all parameters.

  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 a specific verb and resource: 'List recent affiliate clicks on Webgains'. It distinguishes itself from sibling tools like list_transactions by focusing on clicks and specifying the network (Webgains). The optional filters (programme and date) further clarify scope.

  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 explicitly tells when to use this tool: for traffic-side debugging, with concrete examples ('are my links being clicked at all?', 'where is traffic going on Webgains?'). It also names a complementary tool, list_transactions, for comparing clicks vs conversions, providing clear context on when this tool is relevant and how it fits with alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_webgains_list_programmesA
  4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses the scope (joined vs. available to join) and the return shape (array of Programme records). However, it does not mention authentication requirements, pagination behavior, or whether both joined and available are returned in one call, which leaves some gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core action, followed by usage triggers and relationships. Every sentence adds value: action + scope, when to use, output, and related tools. No wasted words.

  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 description gives a solid overview but lacks operational detail needed for a 6-parameter tool with no output schema and no annotations. It does not explain pagination, filtering options, default status scope, or authorization prerequisites. It is adequate for a basic list tool but leaves significant gaps for an AI agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% and the description provides zero explanation of any of the 6 parameters (limit, cursor, offset, search, status, categories). The agent only has parameter names to infer from, which is insufficient for correct invocation (e.g., accepted status values, format of cursor, interaction between offset and cursor).

  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 action ('List affiliate programmes the publisher has joined on Webgains (or which are available to join)') with a specific resource (Webgains programmes). It distinguishes from siblings by naming the related tools get_programme and list_transactions, making it clear this is the list-level operation.

  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 gives explicit trigger examples ('which merchants am I working with?', 'what programmes do I have on Webgains?') and context ('wants a partner inventory'). It also identifies complementary tools for drill-down and activity, implying when not 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.

• affiliate_yieldkit_generate_tracking_linkA
  4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must convey behavioral traits. It states 'Returns a TrackingLink' and advises confirming programmeId via list_programmes, which hints at failure risk. However, it omits authentication requirements, error behavior, or any side effects, leaving the agent with uncertainty about prerequisites.

  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 concise: exactly three sentences, each adding value. The first sentence states the core purpose, the second provides usage context, and the third gives a critical prerequisite. No unnecessary wording or repetition.

  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 link generation tool, the description covers purpose, usage, and a key prerequisite. It does not mention authentication or output details, but given the simplicity and the explicit pointer to list_programmes, it is mostly complete. A small gap remains regarding expected auth state and error handling.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must explain parameters. It references 'a given programme and destination URL,' mapping to programmeId and destinationUrl, and suggests using list_programmes to obtain the correct programmeId. Yet it does not provide detailed formats, constraints, or examples, leaving some ambiguity about expected values.

  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 tool's function: 'Generate a tracking link on Yieldkit for a given programme and destination URL.' This uses a specific verb+resource and distinguishes it from sibling tools by naming Yieldkit, avoiding confusion with other networks' generate_tracking_link 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 provides clear when-to-use guidance: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also recommends pairing with list_programmes to confirm the programmeId, which is an explicit usage note. However, it does not mention when not to use this tool or alternatives beyond that pairing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_yieldkit_get_earnings_summaryA
  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 must carry the burden. It discloses the return shape (EarningsSummary including oldestUnpaidAgeDays) and implies a read-only summarization operation, but it does not clarify how pagination parameters (limit, cursor) or status/programme filters affect the summary, leaving behavioral ambiguity.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences with the core purpose front-loaded, an illustrative example, and a pairing hint. No redundant filler; each sentence adds meaningful information.

  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 description covers the primary use case and return type, but with 8 parameters, no output schema, and no annotations, it leaves significant gaps: parameter behavior (especially pagination and age filters) and the full structure of the EarningsSummary are not explained. Adequate for a simple use case, but incomplete for complex queries.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate, but it only hints at date window (from/to), programme (programmeId), and status (status). It fails to explain 'limit', 'cursor', 'maxAgeDays', and 'minAgeDays', which are all present in the schema but undocumented both there and in the description.

  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?

  Description uses a specific verb ('Summarise earnings') and resource ('on Yieldkit across a date window'), and clearly distinguishes from sibling tools by emphasizing the summary/breakdown nature (by programme and transaction status) versus listing transactions. The return type EarningsSummary is explicitly named.

  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?

  Provides explicit guidance: 'Use this when the user wants a single-figure answer plus context' with a concrete example. Also recommends pairing with list_transactions for drill-down, effectively stating when to choose this tool over an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_yieldkit_list_transactionsA
  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 burden. It discloses that it returns Transaction records with derived ageDays and that filtering is possible by window/programme/status. However, it does not cover default behavior, pagination, or ordering.

  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?

  Three sentences, front-loaded with purpose, followed by concrete use cases and a pairing tip. No redundant wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 9 params, no annotations, and no output schema, the description provides purpose and usage but lacks parameter details, default windows, and pagination behavior. It is adequate but not complete for a higher score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must explain the 9 parameters. It touches on from/to ('within a window'), programmeId ('specific programme'), and status (via listed statuses/examples), but leaves limit, cursor, offset, minAgeDays, and maxAgeDays unexplained.

  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 it lists affiliate transactions on Yieldkit, enumerating status types (earned, pending, reversed, paid) and scope (window or programme). It distinguishes from sibling tools by naming Yieldkit and referring to get_earnings_summary for aggregates.

  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?

  Provides explicit user query examples ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and advises pairing with get_earnings_summary for aggregate totals, giving clear when-to-use and alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_2performant_list_transactionsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It adds useful behavioral context (returns Transaction records including derived ageDays, filters by window or programme), but does not disclose auth requirements, pagination behavior, rate limits, or explicit read-only status. The 'List' verb implies read-only, but it is not stated.

  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 three sentences, front-loaded with the main function, then usage guidance, then return-info and complement. Every sentence earns its place; no filler.

  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 description is adequate for a basic list operation: it covers purpose, basic filters, return type, and a complementary tool. However, with 9 parameters, no output schema, and no annotations, it leaves gaps around pagination, exact parameter formats, and any network-specific quirks. It is not incomplete enough to be unusable, but it could be more thorough.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It hints at mapping for from/to ('within a window'), programmeId ('specific programme'), and status (earned, pending, reversed, paid). However, it does not explain cursor, offset, limit, minAgeDays, maxAgeDays, or that status can be an array, leaving most of the 9 parameters undocumented.

  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 tool lists affiliate transactions on 2Performant, specifies the kinds of transactions (commissions earned, pending, reversed, paid), and distinguishes it from sibling tools like list_programmes, list_clicks, and get_earnings_summary. The verb 'List' plus resource 'affiliate transactions' is specific.

  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?

  It provides explicit usage examples ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and instructs pairing with get_earnings_summary for aggregate totals, effectively differentiating when to use this tool versus alternatives. This is clear guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_addrevenue_list_transactionsA
  4.1/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. It discloses that the tool returns Transaction records including a derived ageDays field, and mentions the status categories it can filter on. This goes beyond the schema but does not cover pagination or auth expectations, which are less critical for a read-only list 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 three sentences with no fluff. Each sentence adds value: function/scope, example use cases, and return/pairing information. It is front-loaded with the core purpose and remains concise despite the tool's complexity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 9 optional parameters, no output schema, and no annotations. The description covers purpose, usage examples, return records, and derived ageDays, but omits pagination behavior and more detailed parameter interactions. For a complex list tool, this leaves the agent to infer some invocation details, making it adequate but not 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 coverage is 0% and there are 9 parameters. The description adds meaning to key params: 'within a window' (to/from), 'specific programme' (programmeId), statuses (status), and derived ageDays (minAgeDays/maxAgeDays). However, it does not explain pagination params (limit, cursor, offset), which are important for a list operation. It partially compensates for the schema gap but not fully.

  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 tool lists affiliate transactions on Addrevenue, enumerates status types (earned, pending, reversed, paid), and specifies scope (within a window or for a specific programme). This distinguishes it from sibling list_transactions tools for other networks and from list_clicks or get_earnings_summary.

  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 explicit example queries ('what did I earn last month?', 'what's still pending?') and recommends pairing with get_earnings_summary for aggregates. It does not explicitly state when NOT to use the tool or name alternatives like list_clicks, but the guidance is clear and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_admitad-advertiser_get_programmeA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It clearly indicates a read operation via 'Fetch' and specifies the return as a single Programme with key fields (commission, status, advertiser URL). However, it does not disclose any potential side effects, auth requirements, error scenarios, or the meaning of the required 'brand' parameter, leaving partial 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 three focused sentences: action/scope, usage context, and return plus alternative. No redundant words.

  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 single-record GET, the description captures the purpose, usage, return shape, and the naming of the look-up key. It misses an explanation of the 'brand' parameter and does not mention the potential ambiguity with the non-advertiser sibling (affiliate_admitad_get_programme), but overall it's reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only indirectly explains 'programmeId' as the 'network programme id'. The required 'brand' parameter is not mentioned in the description at all, leaving the agent without guidance on what value to provide.

  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 the specific verb 'Fetch' with a clear resource ('a single programme on Admitad (advertiser)') and identifies the lookup key ('network programme id'). It also differentiates from sibling tools by explicitly mentioning the alternative list_programmes for discovery.

  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?

  It states when to use this tool ('when you already know the programme id and need its full record') and when to use the alternative ('pair with list_programmes when you need to discover the id first'). This is explicit and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_admitad_list_clicksA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of disclosing behavior. It adds that the tool returns Click records and is for recent clicks, which implies a read-only operation. However, it does not disclose pagination behavior, rate limits, authentication requirements, or what 'recent' means in terms of a default time window.

  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 three sentences with no fluff. It front-loads the core purpose, then provides usage context, return type, and a pairing suggestion. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 6 optional parameters, no output schema, and no annotations. The description covers purpose, use cases, and return type, but lacks details on parameter formats, pagination, and any constraints or defaults. It is adequate but leaves noticeable gaps for an agent to invoke it correctly in all situations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 6 parameters with 0% description coverage. The description adds meaning for 'programme' and 'date' (likely mapping to programmeId and from/to), which is valuable. However, it does not explain limit, cursor, or offset, leaving pagination parameters semantically undocumented.

  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 tool lists recent affiliate clicks on Admitad, with optional filtering by programme and date. It distinguishes itself from sibling tools by naming the specific network (Admitad) and the traffic-side debugging use case, and explicitly references pairing with list_transactions.

  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 gives explicit when-to-use guidance: 'Use this for traffic-side debugging' with concrete example questions. It also directs the agent to pair with list_transactions to compare clicks vs conversions, effectively naming an alternative for a different purpose.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adrecord_get_earnings_summaryA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Without annotations, the description carries the burden of behavioral disclosure. It reveals the return field oldestUnpaidAgeDays and mentions breakdown dimensions, but it does not address read-only safety, rate limits, pagination, or how date filters interact with age filters. It is not misleading, but it is only partially transparent.

  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 three sentences with no fluff: it states what the tool does, when to use it, and what it returns. It is front-loaded and every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an 8-parameter tool with no annotations, no output schema, and 0% schema parameter descriptions, the description provides a clear overview and return type but leaves several parameters (age filters, pagination) and behavioral specifics (date format, status values) unexplained. It is adequate for initial selection but not fully complete for safe 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 coverage is 0%, so the description must compensate for parameter meaning. It explains the date window (from/to), programme breakdown (programmeId), and status breakdown (status), but leaves limit, cursor, maxAgeDays, and minAgeDays unexplained. The description partially compensates for the schema's silence.

  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 tool's function: summarise earnings on Adrecord over a date window, with breakdowns by programme and transaction status. It also distinguishes itself from sibling tools like list_transactions by positioning itself as a summary rather than a detailed record listing.

  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 explicitly says to use it when a 'single-figure answer plus context' is needed, and mentions pairing with list_transactions to drill into underlying records, which defines the appropriate use context and an alternative/complementary tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adrecord_list_transactionsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full weight. It discloses output type (Transaction records), a derived field (ageDays), and status categories. However, it does not mention pagination behavior, default date ranges, or any side effects, leaving room for more behavioral detail.

  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?

  Three sentences deliver the purpose, usage examples, and output details with no redundancy. The description is front-loaded with the main purpose and each sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 9 optional parameters, no schema descriptions, no output schema, and no annotations, so the description must be comprehensive. It covers core use cases, status, window, and returned records, but lacks pagination semantics and detailed filter explanations, so it is not 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 0%, so the description must compensate. It adds meaning for window (from/to), programme (programmeId), and status (pending, reversed, paid), but leaves pagination params (limit, cursor, offset) and age filters (maxAgeDays, minAgeDays) unexplained, providing only partial compensation.

  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 ('List'), resource ('affiliate transactions on Adrecord'), and scope ('within a window or for a specific programme'). It names the statuses covered and distinguishes this from aggregate tools like get_earnings_summary, making it clearly differentiated from siblings.

  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?

  It explicitly lists when to use ('Use this when the user asks "what did I earn last month?", "what's still pending?", or "show me reversed sales"') and mentions the alternative for aggregate totals ('pair with get_earnings_summary for aggregate totals'), providing both when-to-use and when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adtraction-advertiser_get_earnings_summaryA
  4.1/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 full responsibility. It discloses that the tool returns an EarningsSummary and highlights a specific field (oldestUnpaidAgeDays), and implies a read-only summarization operation. However, it does not state authentication requirements, pagination behavior, or side effects (though likely none). It adds some value but lacks full behavioral disclosure.

  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?

  Three sentences with no filler: purpose, usage guidance, and return value. It is front-loaded and every sentence adds information.

  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?

  Despite the complexity of 9 params and no output schema, the description covers the main purpose, usage scenario, and return type. Yet it omits parameter formats, allowed status values, and pagination details, making it only partially complete for an agent to invoke correctly without further inference.

  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 has 0% description coverage, but the description compensates by explaining the meaning of key parameters: date window (from/to), programme breakdown (programmeId), and status breakdown (status). However, it does not explain limit, cursor, maxAgeDays, minAgeDays, or the required brand parameter, leaving several parameters ambiguous.

  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 'Summarise earnings' and identifies the platform (Adtraction advertiser), the scope (date window), and the breakdown dimensions (programme, transaction status). It also distinguishes itself from the sibling list_transactions tool by noting it returns a single-figure answer. This clearly differentiates it from other earnings_summary tools across networks.

  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?

  Explicitly states when to use it: when the user wants a single-figure answer plus context, with a concrete example. It also recommends pairing with list_transactions for drilling into records, which provides guidance on alternatives/complements. This is explicit usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_affiliate-future_list_clicksA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Description discloses it returns Click records and supports filtering, but with no annotations it doesn't cover pagination behavior, default date range, or auth requirements. As a read-only list operation, it's reasonably transparent but leaves some behavioral details unspecified.

  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?

  Three sentences with no fluff; first sentence states purpose, second gives use case, third covers return type and related tool. Very efficient.

  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?

  Provides purpose, use case, return type, and a cross-reference to list_transactions. However, with 6 params and no output schema, the description lacks pagination details and Click record structure, so an agent may need to infer or experiment.

  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?

  Description explains that programme and date filters are available, adding meaning to programmeId/from/to. However, pagination params (limit, cursor, offset) are not mentioned at all, and with 0% schema coverage this is a gap.

  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?

  Clearly states it lists recent affiliate clicks on Affiliate Future, with optional programme/date filters. This is a specific verb+resource+scope, and the traffic-debugging context distinguishes it from transaction listing.

  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?

  Explicitly says to use for traffic-side debugging with example questions, and recommends pairing with list_transactions to compare clicks vs conversions. This gives clear when-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_amazon-creators_get_earnings_summaryA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description discloses the return object and a notable field (oldestUnpaidAgeDays) and the pairing with list_transactions. However, it doesn't state read-only nature, pagination behavior, or effects of status/programme filters, leaving some behavioral ambiguity.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, front-loaded with purpose; every sentence adds either usage guidance or return info, with no filler.

  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 description covers purpose, return type, and complementary tool, which is good for a summary tool. But with 8 optional params and no output schema, it leaves significant gaps around pagination and age filters; still adequate given the simple summary use case.

  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 0%, but the description implies meaning for date window (from/to), status, and programmeId. It does not explain limit, cursor, maxAgeDays, minAgeDays, so half the parameters remain semantically undocumented.

  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 opens with a clear verb+resource: 'Summarise earnings on Amazon Creators across a date window', and distinguishes from list_transactions by indicating summary vs drill-down. It also names breakdown dimensions (programme, transaction status), which separates it from generic listing tools.

  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?

  Explicitly states 'Use this when the user wants a single-figure answer plus context' and gives an example. It also points to list_transactions for deeper drill-down, providing an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_avantlink_get_earnings_summaryA
  4.1/5.0
  Behavior4/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 the return type (EarningsSummary including oldestUnpaidAgeDays) and suggests pairing with list_transactions. However, it does not mention pagination, auth, or whether it is read-only, though the name implies read-only.

  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 three sentences long, front-loaded with the main purpose, and includes a concrete example and return type. Every sentence adds value without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 8 parameters and no output schema/annotations, the description is incomplete. It covers the core use case and output but lacks details on all parameters, pagination, and edge cases. The missing information is likely critical for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 8 parameters with 0% description coverage. The description only hints at 'date window' (from/to), 'status', and 'programme', but does not explain formats, defaults, or the purpose of limit, cursor, maxAgeDays, or minAgeDays. It fails to compensate for the schema's lack of parameter descriptions.

  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 tool summarises earnings on AvantLink over a date window, with breakdowns by programme and transaction status. The verb 'Summarise' and the resource 'earnings' are specific, and the mention of 'single-figure answer plus context' distinguishes it from list_transactions.

  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?

  Explicitly says 'Use this when the user wants a single-figure answer plus context' and gives an example ('total earnings in Q1 with status split'). It also names an alternative, list_transactions, for drilling into underlying records, covering when/alternative usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin_generate_tracking_linksA
  4.1/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 for behavioral disclosure. It provides useful context: returns generated link responses, preserves per-request failures, and supports batch generation up to 100 links. It does not cover all potential concerns (e.g., authentication, rate limits), but the added failure handling and response behavior go beyond basic purpose statements.

  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 three sentences, each serving a distinct purpose: stating the function, specifying when to use it, and disclosing return/failure behavior. There is no wasted wording or 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?

  The description provides the essential context for a batch link generation tool: it mentions the official Link Builder API, the batch limit (100), deeplink validation use case, and how failures are handled. Given there is no output schema, the description's note about returning generated responses is helpful, though it could have been more explicit about the request item structure.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% and the description does not compensate by explaining the structure of the 'requests' array or its fields (advertiserId, destinationUrl, shorten, parameters). It only vaguely references 'advertiser destinations', leaving the agent to rely entirely on the schema. Since the description adds minimal meaning beyond the schema, this is a weak point.

  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 tool's function: 'Generate Awin tracking links through the official Link Builder API for one or many advertiser destinations.' It uses a specific verb ('Generate') and distinct resource ('Awin tracking links'), and the plural form combined with 'one or many' and 'up to 100 links' distinguishes it from the sibling single-link tool.

  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 explicit usage guidance: 'Use this when the user wants Awin to validate deeplink support or generate up to 100 links in one workflow.' This clearly indicates when to choose this tool, but it does not explicitly mention alternatives or when not to use it, which prevents a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_belboon_get_earnings_summaryA
  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 must carry the behavioral disclosure. It discloses that the tool returns an EarningsSummary including oldestUnpaidAgeDays and focuses on summarization, which implies a non-mutating operation. However, it does not explicitly state auth requirements, rate limits, or any side effects, leaving some uncertainty about safety and preconditions.

  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?

  Three sentences, each adding value: purpose, usage context, and return/related-tool hint. Front-loaded and no filler.

  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?

  While the description gives a strong high-level overview and useful usage context, it omits pagination semantics (limit/cursor), the meaning of age-based filters, and any date format constraints. With 8 parameters, no annotations, and no output schema, the description is not fully complete, though it suffices for a basic selection decision.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds meaning for 'date window' (from/to), 'programme' (programmeId), and 'transaction status' (status), but leaves limit, cursor, maxAgeDays, and minAgeDays unexplained. This partial coverage is inadequate for a fully self-contained tool.

  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 opens with 'Summarise earnings on Belboon across a date window, with breakdowns by programme and by transaction status.' This is a specific verb+resource+scope that clearly distinguishes it from the many other network-specific earnings summary tools and from list_transactions.

  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?

  It explicitly states 'Use this when the user wants a single-figure answer plus context — e.g. "total earnings in Q1 with status split".' and advises 'pair with list_transactions to drill into the underlying records.' This gives clear when-to-use and alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_belboon_list_clicksA
  4.1/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 implies a read-only 'List' operation and mentions the return type ('Returns Click records'), but it does not explicitly disclose authentication needs, default time windows, or pagination behavior. The term 'recent' is vague and could mislead about date filters.

  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?

  Three sentences, front-loaded with the core function, then usage context. Every sentence contributes value without redundancy. It is concise yet informative.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema and 6 parameters, the description provides a solid overview but lacks important details. It states the return type and usage, but does not cover pagination parameters, date formats, or authentication requirements. For a list tool with multiple optional filters, these gaps reduce completeness.

  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 0%, so the description must compensate. It adds meaning for some parameters by mentioning filtering 'by programme and date', which maps to programmeId and from/to. However, it does not address limit, cursor, or offset, leaving pagination semantics unexplained.

  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 opens with a specific verb and resource: 'List recent affiliate clicks on Belboon'. It distinguishes itself from sibling tools like affiliate_belboon_list_transactions by focusing on clicks and even suggests pairing with list_transactions for comparison.

  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?

  Provides explicit usage context: 'Use this for traffic-side debugging' with concrete example questions. It also names an alternative/complementary tool ('pair with list_transactions'), giving clear when-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_belboon_list_programmesA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the full burden. It discloses the return type ('array of Programme records') and scope (joined/available programmes), but does not mention pagination behavior, filter effects, or authentication requirements. This is useful but not a deep behavioral disclosure.

  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?

  Three sentences: the first states the core action, the second gives concrete user phrasings, and the third covers return type and related tools. No filler or 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?

  Description is well-rounded for a list tool: purpose, use cases, return shape, and related tools. It lacks parameter semantics and pagination details, but given no output schema and many sibling tools, it provides enough for correct selection.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% and the description mentions none of the six parameters (limit, cursor, offset, search, status, categories). The 'joined/available' distinction gives conceptual context but does not explain how to use any parameter.

  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?

  Description opens with 'List affiliate programmes the publisher has joined on Belboon (or which are available to join)', giving a specific verb, resource, and network scope. It clearly distinguishes this from sibling tools like get_programme (single record drill-down) and list_transactions (activity).

  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?

  Explicitly states usage triggers with natural-language examples: 'which merchants am I working with?', 'what programmes do I have on Belboon?', or wanting a partner inventory. It also recommends get_programme for drill-down and list_transactions for activity, effectively providing alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_cake_list_clicksA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description must disclose behavior. It states the tool returns Click records and focuses on recent, filterable data, but does not describe default date ranges, pagination behavior, or parameter edge cases. This is adequate for a read-only list tool but lacks further depth.

  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?

  Two sentences with no wasted words. Core function, filters, use case, and cross-reference are all packed efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no annotations, no output schema, and 6 undocumented parameters. The description covers the core purpose and usage context but omits parameter format details, pagination, and return field specifics. It is sufficient for selection but not fully complete 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 0%, so the description must compensate. It explains that programmeId and date range (from/to) filter results, but does not explain limit, cursor, or offset beyond their schema names. This partially compensates for the missing schema descriptions.

  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 ('List...'), names the resource ('affiliate clicks on CAKE'), and mentions optional filters ('by programme and date'). It also distinguishes from the sibling list_transactions by stating it returns Click records.

  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?

  Explicitly states the use case for traffic-side debugging with concrete questions ('are my links being clicked at all?', 'where is traffic going on CAKE?') and recommends pairing with list_transactions to compare clicks vs conversions, providing a clear alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_cj-advertiser_get_earnings_summaryA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description bears the full burden of behavioral disclosure. It adds context by stating the return type (EarningsSummary including oldestUnpaidAgeDays) but does not mention limitations, rate limits, or explicitly confirm read-only behavior. It provides some value but lacks comprehensive 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 compact, using two sentences to convey purpose, usage, and return type. The example and pairing advice are valuable and add no unnecessary words.

  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 description covers purpose, usage, and return type, and differentiates from list_transactions. However, with no annotations or output schema and 9 parameters, it omits key parameter semantics, making it only partially complete for a summary 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 coverage is 0%, so the description must compensate. It implies meaning for 'date window' (from/to), 'by programme' (programmeId), and 'by transaction status' (status), covering the most relevant parameters. However, it leaves limit, cursor, maxAgeDays, minAgeDays, and brand undocumented, which is a significant gap for a 9-parameter tool.

  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 tool summarizes CJ Affiliate (advertiser) earnings across a date window, with breakdowns by programme and status. It distinguishes from sibling tools by specifying the advertiser scope and providing an example use case that contrasts with list_transactions.

  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?

  It explicitly instructs when to use this tool ('Use this when the user wants a single-figure answer plus context') and gives a concrete example. It also recommends pairing with list_transactions to drill into underlying records, which is an explicit alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_cj-advertiser_get_programme_performanceA
  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 transparency burden. It does disclose the return type (ProgrammePerformanceRow), the metric fields, and the by-date aggregation, which is useful. However, it omits behavioral details such as pagination behavior, default date ranges, whether zero-activity publishers are included, or any authorization requirements. For a read operation, the description is adequate but not richly transparent.

  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 three sentences, front-loaded with the core purpose, then usage triggers, then complementary tools. Every sentence adds value with no redundancy or padding. It is well-structured for an agent to quickly parse.

  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 8 parameters, no output schema, and no annotations, the description is moderately complete. It covers the primary use case, return type, and related tools, but it does not document several parameters (limit, cursor, offset, programmeId) or explain pagination/error behavior. The absence of an output schema also means the description should clarify the shape of ProgrammePerformanceRow, which it does not. Adequate for the core case but incomplete for complex invocations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds meaning for brand (via 'the brand's programme'), from/to (implied by 'by date'), and publisherId (via the reference to list_media_partners). However, it does not explain the semantics of limit, cursor, offset, or programmeId, which are non-obvious and left entirely to the schema. Thus, it partially compensates but leaves gaps.

  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 action ('Fetch per-publisher performance') and a clear resource ('the brand's programme at CJ Affiliate (advertiser)'), listing the exact metrics (clicks, conversions, gross sale, commission) and the aggregation level (by date, per-publisher). This distinguishes it from sibling tools like list_transactions or get_earnings_summary, which serve different aggregation or drill-down purposes.

  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 explicitly says 'Use this when...' and provides three concrete user query examples. It also names related tools for complementary tasks: list_media_partners for publisher IDs and list_transactions for transaction-level drill-down, implicitly clarifying when not to use this tool (when transactional detail is needed).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_clickbank_list_transactionsA
  4.1/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 returns Transaction records including a derived ageDays field and supports filtering by status and programme/window. However, it does not mention authentication requirements, pagination behavior, default limits, or any side effects, which would be helpful for a tool with no other metadata.

  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 three sentences long, each earning its place: purpose, usage examples, and return value plus pairing recommendation. It is front-loaded with the main verb and resource, and there is no fluff or repetition of the tool name.

  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 9 parameters, no annotations, and no output schema, the description needs to be thorough. It covers the core purpose, usage scenarios, return type, and some param semantics, which is good. But it omits details on pagination (limit/cursor/offset), date format expectations, and the full structure of Transaction records, leaving the agent to guess about important operational aspects.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds meaning to several parameters: 'within a window' clarifies the from/to date range, 'for a specific programme' explains programmeId, and statuses are enumerated. It also hints at age-based filtering through the mention of ageDays. However, the pagination parameters (limit, cursor, offset) are left completely unexplained, and no information is given about date formats or allowed status values.

  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 action ('List affiliate transactions') with a clear resource ('on ClickBank') and scope ('within a window or for a specific programme'). It lists the transaction statuses covered (earned, pending, reversed, paid) and includes example user queries, making it unmistakable. It also differentiates this tool from the sibling get_earnings_summary by noting it returns Transaction records rather than aggregates.

  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 explicitly says when to use this tool: when the user asks things like 'what did I earn last month?', 'what's still pending?', or 'show me reversed sales'. It also provides an alternative by instructing to pair with get_earnings_summary for aggregate totals, implying use that tool when aggregates are needed. This is clear, actionable guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_commission-factory-advertiser_get_programmeA
  4.1/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 burden. It conveys a read-only 'Fetch' action and describes the return type, but it does not disclose auth prerequisites, error behavior, or side effects beyond the basic fetch semantics.

  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?

  Three sentences, each earning its place: action, use case, and pairing with list_programmes. The most critical information is front-loaded, with no redundant wording.

  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 low-complexity two-parameter fetch tool without an output schema, the description covers purpose, when to use it, and what it returns. It misses only the brand parameter semantics and auth details, so it is nearly complete but not perfect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description should compensate for the bare parameter schema. It maps programmeId to 'network programme id' but completely omits any explanation of the required 'brand' parameter, leaving a significant gap for one of only two parameters.

  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 ('Fetch a single programme on Commission Factory (advertiser)') and clearly identifies the resource and the network. It distinguishes itself from sibling tools by naming the advertiser variant and the list_programmes counterpart.

  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?

  It explicitly states when to use the tool ('when you already know the programme id and need its full record') and points to list_programmes as the alternative for discovering the id, giving clear usage direction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_daisycon-advertiser_verify_authA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries full burden. It discloses the return shape: 'Returns {ok:true, identity?} or {ok:false, reason}', and describes the call as 'minimal authenticated endpoint', implying a lightweight, non-mutating operation. It doesn't detail side effects or prerequisites beyond 'configured credentials', but for a verify tool this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each adding distinct value: purpose, usage timing, and return format with a pointer to a related tool. No redundant or filler content; front-loaded with the primary action.

  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 1-parameter tool with no output schema or annotations, the description covers purpose, when to use, return format, and a related diagnostic tool. The only notable gap is the undocumented 'brand' parameter, which prevents it from being fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% and the description does not explain the 'brand' parameter. It says 'configured credentials' but does not link them to the 'brand' property or clarify what values are expected. The description adds very little semantic meaning beyond what the schema already shows (a required string).

  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 tool's purpose: 'Verify the configured credentials for Daisycon (advertiser) are valid by calling a minimal authenticated endpoint.' This specifies the verb (verify), resource (Daisycon advertiser credentials), and method, distinguishing it from the many other network-specific verify_auth sibling 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?

  Provides explicit timing guidance: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also suggests pairing with affiliate_run_diagnostic for a full health check, giving an alternative/related tool. No explicit 'when not to use' is stated, but the positive guidance is strong.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_daisycon_list_transactionsA
  4.1/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 burden. It states the return type ('Returns Transaction records including derived ageDays'), which adds behavioral context beyond simply 'list'. However, it does not mention pagination behavior, default date ranges, or authentication requirements, leaving gaps for a tool with 9 parameters.

  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, front-loaded with the operation and scoping, followed by usage examples and return info. Every sentence adds value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 9 parameters, no annotations, and no output schema, the description provides a solid high-level overview but lacks details on pagination, default behavior, and the full transaction record structure. The mention of derived ageDays helps, but it's not enough to be fully complete for a complex 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 0%, so the description must compensate. It adds meaning by explaining the window (from/to), programme (programmeId), and status values (earned, pending, reversed, paid), plus the derived ageDays. But it leaves pagination parameters (limit, cursor, offset) and age filter parameters (minAgeDays, maxAgeDays) completely unexplained.

  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 tool lists affiliate transactions on Daisycon, scoped by time window or specific programme, and names the transaction statuses (earned, pending, reversed, paid). It uses a specific verb+resource+scope and distinguishes itself from sibling tools like list_clicks and get_earnings_summary by focusing on transactions.

  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?

  It provides explicit when-to-use guidance with concrete user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales'), and even recommends pairing with get_earnings_summary for aggregate totals, covering both usage and alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_everflow-advertiser_get_programmeA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description bears the transparency burden. It discloses the return type ('a single Programme') and the fields included (commission, status, advertiser URL), which is useful. However, it does not explicitly state that this is a read-only operation, what happens on a missing ID, or any auth requirements. The word 'Fetch' implies read-only but leaves some behavioral traits unstated.

  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 compact and front-loaded: the first sentence states the action and scope; the second adds when-to-use and the return contents. Every sentence earns its place, with no redundancy or filler.

  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 2-parameter fetch tool, the description covers purpose, usage, and return fields well. However, the missing explanation of the 'brand' parameter and the lack of any error-behavior notes (e.g., not-found handling) mean it is not fully complete. The absence of annotations and output schema increases the burden that the description should shoulder.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must explain both parameters. It clarifies 'programmeId' as the 'network programme id', but completely ignores the required 'brand' parameter. An agent would not know what value to pass for 'brand' based on the description, which is a significant gap for a required parameter.

  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 names a specific verb ('Fetch'), a clear resource ('a single programme on Everflow (Advertiser)'), and the lookup method ('by its network programme id'). It also explicitly contrasts with list_programmes for id discovery, fully distinguishing it from sibling get_programme tools for other networks.

  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?

  It states the precise condition for use ('when you already know the programme id and need its full record') and names the alternative for id discovery ('pair with list_programmes when you need to discover the id first'). This gives explicit when-to-use and alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_everflow-advertiser_get_programme_performanceA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  There are no annotations, so the description carries the full burden. It usefully states that the tool returns ProgrammePerformanceRow records and lists key metrics, but it does not disclose pagination behavior, date-range semantics, default limits, or authentication/scope expectations. This is partial transparency for a read-style 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 dense but efficient: it leads with the action and metrics, gives concrete example queries, then mentions return type and related tools. No filler or repetition; every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an 8-parameter tool with no output schema and no annotations, the description provides strong use-case orientation and return-type information but leaves important operational details (parameter formats, pagination, defaults) unspecified. It is adequate for selection but not fully complete for invocation confidence.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only partially compensates. It implies date range via 'by date' and publisher filtering via 'per-publisher', plus the pair-with-list_media_partners hint for publisher IDs. However, the meaning of brand vs. programmeId, date formats, and pagination parameters (limit, offset, cursor) remains undocumented.

  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 opens with a specific verb and resource: 'Fetch per-publisher performance for the brand's programme at Everflow (Advertiser) — clicks, conversions, gross sale, and commission, by date.' This clearly distinguishes the tool from siblings by specifying both the network (Everflow Advertiser) and the per-publisher performance angle.

  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?

  Explicit usage triggers are provided via example user queries: 'Use this when the user asks "how is each publisher performing on Everflow (Advertiser)?", "show me the top-earning partners last month"'. It also names complementary tools, list_media_partners for publisher IDs and list_transactions for transaction-level drill-down, giving clear alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_everflow-advertiser_verify_authA
  4.1/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. It discloses the return shape ({ok:true, identity?} or {ok:false, reason}) and indicates the call is minimal, implying low impact. It does not explicitly state side-effect safety, but the nature of a credential check strongly implies read-only 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 three sentences, each adding distinct value: what the tool does, when to use it, and what it returns. It is front-loaded, concise, and free of filler.

  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 verification tool with one required parameter, the description covers purpose, usage triggers, return format, and relationships to other tools. The only missing context is the meaning of 'brand', which limits overall completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has one required parameter 'brand' with zero description coverage. The tool description does not explain what 'brand' means or how it's used, leaving the agent to guess whether it's a network name, account ID, or credential key. This is a critical gap since the parameter is required and its semantics are entirely absent.

  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 explicitly states the tool verifies Everflow (Advertiser) credentials via a minimal authenticated endpoint. It uses a specific verb ('verify') and resource ('credentials'), clearly distinguishing this from sibling verification tools for other networks and from general tools like affiliate_run_diagnostic.

  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 context: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also names a complementary tool (affiliate_run_diagnostic) and describes when to use that instead, offering clear guidance on alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_everflow_get_earnings_summaryA
  4.1/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 transparency burden. It does state that the tool returns an EarningsSummary including oldestUnpaidAgeDays, which is helpful. However, it does not explicitly mention read-only behavior, auth requirements, or side effects (though these are inferable from the 'summarise' verb). It fails to disclose pagination behavior or timezone handling, leaving some ambiguity for a safe invocation.

  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 three sentences long and front-loads the core purpose in the first sentence. Every sentence adds value: function, usage context, and return/companion tool. No redundancy or filler.

  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 8 optional parameters, no annotations, and no output schema, the description provides a good high-level overview but lacks critical details. It does not explain the purpose of limit/cursor/maxAgeDays/minAgeDays, nor does it describe the full return structure beyond one field. For an agent to use advanced filtering or pagination, it would need additional documentation.

  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 has zero property descriptions (0% coverage), so the description must compensate. It adds meaning for the date window (from, to), programme breakdown (programmeId), and status breakdown (status). However, it leaves limit, cursor, maxAgeDays, and minAgeDays completely unexplained, which are less self-explanatory and could affect correct invocation.

  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 a specific action ('Summarise earnings on Everflow'), identifies the resource (earnings), and specifies breakdown dimensions (programme, transaction status). It also distinguishes itself from sibling tools by focusing on summary rather than granular transactions, and explicitly pairs itself with list_transactions for deeper drill-down.

  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 gives an explicit usage criterion: 'when the user wants a single-figure answer plus context', and provides a concrete example. It also advises pairing with list_transactions for underlying records, which clearly signals when this tool is appropriate versus an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_financeads_generate_tracking_linkA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses that it returns a TrackingLink and advises confirming programmeId beforehand, but it does not mention side effects, error conditions, authentication requirements, or whether the operation is read-only. Some behavioral context is provided, but important 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?

  Three sentences, each serving a distinct purpose: action, use case, and return/prerequisite. No redundant words, and the description is front-loaded with the core functionality.

  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 simplicity and lack of output schema, the description covers purpose, usage, return type, and a prerequisite. However, it omits details about output structure beyond 'TrackingLink' and does not address potential errors or auth context, leaving some completeness gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage, so the description must compensate. It partially does by mentioning 'programme and destination URL' in the first sentence, giving context to the two parameters. However, it does not elaborate on formats, validation, or how to obtain the programmeId beyond the pairing instruction.

  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 'Generate a tracking link on financeAds for a given programme and destination URL,' which is a specific verb+resource construction. It distinguishes itself from sibling tools by naming the network 'financeAds' and identifying the key inputs.

  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?

  It explicitly says 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined,' giving a concrete trigger condition. It also recommends pairing with list_programmes to confirm the programmeId, which is a clear prerequisite and companion tool reference.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_financeads_list_transactionsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations exist, so the description must carry behavioral disclosure. It adds value by explaining that results are Transaction records with a derived ageDays field and by enumerating commission statuses (earned, pending, reversed, paid), which gives the agent insight into return semantics. However, it omits pagination behavior, auth prerequisites, and other operational traits, leaving some transparency 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?

  Two sentences: first establishes scope, second provides usage triggers and return/pairing info. Front-loaded and efficient with no filler.

  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 description covers common user questions and return context, but the absence of an output schema and 0% parameter-level schema documentation means the agent must guess at pagination and date-filter details. It's adequate for simple queries but not fully complete for edge cases like paging through large result sets or combining age filters.

  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 0% schema coverage, the description compensates partially by tying 'within a window' to from/to, 'specific programme' to programmeId, and statuses to the status parameter. But cursor, offset, limit, minAgeDays, maxAgeDays, and exact status value formatting are not explained, leaving a significant semantic gap for 9 parameters.

  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 opens with a specific verb ('List') and resource ('affiliate transactions') scoped to 'financeAds' with modifiers for window/programme and explicit statuses. This differentiates it from sibling tools like get_earnings_summary and list_clicks, and from similarly named list_transactions tools on other networks.

  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?

  It provides direct query examples ('what did I earn last month?', 'what's still pending?') that signal exactly when to invoke, and explicitly recommends pairing with get_earnings_summary for aggregate totals. This is explicit guidance on usage and a complementary alternative, though it doesn't list exclusions (e.g., when to prefer list_clicks).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_firstpromoter_get_earnings_summaryA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses the return structure ('Returns an EarningsSummary including oldestUnpaidAgeDays') and implies a read-only summarization operation. However, it does not mention pagination (despite limit/cursor parameters), authentication requirements, or error behavior. This is moderate transparency but leaves 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?

  The description is concise at three sentences, with the main purpose front-loaded. Each sentence adds value: purpose, usage context, and return/hint. No redundant filler.

  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 9 parameters and no output schema, the description provides a good high-level summary and usage example, but lacks full parameter semantics (e.g., status allowed values, brand meaning) and does not fully describe the return object beyond one field. It is adequate for basic use but not fully complete for complex queries.

  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 descriptions cover 0% of parameters, so the description must compensate. It adds meaning to some parameters: 'date window' (from/to), 'breakdowns by programme' (programmeId), and 'by transaction status' (status). It also mentions oldestUnpaidAgeDays corresponding to age filter params. However, limit, cursor, brand, and minAgeDays/maxAgeDays are not explained, leaving several parameters underspecified.

  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 tool's function: 'Summarise earnings on FirstPromoter across a date window, with breakdowns by programme and by transaction status.' This specifies the verb (summarise), resource (earnings on FirstPromoter), and scope (date window, breakdowns), and distinguishes it from sibling tools by naming the network and the summary type.

  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 explicitly tells when to use it: 'Use this when the user wants a single-figure answer plus context — e.g. "total earnings in Q1 with status split".' It also suggests a complementary tool: 'pair with list_transactions to drill into the underlying records.' This provides clear context and alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_firstpromoter_get_programme_performanceA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full transparency responsibility. It discloses that this is a read operation ('Fetch') and states the return type ('ProgrammePerformanceRow records'), which is useful. However, it does not mention pagination behavior, date range handling, defaults, or any edge cases, leaving notable behavioral gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three tight sentences: core function, usage examples, and output/pairing info. Every sentence adds value, and the structure front-loads the essential purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 8 parameters, no output schema, and no annotations, the description covers purpose, use cases, and sibling relationships but leaves parameter specifics, pagination, and detailed return shape underspecified. It is adequate for tool selection but not fully sufficient for confident invocation without additional inference.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds indirect hints: 'by date' implies from/to semantics, 'per-publisher' implies publisherId filtering, and 'brand's programme' ties brand to the programme. It also suggests using list_media_partners to discover publisher ids. However, limit/cursor/offset and programmeId are left unexplained, so compensation is incomplete.

  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 ('Fetch') and resource ('per-publisher performance for the brand's programme at FirstPromoter'), listing concrete metrics (clicks, conversions, gross sale, commission) and date scoping. This clearly distinguishes it from sibling tools like list_transactions or get_earnings_summary.

  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 gives explicit user query examples ('how is each publisher performing on FirstPromoter?', 'show me the top-earning partners last month') and frames the core use case as a per-publisher rollup. It also names complementary tools (list_media_partners for publisher ids, list_transactions for transaction-level drill-down), providing clear when-to-use and alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_flexoffers_list_transactionsA
  4.1/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 burden of behavioral disclosure. It states that the tool returns Transaction records including derived ageDays, which gives some transparency about the return format. However, it does not mention pagination behavior, default limits, or whether the operation is strictly read-only beyond the verb 'List'.

  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 with no fluff. The first sentence states purpose, the second gives usage examples and return details. Every clause earns its place, and the key verb 'List' is front-loaded.

  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 tool with 9 parameters, no output schema, and no annotations, the description provides a solid starting point but has gaps. It covers purpose, example usage, and return type, but does not explain pagination mechanics or all filtering options. The cross-reference to get_earnings_summary is helpful, but the description is not fully complete for an agent to invoke it correctly in all scenarios.

  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 has 0% description coverage, forcing the description to explain parameter meaning. It explains the core dimensions: 'within a window' maps to from/to, 'for a specific programme' maps to programmeId, and the status list maps to the status parameter. However, pagination parameters (limit, cursor, offset) and age filters (minAgeDays, maxAgeDays) are not described, leaving several parameters ambiguous.

  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 action ('List affiliate transactions'), specifies the resource ('on FlexOffers'), and enumerates the transaction statuses (commissions earned, pending, reversed, or paid). It differentiates from sibling tools by naming the network and describing its scope (window or specific programme).

  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?

  Explicitly provides example user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') that should trigger this tool. It also directs the agent to pair with get_earnings_summary for aggregate totals, offering clear guidance on when to use this tool versus adjacent tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_growsurf_get_earnings_summaryA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of behavioral disclosure. It does reveal a key output field (oldestUnpaidAgeDays) and the summary nature of the response, but it does not mention pagination, defaults for date ranges, whether the operation is read-only (though 'Summarise' implies it), or any prerequisites like required brand. It adds some value but lacks rich 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 about 50 words across three sentences, with no fluff. It front-loads the core action, then usage guidance, then output and relationship to a sibling tool. Every sentence adds value and is efficiently 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 the tool's complexity (9 parameters, no annotations, no output schema), the description provides a solid overview of purpose, usage, a sample output field, and a drill-down sibling, but it lacks essential details on parameter formats, required fields, defaults, and full output shape. It is adequate for basic selection but incomplete for full invocation without guessing parameter semantics.

  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 0%, so the description must compensate. It does add meaning to some parameters: 'date window' implies from/to, 'breakdowns by programme' implies programmeId, and 'status split' implies status. However, it leaves limit, cursor, maxAgeDays, minAgeDays, and brand (which is required) unexplained. The partial coverage prevents a higher score.

  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 ('Summarise earnings') and resource ('earnings on GrowSurf') with explicit scoping ('across a date window, with breakdowns by programme and by transaction status'). It clearly distinguishes from sibling tools like list_transactions and other providers' get_earnings_summary, and the example ('total earnings in Q1 with status split') reinforces the purpose.

  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 explicitly states when to use the tool: 'Use this when the user wants a single-figure answer plus context'. It also contrasts with a complementary tool ('pair with list_transactions to drill into the underlying records'), providing a clear alternative for when more detail is needed. This is explicit guidance beyond just naming the tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_growsurf_get_programmeA
  4.1/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 does disclose that it returns a single Programme with example fields (commission, status, advertiser URL), implying a read operation. However, it does not mention potential errors, authentication requirements, or rate limits, which are relevant behavioral traits for a network API call.

  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 concise and front-loaded, stating the purpose in the first sentence and providing supplementary usage guidance in the following two. Every sentence contributes meaningful information with zero 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?

  For a low-complexity read tool with no output schema, the description adequately covers what it does, when to use it, and the return shape. The unclear 'brand' parameter is a notable gap, but the overall context is sufficient for a simple get operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description fails to compensate. It mentions 'programme id' but does not explicitly map it to the 'programmeId' parameter, and it completely omits any explanation of the required 'brand' parameter. The parameter names are self-explanatory, but the description adds no semantic value beyond them.

  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 ('Fetch') and clearly identifies the resource ('a single programme on GrowSurf') and the lookup method ('by its network programme id'). It also distinguishes itself from the sibling list_programmes tool by contrasting its single-record focus with discovery use cases.

  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 explicitly states when to use this tool ('when you already know the programme id') and provides an alternative ('pair with list_programmes when you need to discover the id first'). This gives clear usage guidance and directs the agent to the correct sibling tool for the complementary scenario.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_involve-asia_list_transactionsA
  4.1/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 burden. It discloses that the tool returns Transaction records including derived ageDays and implies a read-only operation. However, it omits pagination behavior, default date ranges, and whether from/to are required, leaving some operational ambiguity.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the core purpose, and includes practical examples with minimal verbosity. Every sentence adds value, efficiently covering what the tool does, when to use it, and key return characteristics.

  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 no annotations and no output schema, the description covers main use cases and return highlights but lacks full parameter details and output structure. It mentions Transaction records and ageDays but not fields, pagination, or constraints, making it incomplete for full invocation confidence.

  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 has 9 parameters with zero descriptions. The description partially compensates by referencing 'window' for from/to, 'programme' for programmeId, and status values (pending, reversed). It does not explain pagination parameters (limit, cursor, offset) or minAgeDays/maxAgeDays explicitly, leaving gaps for several schema fields.

  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 tool lists affiliate transactions on Involve Asia, specifying statuses (earned, pending, reversed, paid) and scope (time window or specific programme). It distinguishes from sibling list_transactions tools by naming the platform and from get_earnings_summary by noting aggregation is handled separately.

  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?

  Explicit example user queries are given ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') that directly signal when to use this tool. It also recommends pairing with get_earnings_summary for aggregate totals, providing clear alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_kwanko-advertiser_get_earnings_summaryA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that the tool returns an aggregate 'EarningsSummary' including 'oldestUnpaidAgeDays', adding context beyond the name about response content and aggregation behavior. With no annotations provided, this is valuable, though it doesn't fully describe all behavioral nuances like pagination or date-window inclusivity.

  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 only two sentences, both of which are purposeful: the first states the core function, the second adds usage context and return-field information. There is no filler.

  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 9 parameters, no annotations, and no output schema, the description omits essential details such as pagination (limit/cursor), date format, the meaning of required brand, and the full structure of the EarningsSummary. It only mentions one return field and gives a high-level overview, which is insufficient for a tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% for 9 parameters, and the description only vaguely refers to a 'date window' (from/to), 'status split' (status), and 'programme' breakdown (programmeId). It fails to explain required brand, limit, cursor, maxAgeDays, or minAgeDays, so it does not sufficiently compensate for the schema's lack of descriptions.

  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 it 'Summarise earnings on Kwanko (advertiser) across a date window, with breakdowns by programme and by transaction status.' This provides a specific verb, resource, and scope, and distinguishes it from sibling tools like list_transactions by describing its aggregate nature.

  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?

  It explicitly instructs 'Use this when the user wants a single-figure answer plus context' and provides an example. It also points to list_transactions as the companion tool for drilling into underlying records, which clarifies the relationship and when to choose each.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_kwanko-advertiser_verify_authA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the return format ({ok:true, identity?} or {ok:false, reason}), implies low cost ('minimal authenticated endpoint'), and clarifies this is not a full health check. It could add more about potential side effects or error details, but for an auth check it is reasonably transparent.

  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 concise sentences: the first states the purpose and mechanism, the second gives usage timing and return format. Every sentence earns its place with no filler or 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?

  For a simple verify tool with one parameter and no output schema, the description covers purpose, usage, return shape, and relationship to a diagnostic tool. The only notable gap is the missing explanation of the 'brand' parameter, which prevents a perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The required 'brand' parameter is completely unexplained. With 0% schema description coverage, the description needed to define what 'brand' means (e.g., brand ID, name, or account identifier), but it does not. This forces the agent to infer or guess the parameter's purpose, which is a significant deficiency.

  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 tool verifies Kwanko (advertiser) credentials via a minimal authenticated endpoint, using a specific verb and resource. It distinguishes itself from sibling tools by specifying 'advertiser' and from other networks by naming Kwanko.

  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?

  Explicit usage timing is provided: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also suggests pairing with affiliate_run_diagnostic as an alternative/complement. However, it does not explicitly state when not to use this tool, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_leaddyno_list_media_partnersA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that it returns MediaPartner records with 'normalised status' and scopes to the brand's programme. It lacks explicit side-effect or authentication statements, but the verb 'list' implies a read operation, and the return-format note adds useful behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single two-sentence block with useful examples and pairing advice; while slightly dense, it is front-loaded with the core action and avoids fluff.

  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?

  It covers the tool's purpose, typical use-cases, and return type, but omits any detail about filtering/pagination parameters and the 'normalised status' values, which an agent would need to construct correct calls.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage for 6 parameters, the description only implicitly references the required 'brand' via 'brand's programme'. Limit, cursor, offset, search, and status receive no explanation at all, leaving their semantics to be guessed from property names.

  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 opens with 'List the media partners (publishers) running on the brand's programme at LeadDyno', providing a specific verb, resource, and platform. This distinguishes it from sibling media-partner listing tools for other networks and from LeadDyno's own get_programme_performance.

  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?

  It gives explicit 'when to use' triggers with example queries ('who is promoting us on LeadDyno?') and recommends pairing with get_programme_performance for performance drill-down, which is clear usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_netrefer_list_programmesA
  4.1/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 full burden. It discloses that the tool returns an array of Programme records and that results may include programmes the publisher joined OR that are available to join. However, it does not mention pagination behavior despite having limit/cursor/offset params, nor does it note auth requirements or side effects. This is adequate but not rich.

  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 concise, three sentences long, front-loaded with the action ('List affiliate programmes'), followed by concrete usage examples and related tools. Every sentence earns its place, with no wasted words.

  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 list tool with no output schema and no annotations, the description covers purpose, usage examples, return type, and related tools. It does not explain pagination or parameter formats, but it provides a solid foundation for an agent to select and invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not explain the six parameters (limit, cursor, offset, search, status, categories). The only hint is 'available to join' which may relate to status, but no explicit param meaning is provided. Parameter names are somewhat self-explanatory, but the description adds little value to compensate for the missing schema descriptions.

  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 tool lists affiliate programmes on NetRefer, using a specific verb ('List') and resource ('affiliate programmes the publisher has joined or which are available to join'). It distinguishes from siblings by specifying NetRefer and by naming companion tools (get_programme, list_transactions), making its function unambiguous.

  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 example queries ('which merchants am I working with?', 'what programmes do I have on NetRefer?') and explicitly names related tools for drill-down (get_programme) and activity (list_transactions). This gives clear context for when to use this tool and how it fits with alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_netrefer_list_transactionsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden and partially fulfills it by disclosing that it returns Transaction records including a derived ageDays field. However, it does not mention pagination behavior, default limits, authentication requirements, or that this is a read-only operation, which are relevant for a list 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?

  Three focused sentences: the first states the core action and scope, the second gives concrete usage triggers, and the third mentions return content and complementary tool. No filler or repetition; every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Despite no annotations or output schema, the description covers purpose, when to use, and basic return format. It is incomplete for a 9-parameter tool because it omits pagination parameter semantics and does not disclose default behaviors. The cross-reference to get_earnings_summary adds valuable integrative context, but gaps remain.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 9 parameters with 0% coverage, so the description must compensate. It explains the filter dimensions of 'within a window or for a specific programme' and status categories, which maps to from/to, programmeId, and status. However, it does not explain cursor, limit, offset, minAgeDays, or maxAgeDays, leaving significant gaps.

  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 ('List') and resource ('affiliate transactions on NetRefer'), and enumerates the status types (earned, pending, reversed, or paid). It clearly distinguishes this from siblings like get_earnings_summary by noting it returns Transaction records rather than aggregates.

  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?

  Explicitly states when to use: 'Use this when the user asks...' with concrete example queries. It also provides guidance on the alternative: 'pair with get_earnings_summary for aggregate totals,' effectively saying when not to use this tool alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_offer18_get_earnings_summaryA
  4.1/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 full burden. It discloses that it returns an EarningsSummary including oldestUnpaidAgeDays, which adds some behavioral context, but it does not mention authentication needs, side effects (though it's likely read-only), pagination behavior, or error handling. With such a high burden, more disclosure would be expected.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose, followed by usage guidance and return value information. Every sentence earns its place with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With no output schema, no annotations, and 8 parameters, the description is moderately complete: it explains the primary function, when to use it, and a key return field. However, it omits details about parameter formats, pagination, and the full structure of the EarningsSummary return, which would be valuable given the lack of schema descriptions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It gives meaning to 'date window' (from/to), 'breakdowns by programme' (programmeId), and 'transaction status' (status), covering 3 of 8 parameters. However, it does not explain limit, cursor, maxAgeDays, minAgeDays, or the exact format of values, leaving significant gaps.

  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 what the tool does: 'Summarise earnings on Offer18 across a date window, with breakdowns by programme and by transaction status.' This specifies the verb (summarise), resource (earnings on Offer18), and scope, distinguishing it from list_transactions and other summary tools.

  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?

  Explicitly tells when to use it: 'Use this when the user wants a single-figure answer plus context — e.g. "total earnings in Q1 with status split".' Also provides a complementary alternative: 'pair with list_transactions to drill into the underlying records.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerize-advertiser_get_earnings_summaryA
  4.1/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 of behavioral disclosure. It does disclose the return type ('Returns an EarningsSummary including oldestUnpaidAgeDays') but does not mention whether the operation is read-only, requires specific authentication, or how pagination/limit/cursor behave. This partial disclosure is insufficient for a safe and effective AI invocation.

  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 long and front-loads the core purpose, then provides usage guidance and return information. Every sentence earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 9 parameters, no output schema, and no annotations, the description is not complete enough. It gives a good overview and return type, but does not explain pagination parameters, age filters, or how the brand context is resolved. An agent would need additional information to confidently invoke this tool with all intended filters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It hints at the purpose of date filters ('date window'), programme breakdown ('programme'), and status ('transaction status'), but several parameters (limit, cursor, maxAgeDays, minAgeDays) are not explained at all. The 'brand' required parameter is also not mentioned, leaving the agent to infer its meaning from the name alone.

  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 tool's function: 'Summarise earnings on Partnerize (Advertiser) across a date window, with breakdowns by programme and by transaction status.' This is a specific verb+resource+scope and differentiates from sibling tools like list_transactions and other networks' earnings summaries by explicitly mentioning 'Advertiser' and the summary nature.

  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 guidance: 'Use this when the user wants a single-figure answer plus context' and suggests pairing with list_transactions for drill-down. This tells the agent when to choose this tool versus the alternative, satisfying the 'when/when-not/alternatives' criterion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerize_list_clicksA
  4.1/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 adds useful context by stating it 'Returns Click records' and is 'optionally filtered by programme and date', implying a read-only listing operation. However, it does not disclose whether authentication with Partnerize is required, nor does it mention pagination behavior (cursor/offset/limit), which are visible in the 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 two sentences with no filler. The first sentence states the action and filters; the second provides use cases and a complementary tool. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  With 6 parameters and no output schema, the description gives a clear high-level purpose and use case but omits details about pagination semantics, default behaviors, and the structure of Click records. While not critically underspecified, the agent would need to infer several invocation details from parameter names and context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It clarifies that programme and date filters exist, which maps to programmeId and from/to, but it does not explain the pagination controls (limit, cursor, offset) or the exact meaning of the date range parameters. This is partial but not comprehensive.

  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 opens with 'List recent affiliate clicks on Partnerize', using a specific verb and clearly identifying the resource. It further distinguishes this tool from siblings by focusing on traffic-side debugging and explicitly contrasting with list_transactions for conversions.

  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?

  It states 'Use this for traffic-side debugging' with concrete example questions like 'are my links being clicked at all?' and 'where is traffic going on Partnerize?'. It also instructs to 'pair with list_transactions to compare clicks vs conversions', providing an explicit alternative and usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnero_get_earnings_summaryA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of behavioral disclosure. It reveals return type ('Returns an EarningsSummary including oldestUnpaidAgeDays') and notes the tool is a summary/read operation, plus suggests pairing with list_transactions for underlying records. It does not detail auth requirements or pagination, but the non-destructive nature is clear.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three tightly written sentences pack the purpose, usage context, return detail, and a cross-reference to list_transactions. No fluff or repetition; each sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 9 parameters, no annotations, and no output schema, the description covers the overall purpose and a few key parameters but omits explanations for pagination parameters (cursor, limit) and filtering by age (maxAgeDays, minAgeDays). It is helpful but not fully complete given the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It gives semantic meaning to key parameters: 'date window' maps to from/to, 'by programme' to programmeId, 'by transaction status' to status. However, it leaves other parameters (cursor, limit, maxAgeDays, minAgeDays) unexplained, providing only partial compensation.

  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 tool's function with a specific verb and resource: 'Summarise earnings on Partnero across a date window', adding breakdowns by programme and transaction status. It distinguishes itself from siblings like list_transactions by noting the summary-level granularity and explicitly recommending pairing with list_transactions for drill-down.

  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?

  Provides clear guidance on when to use: 'Use this when the user wants a single-figure answer plus context', with a concrete example. It also names an alternative (list_transactions) for deeper record-level inspection, but does not explicitly state when not to use it or list other alternative tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerstack-advertiser_verify_authA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description discloses key behavioral aspects: it calls a minimal authenticated endpoint and returns a structured result ({ok:true, identity?} or {ok:false, reason}). This clearly communicates the read-only verification nature and expected outcome.

  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 compact (three sentences) and front-loaded with the main action. Every sentence adds essential context: what it does, when to use it, and what it returns. 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?

  For a simple verification tool with one required parameter and no output schema, the description covers purpose, usage timing, return value, and relationship to a diagnostic tool. The only significant omission is the lack of any explanation of the 'brand' parameter, which prevents full standalone usability.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has one required parameter, 'brand', with no description, and schema description coverage is 0%. The description does not mention 'brand' at all, leaving its meaning, format, or relationship to the credentials entirely unexplained.

  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 tool's purpose: to verify configured PartnerStack (advertiser) credentials through a minimal authenticated endpoint. It distinguishes itself from sibling tools (e.g., publisher variant or other network verifications) and from broader diagnostic tools.

  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?

  Explicit guidance is provided for when to use the tool: at session start, after rotating keys, or when another operation returns an auth error. It also names an alternative/complementary tool (affiliate_run_diagnostic) for a full health check, effectively clarifying scoping.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_post-affiliate-pro_get_earnings_summaryA
  4.1/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 returns an EarningsSummary including oldestUnpaidAgeDays, and 'summarise' implies a read-only operation. However, it does not mention pagination (cursor/limit), filter semantics for status/age fields, or any authentication requirements, which are relevant behavioral details given the 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 only two sentences, with the primary purpose front-loaded. It efficiently packs usage guidance, example, return information, and a cross-tool recommendation without unnecessary filler.

  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 tool with 9 parameters, no output schema, and no annotations, the description is incomplete. It omits required 'brand' semantics, date format expectations, pagination behavior, and full return structure. It covers the core use case but leaves significant gaps for an agent to invoke it correctly in edge cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It clarifies the meaning of 'across a date window' (from/to) and mentions breakdowns by programme and status (programmeId/status), but leaves the required 'brand' parameter unexplained and does not cover 'limit', 'cursor', 'maxAgeDays', or 'minAgeDays'. Partial compensation only.

  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 tool's function: summarizing earnings on Post Affiliate Pro over a date window, with breakdowns by programme and transaction status. It explicitly names the specific network, distinguishing it from the many other get_earnings_summary sibling tools.

  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 when-to-use guidance: 'Use this when the user wants a single-figure answer plus context', with a concrete example. It also suggests pairing with list_transactions for deeper drill-down, effectively naming an alternative tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_post-affiliate-pro_list_transactionsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the transparency burden. It discloses that the tool returns Transaction records including a derived ageDays field, which goes beyond a simple list. However, it does not mention authentication requirements, rate limits, or pagination behavior, leaving some gaps for a read-only 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 three sentences, front-loaded with the action and resource, and provides examples and return details without unnecessary words. Every sentence adds value, 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.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 10 parameters and no output schema or annotations, the description is moderately helpful but leaves significant gaps: what 'brand' means, date formats, pagination behavior, and potential error conditions are unstated. It is not as complete as the high-calibration sample for a similarly complex tool, but it does cover core usage and a derived return field.

  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 0% schema description coverage, the description must compensate for parameter meaning. It explains some key parameters indirectly ('within a window' for from/to, 'specific programme' for programmeId, and the status names), but it does not explain the required 'brand' parameter, pagination controls (limit, cursor, offset), or the age-based filters (minAgeDays, maxAgeDays). The partial coverage warrants a mid-range score.

  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 identifies the action ('List affiliate transactions'), the resource (Post Affiliate Pro), and the scope (within a window or for a specific programme). It also lists the transaction statuses (commissions earned, pending, reversed, or paid), which provides distinctiveness from sibling list_transactions tools for other networks.

  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 explicit example user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and recommends pairing with get_earnings_summary for aggregate totals. It lacks explicit when-not-to-use guidance, but the context and examples are clear enough to guide selection among the many network-specific siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_rakuten_list_clicksA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description must disclose behavior itself. It does mention that the tool returns recent clicks, optional filters, and that the output consists of Click records. However, it omits how pagination (cursor, limit, offset) works, what the date parameters mean, or any default time window, so significant behavioral traits remain unstated.

  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 at three sentences, with the core action in the first sentence. The second sentence provides a concrete use case, and the third directs to a related tool, so every sentence earns its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the central purpose, usage context, and relationship to list_transactions, which is helpful. However, because there is no output schema and no annotations, the absence of pagination and parameter details makes it incomplete for a 6-parameter tool with all-optional arguments.

  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 0% schema description coverage, the description needs to compensate. It explains that filtering by 'programme and date' is possible, which maps to programmeId and from/to, but it does not describe limit, cursor, or offset, leaving the pagination parameters unexplained. It doesn't mention date formats or which parameter is the start vs end date.

  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 explicitly states 'List recent affiliate clicks on Rakuten Advertising' with a specific verb (List) and resource (affiliate clicks on Rakuten Advertising). It also hints at optional filtering by programme and date, and the mention of pairing with list_transactions distinguishes it from the transaction-listing sibling.

  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 gives explicit usage context: 'Use this for traffic-side debugging' with concrete example questions. It also suggests 'pair with list_transactions to compare clicks vs conversions,' which indirectly tells when not to use this tool alone. This is clear guidance for an AI agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_rewardful_get_earnings_summaryA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description must carry the burden. It discloses that the tool returns an EarningsSummary including oldestUnpaidAgeDays, which gives some return behavior context. However, it does not explicitly confirm read-only behavior, explain pagination (limit/cursor), or note any permissions or side effects. The verb 'Summarise' implies read-only, but this is not stated.

  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 three sentences, front-loaded with the core function, followed by a usage example and a return/pairing note. Every sentence adds value and there is no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given 9 parameters, no output schema, and no annotations, the description covers purpose, usage, and return type but omits detail on several parameters (brand, pagination via limit/cursor, age-range filters) and does not elaborate on the breakdown structure. It provides a useful overview but is not fully self-sufficient for a complex 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 0%, and the description compensates partially by mapping 'date window' to from/to, 'breakdowns by programme' to programmeId, and 'by transaction status' to status. However, it does not explain brand, limit, cursor, maxAgeDays, or minAgeDays, leaving several parameters ambiguous.

  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 ('Summarise') and resource ('earnings on Rewardful') with clear scope: 'across a date window, with breakdowns by programme and by transaction status.' It distinguishes from sibling tools like list_transactions by emphasizing a single-figure summary, and mentions 'Returns an EarningsSummary' to clarify the output.

  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?

  Explicitly says 'Use this when the user wants a single-figure answer plus context' with a concrete example. It also provides guidance to 'pair with list_transactions to drill into the underlying records,' which clarifies when to use an alternative tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_rewardful_get_programmeA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must disclose behavior. It mentions 'Returns a single Programme' and lists sample fields (commission, status, advertiser URL), which helps. However, it does not discuss error cases, authentication, or the meaning of the required 'brand' parameter, leaving some behavioral gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, front-loaded with the core purpose, followed by usage guidance and return details. Every sentence adds value with no filler.

  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, but the description still provides useful context: when to use, what to expect in the return, and how to discover the id. The main omission is the role of the 'brand' parameter, which is required but unexplained, so it is not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must explain parameters. The 'programmeId' is partially explained as 'network programme id', but the required 'brand' parameter is never mentioned or described. The description fails to compensate for the missing schema 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 clearly states 'Fetch a single programme on Rewardful by its network programme id', using a specific verb and resource. It also distinguishes from list_programmes by mentioning when to use each, making it unambiguous.

  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?

  Explicit usage guidance is provided: 'Use this when you already know the programme id and need its full record' and 'pair with list_programmes when you need to discover the id first'. This gives clear when-to-use and an explicit alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_shareasale_get_earnings_summaryA
  4.1/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 burden. It adds return-type context (EarningsSummary, oldestUnpaidAgeDays) but does not explicitly state that the operation is read-only, any authentication requirements, or potential side effects. The read-only nature is implied by 'summarise' and 'returns', but the description could be more explicit about safety 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?

  Two sentences that are front-loaded with the core purpose, then provide usage guidance and a return-value note. Every sentence earns its place with no unnecessary filler.

  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 8 parameters, no annotations, and no output schema, the description is reasonably complete but not fully. It covers the primary use case and highlights a key return field, but does not explain all parameter combinations, pagination behavior, or edge cases. The suggestion to pair with list_transactions helps, but more detail on the available filters would improve completeness.

  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 0%, so the description must compensate. It mentions date window (to/from), programme breakdown (programmeId), and status breakdown (status), which maps to the main parameters. However, it does not explain limit, cursor, maxAgeDays, minAgeDays, or pagination semantics. The description adds value but leaves several parameters underdocumented.

  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 (summarise earnings), the resource (ShareASale), and the scope (date window with breakdowns by programme and transaction status). It distinguishes this tool from the many sibling get_earnings_summary tools by naming the network and explaining the output characteristics.

  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?

  Explicitly states when to use the tool ('when the user wants a single-figure answer plus context') and provides a concrete example. It also recommends pairing with list_transactions for deeper detail, which is clear guidance on alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_shareasale_list_clicksA
  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. It discloses that the tool returns Click records and is for listing, which implies read-only, but does not mention pagination behavior, date range defaults, authentication requirements, or rate limits. The use-case framing adds some context, but key behavioral details are absent.

  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 three sentences, each earning its place: the core action, the use case with examples, and the pairing suggestion. It is front-loaded and free of fluff.

  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 tool with 6 parameters, no output schema, and no annotations, the description is moderately complete: it covers the main purpose, return type (Click records), and a supporting use case. However, it lacks essential details on pagination (cursor/offset/limit), date formats, and the structure of Click records, which an agent needs for correct 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 0%, so the description must compensate. It explains the 'programme' and 'date' filters, which map to programmeId and to/from, but provides no detail on limit, cursor, offset, date format, or how filtering is applied. This partial coverage is helpful but insufficient for full parameter understanding.

  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 a specific action: 'List recent affiliate clicks on ShareASale' with an optional filter by programme and date. It distinguishes this tool from sibling list_clicks tools by including the network name and from other ShareASale tools (list_programmes, list_transactions) by focusing on clicks.

  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 context: 'Use this for traffic-side debugging' with concrete examples like 'are my links being clicked at all?'. It also names the companion tool, list_transactions, for comparing clicks vs conversions, giving clear guidance on when to combine tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_shareasale_list_transactionsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden, and it does disclose useful behavior: it returns Transaction records including derived ageDays. It implies read-only operation via 'List' and describes scope (window/programme/status), but omits pagination, auth needs, and side-effect details.

  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 with no filler. The first sentence defines the tool's purpose and scope; the second gives usage triggers and a return detail. Every clause 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?

  Given 9 parameters, no annotations, and no output schema, the description provides core purpose and usage but leaves gaps: no pagination behavior, no exact parameter format, no auth or rate-limit context. It is adequate but not fully complete for a tool of this complexity.

  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 0%, so the description must compensate. It hints at 'within a window' (from/to), 'specific programme' (programmeId), and status terms, but does not explicitly map these to parameters. Pagination params (limit, cursor, offset) and min/maxAgeDays are left to inference.

  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 opens with a specific verb and resource: 'List affiliate transactions (commissions earned, pending, reversed, or paid) on ShareASale within a window or for a specific programme.' This clearly states what the tool does and distinguishes it from siblings like list_clicks or get_earnings_summary by specifying ShareASale and transaction statuses.

  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 explicit usage examples: 'Use this when the user asks "what did I earn last month?", "what's still pending?", or "show me reversed sales".' It also mentions pairing with get_earnings_summary for aggregate totals, but does not explicitly state when not to use this tool, so no exclusion is given.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_sovrn-commerce_generate_tracking_linkA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  There are no annotations, so the description carries the burden of disclosing behavior. It mentions 'Returns a TrackingLink' and implies the user must have joined the merchant programme. However, it does not describe authentication requirements, error behavior, or any side effects beyond generating a link. This is partial transparency but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the main purpose, then when to use, then return type and a pairing tip. Every sentence adds distinct value and there is no redundancy or fluff.

  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 simple two-parameter operation, the description covers purpose, usage context, return type, and a prerequisite. However, with no output schema and no annotations, it fails to describe the return structure, potential errors, or authentication assumptions. It is minimally viable but leaves noticeable gaps for an agent to invoke it confidently.

  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 schema provides zero description coverage, but the description compensates by referencing 'given programme and destination URL' and explaining the use case ('share an affiliate link to a specific product or page'). This clarifies that programmeId refers to the Sovrn Commerce programme and destinationUrl is the product/page URL. It doesn't give formats or examples, but it is sufficient for two string parameters.

  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 action: 'Generate a tracking link on Sovrn Commerce for a given programme and destination URL.' It uses specific verbs and resources, and names the network to distinguish it from the many sibling generate_tracking_link tools for other networks.

  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?

  It provides explicit when-to-use guidance: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to confirm the programmeId, which is a useful prerequisite. However, it does not explicitly mention when not to use or name alternative tools, so a 4 is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_sovrn-commerce_get_earnings_summaryA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses the output includes an EarningsSummary with oldestUnpaidAgeDays, adding useful behavioral context. However, it does not mention side effects or auth needs, though summarise implies read-only.

  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?

  Two sentences, front-loaded with purpose; every sentence adds value. The example and pairing note are useful without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an 8-param tool with no output schema and no annotations, this description is incomplete. It explains the core purpose and return field but omits pagination, parameter formats, and full output structure, making it insufficient for confident invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 8 params with 0% description coverage, so the description must compensate. It references date window (to/from), programme (programmeId), and status, but does not explain limit, cursor, maxAgeDays, minAgeDays, or the string/array nature of status. This leaves significant ambiguity.

  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 tool summarises earnings on Sovrn Commerce over a date window with breakdowns by programme and transaction status. It uses a specific verb ('summarise') and resource, and distinguishes from sibling tools by naming the vendor and describing the breakdown dimensions.

  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?

  It explicitly says to use this when the user wants a single-figure answer plus context, with a concrete example. It also advises pairing with list_transactions for drill-down, which clarifies when to use the alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tapfiliate_get_earnings_summaryA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It discloses the return type (EarningsSummary with oldestUnpaidAgeDays) and implies a read-only summarization behavior. However, it does not explicitly state side-effect safety, pagination behavior, or rate limits, leaving some gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, no redundancy, and includes a concrete example and a pairing hint. Every part earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 9 parameters, no output schema, and no annotations. While the purpose and usage are clear, the description lacks parameter details, required fields, date format expectations, and pagination info, making it insufficient for correct invocation without additional research.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It vaguely references date window (from/to), programme breakdown (programmeId), and status breakdown (status), but leaves brand, limit, cursor, maxAgeDays, and minAgeDays unexplained. Many parameters remain opaque.

  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 it summarizes earnings on Tapfiliate across a date window with breakdowns by programme and status. It distinguishes itself from list_transactions by emphasizing a single-figure answer and provides a concrete example query.

  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?

  Explicitly notes when to use the tool: 'when the user wants a single-figure answer plus context.' It also suggests pairing with list_transactions to drill into underlying records, providing clear contextual alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tapfiliate_list_transactionsA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It conveys read-only behavior via 'List', mentions derived ageDays in returns, and describes status filtering. However, it omits pagination behavior, but the schema provides cursor/offset/limit.

  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?

  Three sentences, front-loaded with purpose, then usage guidance and return info. Every sentence earns its place with no fluff.

  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 complex 10-parameter tool with no output schema and no annotations, the description is incomplete. It ignores the required brand parameter, does not explain date window format, or pagination mechanics, and offers minimal return shape beyond 'Transaction records including derived ageDays'.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 10 parameters and 0% schema coverage, the description must explain parameters. It explains 'window' (from/to), 'programme' (programmeId), and statuses, but leaves required brand, pagination (limit, offset, cursor), minAgeDays/maxAgeDays unexplained, and does not map status values to the status field explicitly.

  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 tool's action: 'List affiliate transactions... on Tapfiliate', with specific filters (window, programme, statuses). It distinguishes itself from sibling list_transactions tools by naming Tapfiliate and citing concrete use cases.

  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?

  It explicitly lists when to use the tool ('Use this when the user asks...') and suggests pairing with get_earnings_summary for aggregate totals, providing clear context and an alternative/complement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradetracker_list_clicksA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Without annotations, the description carries the full burden. It does disclose that the tool returns 'Click records' and is for read-side traffic debugging, but it does not explicitly state that it is a read-only operation, nor does it mention pagination behavior, default date range, or authentication requirements. Some behavioral context is added, but significant 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 three sentences, front-loaded with the core purpose, followed by usage guidance and a complementary tool reference. Every sentence adds value, with no redundancy or filler.

  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 description explains the purpose, usage, and return type, making it adequate for a basic list tool. However, given the 6-parameter schema, no annotations, and no output schema, it omits important context such as pagination syntax, default date ranges, and parameter formats, leaving the description only partially 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 coverage is 0%, so the description must compensate. It explains that results can be 'optionally filtered by programme and date,' covering programmeId and from/to, but does not explain limit, cursor, or offset (pagination parameters). This partial compensation justifies a mid-range score.

  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 tool's function: 'List recent affiliate clicks on TradeTracker, optionally filtered by programme and date.' It uses a specific verb (list) and resource (clicks), and distinguishes itself from sibling tools by focusing on traffic-side debugging and mentioning pairing with list_transactions.

  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?

  Explicitly provides when-to-use scenarios: 'Use this for traffic-side debugging — e.g. "are my links being clicked at all?" or "where is traffic going on TradeTracker?".' It also references an alternative/complementary tool (list_transactions) for comparing clicks vs conversions, which guides tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_value-commerce-advertiser_list_transactionsA
  4.1/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of disclosing behavior. It mentions the return type (Transaction records) and a derived field (ageDays), which adds value, but it does not disclose rate limits, pagination behavior, or whether it is strictly read-only (though inferable from 'list'). This is adequate but not rich.

  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 three sentences with the main purpose front-loaded, followed by concrete example questions and a pairing suggestion. Every sentence earns its place, and there is no redundant information.

  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 (10 params, no output schema, no annotations), the description provides a good overview but leaves gaps around default window behavior, pagination, and parameter interactions. It mentions the return type and derived field, which helps, but a fully complete description would cover more edge cases.

  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 0%, so the description must compensate. It explains the meaning of window filtering (from/to), programmeId, and status values, but does not clarify limit, cursor, offset, maxAgeDays, minAgeDays, or brand beyond their inherent names. Some compensation is provided, but it's partial for a 10-parameter tool.

  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 tool lists affiliate transactions with specific statuses (earned, pending, reversed, paid) on ValueCommerce (advertiser), and distinguishes itself from the publisher-side sibling by explicitly naming 'advertiser'. It also mentions the ability to filter by time window or programme, making the scope precise.

  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 example queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') that signal when to use this tool. It also recommends pairing with get_earnings_summary for aggregate totals, giving clear usage context and an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_value-commerce-advertiser_verify_authA
  4.1/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It discloses that the tool calls a minimal authenticated endpoint and returns {ok:true, identity?} or {ok:false, reason}, which is good insight into behavior. It does not mention rate limits or detailed error handling, but for a read-only verification tool this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three well-structured sentences, front-loaded with the core action, and includes only relevant information. No redundancy or extraneous 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?

  The tool is simple with one parameter and no output schema. The description covers purpose, usage timing, return shape, and relationship to the diagnostic tool. The missing brand parameter semantics is the only notable gap, but otherwise the description is complete for a verification tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has one required parameter, 'brand', with no description, and the description does not mention it at all. With schema description coverage at 0%, the agent has no guidance on what value to provide for 'brand', making invocation ambiguous.

  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 tool's purpose: verifying configured ValueCommerce (advertiser) credentials via a minimal authenticated endpoint. It uses a specific verb ('verify') and resource ('credentials'), and distinguishes itself from sibling verify_auth tools by explicitly naming the network and advertiser mode.

  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?

  Explicit usage guidance is provided: use at session start, after key rotation, or when another operation returns an auth error. It also recommends pairing with affiliate_run_diagnostic for a full health check, giving clear context and a complementary alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adcell_get_earnings_summaryA
  4.2/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 adds context by stating that the return includes 'oldestUnpaidAgeDays' and clarifies this is a summarization tool (implying aggregation, not raw listing). It does not disclose pagination or filtering behavior for the optional parameters, but the read-only nature is strongly implied by 'summarise', and the output detail adds value.

  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, front-loaded with the verb and resource, then a usage example and sibling pairing. Every sentence contributes distinct information (purpose, when-to-use, return detail, related tool), with no fluff.

  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 core functionality is well described for a summary tool: it explains the aggregation, the date window, the breakdowns, and a specific return field. However, it lacks details on the optional parameters (age filters, pagination) and the full return structure. Since there is no output schema, the description needs to provide more on the return shape beyond a single field, and it only partially does so.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It partially explains key parameters: 'date window' maps to from/to, 'by programme' maps to programmeId, and 'by transaction status' maps to status. However, it does not explain limit, cursor, maxAgeDays, or minAgeDays, leaving half of the parameters semantically unexplained. The description adds some value but not enough to cover the 8-parameter 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 states a specific verb ('Summarise') and resource ('earnings on Adcell') with clear scope ('across a date window, with breakdowns by programme and by transaction status'). It clearly distinguishes this from sibling tools like list_transactions (which would provide raw records) and get_programme (which provides programme details).

  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 gives an explicit when-to-use directive: 'Use this when the user wants a single-figure answer plus context' with a concrete example. It also suggests pairing with list_transactions to drill into underlying records, indicating an alternative/complementary tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_addrevenue_generate_tracking_linkA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  There are no annotations, so the description carries the full burden. It discloses that a TrackingLink is returned, but does not mention any side effects, authentication requirements, rate limits, or error conditions. For a simple link generator this is adequate but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences: a clear action, a usage context, and a return/prerequisite note. Every sentence adds value with no repetition or wasted words.

  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 tool with only two string parameters and no output schema, the description covers the core aspects: what it does, when to use it, what it returns, and a prerequisite. It does not cover potential errors or parameter formats, but the tool is simple enough that these gaps are minor.

  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 schema has no descriptions, but the description clarifies both parameters: 'programme' for programmeId and 'destination URL' for destinationUrl, and adds the tip to use list_programmes to confirm the programmeId. This compensates for the 0% schema coverage, though it doesn't specify URL format constraints.

  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 'Generate a tracking link on Addrevenue for a given programme and destination URL,' specifying the exact verb, resource, and network. This distinguishes it from other network-specific generate_tracking_link tools and from addrevenue's list/get 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?

  It explicitly says to use this when the user wants to share an affiliate link to a specific product or page. It also advises pairing with list_programmes to confirm the programmeId, providing clear contextual guidance, though it does not mention when not to use it or name alternative tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_addrevenue_get_programmeA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses return value ('Returns a single Programme') and mentions key fields (commission, status, advertiser URL). However, it does not explicitly state read-only nature, error behavior, auth requirements, or rate limits, leaving gaps for a tool without structured safety hints.

  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?

  Two sentences, both purposeful. The first states the core action, the second provides usage context and return information. No fluff or 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?

  For a simple one-parameter fetch tool, the description covers what, when, and what to expect, and even references the companion list tool. It omits any auth prerequisite (e.g., verify_auth) and error handling, but these are not critical for this basic get operation.

  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 0%, so the description must compensate. It clarifies the single parameter as the 'network programme id' and relates it to list_programmes for discovery. This adds meaning beyond the bare 'string' type, but format, example, and uniqueness details are absent.

  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 tool fetches a single programme on Addrevenue by its network programme id. It uses a specific verb ('Fetch') and resource ('single programme on Addrevenue'), and the mention of 'network programme id' distinguishes it from other get_programme tools across networks.

  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?

  Explicit guidance is provided: use this when you already know the programme id, and pair with list_programmes when you need to discover the id first. This directly names the alternative tool and clarifies the exact scenario for each.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adservice_generate_tracking_linkA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the return type ('Returns a TrackingLink') and hints at a precondition (confirm programmeId with list_programmes). However, it does not mention authentication requirements, potential side effects, or error behavior, leaving some ambiguity for a generative action.

  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?

  Three sentences, all essential: purpose, usage, and a practical precondition/return note. Information is front-loaded and no words are wasted.

  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 2-param generation tool with no output schema or annotations, the description covers the core purpose, use case, return type, and a validation step. It lacks explicit auth guidance, but the sibling verify_auth tools in context signal that need. Overall, it is adequately complete for selection and basic invocation.

  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?

  Schema coverage is 0%, so the description compensates by adding meaning: 'given programme' maps to programmeId, and 'specific product or page on a merchant they have joined' clarifies the destinationUrl's purpose. It stops short of describing format constraints, but it significantly clarifies both parameter roles.

  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-resource pair: 'Generate a tracking link on Adservice' for a given programme and destination URL. It clearly distinguishes this from sibling tools by naming the Adservice platform and specifying the input scope.

  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?

  Provides concrete usage context: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to confirm the programmeId, but does not explicitly list when not to use it or alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adtraction-advertiser_get_programme_performanceA
  4.2/5.0
  Behavior4/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 clearly states this is a read-only fetch and discloses the return type ('ProgrammePerformanceRow records') and data granularity (by date). However, it does not mention pagination (limit/cursor/offset), auth requirements, or potential rate limits, leaving some behavioral aspects implicit.

  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?

  Three sentences, each earning its place: purpose, usage triggers, and complementary tools/return type. No fluff, tautology, or unnecessary repetition.

  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 description covers the primary use case nicely and mentions return type, but with no output schema and 0% param coverage, it leaves important operational details undocumented, such as default date ranges, pagination behavior, and the meaning of optional parameters. It is adequate for simple queries but incomplete for advanced usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description doesn't explain the eight parameters. It only hints at date filtering ('by date') and publisher filtering ('per-publisher') but fails to specify formats for 'to'/'from', the meaning of 'brand', or the usage of 'limit', 'cursor', 'offset', 'programmeId', and 'publisherId'. This is a substantial gap given the param count.

  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 opens with a specific verb and resource: 'Fetch per-publisher performance for the brand's programme at Adtraction (advertiser)' and lists concrete metrics (clicks, conversions, gross sale, commission) and date basis. It clearly distinguishes from transaction-level tools by describing it as a per-publisher rollup.

  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?

  Explicitly provides trigger examples ('Use this when the user asks ...') with exact queries like 'show me the top-earning partners last month'. It also points to complementary tools: 'pair with list_media_partners to discover publisher ids and list_transactions for transaction-level drill-down.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adtraction_generate_tracking_linkA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden for behavioral disclosure. It discloses that the tool returns a TrackingLink and implies link creation, but it does not clarify whether this is a state-changing operation, whether authentication is required, or what happens on invalid input. The prerequisite to verify programmeId is useful but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences with no filler. It front-loads the purpose, then adds usage context, return type, and a pairing recommendation. Every sentence contributes meaningful information.

  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 tool with no output schema or annotations, the description covers the essential aspects: what it does, when to use it, what it returns, and a prerequisite. It could include error handling or auth details, but given the tool's simplicity, it is largely complete. The sibling context is addressed by the explicit Adtraction reference.

  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 schema has no descriptions (0% coverage), so the description must compensate. It explains 'programme' and 'destination URL', indicating that programmeId is the merchant and destinationUrl is the product/page URL. It also references 'a specific product or page on a merchant' in the usage sentence, adding meaning beyond the raw 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 clearly states 'Generate a tracking link on Adtraction for a given programme and destination URL', which gives a specific verb, resource, and network. It distinguishes this from sibling generate_tracking_link tools for other networks by explicitly naming Adtraction, and further describes the output as a TrackingLink.

  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?

  It provides explicit usage context: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to confirm the programmeId before calling, which serves as a practical prerequisite. However, it does not explicitly mention when not to use this tool versus other network-specific tools, though the Adtraction branding makes this implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_avantlink_get_programmeA
  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. It does disclose the return type ('Returns a single Programme') and examples of included fields, which helps set expectations. However, it omits other behavioral details like authentication requirements or error behavior if the id is not found. It is not misleading, but not fully transparent.

  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 three sentences, each earning its place: purpose, when to use, and pairing with list_programmes. It is front-loaded with the core action and free of unnecessary detail.

  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 get-by-id tool with one parameter and no output schema, the description covers the essential aspects: what it does, when to use it, and what it returns. It could mention failure modes or authentication, but the tool's simplicity and the explicit return description make it reasonably 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 has 0% description coverage, so the description must compensate. It adds context by calling it 'network programme id' and clarifies that the id is discovered via list_programmes. This is helpful but does not provide format, examples, or other constraints beyond the schema's bare 'programmeId' string.

  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 tool's action with a specific verb ('Fetch'), the resource ('a single programme on AvantLink'), and the key identifier ('network programme id'). It also distinguishes itself from the many sibling get_programme tools by naming AvantLink and summarizing the return contents (commission, status, advertiser URL).

  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 explicitly says when to use this tool ('when you already know the programme id and need its full record') and explicitly names an alternative (list_programmes) for discovering the id first. This is clear, actionable guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin-advertiser_get_programmeA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It discloses a read-only fetch operation and states that it returns a single Programme with key fields (commission, status, advertiser URL), providing essential behavioral context. However, it doesn't mention error handling or edge cases like missing ids.

  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?

  Two concise, front-loaded sentences; each clause adds value: purpose, usage condition, return type, and pairing advice. No filler.

  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 description covers the core use case and return shape but lacks explanation of the brand parameter and any error/not-found behavior. Given no output schema and no annotations, some key information is missing, though the simple read-only nature reduces the burden.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, and while the description clarifies programmeId as the network programme id, it offers no meaning for the required brand parameter, leaving the agent to guess its purpose (likely the Awin brand/account scope).

  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 tool fetches a single programme on Awin (advertiser) by network programme id, using a specific verb and resource. It distinguishes from sibling get_programme tools by specifying the Awin advertiser context and mentions the return type.

  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?

  It explicitly tells the agent to use this when the programme id is already known, and to pair with list_programmes when discovery is needed, providing clear when-to-use and when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin_get_programmeA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It accurately describes a read operation ('Fetch') and the return shape ('Returns a single Programme'), but does not mention auth requirements, error handling, or potential rate limits. This is adequate for a simple fetch but lacks deeper behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each adding value: what it does, when to use it, and what it returns. No redundancy or fluff.

  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 description covers the core aspects: the action, the input, the return shape, and the companion discovery tool. It does not clarify how it differs from the sibling affiliate_awin_get_programme_details, but for a single-parameter fetch tool, it is fairly 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 coverage is 0% and the description adds minimal clarification by referring to 'network programme id,' which maps to the programmeId parameter. It confirms the purpose of the parameter but provides no format, examples, or validation details.

  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 it fetches a single Awin programme by its network programme id, specifying the verb, resource, and scope. It also distinguishes from list_programmes by noting when each is appropriate.

  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?

  Explicit guidance is provided: use when you already know the programme id and need the full record; pair with list_programmes to discover the id first. This clearly explains when to use this tool versus the alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin_list_clicksA
  4.2/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 burden of disclosing behavior. It states that the tool returns Click records, lists recent clicks, and supports optional filters. While it doesn't mention pagination or default time windows, it clearly implies a read-only listing operation and provides useful context beyond the bare name.

  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 three sentences long, front-loaded with the core function, and every sentence contributes value (purpose, use cases, output/pairing). There is no redundancy or filler.

  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 lack of output schema and annotations, the description could be more complete. It explains the tool's purpose and output type but does not describe pagination parameters, default behavior, or the structure of Click records. It is adequate for a simple list tool but leaves notable gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate for parameter meaning. It mentions 'programme and date' filters, which maps to programmeId and from/to, but it completely ignores limit, cursor, and offset pagination parameters. This leaves a significant gap for an agent trying to invoke the tool correctly with cursor-based pagination.

  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 tool lists recent affiliate clicks on Awin, with optional filtering by programme and date. It also provides concrete use cases ('are my links being clicked at all?', 'where is traffic going?') that distinguish it from transaction-focused tools like list_transactions and from other networks' list_clicks tools.

  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?

  Explicitly says 'Use this for traffic-side debugging' and gives example diagnostic questions. It also recommends pairing with list_transactions to compare clicks vs conversions, naming an alternative and establishing when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin_list_commission_sharing_rulesA
  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 burden of behavioral disclosure. It states that the tool returns specific data fields, which implies a read-only operation, but it does not explicitly mention authentication requirements, rate limits, or side effects. The 'raw Awin data' note adds some context, but more transparency would be needed for a full picture.

  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 long and front-loaded with the primary purpose. The second sentence adds scope and return details without repetition or fluff. Every word earns its place, 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.

  Completeness4/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 tool with no output schema, the description covers the action, target account type, usage conditions, and return contents. It is fairly complete, though it could mention prerequisites like authentication or typical response size. Overall, it is sufficient for an agent to select and invoke the tool correctly.

  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 accepts zero parameters, so there is no parameter ambiguity. With schema coverage of 100% (trivially, since there are no properties), the baseline is 4. The description does not need to elaborate on parameters, and it appropriately focuses on the result contents instead.

  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 action ('List') and the resource ('commission-sharing rules'), scoped to 'an Awin service partner publisher account.' It also distinguishes itself by naming a unique resource not shared by any sibling tool, and lists key return fields.

  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 explicit guidance with 'Use this only for publishers using Awin commission sharing workflows,' which clarifies when the tool is appropriate. However, it does not name alternative tools or explicitly state when not to use it beyond this workflow restriction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_belboon_generate_tracking_linkA
  4.2/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 returns a TrackingLink and hints at a prerequisite (confirming programmeId via list_programmes). However, it does not mention whether this is a safe/read-only operation, authentication needs, or potential side effects. This is a moderate gap given the absence of 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 concise and front-loaded: three sentences with no filler. It delivers purpose, usage context, and a return type/prerequisite in an efficient order. Every sentence 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 simplicity (two parameters, no output schema), the description provides adequate context: purpose, usage, and return type. It could be improved by elaborating on the TrackingLink structure or potential errors, but for a two-parameter tool, this is reasonably complete.

  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?

  With 0% schema description coverage, the description must compensate. It does so by naming 'programme and destination URL' and clarifying that these correspond to 'a specific product or page on a merchant.' This adds semantic meaning beyond the bare schema, though it doesn't specify formats (e.g., URL encoding) or validate types.

  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 tool's function: 'Generate a tracking link on Belboon for a given programme and destination URL.' It specifies the network (Belboon), the action (generate tracking link), and the key inputs. This distinguishes it from sibling tools for other networks.

  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?

  Provides a concrete use case: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to confirm the programmeId, offering a useful sequential guideline. Does not explicitly state when not to use it, but the context is clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_cj_list_transactionsA
  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 does reveal that the tool returns Transaction records with a derived ageDays field and supports filtering by status and programme, which adds useful context. However, it omits details about pagination behavior, default date windows, or any potential side effects (though listing is inherently read-only), leaving some behavioral ambiguity.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the main purpose, and includes practical usage examples and return-value information. Every sentence adds value, with 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?

  Given the tool has 9 optional parameters, no output schema, and no annotations, the description does a commendable job covering the primary use cases and key filtering dimensions (window, programme, status). It also hints at derived data (ageDays) and points to a complementary tool for aggregates. However, it leaves out details like pagination mechanics and default behavior when no filters are applied, which would be needed for a perfect score.

  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?

  Schema description coverage is 0%, so the description must compensate. It does explain the meaning of several key parameters: 'within a window' maps to from/to, 'specific programme' maps to programmeId, and the status examples (earned, pending, reversed, paid) map to the status parameter. The mention of derived ageDays also hints at minAgeDays/maxAgeDays. However, it does not clarify date formats, exact status string values, or pagination parameters (limit, cursor, offset), so it is not fully comprehensive.

  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 tool lists CJ Affiliate transactions with specific statuses (commissions earned, pending, reversed, or paid) and a scoping window or programme filter. The verb 'List' and resource 'affiliate transactions' are precise, and the mention of 'CJ Affiliate' distinguishes it from sibling list_transactions tools for other networks.

  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 explicit when-to-use examples ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and suggests pairing with get_earnings_summary for aggregate totals. However, it does not explicitly state when not to use this tool or name alternative tools for different types of queries (e.g., clicks), so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_clickbank_get_earnings_summaryA
  4.2/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 full burden. It discloses the return type (EarningsSummary, oldestUnpaidAgeDays) but does not mention read-only nature, pagination behavior, or parameter defaults/requirements. It adds some useful context but leaves operational details vague.

  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?

  Three concise sentences, each adding value: purpose, usage guidance, and return/pairing info. No redundancies.

  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?

  Despite 8 parameters and no output schema, the description provides sufficient orientation for the main use case, including return shape and relationship to list_transactions. Some parameter details are absent but the essential selection criteria are clear.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It maps 'date window' to from/to, 'programme' to programmeId, and 'status' to status, but leaves limit, cursor, maxAgeDays, minAgeDays unmentioned. Partial coverage of the key parameters.

  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 opens with a clear verb 'Summarise earnings on ClickBank across a date window' and specifies breakdown dimensions (programme, transaction status), distinguishing it from sibling list_transactions and other network tools.

  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?

  Explicitly provides when-to-use guidance ('Use this when the user wants a single-figure answer plus context') and names the alternative (list_transactions) for drilling down.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_clickbank_get_programmeA
  4.2/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 returns a single Programme and lists included fields, but does not mention error behavior, authentication requirements, or data freshness. For a simple read operation, this is minimal but acceptable.

  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, each earning its place: the first states the purpose, the second provides usage guidance and return type. It is front-loaded and free of filler.

  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 low-complexity fetch tool with one parameter and no output schema, the description covers the core workflow, return type, and relationship to list_programmes. It lacks error handling details and authentication notes, but those are less critical for a simple get-by-id operation.

  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 0%, so the description must compensate. It usefully clarifies that programmeId is the network programme id from ClickBank and frames it as an already-known value, but it does not provide format, example, or edge-case guidance. It adds some meaning beyond the raw 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 clearly states the tool fetches a single programme on ClickBank by its network programme id, naming specific fields returned. It distinguishes itself from sibling tools by network and from list_programmes by focusing on a single known id.

  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 explicitly says to use this when the programme id is already known and to pair with list_programmes for id discovery. This provides clear when-to-use and when-not-to-use guidance with a named alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_connexity_list_transactionsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses that the tool returns Transaction records and includes a derived ageDays field, which is behavioral information not inferable from the schema. It also mentions status values and scoping, giving the agent a better sense of the output and query behavior. It does not cover pagination, rate limits, or ordering, but these are less critical for a read-only list 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 three sentences with zero wasted words. It front-loads the core purpose in the first sentence, adds practical usage examples in the second, and finishes with return value and complementary tool information in the third. Every sentence 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 moderate complexity (9 params, no annotations, no output schema), the description provides sufficient context for an agent to select and use it: it explains the domain, gives realistic user prompts, and clarifies the return type including the derived ageDays. The main gap is that several parameters remain undocumented, and no mention is made of pagination or default behavior, which an agent might need for full autonomous 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?

  The schema has 0% description coverage, so the description must compensate. It adds meaning to 'from'/'to' via 'within a window', to 'programmeId' via 'for a specific programme', and to 'status' via the listed statuses (earned, pending, reversed, paid). However, it does not explain limit, cursor, offset, maxAgeDays, or minAgeDays, leaving several parameters undefined. This is a partial but not complete compensation for the lack of schema descriptions.

  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 action ('List'), the resource ('affiliate transactions'), and the platform ('Connexity'), and distinguishes itself from siblings by specifying statuses ('commissions earned, pending, reversed, or paid') and scoping options ('within a window or for a specific programme'). It also mentions how it complements get_earnings_summary, reinforcing differentiation.

  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 explicit example queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') that signal when to use this tool. It also tells the agent to pair it with get_earnings_summary for aggregate totals. However, it does not explicitly mention when not to use it or list alternative tools like list_clicks or list_programmes, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_effiliation_generate_tracking_linkA
  4.2/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 does disclose the return type ('Returns a TrackingLink') and hints at a failure-prevention step (confirming programmeId via list_programmes). However, it does not mention authentication requirements, error conditions, URL format constraints, or potential side effects, leaving notable gaps for an unannotated 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?

  Three sentences, each earning its place: what the tool does, when to use it, and what it returns plus a prerequisite. Front-loaded and free of redundancy or filler.

  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 2-param tool with no output schema and no annotations, the description covers purpose, when-to-use, parameter semantics, and return value. It is reasonably complete, though it omits potential error cases and auth prerequisites that would make it fully self-sufficient.

  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?

  Schema description coverage is 0%, so the description must compensate. It adequately maps the two parameters: 'programme' refers to programmeId (the merchant joined) and 'destination URL' is the specific product or page. The advice to pair with list_programmes adds meaning to programmeId. It lacks format/validation details for either parameter, which prevents a 5.

  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 first sentence states a specific action and resource: 'Generate a tracking link on Effiliation for a given programme and destination URL.' It names the network (Effiliation), so it is clearly distinguished from the many sibling generate_tracking_link tools for other networks. The use-case sentence ('share an affiliate link to a specific product or page') adds further clarity.

  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?

  'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined' gives a clear context for invoking this tool. The pairing advice to 'confirm the programmeId before calling' is a useful prerequisite. However, it does not explicitly name alternatives or state when NOT to use it, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_effiliation_list_transactionsA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of behavioral disclosure. It states the tool lists transactions, returns Transaction records with derived ageDays, and supports status/window/programme filtering. It could mention pagination behavior, but the read-only nature and return characteristics are reasonably transparent.

  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 three sentences, front-loaded with the core action, then concrete use cases, then return/companion info. Every sentence earns its place with no filler or tautology.

  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 9-parameter tool with no output schema and no annotations, the description covers the main filtering dimensions (status, date window, programme) and return expectations (Transaction records, ageDays). It lacks pagination semantics and default behavior, but overall provides enough context for an agent to use it effectively.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds semantic meaning for from/to ('window'), programmeId ('specific programme'), status ('commissions earned, pending, reversed, or paid'), and implies min/maxAgeDays via 'derived ageDays'. However, it does not explain cursor, limit, offset, or date formatting, leaving several parameters under-specified.

  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 opens with 'List affiliate transactions' and clearly identifies the resource (transactions on Effiliation), scope (within a window or for a specific programme), and statuses (earned, pending, reversed, paid). This differentiates it from sibling tools like list_clicks and get_earnings_summary.

  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?

  It provides explicit when-to-use examples ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and directs pairing with get_earnings_summary for aggregate totals. It doesn't explicitly state when not to use it, but the guidance is clear enough for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_ehub_list_transactionsA
  4.2/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 burden of behavioral disclosure. It discloses the output type ('Transaction records including derived ageDays') and return context, but does not mention pagination behavior (cursor/offset/limit), default date ranges, or any rate limits. This is partial transparency but not exhaustive.

  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?

  Two concise sentences: the first states the primary function and filters, the second provides usage examples and pairing advice. Every sentence adds value with no 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 9 optional parameters, no output schema, and no annotations, the description is relatively complete. It defines the core use cases, return type, and relationship to get_earnings_summary. Missing details include pagination mechanics and default behavior, but the essential context for selection and invocation is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It semantically covers 'window' (from/to), 'specific programme' (programmeId), and statuses, and hints at ageDays (minAgeDays/maxAgeDays). However, it does not explain limit, cursor, offset, or the exact status values, leaving several parameters under-explained.

  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 tool lists affiliate transactions on eHUB with statuses (commissions earned, pending, reversed, or paid) and supports filtering by date window or programme. This specific verb+resource+scope distinguishes it from sibling tools like list_clicks or get_programme.

  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?

  Explicitly provides example user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') that map to this tool, and advises pairing with get_earnings_summary for aggregate totals, effectively guiding when to use this vs alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_everflow_generate_tracking_linkA
  4.2/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 does disclose the return type ('Returns a TrackingLink') and a key prerequisite (confirming programmeId), which is valuable. However, it lacks information about authentication requirements, potential errors, or any side effects, leaving some ambiguity.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary action, and includes only essential information: purpose, use case, return type, and a practical pairing instruction. No filler or redundant 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?

  Given the tool's simplicity (2 required parameters, no output schema, no annotations), the description covers the essential aspects: what it does, when to use it, what it returns, and a prerequisite. It could be slightly more complete by describing the format of the returned TrackingLink, but overall it is sufficient for an agent to invoke the tool correctly.

  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?

  Schema description coverage is 0%, so the description must compensate. It does so by referencing both parameters in context: 'for a given programme and destination URL.' This clarifies the purpose of each parameter at a high level, though it does not specify formats (e.g., URL structure or programmeId type) beyond the schema's basic string types.

  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 starts with a specific action: 'Generate a tracking link on Everflow for a given programme and destination URL.' This clearly states the tool's function and distinguishes it from sibling tools by naming the Everflow platform. The additional use case ('when the user wants to share an affiliate link to a specific product or page on a merchant they have joined') reinforces the purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool ('when the user wants to share an affiliate link...') and a concrete prerequisite: 'pair with list_programmes to confirm the programmeId before calling.' It does not explicitly name alternatives or exclusions, but the Everflow-specific naming and contextual guidance make the intended usage clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_financeads_list_clicksA
  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 identifies the action as listing, mentions optional filters, and states that it returns Click records, but it does not clearly disclose read-only semantics, pagination behavior, or any side effects. The phrase 'recent' is vague and not defined.

  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 concise at two sentences, front-loaded with the main action ('List recent affiliate clicks...') and then adds practical context. Every sentence adds value, and there is no redundant 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?

  The tool has 6 parameters, no annotations, and no output schema, so the description must provide essential context. It covers the core purpose, key filters, and how it relates to list_transactions, but it omits details about pagination, date formats, and the full structure of a Click record. Given the tool's simplicity, it's adequate but not exhaustive.

  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 zero description coverage for the 6 parameters, so the description must compensate. It mentions 'filtered by programme and date,' giving meaning to programmeId and from/to, but does not explain limit, cursor, or offset. This partial clarification helps map some params but leaves pagination parameters unexplained.

  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 tool 'List recent affiliate clicks on financeAds' with a specific verb, resource, and scope. It also differentiates from siblings by naming the network (financeAds) and providing example use cases. The mention of pairing with list_transactions further distinguishes its role.

  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?

  It explicitly states 'Use this for traffic-side debugging' and gives concrete questions like 'are my links being clicked at all?' It also points to a related tool ('pair with list_transactions to compare clicks vs conversions'), which provides an alternative/complementary usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_firstpromoter_get_programmeA
  4.2/5.0
  Behavior4/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 the return format ('Returns a single Programme') and the specific fields included (commission, status, advertiser URL), and implies a read-only operation via 'Fetch'. It does not explicitly mention auth requirements or error behavior, but the fetch semantics are clear enough for a simple read 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 two succinct sentences. The first sentence states the core action, and the second adds usage guidance and relationship to list_programmes. There is no redundancy or extraneous information, and the structure is front-loaded with the primary verb and resource.

  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 description covers purpose, usage, and return details, which is good for a simple tool. However, the required 'brand' parameter is not explained, and with no output schema or annotations, the agent lacks complete context for correct invocation. This gap prevents a higher score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for parameter meanings. It clarifies programmeId as 'network programme id', but completely fails to explain the required 'brand' parameter. The agent is left guessing what value to provide for brand, which is a significant gap given both parameters are required.

  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 'Fetch a single programme' with a specific verb and resource, and distinguishes it from sibling tools by specifying 'on FirstPromoter' and 'by its network programme id'. It also explicitly notes it returns a single Programme, further clarifying its role versus list_programmes.

  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 explicitly says 'Use this when you already know the programme id and need its full record' and instructs to 'pair with list_programmes when you need to discover the id first'. This provides clear when-to-use guidance and names the alternative tool directly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_firstpromoter_list_transactionsA
  4.2/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 burden. It adds useful context: returns Transaction records including derived ageDays, and mentions the companion tool for aggregates. It does not explicitly state read-only behavior or pagination, but 'list' strongly implies non-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?

  Three sentences, front-loaded with the core verb and resource. Each sentence earns its place: definition, usage examples, and return/complementary tool info. No fluff.

  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?

  Captures the core use case well, but with 10 parameters, no output schema, and no annotations, the description should explain pagination, the required brand parameter, and the meaning of ageDays filters. The lack of schema parameter descriptions amplifies this gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema has zero descriptions for 10 parameters. The description only hints at window (from/to), programme (programmeId), and status categories, but omits required brand, pagination parameters (limit, offset, cursor), and ageDays filters. This leaves many parameters poorly understood.

  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 action (List), the resource (affiliate transactions on FirstPromoter), and the filtering scope (window or specific programme). It also distinguishes from the sibling get_earnings_summary by noting it returns individual transactions rather than aggregate totals.

  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?

  Provides concrete example user questions ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and explicitly recommends pairing with get_earnings_summary for aggregate totals, which helps the agent decide when to use this tool vs. the alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_flexoffers_generate_tracking_linkA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description must disclose behaviors. It states the output ('Returns a TrackingLink') and suggests verifying the programmeId first, but does not mention auth requirements, error conditions, or whether the operation is non-destructive. Adequate but with 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?

  Two sentences, front-loaded with the action and resource. Every sentence adds value: purpose, use case, return type, and a pairing instruction. No 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?

  For a simple 2-parameter tool with no output schema and no annotations, the description covers purpose, trigger, return type, and prerequisite. It does not explain failure modes or exact formats, but the essential context is present.

  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?

  Schema has zero field descriptions, so the description compensates by naming the two inputs ('programme and destination URL') and explaining programmeId's source via list_programmes. Does not specify URL format, but enough for an agent to invoke correctly.

  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 'Generate a tracking link on FlexOffers for a given programme and destination URL'—a specific verb, resource, and parameters. The network name and action distinguish it from sibling generate_tracking_link tools across other networks.

  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?

  Explicitly says 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined' and instructs to 'pair with list_programmes to confirm the programmeId before calling.' Lacks explicit when-not-to-use alternatives, but the companion instruction is useful.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_flexoffers_get_earnings_summaryA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry the behavioral burden. It discloses that the tool returns an EarningsSummary including oldestUnpaidAgeDays and supports breakdowns, which adds real context. However, it does not explicitly clarify read-only status, pagination behavior, or date format handling, leaving some gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with purpose, then a usage example, and a companion-tool pointer. Every sentence contributes meaning and there is no redundancy or filler.

  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 an 8-parameter tool with no output schema and no annotations, this description provides a solid starting point with usage guidance and a return-shape hint, but it is not fully complete. It lacks parameter format details, full output structure, and explicit edge-case behavior, so an agent would still need to infer several invocation details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It maps the date window to from/to and hints at status and programme breakdowns, but leaves limit, cursor, maxAgeDays, and minAgeDays completely unexplained. Date and status formats are also unspecified, making reliable invocation difficult.

  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 ('Summarise'), names the resource ('earnings on FlexOffers'), and scopes it to a date window with breakdowns by programme and status. It also distinguishes itself from list_transactions by positioning this as the summary-level counterpart.

  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?

  It explicitly states when to use the tool ('when the user wants a single-figure answer plus context') and provides a concrete example. It also directs the agent to pair it with list_transactions for drill-down, effectively identifying the alternative for more granular queries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_growsurf_get_programme_performanceA
  4.2/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 the return type (ProgrammePerformanceRow records), but does not mention authentication requirements, rate limits, pagination behavior, or whether the operation is read-only. The verb 'Fetch' implies a safe read, but without explicit statement, it's only adequate, not thorough.

  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 three sentences with no redundant words. It front-loads the core purpose, then gives usage triggers, then returns/complementary tools. Every sentence adds value and no information is repeated from the schema.

  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 description covers the essential context: what it returns, when to use it, and how to combine it with other tools. The tool has 8 parameters and no output schema, and while the description handles the core intent well, it leaves parameter format details (e.g., date formats, pagination parameters) unspecified. This is a minor gap that prevents a perfect score.

  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 schema description coverage at 0%, the description must compensate. It explicitly references 'brand' (brand's programme) and 'by date' (implying from/to), and publisher IDs via 'per-publisher' and pairing with list_media_partners. However, it does not explain optional parameters like limit, cursor, offset, programmeId, or publisherId, leaving those undefined in both schema and description.

  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 opens with a specific verb 'Fetch per-publisher performance' and names both the resource (programme at GrowSurf) and the metrics (clicks, conversions, gross sale, commission) grouped by date. This clearly distinguishes it from sibling tools like list_transactions, get_earnings_summary, and other networks' get_programme_performance tools.

  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?

  It explicitly provides trigger phrases ('how is each publisher performing on GrowSurf?', 'show me the top-earning partners last month') and specifies when to use it ('wants the per-publisher rollup'). It also names complementary tools (list_media_partners for publisher IDs, list_transactions for drill-down), effectively guiding when not to use this tool alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_impact_generate_tracking_linkA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the full burden. It does disclose the return type ('Returns a TrackingLink') and a prerequisite (confirm programmeId via list_programmes), which is valuable. However, it does not mention authentication needs, failure behavior, or side effects, leaving notable gaps for a tool with no annotation support.

  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?

  Three sentences, each earning its place: the action, the use case, and the return/prerequisite guidance. Front-loaded and free of repetition or filler.

  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 2-parameter tool with no output schema and no annotations, the description covers the essential context: purpose, when to use it, what it returns, and a companion call. It could have mentioned the need for prior auth/verification (sibling verify_auth exists), but overall it is coherent and practical.

  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?

  Schema description coverage is 0%, so the description must compensate. It does: 'programme' maps to programmeId, and 'destination URL' plus 'specific product or page' maps to destinationUrl. This adds meaning beyond the bare schema, though it stops short of providing formats or examples.

  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 opens with a specific verb and resource: 'Generate a tracking link on Impact' and names the key inputs (programme and destination URL). It clearly distinguishes itself from sibling generate_tracking_link tools by explicitly naming Impact and describing the affiliate-sharing use case.

  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?

  Provides clear context: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also gives a companion instruction to pair with list_programmes to confirm the programmeId. It lacks explicit negative guidance about when to use different network tools, so it doesn't earn a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_impact_list_clicksA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the full burden. It discloses that the tool returns Click records and supports filtering by programme/date, but it does not explain pagination behavior (cursor/offset/limit), date format semantics, or what 'recent' means. This is a read-only operation, but the description omits some behavioral details that would help the agent set expectations.

  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 exactly three sentences, each earning its place: function declaration, usage guidance, and return-type plus cross-reference. It front-loads the core purpose and wastes no words.

  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?

  Despite having no output schema, the description states that Click records are returned and gives concrete debugging scenarios. However, it does not explain pagination controls (especially given cursor/offset/limit params) or the structure of Click records, so the agent is left with some uncertainty about how to iterate through results.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It does explain that to/from and programmeId relate to date and programme filters, respectively, but it provides no explanation of limit, cursor, offset, or date formats. The added meaning is partial, leaving pragmatically important pagination semantics to parameter name inference.

  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 tool lists recent affiliate clicks on Impact, with optional programme and date filters. It distinguishes itself from sibling transaction-focused tools by emphasizing traffic-side debugging and explicitly suggesting pairing with list_transactions.

  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 use cases (e.g., 'are my links being clicked at all?') and names the alternative list_transactions for comparison. This gives the agent clear when-to-use guidance and a relevant complementary tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_indoleads_get_programmeA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of explaining behavior. It does state that this is a fetch operation returning a single Programme and lists included fields, implying a read-only action. However, it does not mention authentication prerequisites, error behavior, or id format nuances, which would be valuable for safe invocation.

  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?

  Two sentences, front-loaded with the core action, and no filler. Every sentence contributes either the operation, the usage condition, return highlights, or the relationship to a sibling tool.

  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 single-parameter fetch tool, the description is complete enough: it explains what is returned, the key fields, and how to discover the id when missing. It lacks a note on required authentication, but overall this is more than sufficient for a low-complexity read operation.

  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 single parameter programmeId has 0% schema description coverage, so the description must compensate. It clarifies that the id is the 'network programme id' and that the caller should 'already know' it, adding meaning beyond the bare schema. Still, it omits format examples or how the id relates to other network identifiers.

  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 tool 'Fetch a single programme on Indoleads by its network programme id', combining a specific verb with a specific resource. It distinguishes itself from list_programmes and from other networks' get_programme tools by naming Indoleads and emphasizing the single-record-by-id scope.

  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?

  Provides explicit usage guidance: use when you already know the programme id and need the full record. It also names an alternative: pair with list_programmes to discover the id first, which directly addresses workflow sequencing.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_involve-asia_get_earnings_summaryA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses the return type ('Returns an EarningsSummary including oldestUnpaidAgeDays') and the breakdown dimensions (programme and transaction status), which goes beyond a mere op-name restatement. It does not mention authentication or side effects, but the read-only, summarising nature is clear from the description.

  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 three sentences, front-loads the purpose, and includes a concrete usage example plus a cross-reference to the related transaction-list tool. Every sentence adds value; there is no fluff or repetition of schema field names.

  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 description gives the core purpose, when to use it, and the return type, but the tool has 8 parameters, no schema descriptions, no annotations, and no output schema. Several parameters (limit, cursor, maxAgeDays, minAgeDays) and practical constraints like date formatting or pagination are not addressed, leaving a moderate gap for a tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 8 parameters with 0% description coverage, so the description must compensate. It maps some concepts: date window (from/to), programme breakdown (programmeId), and transaction status (status), but it leaves limit, cursor, maxAgeDays, and minAgeDays completely unexplained. This is insufficient for an agent to use all parameters confidently.

  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 + resource: 'Summarise earnings on Involve Asia across a date window, with breakdowns by programme and by transaction status.' It clearly distinguishes this aggregate tool from sibling transaction-level tools by noting 'single-figure answer plus context' and explicitly pairing with list_transactions for drill-down.

  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 tells the agent exactly when to use this tool: 'Use this when the user wants a single-figure answer plus context.' It also provides an explicit alternative/companion: 'pair with list_transactions to drill into the underlying records,' which clearly separates aggregation from detailed record retrieval.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_involve-asia_list_clicksA
  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. It discloses that the tool returns 'Click records' and describes filtering behavior, but does not mention pagination behavior, default date ranges, or authentication requirements. 'Recent' is vague and could leave the agent uncertain about the exact time window.

  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 compact and well-structured: a clear declarative sentence, a usage guideline, and a return/related-tool clause. No redundant or filler content; every sentence 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 list operation with 6 optional parameters and no output schema, the description provides purpose, usage context, return type, and a related tool. It is adequately complete for a simple list, though it could ideally mention pagination defaults or the structure of Click records. The lack of an output schema raises the bar slightly, but the description still meets most essential needs.

  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 0% with 6 parameters, so the description must compensate. It adds meaning for programmeId and date filtering ('filtered by programme and date'), but does not explain limit, cursor, offset, or their relationships. Parameter names are somewhat self-explanatory, so the description partially compensates but leaves gaps for pagination parameters.

  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 opens with a specific verb and resource: 'List recent affiliate clicks on Involve Asia', and notes optional filters by programme and date. This clearly distinguishes it from transaction tools and other network-specific click tools by naming the network and the data type.

  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?

  It explicitly states when to use this tool: 'Use this for traffic-side debugging' with concrete example questions. It also recommends pairing with list_transactions to compare clicks vs conversions, providing clear alternative/complement context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_kwanko_generate_tracking_linkA
  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 does add useful context: it returns a 'TrackingLink' and implies a creation operation ('Generate'). However, it does not clearly state whether this operation is safe (e.g., non-destructive), what side effects occur (if any), or whether authentication/permissions are required. The lack of safety hints is less critical for a 'generate' tool than for a mutation tool, but the description still leaves gaps for an agent to infer 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 two sentences long, front-loaded with the core action, and each sentence earns its place: the first states what the tool does, the second explains when to use it and what it returns. 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?

  Given the tool's simplicity (2 params, no output schema, no annotations), the description covers the essential aspects: purpose, usage scenario, parameters, return type, and a workflow hint. It does not detail error conditions or the structure of a TrackingLink, but for a link-generation tool, the provided information is likely sufficient for an agent to invoke it correctly. Slightly more detail on the return value (e.g., that it is a URL string) would push it to a 5.

  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?

  Schema description coverage is 0%, so the description must compensate. It does: it explains that the tool works 'for a given programme and destination URL' and explicitly instructs to pair with list_programmes to confirm programmeId. This gives practical semantic meaning to both parameters. It does not provide format or encoding details, but the explanations are sufficient for an agent to understand what to pass.

  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 the specific verb 'Generate' and clearly identifies the resource: 'tracking link on Kwanko'. It explicitly names the two required inputs ('given programme and destination URL') and states the use case ('share an affiliate link to a specific product or page'). This distinguishes it from sibling tools for other networks by including 'on Kwanko' and noting the target use case.

  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 an explicit when-to-use scenario: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also provides a prerequisite/companion action: 'pair with list_programmes to confirm the programmeId before calling.' However, it does not explicitly state when not to use this tool or mention alternatives (e.g., other networks' tracking link tools), so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_leaddyno_get_programmeA
  4.2/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. The term 'Fetch' clearly implies a read-only operation, and the description explicitly states what is returned (a single Programme) and the fields included (commission, status, advertiser URL). It does not mention error behavior or authentication, but for a simple fetch tool this is adequate disclosure.

  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?

  Three concise, front-loaded sentences: purpose, usage context, and return value/alternative. Every sentence adds value with no redundancy or filler. This is an excellent example of economical, well-structured description.

  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 description covers the core purpose, return type, and usage pairing, which is decent for a two-parameter get operation. However, with no output schema and no annotations, it leaves out the meaning of 'brand', potential failure modes (e.g., invalid id), and any prerequisite authentication or network context. It is adequate but not fully complete for an agent needing to invoke the tool correctly in all scenarios.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It explains that programmeId is the 'network programme id', adding meaning for that parameter, but completely omits any explanation for the 'brand' parameter, which is also required. This leaves the agent guessing about the role of brand in the call, a significant gap given both parameters are required.

  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 tool fetches a single programme on LeadDyno by its network programme id, distinguishing it from list_programmes and other network-specific get_programme tools. It also specifies the return type (single Programme) and key fields (commission, status, advertiser URL), making the purpose unmistakable.

  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?

  Explicit usage guidance is provided: 'Use this when you already know the programme id and need its full record.' It also directs users to pair with list_programmes when discovery is needed, clearly naming the alternative. This gives the agent a clear decision rule for when to invoke this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_levanta_get_earnings_summaryA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses that the tool returns an EarningsSummary including oldestUnpaidAgeDays and suggests pairing with list_transactions, which implies a summary-level result. However, it does not mention auth requirements, pagination behavior, or any limitations, leaving some gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the main purpose, then usage guidance, and finally return type and complementary tool. No fluff, every sentence adds valuable context.

  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 no output schema and 8 optional parameters, the description covers enough to understand when and why to invoke the tool, plus what to expect in the response. It lacks detailed parameter semantics and behavioral caveats, but is sufficient for a summary 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 0%, so the description must compensate. It conceptually maps 'date window' to from/to, 'programme' to programmeId, and 'status' to status, but it does not explain limit, cursor, maxAgeDays, or minAgeDays. The core parameters are addressed, but not all, and without parameter names or formats.

  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 identifies the tool as summarizing earnings on Levanta within a date window, with breakdowns by programme and transaction status. The verb 'summarise' and the explicit scope distinguish it from the sibling list_transactions tool.

  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 explicitly says to use this when the user wants 'a single-figure answer plus context' and gives an example query. It also directs the agent to pair with list_transactions for deeper detail, providing clear contextual guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_linkconnector_get_earnings_summaryA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the return type ('EarningsSummary including oldestUnpaidAgeDays') and positions the tool as a summary/read operation. This adds meaningful behavioral context beyond the schema, though it doesn't cover pagination or edge-case 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?

  Three sentences, front-loaded with the core purpose, followed by usage and output details. Every sentence adds value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 8 parameters, no annotations, and no output schema. The description covers purpose, usage, and some return details, but omits parameter semantics for several fields, pagination, and the full output structure. It 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.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It indirectly references 'date window' (to/from), 'programme' (programmeId), and 'transaction status' (status), but leaves limit, cursor, maxAgeDays, and minAgeDays completely unexplained. This is insufficient for 8 undocumented parameters.

  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 tool summarizes LinkConnector earnings over a date range with breakdowns by programme and transaction status. It distinguishes from sibling tools by naming the specific network (LinkConnector) and the summary focus, and it contrasts with list_transactions for drill-down.

  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?

  Explicit guidance is provided: 'Use this when the user wants a single-figure answer plus context' with a concrete example. It also explicitly recommends pairing with list_transactions for deeper detail, making the alternative use case clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerize-advertiser_get_programmeA
  4.2/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 transparency burden. It discloses the return type ('Returns a single Programme') and hints at the content ('commission, status, advertiser URL'). However, it does not explicitly state that this is a read-only operation or address error/edge behaviors, though the verb 'Fetch' strongly implies no mutation.

  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?

  Two efficiently structured sentences: first states purpose, second gives usage context and return value. No filler; 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?

  For a simple get-by-id tool, the description covers purpose, return value, and usage context. However, it omits any explanation of the required 'brand' parameter, and given there are sibling advertiser/publisher variants, it doesn't explicitly state when to choose this advertiser version over the non-advertiser tool. The core behavior is clear, but these gaps prevent a higher score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must explain both required parameters. It clarifies programmeId ('by its network programme id'), but the 'brand' parameter is completely unexplained in both the schema and description. This is a significant gap for a required parameter.

  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 opens with a specific verb ('Fetch'), identifies the exact resource ('a single programme on Partnerize (Advertiser)'), and clarifies the lookup key ('by its network programme id'). It also distinguishes this from list_programmes by noting it returns a single Programme, so the agent knows this is the point lookup tool.

  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?

  It explicitly states when to use this tool ('when you already know the programme id and need its full record') and provides a direct alternative with guidance ('pair with list_programmes when you need to discover the id first'). This meets the standard for explicit when/alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_post-affiliate-pro_get_programme_performanceA
  4.2/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 the return type (ProgrammePerformanceRow) and the core metrics, but it does not mention pagination behavior for cursor/offset parameters, default date ranges, or whether the operation is read-only. The term 'Fetch' implies a read, but mutability and filtering semantics are not explicitly disclosed.

  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 three sentences, front-loaded with the primary purpose, then usage examples, then related tools. Every sentence adds value, no fluff, and the structure makes it easy to scan.

  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 no annotations and no output schema, the description does a solid job of explaining what the tool returns (ProgrammePerformanceRow with key metrics) and how it fits into the broader workflow (pairing with other tools). It lacks some behavioral details like pagination defaults and response shape, but for a simple fetch tool, the core context is sufficiently covered.

  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 0%, so the description must compensate. It explains the role of brand ('brand's programme'), date range (implied by 'by date'), and per-publisher grouping (implied by 'per-publisher' and 'publisher ids'). However, it omits meaning for limit, cursor, offset, and programmeId, leaving those parameters unexplained. The most important parameters are covered, but not all.

  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 opens with a specific verb-resource combination ('Fetch per-publisher performance') and clearly distinguishes this from sibling tools like get_programme and list_transactions by focusing on per-publisher rollup. It lists concrete metrics (clicks, conversions, gross sale, commission) and grounds the purpose with example user questions.

  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?

  Explicitly tells when to use the tool with natural language query examples ('how is each publisher performing...', 'show me the top-earning partners last month'). It also names companion tools (list_media_partners, list_transactions) and explains how they complement this one, providing clear guidance on alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_profitshare_generate_tracking_linkA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses that a TrackingLink is returned and implies a prerequisite (merchant joined, valid programmeId). However, with no annotations present, it carries the full burden of behavioral disclosure. It does not mention auth requirements, error conditions, or potential side effects, leaving notable gaps for a mutation-like 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 three concise sentences, each earning its place: action and inputs, usage context, and return type plus pairing recommendation. It is front-loaded and contains no redundant exposition.

  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 tool without output schema or annotations, the description covers purpose, when to use, return type, and a prerequisite. It does not specify the structure of the returned TrackingLink or error behavior, but the essential information for calling is present.

  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 description names both parameters ('programme' and 'destination URL') and explains that programmeId should be confirmed via list_programmes, adding meaning over the bare schema with 0% coverage. It does not provide detailed format constraints (e.g., URL scheme), but for two simple string parameters it adequately clarifies their roles.

  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 tool generates a tracking link on Profitshare for a given programme and destination URL. It uses a specific verb ('Generate') and identifies the resource ('tracking link on Profitshare'), which distinguishes it from sibling tools for other networks.

  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?

  Explicit usage context is provided: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also recommends pairing with list_programmes to confirm the programmeId, offering a concrete prerequisite. It does not explicitly mention when not to use it, but the network-specific naming makes alternatives implicit.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_profitshare_get_earnings_summaryA
  4.2/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 burden. It discloses the return type (`EarningsSummary` including `oldestUnpaidAgeDays`) and indicates this is a summary-level operation by pairing with `list_transactions` for details. It does not explicitly mention read-only behavior or potential pagination nuances, but the provided context is genuinely helpful.

  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 three sentences, front-loaded with purpose, followed by usage guidance and return information. Every sentence adds value with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an 8-parameter tool with no output schema and no annotations, the description provides a clear purpose, usage context, and partial return/relationship info. However, it omits details on pagination (`limit`, `cursor`) and age filters (`maxAgeDays`, `minAgeDays`), and the return summary is only partially described. It is adequate but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage, so the description must compensate. It gives context for `from`/`to` via 'date window', and for `programmeId`/`status` via 'breakdowns by programme and by transaction status'. However, it does not explain `limit`, `cursor`, `maxAgeDays`, or `minAgeDays`, leaving several parameters semantically unexplained.

  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 tool's function with a specific verb ('Summarise earnings') and resource ('Profitshare'), and specifies breakdowns by programme and transaction status. It distinguishes itself from sibling `list_transactions` tools by emphasizing summarization rather than raw transaction data.

  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?

  Explicitly states when to use the tool: 'when the user wants a single-figure answer plus context', and provides a concrete example. It also suggests pairing with `list_transactions` to drill into underlying records, giving an alternative/complement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_profitshare_list_clicksA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry the transparency burden. It states returns 'Click records' and mentions filtering, but is silent on pagination, ordering, default date ranges, or rate limits—important behaviors for a list tool with cursor/offset/limit parameters.

  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?

  Three compact sentences with all content earning its place: purpose, example use case, and a practical companion suggestion. No fluff, well 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 moderately complex tool (6 params, no annotations, no output schema), the description provides sufficient context for selection and basic invocation: it names the return type, optional filters, and a related tool. However, it leaves ambiguity around the meaning of 'recent' and doesn't mention pagination behavior, which could be clearer.

  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 0%, so the description must compensate. It explains that results can be filtered by 'programme and date', which maps to programmeId and from/to, but leaves limit, cursor, and offset unexplained. Partial compensation only.

  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 opens with a specific verb ('List') and resource ('recent affiliate clicks on Profitshare'), immediately distinguishing it from sibling click-list tools by naming the network. It also notes optional filtering by programme and date, clarifying scope beyond the tool's name.

  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?

  Explicitly states when to use the tool ('traffic-side debugging') with concrete example questions, and recommends pairing with list_transactions for click-to-conversion comparison. This gives clear selection guidance relative to sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_rakuten_generate_tracking_linkA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry the full disclosure burden. It does add value by stating that it returns a TrackingLink and implying the prerequisite of a joined merchant programme. However, it does not mention potential failure modes, authentication requirements, or whether any state changes occur, leaving gaps for a tool with zero annotation support.

  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 three focused sentences: purpose, when to use, and return value with a pairing tip. Each sentence earns its place, and the most important information is front-loaded in the first sentence. No redundancy or filler.

  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 two-parameter link-generation tool with no output schema, the description covers the essential aspects: what it does, when to use it, what it returns, and a practical prerequisite for the key parameter. It does not address error handling or authentication, but given the simple nature of the tool, it is reasonably complete.

  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 schema has no descriptions (0% coverage), so the description must compensate. It clarifies that programmeId is the identifier from a joined programme and recommends confirming it via list_programmes, and it explains destinationUrl as the specific product or page URL. This adds meaning beyond the raw parameter names and types.

  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 opens with 'Generate a tracking link on Rakuten Advertising for a given programme and destination URL,' which clearly specifies the verb, resource, and network. It also differentiates from sibling generate_tracking_link tools for other networks by naming Rakuten Advertising explicitly. The use case ('share an affiliate link to a specific product or page on a merchant they have joined') further clarifies purpose.

  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 when-to-use: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to confirm the programmeId, which is a useful procedural prerequisite. However, it does not explicitly mention when not to use this tool or name an alternative for other networks, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_rakuten_get_earnings_summaryA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the return type (EarningsSummary) and a notable field (oldestUnpaidAgeDays), and implies a read-only summarisation operation. However, it does not explicitly mention authentication needs, side effects, or default behaviour when no date range is given.

  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 three sentences, each adding distinct value: purpose, usage guidance, and return hint. It is front-loaded with the core action and contains no redundant wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the tool's purpose, usage, and return type, which is helpful. However, the tool has 8 parameters, no output schema, and no annotations, so the description leaves gaps around pagination, age filters (min/maxAgeDays), and default behaviour when no filters are provided. It is adequate but not complete for a tool of this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 8 undocumented parameters (0% coverage). The description hints at a date window (from/to), programme (programmeId), and status, but leaves limit, cursor, minAgeDays, and maxAgeDays unexplained. It does not name any parameters explicitly, so the agent must infer mapping from natural language, which is insufficient for such a large parameter set.

  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 tool summarises earnings on Rakuten Advertising with breakdowns by programme and transaction status. It uses a specific verb ('summarise') and distinguishes itself from sibling tools like list_transactions by describing the higher-level nature of the output.

  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?

  It explicitly says when to use this tool ('when the user wants a single-figure answer plus context') and provides an example. It also directs users to pair with list_transactions for deeper detail, effectively framing the choice against the alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_refersion_verify_authA
  4.2/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 burden of behavioral disclosure. It discloses the return format ('Returns {ok:true, identity?} or {ok:false, reason}') and describes the call as 'minimal authenticated endpoint,' implying a lightweight, non-mutating request. It doesn't explicitly state the absence of side effects or rate-limit behavior, but for a simple auth verification the disclosure is strong.

  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 three sentences, front-loaded with the main purpose, followed by usage guidance and return contract. Every sentence contributes value with no redundant content. Ideal structure for a simple verification tool.

  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 (1 param, no output schema) and the description covers purpose, when-to-use, and return value. However, it omits any explanation of the 'brand' parameter, which is essential for correct invocation. This gap prevents the description from being fully complete, though the rest of the context is sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has a single required parameter 'brand' with zero description coverage, and the description never mentions this parameter. With 0% schema coverage, the description must compensate but fails to explain what 'brand' refers to (likely a Refersion brand/account). The agent is left to guess the parameter's purpose, making this a clear gap.

  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 a specific verb+resource: 'Verify the configured credentials for Refersion are valid by calling a minimal authenticated endpoint.' It explicitly names Refersion, distinguishing it from sibling verify_auth tools for other networks. The purpose is unambiguous and actionable.

  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 when-to-use guidance: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also points to an alternative/complement: 'pair with affiliate_run_diagnostic for a full health check.' This fully covers usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_shareasale_generate_tracking_linkA
  4.2/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 the return type ('Returns a TrackingLink') and warns to confirm programmeId, but it does not mention authentication requirements, potential errors, or whether any server-side state changes occur. For a simple link generator, this is adequate but not rich.

  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 three sentences, front-loaded with the primary action, and every sentence adds value: action+resource, usage context, return type+workflow tip. No redundant or vague wording.

  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 tool with two parameters, no output schema, and low complexity, the description covers the core purpose, usage scenario, return type, and a prerequisite. It omits authentication needs and error behavior, but these are not critical for this action. Overall, it is sufficiently complete for an agent to select and invoke the tool correctly.

  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?

  Schema description coverage is 0%, so the description must compensate. It explains programmeId as the merchant programme and destinationUrl as a specific product/page URL. The hint to use list_programmes helps clarify how to obtain programmeId. However, it does not specify formats or constraints, leaving some ambiguity.

  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 action: 'Generate a tracking link on ShareASale for a given programme and destination URL.' It identifies the specific network (ShareASale), the verb (generate), and the resource (tracking link). This distinguishes it from sibling tools that generate tracking links for other networks.

  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?

  Explicitly states when to use: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also provides a workflow hint: 'pair with list_programmes to confirm the programmeId before calling.' It lacks an explicit 'instead' alternative, but the context is clear given the sibling set.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_shopmy_list_transactionsA
  4.2/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. It discloses return content (Transaction records with derived ageDays) and filter capabilities (window, programme, status). While it doesn't explicitly state auth requirements or confirm no side effects, the verb 'List' implies a non-mutating read operation, and the added detail about ageDays provides useful behavioral context beyond a simple listing.

  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 three sentences with the action and key scope front-loaded. Every sentence contributes: what it lists, when to use it, and what it returns alongside a complementary tool. No fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 9 parameters, no output schema, and no annotations. The description covers main intent, statuses, and return type but omits details on pagination, date formats, and the full structure of Transaction records. It's adequate for basic use but incomplete for complex queries involving cursor, offset, or age-based filtering.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It mentions window (from/to), programme (programmeId), and statuses, but ignores pagination parameters (limit, cursor, offset) and maxAgeDays/minAgeDays. With 9 parameters, only about half are semantically described, leaving significant gaps for an agent to infer correct usage.

  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 ('List') and resource ('affiliate transactions on ShopMy'), and specifies the scope (time window or specific programme) and statuses (earned, pending, reversed, paid). It clearly distinguishes from siblings like get_earnings_summary and network-specific list_transactions tools.

  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?

  It explicitly states when to use the tool with example user queries ('what did I earn last month?', 'what's still pending?') and recommends pairing with get_earnings_summary for aggregate totals. This provides clear usage context and an alternative, fully meeting the 'when to use vs alternatives' requirement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradedoubler-advertiser_get_programmeA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of revealing behavioral traits. It discloses the return type ('Returns a single Programme'), the key data fields ('commission, status, advertiser URL'), and the prerequisite condition (knowing the id), which collectively imply a non-mutating, read-only operation. It does not detail error cases or auth requirements, but for a simple fetch this is reasonably transparent.

  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 long, front-loaded with the verb and resource, and contains no redundant information. Every clause adds value, including the alternative guidance and the return summary.

  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 description covers the primary purpose, return contents, and usage context, but leaves the 'brand' parameter undefined, which is necessary for invocation. There is no output schema or annotations, so the description must be self-contained; the brand omission creates a notable completeness gap. Overall, it is serviceable but not fully complete for smooth agent execution.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must compensate. It explains 'programmeId' as 'network programme id', but the required 'brand' parameter is never mentioned or defined. An agent would struggle to know what value to supply for 'brand', making this a significant semantic gap. The description only partially clarifies one of the two parameters.

  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 action ('Fetch'), the resource ('a single programme on Tradedoubler (Advertiser)'), and the exact lookup key ('by its network programme id'). It also distinguishes itself from the generic Tradedoubler get_programme by specifying the Advertiser variant, and from list_programmes by noting it retrieves a single record.

  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 explicitly tells when to use this tool: 'Use this when you already know the programme id and need its full record.' It also provides a direct alternative for when the id is unknown: 'pair with list_programmes when you need to discover the id first.' This clearly guides selection among sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_travelpayouts_list_transactionsA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses that the tool returns Transaction records including derived ageDays, which is useful. However, it does not explicitly state that the operation is read-only, nor does it mention pagination behavior, default date windows, or authentication requirements.

  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 three sentences long, front-loaded with the core purpose, and every sentence adds value: purpose, use cases, and return/pairing info. No wordiness or repetition.

  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 has 9 parameters and no output schema, the description covers the main user intents, return shape, and pairing guidance well. It falls short only on pagination details (limit/cursor/offset) and explicit edge cases, which keeps it from being 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 0%, so the description must compensate. It gives semantic meaning to window (from/to or ageDays), programme (programmeId), and status (earned/pending/reversed/paid), but leaves limit, cursor, offset, and the exact format of min/maxAgeDays unexplained.

  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 action ('List affiliate transactions'), the target resource (Travelpayouts), and the scope (statuses, window/programme). It distinguishes from sibling tools by naming the network and explicitly pairing with get_earnings_summary for aggregate totals.

  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 concrete user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') to signal when the tool is appropriate. It also tells the agent to pair with get_earnings_summary for aggregate totals, implicitly drawing a boundary against the summary tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tune_generate_tracking_linkA
  4.2/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It discloses the return type (TrackingLink) and hints at a prerequisite (confirm programmeId). However, it doesn't state whether authentication is required, whether the operation has side effects, or how errors are surfaced, leaving gaps for a tool with zero annotation safety signals.

  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?

  Three compact sentences with no filler; the first sentence states the action, the second gives the use case, and the third provides a cross-tool tip. Every sentence 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 straightforward two-parameter tool, the description covers purpose, when to use, return type, and a prerequisite call. It omits authentication and error behavior, which matters given there are no annotations or output schema, but it remains usable.

  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?

  Schema descriptions are completely absent (0% coverage), so the description compensates by mapping 'programme' to programmeId and 'destination URL' to destinationUrl, and adds the practical advice to confirm the ID via list_programmes. It doesn't detail formats or constraints, but for a two-string parameter tool, this is sufficient.

  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 opens with a clear verb and object ('Generate a tracking link on TUNE') and precisely scopes it to a given programme and destination URL. The explicit 'on TUNE' differentiates it from the many sibling network-specific generate_tracking_link 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?

  It gives an explicit use case ('when the user wants to share an affiliate link to a specific product or page on a merchant they have joined') and recommends pairing with list_programmes to confirm the programmeId. It doesn't explicitly exclude other networks, but the TUNE scoping and sibling names make the context clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_value-commerce-advertiser_get_programmeA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It discloses the operation type via 'Fetch' (implying read-only), states the return type ('Returns a single Programme'), and mentions expected fields (commission, status, advertiser URL). It does not explicitly note side effects, but the verb and context make them negligible.

  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 long, front-loaded with the action, and every sentence contributes value: purpose and usage guidance. 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.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the primary fetch behavior, return type, and usage context, which is good for a simple tool. However, it lacks explanation for the required brand parameter, and does not differentiate between the advertiser and non-advertiser variants beyond a parenthetical hint. Given no annotations or output schema, these omissions reduce completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must explain parameters. It describes programmeId as the network programme id, but the required brand parameter is entirely unexplained. This leaves half the required inputs without semantic guidance, creating a clear gap.

  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 tool fetches a single programme on ValueCommerce (advertiser) by network programme id, specifying the verb, resource, and scope. It also distinguishes from the non-advertiser variant by explicitly calling out '(advertiser)' and from list_programmes by mentioning id discovery.

  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 explicitly says 'Use this when you already know the programme id and need its full record' and advises pairing with list_programmes when needing to discover the id first. This names the alternative and provides clear conditions for use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_value-commerce-advertiser_list_clicksA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided, so description carries the burden. It discloses return type ('Returns Click records'), the 'recent' temporal scope, and optional filtering by programme/date. It doesn't mention pagination or auth, but for a straightforward read-only list, this is solid 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?

  Three sentences, front-loaded with the main function, followed by use cases and a cross-reference. Every sentence adds distinct value with no filler.

  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 description covers purpose, use cases, and companion tool, but with 7 parameters and no output schema, it misses parameter semantics (especially brand) and doesn't describe Click record fields or pagination behavior. Adequate for a basic list tool but with clear gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so description must compensate. It only vaguely references 'programme and date' filters, not their parameter names. It omits the required 'brand' parameter and the pagination params (limit, cursor, offset), leaving significant gaps.

  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 clear action: 'List recent affiliate clicks on ValueCommerce (advertiser)', with explicit filters ('optionally filtered by programme and date'). It distinguishes from siblings by specifying 'advertiser' and by directing to 'list_transactions' for conversion comparison.

  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?

  Provides explicit use cases: 'traffic-side debugging' with examples like 'are my links being clicked at all?' and 'where is traffic going...'. It also names a complementary tool: 'pair with list_transactions', giving clear guidance on when to use this tool versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_value-commerce-advertiser_list_media_partnersA
  4.2/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. It discloses the return type (MediaPartner records), notes that status is 'normalised', and implies read-only behavior. It stops short of discussing pagination, auth requirements, or potential side effects, but for a listing tool this is solid added context beyond the 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 three sentences, front-loaded with the core action and resource, and each sentence earns its place by providing purpose, usage criteria, and a hint at the return shape. No wasted words.

  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 description covers purpose, usage triggers, and output type, which is good for a listing tool. However, it lacks any parameter documentation or pagination details, and there is no output schema or annotations to fill the gaps. It is adequate but not fully complete for the 6-parameter signature.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description does not explain any of the six parameters (brand, limit, cursor, offset, search, status). While parameter names are somewhat self-explanatory, the description fails to add meaning about filtering behavior, status values, or pagination semantics, leaving the agent to guess.

  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 action ('List the media partners (publishers) running on the brand's programme') and specifies the resource (ValueCommerce advertiser). It distinguishes itself from sibling tools by focusing on media partners and explicitly naming a complementary tool (get_programme_performance).

  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?

  Provides explicit when-to-use guidance with example user queries ('who is promoting us...', 'which publishers are active...') and recommends pairing with a related tool for per-publisher performance, effectively directing the agent on when to choose this tool over alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_webgains-advertiser_get_programme_performanceA
  4.2/5.0
  Behavior4/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. The verb 'Fetch' implies a read-only operation, and the description adds context about the return type (ProgrammePerformanceRow records) and how it pairs with other tools. However, it does not explicitly state whether authorization is required or mention any potential side effects, though for a read operation this is less critical.

  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 concise and well-structured: first sentence states the core function, second sentence provides use-case examples, and third sentence explains complementary tools and return type. No unnecessary words; every sentence adds value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with 8 parameters, no output schema, and no parameter descriptions, the description should be more exhaustive. It does state the return type and use cases, which is helpful, but the lack of parameter semantics and the absence of any details about pagination, filters, or date ranges make it only partially complete for the agent to invoke correctly in all scenarios.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate, but it only mentions 'by date' and does not explain the roles of specific parameters like publisherId, programmeId, limit, cursor, or offset. The description gives no guidance on how to format dates or which parameters are needed for common use cases, leaving the agent to infer param meanings from names alone.

  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 verb 'Fetch' and the specific resource: per-publisher performance for the brand's programme at Webgains (advertiser), including the exact metrics (clicks, conversions, gross sale, commission). It distinguishes this from sibling tools like list_media_partners and list_transactions, which have different scopes (discovering publisher IDs and transaction-level drill-down).

  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 explicitly says 'Use this when' and gives concrete example user queries ('how is each publisher performing on Webgains (advertiser)?', 'show me the top-earning partners last month'). It also names complementary tools (list_media_partners, list_transactions) and explains how they relate, providing clear guidance on when to use this tool vs alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_webgains-advertiser_verify_authA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the return contract ({ok:true, identity?} or {ok:false, reason}) and the fact that it calls a minimal endpoint. It falls short of detailing side effects, rate limits, or error conditions beyond the return shape.

  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?

  Three sentences, front-loaded with the purpose, followed by usage guidance and return format. Every sentence earns its place with no redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple verification tool with one parameter and no output schema, the description covers purpose, usage, and return values. However, the unexplained 'brand' parameter is a notable gap, and the absence of any description of parameter semantics leaves the tool incomplete for an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The 'brand' parameter is required but has zero schema documentation. The description never mentions 'brand' or explains how it identifies the credential set, failing to compensate for the schema gap. The meaning is only indirectly inferable from the tool name.

  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 tool verifies Webgains (advertiser) credentials via a minimal authenticated endpoint. The verb 'Verify' and specific resource differentiate it from sibling tools, including the Webgains publisher verify tool.

  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?

  It explicitly says when to use the tool: at start of session, after rotating keys, or on auth errors. It also suggests pairing with affiliate_run_diagnostic for a full health check, providing a clear alternative for that use case.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_webgains_get_programmeA
  4.2/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 full responsibility. It discloses that the tool returns a single Programme with specific fields, which is useful. However, it does not mention authentication requirements, error behavior (e.g., invalid id), rate limits, or explicitly state the operation is read-only, though 'Fetch' implies retrieval. This is enough for a simple read but leaves 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?

  The description is just two sentences, front-loaded with the purpose and then the usage guidance. Every sentence adds value: the first defines the operation and output, the second gives when-to-use and the alternative. No redundancy or filler.

  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 single-parameter fetch tool with no output schema, the description covers purpose, parameter semantics, expected return contents, and how to obtain the id. It lacks details on error cases or authentication, but given the straightforward nature and the clarity of the description, it is sufficiently complete for an agent to invoke correctly.

  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 only the parameter name 'programmeId' with type string and no description, so schema coverage is 0%. The description compensates by explaining that it is a 'network programme id' and references pairing with list_programmes to discover the id, which clarifies its source. However, it does not specify format, constraints, or examples, so the compensation is partial.

  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 opens with 'Fetch a single programme on Webgains by its network programme id,' which gives a specific verb, resource, and identifier basis. It also distinguishes itself from list_programmes by contrasting 'single programme' with discovering the id first, and names the output type ('Returns a single Programme').

  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?

  Explicitly states the ideal usage context: 'Use this when you already know the programme id and need its full record (commission, status, advertiser URL).' It also names the alternative, list_programmes, for when the id is not yet known, which is clear guidance on when not 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.

• affiliate_yieldkit_list_clicksA
  4.2/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 returns Click records and supports filtering by programme/date, but omits details on pagination behavior (cursor/offset), default date ranges, or authentication requirements. It correctly implies a read-only listing operation, but more behavioral context would improve 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 two sentences with no wasted words. The first sentence states the action and filters, and the second provides use-case context and a sibling relationship. It is front-loaded and every sentence 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 6 optional parameters, no output schema, and no annotations, the description covers purpose, use cases, return type, and relationship to list_transactions. However, it omits pagination mechanics and exact parameter formats, which are important for a listing tool with cursor/offset. It is fairly complete but not fully self-sufficient.

  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 0% schema description coverage, the description must compensate for the 6 undocumented parameters. It clarifies that 'from'/'to' are date filters and 'programmeId' filters by programme, but it does not explain 'limit', 'cursor', or 'offset' (likely pagination controls). This is partial compensation — helpful for the main filters but incomplete for the remaining parameters.

  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 tool lists recent affiliate clicks on Yieldkit, optionally filtered by programme and date. It explicitly distinguishes itself from list_transactions by framing it for traffic-side debugging, which separates it from the sibling transaction tool.

  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?

  It provides explicit usage guidance with concrete example questions ('are my links being clicked at all?' and 'where is traffic going on Yieldkit?') and recommends pairing with list_transactions to compare clicks vs conversions. While it doesn't explicitly list when not to use it, the examples and pairing instruction give strong contextual guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_admitad-advertiser_list_transactionsA
  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 transparency burden. It discloses the return type ('Transaction records including derived ageDays'), which is meaningful beyond the schema. It implies read-only behavior through 'List', though it does not explicitly state auth requirements or pagination 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 three sentences, front-loaded with the core purpose, and every clause earns its place. It packs statuses, filtering options, example queries, return value hints, and a pairing suggestion without unnecessary verbosity.

  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—10 parameters, no annotations, and no output schema—the description is strong on usage intent and return type but leaves gaps. It omits the required 'brand' parameter, pagination mechanics, and exact status value constraints, which an agent needs for correct invocation beyond tool selection.

  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 has 0% description coverage, so the description must compensate. It adds meaning for window (from/to), programme (programmeId), status, and age-related fields via 'derived ageDays'. However, the required 'brand' parameter is not mentioned, and limit/cursor/offset pagination semantics are left entirely to the schema, which has no descriptions.

  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 tool lists affiliate transactions with a specific verb ('List'), a resource ('transactions on Admitad (advertiser)'), and scope ('within a window or for a specific programme'). It also enumerates relevant statuses (pending, reversed, paid), distinguishing it from sibling tools like list_clicks and get_earnings_summary.

  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?

  It provides explicit user-intent examples ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and recommends pairing with get_earnings_summary for aggregate totals. This clearly tells an agent when to select this tool and how it fits with related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adservice_list_transactionsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  There are no annotations, so the description must carry the burden. It discloses that the tool returns Transaction records including a derived ageDays field, and that it does not provide aggregate totals (by redirecting to get_earnings_summary). However, it does not mention pagination behavior, default windows, or explicit read-only semantics, though 'list' implies a safe 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 three sentences, front-loaded with purpose, followed by usage examples and a return-value note. There is no fluff or redundancy; every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 9 parameters, no output schema, and no annotations. The description gives a solid overview and covers primary use cases, but omits pagination parameter semantics (limit, cursor, offset) and the minAgeDays/maxAgeDays age filters. It also only hints at the return shape via 'ageDays'. Given the complexity, more detail would be needed for full self-sufficiency.

  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 has 9 parameters with 0% description coverage. The description adds meaning to status (listed statuses), window (from/to), and programmeId ('within a window or for a specific programme'), but leaves limit, cursor, offset, minAgeDays, and maxAgeDays unexplained. It partially compensates for the schema gaps but not fully.

  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 tool's verb and resource: 'List affiliate transactions (commissions earned, pending, reversed, or paid) on Adservice'. It highlights specific filters (window, programme) and distinguishes from sibling tools by naming the network and contrasting with get_earnings_summary.

  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 gives explicit when-to-use guidance with example user queries: "what did I earn last month?", "what's still pending?", or "show me reversed sales". It also provides an alternative/complement: 'pair with get_earnings_summary for aggregate totals', making the choice clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adtraction-advertiser_list_transactionsA
  4.3/5.0
  Behavior4/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 the return type (Transaction records), includes derived ageDays, and covers status filtering. However, it does not mention pagination behavior, default date ranges, or ordering, which are relevant for a list operation. Still, it adds meaningful behavioral context beyond the name.

  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 compact and well-structured: purpose sentence, usage examples, and return/companion guidance. Every sentence adds value with no redundancy or filler.

  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 no output schema and no annotations, the description partially covers what an agent needs. It explains scope, statuses, return type, and derived ageDays, but omits pagination details, output field specifics, and behavior when no filters are provided. Enough for basic use but not fully complete for a 10-parameter tool with rich transaction data.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds meaning for from/to (window), programmeId (specific programme), status (statuses listed), and hints at ageDays via the derived field. However, it does not explain brand, limit, cursor, or offset, leaving several of the 10 parameters without semantic guidance.

  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 tool lists affiliate transactions on Adtraction (advertiser) with specific statuses (earned, pending, reversed, paid) and supports time windows or programme filtering. It distinguishes itself from sibling tools like affiliate_adtraction_list_transactions by explicitly specifying '(advertiser)'.

  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?

  Explicitly provides when-to-use guidance with concrete user intents ('what did I earn last month?', 'what's still pending?', 'show me reversed sales'). Also advises pairing with get_earnings_summary for aggregate totals, guiding when not to use this tool alone for summaries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adtraction-advertiser_verify_authA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses the verification behavior, that it calls a minimal endpoint, and the return shape ({ok:true, identity?} or {ok:false, reason}). This is solid, though it does not explicitly state there are no side effects, which would have pushed it to 5.

  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?

  Three concise sentences deliver purpose, usage timing, return values, and a cross-reference to a related tool. No filler or 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?

  For a simple verification tool with one parameter and no output schema, the description covers the core behavior, trigger conditions, and response format. It falls short only by omitting the meaning of the 'brand' parameter, which is needed for full completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has one required parameter 'brand' with no description, and description coverage is 0%. The description never explains what 'brand' means or how it relates to the verified credentials, so it fails to compensate for the missing schema 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 clearly states a specific action (verify credentials) applied to a specific resource (Adtraction advertiser) via a minimal authenticated endpoint. It also distinguishes itself from the sibling affiliate_adtraction_verify_auth by explicitly scoping to the advertiser role.

  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?

  Provides explicit when-to-use guidance: at session start, after key rotation, or on auth errors. It also names a complementary tool (affiliate_run_diagnostic) for a full health check, which helps with tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_affilae_list_transactionsA
  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 burden of behavioral disclosure. It reveals that returns are Transaction records and that a derived 'ageDays' field is included, and implies read-only behavior through the verb 'List.' It does not mention pagination, authentication, or rates, but covers key behavioral aspects for a list 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 three sentences, front-loaded with the primary action and resource. Each sentence adds distinct value: purpose, use-case triggers, and return/complement information. No redundant or filler content.

  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 moderate complexity (9 parameters, no output schema, no annotations), the description gives a clear functional overview and derived ageDays, but lacks details on return structure, pagination, and parameter semantics for all fields. It is sufficient for a first-order understanding but not 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 0%, so the description must compensate. It explains the domain meaning of core filters (time window, programme, status) but omits others like limit, cursor, offset, minAgeDays, maxAgeDays. It provides partial value beyond the schema, but not enough for a 9-parameter tool.

  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 ('List affiliate transactions') and the resource (Affilae), and distinguishes from sibling tools by scope: 'within a window or for a specific programme.' It also enumerates relevant statuses (earned, pending, reversed, paid), making the purpose unmistakable.

  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?

  Explicit usage guidance is provided via direct example queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and a clear alternative/complement: 'pair with get_earnings_summary for aggregate totals.' This tells the agent when to use this tool and when to use another.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_amazon-creators_list_transactionsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It explains that the tool returns 'Transaction records including derived ageDays', giving return-value context. It also lists the statuses ('earned, pending, reversed, or paid') and mentions window/programme scoping. It does not disclose pagination or rate limits, but for a list operation the provided details are reasonably transparent.

  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, front-loaded with the main action. Every sentence adds value: the first defines the scope and statuses, the second provides usage examples and a cross-reference to the earnings summary. No redundant or filler content.

  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 tool with 9 parameters, no annotations, and no output schema, this description is not fully complete. It gives usage context and return info, but lacks detailed parameter semantics, pagination behavior, date format expectations, and any caution about auth or rate limits. It is adequate for common cases but leaves gaps for an agent needing exact invocation details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It does add meaning by referencing 'within a window' (from/to, minAgeDays/maxAgeDays), 'specific programme' (programmeId), and 'commissions earned, pending, reversed, or paid' (status). However, parameters like limit, cursor, and offset are not mentioned, and date formats are unspecified. The partial coverage is helpful but not comprehensive.

  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 tool lists affiliate transactions (commissions earned, pending, reversed, or paid) on Amazon Creators, with a specific verb ('List') and resource ('transactions'). It distinguishes itself from sibling tools by naming the network (Amazon Creators) and by explicitly mentioning filtering by window or programme, and by cross-referencing get_earnings_summary for aggregates.

  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 gives concrete example queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') that signal when this tool should be used. It also provides an explicit alternative: 'pair with get_earnings_summary for aggregate totals' — telling the agent when to use a different tool. This is clear usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_avantlink_list_transactionsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description adds useful behavioral details: it mentions supported statuses (earned, pending, reversed, paid), the returned object type (Transaction records), and a derived field (ageDays). It does not mention pagination behavior, rate limits, or default date ranges, but covers core output characteristics.

  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 three sentences with no filler. The first sentence defines the action and scope, the second gives practical usage triggers, and the third explains return content and cross-references to the summary tool. Every sentence adds value and the structure is front-loaded.

  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 9 parameters, no annotations, and no output schema, the description is somewhat under-specified. It covers key user intents and return type, but leaves gaps around parameter defaults, pagination, and allowed status values. It is minimally viable but not thorough.

  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 0%, so the description must compensate. It effectively maps 'window' to date-range parameters and 'programme' to programmeId, and lists status values. However, it does not explain pagination parameters (limit, cursor, offset), age range parameters (minAgeDays, maxAgeDays), or clarify the expected format for dates or status values.

  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 tool lists affiliate transactions on AvantLink, specifying the scope ('within a window or for a specific programme') and the resource type. It distinguishes from sibling list_transactions tools by naming the network and further differentiates from get_earnings_summary by recommending pairing for aggregate totals.

  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?

  Explicit usage guidance is provided with concrete example user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales'). It also names the complementary alternative (get_earnings_summary) for aggregate totals, clarifying when not to use this tool alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin-advertiser_verify_authA
  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 for behavioral transparency. It discloses the mechanism (minimal authenticated endpoint), the return shape ({ok:true, identity?} or {ok:false, reason}), and the relationship to the diagnostic tool. It does not explicitly state non-destructiveness, but the nature of a verification call implies read-only behavior, and the described outputs are sufficient for an auth check.

  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 three sentences, each earning its place: purpose, usage timing, and return/companion. It is front-loaded with the core action and avoids redundancy or fluff.

  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 verification tool with one parameter and no output schema, the description is nearly complete: it states the purpose, when to use it, what it returns, and how it relates to a fuller diagnostic. The only notable gap is the lack of explanation for the 'brand' parameter, which prevents a perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has one required parameter, 'brand', with no description (0% coverage), and the tool description never mentions 'brand' or explains what values it expects. The parameter name is somewhat self-explanatory but the description adds zero value for parameter semantics. Given the low schema coverage, the description should have compensated but did not.

  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 action ('Verify the configured credentials for Awin (advertiser) are valid') with a clear resource (Awin advertiser credentials) and method (calling a minimal authenticated endpoint). It distinguishes itself from sibling verify_auth tools by explicitly naming the Awin network and advertiser variant.

  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 gives explicit when-to-use guidance: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also points to an alternative/complement: 'pair with affiliate_run_diagnostic for a full health check.' This fully satisfies the dimension.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin_list_accountsA
  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 takes on the full burden. It discloses that the tool respects the configured token's access scope, defaults to publisher accounts, and returns account IDs, names, roles, and raw metadata. It also implies a read-only operation without needing annotations. This is clear and honest, though it doesn't mention rate limits or pagination, which are not critical for an account-listing 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 three concise sentences, each adding distinct value: what it lists, when to use it, and what it returns. It is front-loaded with the primary action and avoids redundancy with the schema. No wasted words.

  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 tool with one optional parameter and no output schema, the description is complete: purpose, usage context, default behavior, and return content are all covered. The input schema provides the enum values, and the description fills in the operational context. This is on par with the best examples for a filtered-list 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?

  The only parameter, accountType, has enum values in the schema but no description. The description adds the key semantic that it defaults to publisher accounts, which clarifies the default behavior. However, it does not explicitly explain the effect of each enum value (publisher, advertiser, all), leaving the agent to infer from the enum names. Since schema coverage is 0%, the description should compensate more fully but only partially does.

  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 tool's function: 'List Awin accounts the configured token can access.' It specifies the resource (Awin accounts) and includes a scope constraint (configured token access), with a default behavior (publisher accounts). This distinguishes it from sibling tools like affiliate_awin_list_programmes and affiliate_awin_verify_auth, which serve different purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says 'Use this at setup time or when a user has access to multiple publisher IDs,' providing clear usage context. It does not enumerate alternatives or when-not-to-use scenarios, but the recommended usage is concrete enough for an agent to select this tool appropriately among many sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_belboon_list_transactionsA
  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 discloses the return type (Transaction records), the derived ageDays field, and the covered statuses, which is meaningful behavioral context. It implies a read-only operation via 'List' but does not mention pagination behavior or rate limits; however, those are partially inferred from schema fields (limit, cursor, offset).

  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 three sentences, front-loaded with the action and resource, and every sentence earns its place: action, usage examples, and return/pairing details. No redundant phrasing or filler.

  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 9-parameter tool with no output schema and no annotations, the description covers purpose, usage examples, return type, and pairing with get_earnings_summary. However, it omits pagination behavior (cursor/limit/offset), exact status value formats, and precise window semantics, leaving gaps for an agent needing fully self-contained understanding.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It explains the 'window' (from/to), 'programme' (programmeId), and status filter via examples, and the mention of derived ageDays aids understanding of minAgeDays/maxAgeDays. However, limit, cursor, and offset are not explained, leaving a significant portion of the 9 parameters undocumented.

  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 it lists Belboon affiliate transactions with status categories (earned, pending, reversed, paid) and supports filtering by time window or programme. This distinguishes it from sibling list_transactions tools for other networks and from Belboon's own list_clicks or get_earnings_summary tools.

  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?

  It explicitly provides example user queries for when to use it ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and recommends pairing with get_earnings_summary for aggregate totals, implicitly steering away from this tool for aggregated needs. This gives clear when-to-use and alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_cj-advertiser_verify_authA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden and discloses the return format: '{ok:true, identity?} or {ok:false, reason}'. It also mentions the call is to a 'minimal authenticated endpoint', implying low-overhead read-only behavior. However, it does not elaborate on what 'identity' contains or mention any error specifics beyond 'reason'.

  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 three sentences, front-loaded with purpose, then usage, then return format. Every sentence adds unique value and there is no redundancy or filler.

  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 tool with no output schema, the description covers the essential elements: what it does, when to use it, and what it returns. The only notable omission is the meaning of the 'brand' parameter, which prevents a perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has one required 'brand' parameter with no description (coverage 0%), and the description does not explain or even mention it. The agent is left to infer what 'brand' represents (e.g., brand ID, brand name) without guidance, which is a significant gap.

  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 tool validates CJ Affiliate (advertiser) credentials via a minimal authenticated endpoint, using a specific verb ('Verify') and resource. It also distinguishes itself from sibling tools by naming the network and advertiser variant, and from affiliate_run_diagnostic by positioning it as a lighter check.

  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?

  Explicit when-to-use guidance is given: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also provides an alternative by recommending pairing with affiliate_run_diagnostic for a full health check, making the scope clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_commission-factory-advertiser_verify_authA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the burden. It explains the tool calls a 'minimal authenticated endpoint' and describes the return shape ({ok:true, identity?} or {ok:false, reason}). This conveys a lightweight, read-only check, though it does not explicitly state 'no side effects' or 'no data modification.'

  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?

  Three sentences with zero fluff: purpose, usage timing, and return format/pairing. Front-loaded with the action and resource, every sentence 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 simple auth verification tool, the description covers purpose, when to use, return values, and relationship to diagnostics. The only notable gap is the undefined 'brand' parameter, but the low complexity and explicit return shape keep it reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% for the sole parameter 'brand', and the description does not explain what 'brand' refers to or how it should be formatted. Given that the tool targets Commission Factory advertiser, 'brand' is likely the advertiser brand identifier, but this is only inferable from the tool name, not described.

  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 'Verify the configured credentials for Commission Factory (advertiser) are valid by calling a minimal authenticated endpoint.' The verb 'verify' and resource 'credentials for Commission Factory (advertiser)' are specific and distinguish this from other network-specific verify_auth tools and affiliate_run_diagnostic.

  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?

  Explicit when-to-use guidance is provided: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also mentions pairing with affiliate_run_diagnostic for a full health check, giving an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_connexity_get_earnings_summaryA
  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 adds valuable context by specifying the return type (EarningsSummary), highlights a notable field (oldestUnpaidAgeDays), and explains how it complements list_transactions for drill-down. It does not cover all possible side effects or auth requirements, but for an earnings summary read operation, this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three efficient sentences: purpose, usage guidance, and return/pairing context. Every sentence earns its place with no redundant text. The front-loaded description immediately states the core 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?

  The tool has 8 optional parameters and no output schema, so the description is the sole documentation source. It covers the main use case and return type but does not explain the meaning of all parameters (e.g., cursor, limit, maxAgeDays interaction with date window) or the semantics of 'oldestUnpaidAgeDays' beyond its name. This is sufficient for a simple summary but not fully complete for advanced usage.

  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 0%, so the description must compensate. It indirectly explains 'to'/'from' via 'date window', 'programmeId' via 'by programme', and 'status' via 'by transaction status'. However, it leaves limit, cursor, maxAgeDays, and minAgeDays undefined. The mention of oldestUnpaidAgeDays hints at age-related parameters but does not explicitly connect them, leaving gaps.

  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 opens with a specific verb+resource+scope: 'Summarise earnings on Connexity across a date window, with breakdowns by programme and by transaction status.' This clearly differentiates it from sibling tools like list_transactions (which lists individual records) and list_clicks. The example use case further reinforces its purpose.

  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?

  Explicitly states when to use: 'Use this when the user wants a single-figure answer plus context — e.g. "total earnings in Q1 with status split".' This directly addresses selection criteria, and the pairing guidance with list_transactions ('pair with list_transactions to drill into the underlying records') clarifies the relationship with an alternative tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_daisycon-advertiser_get_earnings_summaryA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Without annotations, the description carries the full burden. It discloses the return shape (EarningsSummary including oldestUnpaidAgeDays) and aggregation behavior. However, it omits details about pagination (limit/cursor), authentication requirements, or rate limits, which are relevant for a network API.

  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, front-loaded with the primary purpose, and includes an example and a pointer to a related tool. Every sentence adds value with no filler or redundant information.

  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 tool with 9 parameters, no annotations, and no output schema, the description covers the main use case but omits explanations for several parameters (e.g., maxAgeDays, minAgeDays, cursor) and the full return structure. This leaves ambiguity for complex queries involving age filters or pagination.

  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 0% schema description coverage, the description must compensate. It maps 'date window' to from/to, 'breakdown by programme' to programmeId, and 'status' to status, but leaves limit, cursor, maxAgeDays, and minAgeDays unexplained. This partial coverage is helpful but incomplete for a 9-parameter tool.

  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 tool's function: summarizing Daisycon advertiser earnings across a date window with breakdowns by programme and status. It specifically notes 'advertiser' to distinguish from publisher variants and provides an example use case, making it highly identifiable.

  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?

  Explicitly states when to use the tool ('when the user wants a single-figure answer plus context') and provides an example. It also recommends pairing with list_transactions for deeper detail, effectively directing the agent away from using this for transaction-level queries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_daisycon-advertiser_get_programmeA
  4.3/5.0
  Behavior4/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 states the return is a single Programme with fields like commission, status, and advertiser URL, and implies a read-only operation via 'Fetch.' However, it could be more explicit about read-only semantics, auth requirements, or error behavior, so it misses a perfect score.

  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?

  Three sentences, front-loaded with the action, then usage, then return/pairing. Every sentence earns its place with no filler or redundancy, making it highly efficient.

  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 tool with no output schema or annotations, the description covers purpose, usage, and return contents, and references the sibling list_programmes for discovery. However, the unexplained 'brand' parameter and lack of explicit read-only declaration leave minor gaps, so it is not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only clarifies programmeId by calling it the 'network programme id.' The required 'brand' parameter is entirely unexplained, leaving the agent to guess its format or purpose. This is a significant gap for a required parameter.

  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 tool fetches a single programme by its network programme id, specifying the Daisycon (advertiser) context. It also distinguishes from sibling list_programmes by explicitly noting this returns a single record, meeting the criteria of specific verb+resource+scope and 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says 'Use this when you already know the programme id and need its full record' and instructs to pair with list_programmes when discovery is needed. This provides clear when-to-use guidance and an explicit alternative, satisfying the highest level.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_digistore24_get_earnings_summaryA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Without annotations, the description carries the burden of behavioral disclosure. It does well by revealing that the tool returns an EarningsSummary including the field oldestUnpaidAgeDays, and that it aggregates across date windows with programme/status breakdowns. It doesn't explicitly state read-only status or side effects, but the tool name and summary nature make this a read operation, and no annotation contradicts the description.

  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 three sentences, leading with the main verb and scope, then usage guidance, then return details. Every sentence earns its place—there is no fluff or repetition. It is front-loaded and efficient.

  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 description captures the core use case and mentions a specific return field, but with no output schema and 8 parameters, it remains incomplete. It doesn't explain what maxAgeDays/minAgeDays do, even though the return field oldestUnpaidAgeDays hints at aging semantics. It also doesn't address pagination via cursor/limit, so an agent might not know how to fetch beyond the first page or filter by age. Given the complexity, more context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It indirectly explains key parameters: 'date window' maps to from/to, 'breakdowns by programme and by transaction status' maps to programmeId and status. However, it does not mention cursor, limit, maxAgeDays, or minAgeDays, which are likely pagination and aging filters. With 8 parameters and no schema descriptions, this is an important gap.

  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 tool's function: to summarise earnings on Digistore24 across a date window with breakdowns by programme and transaction status. It uses a specific verb ('summarise') and resource ('earnings on Digistore24'), and it distinguishes itself from sibling tools like list_transactions by positioning itself as a summary-level answer.

  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 explicitly says when to use this tool: 'Use this when the user wants a single-figure answer plus context', and provides a concrete example ('total earnings in Q1 with status split'). It also names an alternative and points to it: 'pair with list_transactions to drill into the underlying records'. This is clear usage guidance with exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_eduzz_list_transactionsA
  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 goes beyond a bare 'list' by stating it returns Transaction records including a derived 'ageDays' field, and that it can filter by window or programme. It does not mention pagination, auth, or read-only status, but for a listing operation the description conveys the key behavior and return data.

  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, front-loaded with the core function, and uses concrete examples for usage. Every sentence provides value—function, use cases, return data, and cross-tool guidance—with no wasted words.

  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 9 optional parameters, no output schema, and no annotations, the description covers the main use cases but leaves gaps: it does not explain default date ranges, pagination behavior, status value formats, or how parameters interact. The pairing with get_earnings_summary adds context, but the description is not fully complete for a tool with this complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds meaning to several parameters: 'within a window' explains to/from, 'specific programme' explains programmeId, the status examples map to status, and 'derived ageDays' hints at minAgeDays/maxAgeDays. However, pagination params (limit, cursor, offset) are not explained, and the description does not clarify whether filters are optional or how they combine.

  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 opens with a specific verb and resource: 'List affiliate transactions' on Eduzz, and enumerates the statuses covered (earned, pending, reversed, paid). It clearly distinguishes this tool from siblings by network (Eduzz) and by operation (transactions vs clicks, programmes, earnings summary), and the example queries further reinforce its role.

  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 explicitly states when to use the tool with concrete user phrasings: 'what did I earn last month?', 'what's still pending?', 'show me reversed sales'. It also directs pairing with get_earnings_summary for aggregate totals, which helps the agent choose between this tool and the sibling summary tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_get_brand_action_bundleA
  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 adds valuable context about the entitlement gate ('paid brand-data tool gated by the local entitlement check') and the failure mode ('returns a structured entitlement_required result rather than data'). It also clarifies what the bundle contains and what it excludes, but it doesn't explicitly state side effects or whether the tool is read-only, leaving a small gap.

  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 information-dense and front-loaded with the primary purpose, followed by usage guidance, exclusions, and entitlement behavior. Each sentence earns its place, though it is slightly longer than necessary. The structure is logical and scannable.

  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 tool with one simple parameter and no output schema, the description is quite complete: it explains the bundle contents, usage context, prerequisites, exclusions, and entitlement behavior. It doesn't detail the exact output structure or return format, but it provides enough for an agent to select and invoke the tool with confidence.

  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 has a single 'brand' parameter with 0% schema description coverage, so the description must compensate. While the description mentions the brand's strategy, networks, and snapshot, it doesn't explicitly define the 'brand' parameter's format or accepted values (e.g., ID vs. name). The meaning is inferable from context, but the description doesn't add specific parameter-level semantics beyond what's obvious.

  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 identifies the tool's action ('Assemble the input bundle') and its resource ('brand AI deliverables'), enumerating the specific components it includes. It distinguishes itself from sibling tools by noting it excludes raw transaction rows, making its purpose distinct and well-defined.

  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 explicitly states when to use this tool ('Use this to hand Claude one clean, structured input for a client-ready write-up') and provides a prerequisite ('build a snapshot first with affiliate_build_brand_snapshot'). It also gives a clear when-not by noting the deliberate exclusion of raw transaction rows, effectively steering agents away from using it for raw data needs.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_growsurf_verify_authA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, but the description reveals the endpoint type and return shape ({ok:true, identity?} or {ok:false, reason}), adding useful behavioral context. It doesn't mention rate limits or side effects, though a read-only auth check likely has none.

  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 three concise sentences covering purpose, usage timing, and return format. Every sentence earns its place with no 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?

  For a simple auth-check tool, it covers purpose, usage context, return format, and a complementary diagnostic tool. The only notable gap is the undocumented 'brand' parameter, but the overall tool is simple enough that this is a minor omission.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has a single required 'brand' string with no description, and schema description coverage is 0%. The description never explains what 'brand' refers to or how it maps to GrowSurf credentials, leaving the agent uncertain.

  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 tool verifies GrowSurf credentials via a minimal authenticated endpoint, using a specific verb and resource. It distinguishes itself from the many sibling verify_auth tools by naming GrowSurf explicitly.

  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?

  Provides explicit usage triggers: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also mentions pairing with affiliate_run_diagnostic for a full health check, offering a clear alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_impact-advertiser_verify_authA
  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 burden of behavioral disclosure. It reveals that the tool makes a network call ('calling a minimal authenticated endpoint'), returns a structured response ({ok:true, identity?} or {ok:false, reason}), and uses preconfigured credentials. It implies non-mutating behavior through the verb 'verify', though it does not explicitly state that no data is modified. It also does not explain the role of the 'brand' parameter in selecting credentials, which is a minor gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each serving a distinct purpose: purpose, usage, and return value. It is front-loaded with the primary action, and there is no wordiness or redundant information. Every sentence earns its place in the description.

  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 verification tool with no output schema, the description covers the core context: what it does, when to use it, and what it returns. It even mentions a complementary tool for fuller diagnostics. However, it omits an explanation of the 'brand' parameter, which is the only required input, leaving a completeness gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has only one required parameter 'brand' with no description (schema description coverage 0%), so the description must compensate. It does not mention 'brand' at all, leaving the agent to infer that it identifies which Impact advertiser brand to verify. Given the low schema coverage, this is a clear gap in parameter semantics.

  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 tool's purpose: 'Verify the configured credentials for Impact (advertiser) are valid by calling a minimal authenticated endpoint.' This specifies the action (verify), the resource (credentials for Impact advertiser), and the method (minimal endpoint). It also distinguishes itself from sibling tools by explicitly noting 'Impact (advertiser)' and contrasting with the full health check 'affiliate_run_diagnostic'.

  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 when-to-use guidance: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also clarifies the alternative: 'pair with affiliate_run_diagnostic for a full health check,' indicating this tool is a lightweight quick check rather than a comprehensive diagnostic.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_leaddyno_verify_authA
  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 full burden and does well: it reveals the method ('calling a minimal authenticated endpoint'), the return format ('Returns {ok:true, identity?} or {ok:false, reason}'), and implies a safe, non-destructive verification. It could add more detail on error handling or prerequisites, but overall it provides strong behavioral insight.

  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 three sentences long, front-loaded with the core purpose, followed by usage timing and return behavior. Every sentence provides necessary information with no redundancy or filler.

  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 auth-check tool with one parameter and no output schema, the description covers purpose, usage scenarios, return values, and the relationship to a diagnostic sibling. The only notable omission is the meaning of the 'brand' parameter, which prevents a perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% and the description does not explain the required 'brand' parameter. It only indirectly references LeadDyno, leaving the agent to infer what 'brand' means (e.g., the brand/account identifier). This is a clear gap for a required parameter.

  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 a specific verb (Verify) and resource (configured credentials for LeadDyno), and differentiates from siblings by naming the exact network and mentioning 'pair with affiliate_run_diagnostic for a full health check.' It fully explains what the tool does.

  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?

  Explicitly states when to use the tool: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also mentions the complementary relationship with affiliate_run_diagnostic, giving clear usage context and an alternative for a broader check.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_linkconnector_list_programmesA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses that the tool returns an array of Programme records and clarifies the joined/available scope. However, it does not mention pagination behavior, filtering semantics, or authentication requirements, which would be useful for full 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 three sentences, all informative and front-loaded with the core action. Each sentence adds value: purpose, usage triggers, and return/companion tools. No fluff or repetition.

  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 description covers purpose, usage, and return type, which is mostly complete for a list tool. However, with no output schema and 6 parameters, there is no detail on Programme record fields or parameter constraints, and the ambiguous 'or which are available to join' leaves room for interpretation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0% and the description does not explain any of the 6 parameters (limit, cursor, offset, search, status, categories). While the names are somewhat self-explanatory, there are no details about valid values, formats, or how they behave, leaving the agent to guess.

  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 it lists affiliate programmes on LinkConnector and defines the scope as programmes the publisher has joined or are available to join. The action and resource are specific, and the tool is distinguished from siblings like get_programme and list_transactions.

  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?

  Explicit usage triggers are provided via example questions such as 'which merchants am I working with?' and 'what programmes do I have on LinkConnector?'. It also suggests complementary tools for drill-down (get_programme) and activity (list_transactions), giving clear guidance on when to use each.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_lomadee_get_earnings_summaryA
  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. It discloses that the tool returns an EarningsSummary including oldestUnpaidAgeDays, which is useful behavioral context. However, it does not explicitly state whether the operation is read-only or any limitations/edge cases, though the summarization nature implies a safe read operation. This is a reasonable disclosure but not exhaustive.

  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 concise sentences, front-loaded with the core purpose. The first sentence defines what the tool does; the second provides usage guidance and return context. Every sentence earns its place with no wasted words.

  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 description provides a clear use case, return shape, and a companion tool, which is good for selection. However, it does not explain all 8 parameters (e.g., cursor, maxAgeDays) nor the full output structure, relying on self-explanatory parameter names. Given the complexity and absence of schema descriptions, the description is adequate but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 8 parameters with 0% description coverage, so the description must compensate. It adds meaning by referencing 'date window' (from/to), 'breakdowns by programme' (programmeId), and 'status' (status), but it does not explain limit, cursor, maxAgeDays, or minAgeDays. This partial coverage leaves some parameters semantically ambiguous.

  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 tool summarizes earnings on Lomadee across a date window, with breakdowns by programme and transaction status. This is a specific verb+resource+scope, and it distinguishes itself from sibling tools like list_transactions by focusing on the summary rather than individual records.

  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 explicitly says 'Use this when the user wants a single-figure answer plus context' and provides a concrete example. It also names list_transactions as a companion tool for drilling into underlying records, giving clear guidance on when to use this tool versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_mrge_list_transactionsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the full burden. It discloses the return type ('Returns Transaction records including derived ageDays') and available status filters. However, it does not mention pagination, default time windows, or rate limits. For a read-only list operation, this is acceptable transparency, though not exhaustive.

  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?

  Two concise sentences: the first states the core function, the second adds user examples, return info, and a pairing suggestion. No redundancy or filler.

  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 an 8-parameter tool with no annotations and no output schema, the description covers the primary use cases and return types, but omits details on pagination, date format, and comprehensive response fields. This leaves some ambiguity for an agent attempting to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but the description adds meaning to several parameters: from/to as a 'window', programmeId as a 'specific programme', status via the provided list, and ageDays implication via 'derived ageDays'. However, limit and cursor are left unexplained, and value formats or defaults are not given.

  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 action: 'List affiliate transactions... on mrge within a window or for a specific programme.' It names the resource (transactions), the platform (mrge), and includes status categories (earned, pending, reversed, paid), distinguishing it from siblings like list_programmes and list_clicks.

  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?

  Provides explicit user query examples ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and recommends pairing with get_earnings_summary for aggregates, giving clear when-to-use and when-to-pair guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_optimise-media_list_clicksA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses that it lists *recent* clicks, supports optional filtering, and "Returns Click records". This conveys read-only intent and basic behavior. However, it omits details like pagination behavior (though limit/cursor/offset exist in the schema) and whether 'recent' implies a default time window.

  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?

  Three sentences, each earning its place: the first states the action and optional filters, the second gives concrete use-case examples, and the third mentions the return type and a complementary tool. No filler or 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?

  For a simple list tool with no output schema, the description provides useful context: what it returns, what it's for, and how to combine it with another tool. It lacks details on pagination and date formats, but these are relatively minor gaps given the tool's simplicity and the absence of required parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It mentions filtering "by programme and date", which explains programmeId and likely from/to, but does not explain limit, cursor, or offset. The pagination parameters are left undocumented, and date format remains unspecified. The description covers only a minority of the six parameters.

  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 tool's function: "List recent affiliate clicks on Optimise Media" — a specific verb, resource, and network. It distinguishes itself from sibling tools by focusing on clicks and even references pairing with list_transactions, making its 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 Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says "Use this for traffic-side debugging" and provides concrete example questions (“are my links being clicked at all?”, “where is traffic going?”). It also recommends pairing with list_transactions to compare clicks vs conversions, offering clear guidance on when and how to use it relative to alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnero_get_programmeA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description uses the verb 'Fetch' to imply read-only behavior and discloses what the return value contains (commission, status, advertiser URL). However, with no annotations provided, the description carries the full burden and does not mention potential errors, authentication requirements, or behavior when the id is not found. Still, for a simple get operation, it provides useful behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the main purpose, then usage guidance, and finally return value and pairing suggestion. Every sentence adds value with no redundancy or fluff.

  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 tool with two parameters and no output schema, the description covers the core context: what it does, when to use it, what it returns, and how to discover the id. The missing 'brand' parameter semantics and lack of error handling details prevent a perfect score, but overall it is adequate for an agent to select and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema coverage, the description must compensate for parameter documentation. It explains 'programmeId' as the network programme id, but 'brand' is not mentioned at all in the description. The schema only specifies type string, leaving the agent uncertain about what values are valid or how brand relates to the programme lookup.

  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 tool fetches a single programme on Partnero using its network programme id. It specifies the resource (programme), the network (Partnero), and the identifier, distinguishing it from list_programmes and other network-specific get_programme tools.

  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?

  Explicitly states when to use this tool ('when you already know the programme id and need its full record') and provides an alternative path ('pair with list_programmes when you need to discover the id first'). This gives clear contextual guidance beyond mere capability.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnero_list_media_partnersA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden; it discloses that the tool returns MediaPartner records with normalised status, which is a useful transformation detail. However, it doesn't mention pagination behavior, auth, or side effects, though 'List' implies a read-only 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?

  Three sentences with no wasted words; front-loaded purpose, then usage examples, then complementary pairing. Every sentence adds value.

  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 no output schema or annotations, the description covers the core purpose, usage scenarios, return type, and the related performance tool. It leaves some gaps around parameter semantics and the meaning of 'normalised status', but is fairly complete for selection and initial invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage, and the description does not explain any of the optional parameters (limit, cursor, offset, search, status). The only hint is 'brand's programme' relating to the required brand param, leaving the agent to infer meanings from parameter names.

  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 it lists media partners (publishers) on the brand's Partnero programme, using the specific verb 'List' and resource type. It distinguishes from sibling tools like list_programmes and get_programme_performance by clarifying it returns MediaPartner records.

  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?

  It provides explicit user-question triggers ('who is promoting us on Partnero?') and suggests pairing with the matching get_programme_performance tool, giving clear when-to-use guidance and an alternative for deeper performance analysis.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnero_verify_authA
  4.3/5.0
  Behavior4/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 calls a minimal authenticated endpoint and describes the exact return shape ({ok:true, identity?} or {ok:false, reason}). This is reasonably transparent, though it could mention whether the tool makes network calls or has side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences with no fluff. The first sentence states the core purpose, the second provides usage timing, and the third describes the return and related tool. Front-loaded and efficient.

  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 verification tool with one parameter and no output schema, the description covers purpose, usage, return format, and a related diagnostic tool. It is largely complete, but the lack of brand parameter explanation is a small gap given the schema provides no description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage for the single required parameter 'brand'. The description does not explain what 'brand' refers to, leaving the agent to infer from context that it identifies the Partnero configuration to verify. The description fails to compensate for the schema's lack of 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 clearly states the tool's purpose: verifying Partnero credentials via a minimal authenticated endpoint. It uses a specific verb+resource construction and is distinct from sibling verify_auth tools for other networks by explicitly naming Partnero.

  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?

  Explicitly states when to use the tool: at the start of a session, after rotating keys, or when another operation returns an auth error. It also suggests pairing with affiliate_run_diagnostic for a full health check, providing clear context and an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerstack-advertiser_get_programmeA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden and does well by stating it returns a single Programme and listing example fields. It does not explicitly note read-only behavior, error cases, or authentication, but for a simple get operation the return disclosure is meaningful and sufficient.

  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?

  Two concise sentences front-load the core action and key details, with no filler or redundant information. Every clause adds value.

  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 description covers the primary flow (identify id → fetch record) well, especially given the large sibling list of network-specific get_programme tools. It lacks error/not-found handling and explicit brand semantics, but the simple parameter set and return description make it largely complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description only explains programmeId via 'by its network programme id'. The required brand parameter is not described at all, leaving the agent to guess its meaning or format. The description partially compensates but does not fully document both required parameters.

  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 tool fetches a single programme on PartnerStack (advertiser) by network programme id, specifying the exact action and resource. It distinguishes itself from sibling tools by noting the advertiser scope and the fields returned (commission, status, advertiser URL).

  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?

  Explicitly says to use when the programme id is already known and the full record is needed, and recommends pairing with list_programmes when discovery is required. This gives clear when-to-use guidance and identifies an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_pepperjam_get_earnings_summaryA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of behavioral disclosure. It adds useful context beyond the name by clarifying that the tool returns an EarningsSummary including oldestUnpaidAgeDays, which hints at the return structure. It appropriately implies a read-only aggregation behavior without needing to state destructive effects, though it omits details like auth requirements or response format.

  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?

  Three sentences, all purposeful. It front-loads the core action ('Summarise earnings'), then explains when to use it with an example, and finally notes the return value and a related tool. There is no fluff or redundant restatement of the name or schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 8 optional parameters, no output schema, and no annotations. The description covers the main purpose and gives an example, but it does not fully describe the return structure (only mentions one field) or clarify parameter relationships like minAgeDays/maxAgeDays vs from/to. It is enough to get started but not fully complete for a complex 8-param 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?

  The description provides some semantic mapping for parameters: 'date window' implies from/to, 'by programme' maps to programmeId, and 'by transaction status' maps to status. However, with schema description coverage at 0%, it does not explain the meaning or default behavior of limit, cursor, minAgeDays, maxAgeDays, or how the status parameter accepts multiple values, leaving significant gaps for the agent.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Summarise') and identifies the resource (earnings on Pepperjam) with clear scope ('date window', 'breakdowns by programme and by transaction status'). It distinguishes itself from the sibling list_transactions by emphasizing the single-figure answer with context, and provides a concrete example ('total earnings in Q1 with status split').

  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?

  Explicitly states when to use this tool: 'when the user wants a single-figure answer plus context'. It also gives a clear alternative for deeper investigation: 'pair with list_transactions to drill into the underlying records'. This is direct, unambiguous guidance for the agent.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_query_brand_dataA
  4.3/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Beyond the readOnlyHint annotation, the description discloses several non-obvious behaviors: aggregate results always group by currency because sums never cross currencies, a coverageMismatch signal when the requested range exceeds the persisted window, an unsupported result when falling back to aggregated mode, and gating by a local entitlement check. These details meaningfully reduce surprise and are not inferable from annotations alone.

  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 efficient and front-loaded, opening with the core purpose and then expanding into usage and return behavior. It is packed with valuable details but the second sentence is long and multi-clause, which slightly reduces scannability. Overall, every clause 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 there is no output schema, the description does a solid job explaining what the tool returns: grouped metrics, matching rows with mode 'rows', persisted coverage window, coverageMismatch, and unsupported result. It also covers the 30-day scope, the prerequisite to build a snapshot, and the entitlement check. Missing are concrete output field shapes and a precise definition of coverageMismatch, but the level of detail is adequate for a complex analytical 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 0%, so the description must compensate. It maps high-level concepts to parameters: 'filters, group-bys, sums, top-N' correspond to the filters, groupBy, metrics, and orderBy/limit fields; 'mode "rows"' is mentioned. However, it is not a systematic parameter explanation, leaving the meaning of offset, specific filter fields, and orderBy.direction to be inferred from names and enums rather than described.

  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+resource combination: 'Run a read-only analytical query ... over the persisted 30-day brand dataset'. It enumerates concrete operations (filters, group-bys, sums, top-N) and provides examples (commission by programme and month) that clearly differentiate it from sibling tools like affiliate_get_brand_rows and affiliate_build_brand_snapshot.

  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 explicitly says 'Use this to answer questions over a large account's full data', providing a clear when-to-use context. It also gives a prerequisite by instructing to 'build a snapshot first with affiliate_build_brand_snapshot' and contrasts with 'without pulling every row through a tool result'. While it doesn't explicitly name an alternative for raw-row retrieval, the context strongly implies the division of labor.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_scaleo_list_transactionsA
  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 burden of disclosing behavior. It states that the tool returns Transaction records including derived ageDays, and lists the statuses handled (earned, pending, reversed, paid). While it doesn't mention pagination or authentication, the verb 'List' and 'Returns' convey a read-only operation, and the return detail is useful behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, no fluff. The first sentence states the core action and scope, the second gives concrete use cases, and the third notes return content and a companion tool. Every sentence earns its place and the structure is front-loaded.

  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 9 optional parameters, no output schema, and no annotations, the description is not fully complete operationally. It covers the main use cases and return shape, but omits pagination behavior and details about the ageDays filters. It is adequate for tool selection but leaves gaps for full 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 coverage is 0% and there are 9 parameters. The description effectively clarifies several of them through natural language: 'window' maps to from/to, 'specific programme' maps to programmeId, and the status examples map to status. However, it does not explain limit, cursor, offset, minAgeDays, or maxAgeDays, leaving part of the parameter surface undocumented.

  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 opens with a specific verb and resource: 'List affiliate transactions ... on Scaleo', and further scopes by status, date window, and programme. This clearly distinguishes it from sibling tools like list_clicks and get_earnings_summary.

  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?

  Provides concrete user queries that should trigger this tool ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and explicitly advises pairing with get_earnings_summary for aggregate totals. This gives clear when-to-use guidance and names the complementary alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tapfiliate_verify_authA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the method (minimal authenticated endpoint), the return shape ({ok:true, identity?} or {ok:false, reason}), and implies a non-mutating verification. It doesn't explicitly state permissions or read-only status, but the verification nature is clear and the return format adds useful 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 exactly three sentences: purpose, usage triggers, and return format with a pairing suggestion. It is front-loaded with the primary action and contains no redundant or filler words.

  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 low-complexity tool with one required parameter and no output schema, the description covers purpose, when to use, return values, and a related tool. The only significant gap is the undocumented 'brand' parameter, but the overall context is sufficient for basic usage, especially given the extensive sibling toolset.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema lists only 'brand' as a required string with no description, and schema coverage is 0%. The tool description does not explain the meaning or expected values of 'brand,' so the agent is left to infer that it selects the Tapfiliate configuration. The description fails to compensate for the schema's lack of 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 clearly states the tool's purpose: 'Verify the configured credentials for Tapfiliate are valid by calling a minimal authenticated endpoint.' This uses a specific verb-resource pair and distinguishes it from sibling verify_auth tools by explicitly naming Tapfiliate.

  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 gives explicit when-to-use guidance: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also mentions pairing with affiliate_run_diagnostic for a full health check, helping the agent choose between this tool and an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tolt_verify_authA
  4.3/5.0
  Behavior4/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 the call method (minimal authenticated endpoint) and the return shape ({ok:true, identity?} or {ok:false, reason}). This is useful behavioral context, though it does not explicitly state that the call is read-only or what side effects (if any) occur, which is slightly less complete for a verification 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 three sentences long and each sentence adds value: what it does, when to use it, and what it returns. It is front-loaded with the primary purpose and contains no redundant information. Excellent structure for a small tool.

  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 verification tool with one parameter and no output schema, the description covers the key aspects: purpose, usage timing, return format, and relationship to the diagnostic tool. The only notable omission is an explanation of the 'brand' parameter, which prevents a perfect score. Otherwise, the description is complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has one required parameter 'brand' with no description (0% schema description coverage). The tool description does not explain what 'brand' means or how it relates to Tolt credentials, leaving the agent to infer that 'brand' identifies which Tolt account to verify. This is a significant gap since the description should compensate for the lack of schema descriptions.

  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 action: 'Verify the configured credentials for Tolt are valid by calling a minimal authenticated endpoint.' This clearly distinguishes the tool from the many sibling verify_auth tools for other networks and from the broader health check tool (affiliate_run_diagnostic). It is a specific verb + resource (verifying Tolt credentials).

  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?

  Explicit usage guidance is provided: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also offers an alternative/complement: 'pair with affiliate_run_diagnostic for a full health check.' This clearly indicates when to use this tool versus the diagnostic.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradetracker_get_earnings_summaryA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It discloses the return type ('EarningsSummary') and a notable field ('oldestUnpaidAgeDays'), and implies a read-only aggregation. However, it does not explicitly state that it is non-mutating, nor does it discuss default behaviors or edge cases, so transparency is good but not exhaustive.

  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?

  Three tightly constructed sentences: purpose, usage example, and return/pairing note. No redundant phrasing; all sentences add new information.

  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 description covers the tool's core purpose, example use, return type, and relationship to list_transactions. However, with no output schema and no param descriptions, it omits details about pagination (cursor/limit), the meaning of maxAgeDays/minAgeDays, and the full shape of the returned EarningsSummary beyond one field.

  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?

  All 8 parameters are undocumented in the schema (0% coverage). The description gives contextual hints for a date window (from/to), programme (programmeId), and status, but does not explain limit, cursor, maxAgeDays, or minAgeDays, and does not specify parameter names or formats. It partially compensates but leaves substantial ambiguity.

  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 ('Summarise') and identifies the resource ('earnings on TradeTracker') with a date window, plus breakdowns by programme and transaction status. It clearly distinguishes from sibling tools like list_transactions by indicating this provides a summary rather than raw transactions.

  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?

  Explicitly states when to use: 'when the user wants a single-figure answer plus context', and gives a concrete example ('total earnings in Q1 with status split'). It also references the alternative 'pair with list_transactions' for drilling into records, providing a clear comparison.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradetracker_get_programmeA
  4.3/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It discloses that a single Programme is returned and mentions the fields included, but does not cover auth requirements, error behavior, or side-effect safety. For a simple fetch, this is adequate but not rich.

  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?

  Three concise sentences immediately state the action, then give usage context and a pointer to an alternative. Every sentence earns its place with no fluff.

  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 one-parameter, single-record fetch with no output schema, the description covers what it does, when to use it, what it returns, and how to discover the id. This is complete enough for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but the description clarifies that programmeId is the network programme id and must already be known. It adds contextual meaning beyond the schema, but does not specify format or provide examples, so it only partially compensates.

  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 tool fetches a single programme on TradeTracker by its network programme id, which is a specific verb+resource combination. It also contrasts with list_programmes, distinguishing it from sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says to use it when you already know the programme id and need the full record, and points to list_programmes as the discovery alternative. This gives clear when-to-use and alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tune_list_clicksA
  4.3/5.0
  Behavior4/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 this is a listing (read) operation, mentions optional filters, and states the return type is Click records. It does not cover pagination behavior, default date ranges, or rate limits, but for a simple read-only list tool it adds useful context about the use case and output.

  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 three sentences long, starts with the core purpose, and uses concrete examples. Every sentence adds value—purpose, use case, and output plus a comparison to a related tool. No fluff.

  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 has no output schema and no annotations, so the description needs to explain both behavior and returns. It states that Click records are returned and provides a pair-with hint, but does not explain pagination behavior, date format requirements, or default limits. Given the tool's simplicity, this is adequate but not exhaustive.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% and none of the 6 parameters have descriptions. The description mentions filtering by programme and date, which maps to programmeId and from/to, but leaves limit, cursor, and offset completely unexplained. This partial compensation is insufficient for a 6-parameter tool.

  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 tool lists recent affiliate clicks on TUNE, with optional filtering by programme and date. It provides concrete example use cases ('are my links being clicked at all?') and distinguishes from the sibling tool list_transactions by suggesting pairing them. This is a specific verb+resource that differentiates it from other network-specific list_clicks tools.

  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 explicitly says to use this for traffic-side debugging and gives diagnostic questions. It also instructs pairing with list_transactions to compare clicks vs conversions, which is a clear alternative/complement. This meets the 'explicit when/alternatives' standard.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_webgains_list_transactionsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Despite having no annotations, the description discloses the return type ('Returns Transaction records including derived ageDays') and indicates that results can be filtered by window, programme, and status. This goes beyond the schema, though it does not cover operational details like pagination or authentication. Since this is a read-only listing operation, the provided transparency is adequate but not exhaustive.

  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 three sentences, front-loaded with the primary verb and resource, followed by usage examples and return details. Every sentence contributes distinct value, with no fluff or redundant restatement of the tool name.

  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 9 parameters, no annotations, and no output schema, the description provides a solid high-level overview but lacks details on pagination, parameter semantics for cursor/offset/limit, and a complete list of return fields. The mention of 'Transaction records including derived ageDays' is a start, but it does not fully describe the response structure or edge cases.

  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 has 0% description coverage, so the description must compensate. It adds meaning to at least four parameters: 'within a window' (from/to), 'specific programme' (programmeId), statuses (status), and derived ageDays (minAgeDays/maxAgeDays). However, it does not explain limit, cursor, or offset, leaving several parameters ambiguous for the agent.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'List affiliate transactions (commissions earned, pending, reversed, or paid) on Webgains within a window or for a specific programme.' It identifies the specific resource (affiliate transactions on Webgains) and explicitly mentions statuses and filter scopes, distinguishing it from sibling tools like list_clicks or get_earnings_summary.

  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 guidance with example queries: 'Use this when the user asks "what did I earn last month?", "what's still pending?", or "show me reversed sales".' It also names an alternative tool for aggregate totals ('pair with get_earnings_summary'), clarifying when not 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.

• affiliate_2performant_get_programmeA
  4.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 discloses the return type (single Programme) and key fields, which is useful, but it does not address error handling, authentication needs, or side effects. For a simple read operation this is acceptable but not rich.

  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 three sentences, front-loaded with the primary action, and each sentence contributes distinct value: what it does, when to use it, and how it relates to list_programmes. There is no waste or 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?

  For a tool with one parameter and no output schema, the description covers the return value, usage timing, and how to discover the ID. It omits error cases and auth, but these are likely standard across the network family; the essential guidance for selection and invocation is present.

  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 schema has 0% description coverage, but the description compensates by explaining that programmeId is the network's programme id and the condition for using the tool (already knowing the id). This adds meaningful context beyond the bare 'string' type.

  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 tool fetches a single programme by its network programme id, distinguishing it from list_programmes by specifying 'single' and the return fields (commission, status, advertiser URL). This is a specific verb+resource with clear scope.

  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 explicitly says to use this tool when you already know the programme id, and pairs it with list_programmes when discovery is needed. This provides a clear decision rule and names the alternative, which is exactly the kind of guidance an agent needs.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_admitad-advertiser_get_programme_performanceA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses the return type (ProgrammePerformanceRow records) and key behavior (per-publisher metrics by date). It does not mention pagination behavior or rate limits, but 'Fetch' clearly implies a read-only operation, and the core behavioral scope is well covered.

  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 three sentences and every sentence earns its place: the first states the function and metrics, the second gives concrete use cases, the third mentions related tools and return type. It is front-loaded, dense but not verbose.

  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 absence of output schema and annotations, the description does a good job covering purpose, usage, return type, and relationships to sibling tools. Missing details like pagination semantics and date-range defaults are notable gaps, but for a read-oriented fetch tool this is largely sufficient for selection and 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 has 8 parameters with 0% description coverage. The description compensates partially by implying date range (from/to), publisher focus (publisherId), and programme context (programmeId), but it does not explain limit, cursor, offset, or parameter formats. Parameter names are somewhat self-explanatory, but for this many parameters, more explicit mapping would be needed.

  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 ('Fetch') and resource ('per-publisher performance for the brand's programme at Admitad (advertiser)'), explicitly listing the metrics included (clicks, conversions, gross sale, commission) and the date dimension. This clearly distinguishes it from sibling tools like list_transactions or get_earnings_summary by focusing on per-publisher rollup data.

  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 when-to-use scenarios with example phrasings ('how is each publisher performing...', 'show me the top-earning partners last month'), and points to alternatives for related tasks (list_media_partners for publisher IDs, list_transactions for drill-down). This gives the agent actionable selection criteria.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adrecord_generate_tracking_linkA
  4.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of behavioral disclosure. It does disclose the return type and hints at error prevention by recommending programmeId confirmation, but it omits details about authentication requirements, side effects (if any), or failure modes. This is adequate but not rich.

  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?

  Three sentences, each earning its place: purpose in the first, usage context in the second, return type and prerequisite in the third. It is front-loaded with the core action, concise, and free of fluff.

  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 two-parameter tool with no annotations and no output schema, the description covers the essential aspects: what, when, return type, and a crucial prerequisite. Minor gaps like potential error conditions or auth expectations are not covered, but the description is sufficient for an agent to select and invoke the tool correctly in most scenarios.

  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?

  Schema description coverage is 0%, so the description must compensate. It does by mapping 'programme' to programmeId and 'destination URL' to destinationUrl, and clarifies that programmeId should come from list_programmes. This adds meaningful context beyond the bare schema, though it could be more explicit about URL formatting or programme ID structure.

  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 a specific action ('Generate a tracking link on Adrecord'), identifies the resource and inputs ('for a given programme and destination URL'), and distinguishes it from sibling network-specific tools by naming Adrecord. It also mentions the return type ('Returns a TrackingLink'), leaving no ambiguity about what the tool does.

  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?

  Explicitly provides a usage scenario ('when the user wants to share an affiliate link to a specific product or page on a merchant they have joined') and gives a direct prerequisite instruction ('pair with list_programmes to confirm the programmeId'). This clearly guides when to use the tool and how to avoid errors, effectively steering the agent among the many sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adservice_get_programmeA
  4.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 does mention the return type ('Returns a single Programme') and sample fields (commission, status, advertiser URL), but it does not disclose error behavior, authentication requirements, or side effects. For a simple fetch this is adequate but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with purpose, then usage, then return information. Every sentence adds value and there is no filler.

  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 single-parameter get tool, the description covers purpose, usage, and return content. It does not describe error cases or note that is a read-only operation, but the simplicity and single parameter reduce the need. The 'Returns a single Programme' helps fill the absence of an output schema.

  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?

  Schema has 0% description coverage for the single programmeId parameter. The description compensates by clarifying it is the 'network programme id' and that you must already have it, adding meaningful context beyond the bare parameter name and type.

  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 tool fetches a single programme by its network programme id, with a specific verb and resource. It distinguishes from sibling list_programmes by noting when to pair with it, and the network name is explicitly mentioned in the description and title.

  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?

  It explicitly says 'Use this when you already know the programme id' and provides an alternative: 'pair with list_programmes when you need to discover the id first.' This gives clear when-to-use and when-not-to-use guidance, naming the specific alternative tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adtraction_get_programmeA
  4.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  There are no annotations, so the description carries the burden of behavioral disclosure. It adds return context (single Programme, includes commission/status/advertiser URL), but does not mention prerequisites like authentication (though a verify_auth sibling exists), error behavior for missing/invalid IDs, or that the operation is read-only. The description adds some value but omits several meaningful behavioral details.

  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 with no filler. The first sentence front-loads the action and resource; the second provides when-to-use and an alternative. Every clause adds value, and the structure makes it easy to scan.

  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 single-parameter read tool with no output schema and no annotations, the description covers purpose, usage context, return type, and pairing with a related tool. It lacks only explicit auth requirements and error handling, which are somewhat inferred from the sibling verify_auth tool. Overall, it is nearly complete for the tool's simplicity.

  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 schema has 0% description coverage, so the description must compensate. It does so by explaining that programmeId is the network's programme id and that it must already be known (discoverable via list_programmes). This adds practical meaning beyond the raw schema, which only says 'type: string.' It does not give format details like numeric vs. string, but that is a minor gap.

  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 opens with 'Fetch a single programme on Adtraction by its network programme id,' which names a specific action, resource, and unique key. It further clarifies the record contents (commission, status, advertiser URL), and the sibling list shows many network-specific get_programme tools, so 'on Adtraction' distinguishes this from other networks. The pairing with list_programmes clearly separates discovery from retrieval.

  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 explicitly states when to use this tool: 'Use this when you already know the programme id and need its full record.' It also names the alternative for discovery: 'pair with list_programmes when you need to discover the id first.' This gives the agent a clear decision rule between the two complementary tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_affiliate-future_get_programmeA
  4.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 must convey behavioral traits on its own. It discloses the return type ('a single Programme') and example fields (commission, status, advertiser URL), which is helpful. However, it does not explicitly state that the operation is read-only, mention authentication prerequisites, or describe error scenarios. Given the absence of annotations, the burden is only partially met.

  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 three concise sentences, front-loaded with the action verb 'Fetch', and contains no fluff. Each sentence contributes distinct value: what the tool does, when to use it, and what it returns/how it relates to list_programmes.

  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 1-parameter tool with no output schema, the description covers the core purpose, usage conditions, and return content reasonably well. It hints at the return fields and pairing with list_programmes. Gaps remain around authentication and error handling, but the overall low complexity means the description is largely adequate.

  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 schema has only one parameter (programmeId) with zero description coverage. The description compensates by identifying it as the 'network programme id' and indicating it should already be known, which adds meaning beyond the raw parameter name. It falls short of explaining format or source, but for a single, self-descriptive parameter, this is sufficient.

  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 action ('Fetch a single programme'), the specific resource ('on Affiliate Future'), and the key identifier ('network programme id'). It distinguishes from sibling get_programme tools for other networks by naming the network, and it differentiates from list_programmes by specifying the single-record use case.

  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 explicitly states when to use the tool ('when you already know the programme id') and provides a clear alternative for discovery ('pair with list_programmes when you need to discover the id first'). This is direct, actionable guidance that helps an agent decide between siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_affiliate-future_list_transactionsA
  4.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 adds useful behavioral context by mentioning derived ageDays and the statuses it returns, but it does not explicitly state that this is a read-only operation, mention pagination behavior, or disclose authentication requirements.

  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 concise sentences that front-load the tool's purpose, then provide usage examples, return details, and a pairing suggestion. There is no redundant or irrelevant information.

  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 description covers the core use cases well and even hints at return fields (derived ageDays). However, given the tool has 9 optional parameters and no output schema or annotations, it omits important operational details like pagination defaults, date handling, and explicit read-only confirmation.

  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?

  Since schema descriptions are absent (0% coverage), the description compensates by explaining the meaning of 'window' (from/to), 'specific programme' (programmeId), and statuses (earned, pending, reversed, paid). However, pagination parameters (limit, cursor, offset) are not described, and the date format for from/to is not specified.

  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 tool lists affiliate transactions on Affiliate Future, including statuses like earned, pending, reversed, or paid. It also specifies the scoping options (window or specific programme), which distinguishes it from other network list_transactions tools.

  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?

  It gives explicit when-to-use examples with natural language queries ('what did I earn last month?', etc.) and provides an alternative by suggesting pairing with get_earnings_summary for aggregate totals. This helps the agent decide when to invoke this tool versus the summary tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_amazon-creators_get_programmeA
  4.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 burden of behavioral disclosure. It does add useful context: 'Returns a single Programme' and lists the record fields (commission, status, advertiser URL), which helps set expectations. However, it does not disclose error handling (e.g., what happens if the id is not found), authentication requirements, or rate limits. 'Fetch' implies read-only but is not explicit. This is a moderate disclosure for a simple fetch 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 three sentences, each serving a distinct purpose: what it does, when to use it, and what it returns/companion tool. There is no redundant phrasing and the most critical information is front-loaded. It is concise without losing substance.

  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: one required parameter, no output schema, no annotations. The description covers the purpose, usage context, and return type, and even explains the discovery workflow via list_programmes. It lacks edge-case details (e.g., not found errors), but given the low complexity, the description is sufficiently complete for an agent to select and invoke the tool correctly.

  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 schema has one parameter (programmeId) with no description, giving 0% schema coverage. The description compensates by explaining the parameter is the 'network programme id' and that it is the key for fetching the full record. It also implies the id can be obtained from list_programmes. This adds meaning beyond the schema, though it does not provide format details like length or allowed characters.

  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 tool's function: 'Fetch a single programme on Amazon Creators by its network programme id.' It specifies the verb (fetch), the resource (single programme), the platform (Amazon Creators), and the scope (by id). It also distinguishes itself from the sibling list_programmes tool, making it easy for an agent to select the correct tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicit usage guidance is provided: 'Use this when you already know the programme id and need its full record' and 'pair with list_programmes when you need to discover the id first.' This directly names the alternative sibling tool and states the condition under which each should be used, giving clear when-to-use and when-not-to-use instructions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_avantlink_generate_tracking_linkA
  4.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 'Returns a TrackingLink' and implies a dependency on a valid programmeId, but does not mention authentication requirements, potential side effects, or error behavior for invalid input. For a simple link-generation tool this is adequate but not rich.

  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?

  Two sentences, zero filler. The main action is front-loaded, followed by usage context, and then a return-value note plus a pairing hint. Every sentence 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 tool with 2 parameters, no annotations, and no output schema, the description covers purpose, usage context, the return value, and a recommended setup step (list_programmes). It lacks details on error handling or auth, but for a simple, well-scoped operation this is near-complete.

  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?

  Schema description coverage is 0%, so the description must compensate. It does so by naming both parameters in prose: 'given programme and destination URL' and elaborating that the destination is 'a specific product or page on a merchant.' It also points to list_programmes for programmeId sourcing, adding practical meaning beyond bare schema names.

  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+resource construction: 'Generate a tracking link on AvantLink' for a given programme and destination URL. It clearly distinguishes this tool from sibling network-specific generate_tracking_link tools by naming AvantLink and specifying the purpose (sharing an affiliate link to a product/page).

  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?

  Provides explicit use-case guidance: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' Also gives a concrete operational recommendation: 'pair with list_programmes to confirm the programmeId before calling,' which helps the agent avoid errors. This goes beyond generic context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_avantlink_list_clicksA
  4.4/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 burden. It discloses the read-only nature (listing), the return type (Click records), and the 'recent' default scope. However, it does not mention pagination behavior, date format, or any potential rate limits. Still, it offers more than a minimal listing statement.

  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?

  Two sentences, front-loaded with the core purpose, then usage context, return type, and pairing advice. No filler or repeated schema information.

  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 list tool with no output schema and no annotations, the description gives essential context: what it does, when to use it, what it returns, and how it relates to a sibling tool. Missing details on parameter formats and pagination, but the description is sufficient for a basic agent to select and invoke the tool correctly.

  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 description adds meaning to some parameters: 'optionally filtered by programme and date' maps to programmeId and from/to. It does not explain limit, cursor, or offset, which remain opaque. Since schema description coverage is 0%, the description partially compensates but leaves pagination semantics undocumented.

  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 opens with 'List recent affiliate clicks on AvantLink' – a specific verb, resource, and platform. It further distinguishes from siblings by noting optional filtering by programme and date, and by returning Click records rather than transactions.

  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?

  Explicitly frames the tool for traffic-side debugging with concrete example questions, and explicitly recommends pairing with list_transactions to compare clicks vs conversions. This provides clear when-to-use guidance and an alternative tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin_list_offersA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the experimental status, the observed HTTP 500 error, and that results are returned only when Awin responds 200. This provides useful behavioral context, though it omits pagination details and authentication requirements.

  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?

  Three well-structured sentences, each serving a distinct purpose: stating the function, providing usage guidance, and describing return behavior. No filler or redundant 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?

  Given 9 optional parameters and no output schema, the description explains the main filter capabilities and return behavior, and warns about instability. However, pagination behavior and the exact response structure are not specified, leaving some gaps for an agent fully invoking the 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 schema has 0% description coverage, so the description must compensate. It maps the filter criteria (advertiser, region, membership, offer type, status, exclusivity, updated-since) to the schema parameters. However, it does not mention the pagination parameters page and pageSize, and enum values are left to 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 clearly states it retrieves Awin promotions and voucher offers visible to the publisher, using the specific verb 'retrieve'. It distinguishes from sibling tools like affiliate_awin_list_programmes by focusing on offers with filter dimensions such as membership, region, and status.

  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?

  It explicitly says 'Use this to find joined or not-joined offers by advertiser, region, membership, offer type, status, exclusivity, or updated-since date', giving a clear use case. It also warns 'once the endpoint is validated for the account', which is a prerequisite condition. It does not explicitly name alternative tools but implies its specialized role.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin_list_product_feedsA
  4.4/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. It discloses the return value as an 'actionable not-enabled envelope with required credentials and documentation links,' which conveys important behavioral context. It does not explicitly state whether the operation is read-only, but the nature ('status') strongly implies it is a safe check.

  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 three sentences, each serving a distinct purpose: purpose, usage condition, and return behavior. There is no redundant wording or restating of the name.

  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 zero-parameter tool with no output schema, the description covers the essential aspects: what it returns, when to use it, and the shape of the response. It could be improved by listing exact envelope fields or providing an example, but it is sufficient for agent selection.

  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 takes no parameters, and the input schema is empty (100% coverage). Per the rubric, zero-parameter tools receive a baseline score of 4; the description appropriately focuses on purpose and return rather than parameters.

  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 tool returns the current Awin product feed implementation status, using a specific verb ('Return') and resource. It distinguishes itself from the sibling 'affiliate_awin_download_product_feed' by emphasizing status rather than download, making its 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 Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly instructs when to use this tool: when a user asks for product feed access before the separate feed API key flow is configured. While it doesn't name an alternative tool, the condition implies that once configured, a different flow applies. This is clear enough for an agent to select it appropriately.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_belboon_get_programmeA
  4.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description must carry the transparency burden. It discloses the operation is a read-only fetch and specifies return contents (commission, status, advertiser URL), but does not mention error behavior, authentication requirements, or rate limits. For a simple getter this is adequate, but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the action and resource, then concise usage guidance. Every sentence earns its place with no redundancy or fluff.

  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 simplicity (one parameter, no output schema, no annotations), the description covers the essential facts: what it does, when to use it, and what it returns ('single Programme', including key fields). Minor omissions like error cases or auth notes are acceptable for a straightforward getter, and the return value description is especially useful because no output schema exists.

  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?

  Schema description coverage is 0%, so the description must compensate. It gives meaning to programmeId by calling it the 'network programme id', clarifies it must already be known, and directs users to list_programmes for discovery. This adds valuable context beyond the raw string type, though it doesn't detail format or validation rules.

  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 action ('Fetch a single programme on Belboon'), the exact lookup key ('by its network programme id'), and differentiates from sibling tools by naming the Belboon network and pairing with list_programmes. This clearly distinguishes it from other network-specific get_programme tools.

  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?

  Explicitly states when to use this tool ('when you already know the programme id') and provides the alternative workflow ('pair with list_programmes when you need to discover the id first'). This gives the agent clear decision guidance relative to a specific sibling tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_commission-factory_get_earnings_summaryA
  4.4/5.0
  Behavior4/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 returns an EarningsSummary including oldestUnpaidAgeDays, which is meaningful behavioral context. However, it stops short of describing any side effects, authorization needs, or rate limits, so it is not fully comprehensive.

  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 with an embedded example, front-loading the core purpose and adding practical guidance without any fluff. Every clause 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 8 optional parameters, lack of annotations, and absence of an output schema, the description covers the primary use case and discloses a key return field. It does not explain all parameters or the full EarningsSummary structure, but it is adequate for an agent to select the tool and understand its general behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It relates the date window to from/to and breakdowns to programmeId/status, but leaves limit, cursor, maxAgeDays, and minAgeDays unexplained. This partial coverage is helpful but insufficient for complete parameter understanding.

  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 verb 'Summarise', the resource 'earnings on Commission Factory', and specific scope: a date window with breakdowns by programme and transaction status. It distinguishes itself from sibling list_transactions by presenting itself as a summary rather than transaction-level detail.

  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?

  It explicitly says 'Use this when the user wants a single-figure answer plus context' and provides a concrete example ('total earnings in Q1 with status split'). It also recommends pairing with list_transactions for drilling into underlying records, establishing a clear alternative and an implicit when-not-to-use-this-for-detail.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_commission-factory_get_programmeA
  4.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 does state the tool 'Returns a single Programme' and lists example fields, implying a read operation. However, it doesn't disclose error behavior (e.g., what happens if the id is invalid or not found), auth requirements, or rate limits. For a simple fetch, this is a minimum-viable disclosure but has clear 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?

  The description is two sentences, front-loaded with the action ('Fetch a single programme'), and contains no redundant phrasing. Every clause adds value: context, usage, return type, and pairing suggestion.

  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 tool with one parameter and no output schema, the description covers the essential context: what it does, when to use it, what it returns, and key fields (commission, status, advertiser URL). It lacks error-handling and auth details, but given the simplicity of the operation and the explicit pairing guidance, it is nearly complete. A score of 5 would require those missing pieces.

  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?

  Schema coverage is 0%, so the description must compensate. It adds meaning by explaining the parameter as a 'network programme id' and indicating it is used to fetch a full record. It also suggests pairing with list_programmes to discover the id, which hints at the id's origin. While it doesn't provide format examples, it gives sufficient semantic context for a single string parameter.

  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+resource ('Fetch a single programme on Commission Factory') and clearly identifies the input as 'network programme id'. It distinguishes itself from sibling get_programme tools by naming the network ('Commission Factory') and from list_programmes by noting it returns a single record, not a list.

  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?

  Explicitly states when to use: 'Use this when you already know the programme id and need its full record'. Also names the alternative workflow: 'pair with list_programmes when you need to discover the id first'. This is clear guidance on usage vs alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_connexity_generate_tracking_linkA
  4.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries full burden for behavioral disclosure. It does add some context by saying it returns a TrackingLink and advising to confirm the programmeId first, but it does not mention authentication requirements, side effects, rate limits, or error conditions. For a mutation-like tool this is a modest but not comprehensive disclosure.

  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 three sentences, front-loaded with the core action, followed by usage context and a return/workflow note. No redundant or filler content; every sentence contributes useful information.

  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 has only two string parameters and no output schema, the description is fairly complete: it states the purpose, when to use it, the return type, and a prerequisite. It could enrich the return type description or mention error handling, but for this small scope the missing details are not critical.

  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?

  Schema description coverage is 0%, so the description must compensate. It names both parameters implicitly ('given programme and destination URL') and gives extra guidance for programmeId by recommending confirmation with list_programmes. While it doesn't provide formats or examples, it clarifies the intended meaning of both inputs, adding value beyond the bare 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 opens with a specific action ('Generate a tracking link on Connexity') and names the key inputs (programme and destination URL), making the tool's purpose immediately clear. It also distinguishes this Connexity-specific tool from the many sibling network-specific generate_tracking_link tools.

  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?

  Explicitly states when to use the tool ('when the user wants to share an affiliate link to a specific product or page on a merchant they have joined') and provides a concrete workflow hint ('pair with list_programmes to confirm the programmeId before calling'). This gives clear context and a pointer to the companion tool, covering the main usage guidance needs.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_coupang-partners_generate_tracking_linkA
  4.4/5.0
  Behavior4/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 the return type (TrackingLink) and warns to confirm programmeId before calling, which implies a failure mode for unverified IDs. It does not mention side effects or auth, but for a link generator this is reasonable context, and it does not contradict any annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, all informative: purpose, usage scenario, and return/prerequisite. No fluff or repetition. Key information is front-loaded in the first sentence.

  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 two-parameter tool with no output schema and no annotations, the description covers what the tool does, when to use it, what it returns, and a key prerequisite. It lacks details on error handling or output structure, but the pairing advice and mention of 'merchant they have joined' give enough context for an agent to invoke it correctly in most cases.

  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 0%, so the description must compensate. It maps 'programme' to programmeId and 'destination URL' to destinationUrl, and tells the agent to obtain programmeId via list_programmes. However, it does not explain URL format, type constraints beyond string, or examples, leaving some ambiguity.

  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 says 'Generate a tracking link on Coupang Partners for a given programme and destination URL' – a specific verb, resource, and network. It clearly distinguishes this from sibling generate_tracking_link tools for other networks by naming Coupang Partners, and states the return type 'TrackingLink'.

  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?

  Explicitly states when to use: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also advises pairing with list_programmes to confirm programmeId, which is a clear prerequisite and points to a complementary tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_daisycon-advertiser_get_programme_performanceA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the return type (ProgrammePerformanceRow records) and the data shape (per-publisher metrics by date), implying a read-only fetch. However, it does not mention pagination behavior, default date ranges, or authentication requirements explicitly.

  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 long, front-loaded with the main function and metrics, then adding usage examples and related tools. Every sentence adds value with no 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 no output schema and 8 parameters, the description covers the core purpose, return type, and relations to sibling tools, but lacks details on pagination and exact parameter syntax. It is nonetheless a substantial overview for a moderately complex tool, though not fully comprehensive.

  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 0% for parameters, so the description compensates by clarifying the date context (by date), publisher grouping (per-publisher), and the programme/brand relationship. It does not explain limit, cursor, offset, or validate the format of brand, programmeId, or publisherId, leaving some ambiguity for a tool with 8 parameters.

  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 tool fetches per-publisher performance for a brand's programme at Daisycon, listing specific metrics (clicks, conversions, gross sale, commission) and the date dimension. This specific verb+resource combination distinguishes it from sibling tools like list_transactions or list_media_partners.

  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?

  Explicitly provides when to use: 'when the user asks...' with example queries, and gives alternatives by saying to pair with list_media_partners for publisher IDs and list_transactions for transaction-level drill-down. This clearly guides selection among sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_daisycon-advertiser_list_transactionsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It discloses that results include derived ageDays, filters by status/window/programme, and implies a read-only list operation. This adds useful behavioral context, though it stops short of mentioning pagination or auth.

  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?

  Three sentences with no filler. The core purpose is front-loaded, and the following sentences provide useful usage examples and a pointer to a sibling tool, making every sentence valuable.

  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 10 parameters, no output schema, and no annotations, the description gives a strong high-level overview and operational context for common queries. However, it omits important invocation details like required brand, date format, and pagination behavior, so it is not 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 coverage is 0%, and the description partially compensates by referencing a date window (from/to), programme (programmeId), and statuses (status). However, it does not explain the required brand parameter, pagination (cursor/limit/offset), or minAgeDays/maxAgeDays, leaving several parameters under-described.

  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?

  Clearly states 'List affiliate transactions' on 'Daisycon (advertiser)' with statuses and filtering scope, using a specific verb and resource. This distinguishes it from sibling list_transactions tools for other networks and from the non-advertiser Daisycon variant.

  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?

  Explicitly gives example user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') and recommends pairing with get_earnings_summary for aggregates. This provides clear when-to-use and complementary-tool guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_daisycon_list_clicksA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses that the operation is a listing ('List recent...'), indicates optional filtering, and states the return type ('Returns Click records'). It does not detail pagination, auth, or side effects, but as a read-only list operation the core behavior is transparent. It could add more context on 'recent' or pagination, but the description goes beyond the basic 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?

  Three sentences, each serving a purpose: statement of function, usage examples, and return type/complementary tool. No redundant words or filler; front-loaded with the core action.

  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 description covers the main purpose, typical use cases, return type, and relationship to list_transactions. Since there is no output schema or annotations, it would be beneficial to describe the Click record shape or pagination behavior, but the description is still sufficiently complete for an agent to select and invoke the tool in the common traffic-debugging scenario.

  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 0%, so the description must compensate. It explains that filtering is by 'programme and date', which maps to programmeId and from/to parameters. However, it does not explain limit, cursor, offset, or the format of date strings. This leaves three of six parameters without any semantic guidance, so the description only partially compensates.

  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 verb and resource: 'List recent affiliate clicks on Daisycon'. It also specifies optional filters ('by programme and date') and distinguishes from sibling list_transactions by noting 'Returns Click records; pair with list_transactions to compare clicks vs conversions.' This is a specific and unambiguous description.

  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?

  Explicitly provides use cases: 'traffic-side debugging — e.g. "are my links being clicked at all?" or "where is traffic going on Daisycon?"'. It also names an alternative/complementary tool: 'pair with list_transactions to compare clicks vs conversions.' This gives clear when-to-use guidance and distinguishes from related tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_digistore24_get_programmeA
  4.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 burden. It conveys a read-only nature via 'Fetch' and discloses return contents (commission, status, advertiser URL). However, it does not mention error behavior (e.g., not found), authentication prerequisites, or confirm lack of side effects, leaving some gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise, front-loaded sentences with zero fluff. The action and resource are stated first, followed by usage guidance and return description. Every sentence 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 simple 1-parameter get with no output schema, the description covers the purpose, when to use, alternative, and return shape (single Programme with key fields). Missing edge-case behavior details, but these are not critical for this straightforward 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?

  Schema description coverage is 0% and the only parameter is bare 'programmeId'. The description adds semantic meaning by calling it a 'network programme id' and clarifying it is the identifier needed to fetch a full record. Format specifics are absent, but the core meaning is established.

  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 starts with a specific verb+resource: 'Fetch a single programme on Digistore24 by its network programme id.' This clearly distinguishes it from list_programmes and other sibling tools, and the 'single' vs. list contrast is explicit.

  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?

  It provides explicit when-to-use guidance ('when you already know the programme id and need its full record') and directly names the alternative (list_programmes) for id discovery. This is exactly what an agent needs to choose correctly among siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_digistore24_verify_authA
  4.4/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. It discloses the mechanism (minimal authenticated endpoint), the return shape ({ok:true, identity?} or {ok:false, reason}), and the context. It does not explicitly state 'no side effects,' but the nature of a verify operation implies non-mutating behavior, making this reasonably transparent.

  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 three sentences, each contributing value: purpose/method, usage triggers, and return/complementary pairing. It is front-loaded and contains no fluff.

  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 zero-parameter verify tool, the description covers the essential aspects: what it does, when to use it, what it returns, and its relation to affiliate_run_diagnostic. It doesn't detail the contents of 'identity?' or possible 'reason' values, but for this simple tool, that is an acceptable minor 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 tool has zero parameters and the schema description coverage is 100% vacuously. Per the rubric, a baseline of 4 is appropriate for 0 params. The description adds no parameter-specific details, but none are needed.

  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 tool's purpose: 'Verify the configured credentials for Digistore24 are valid by calling a minimal authenticated endpoint.' It uses a specific verb (verify), names the resource (credentials for Digistore24), and distinguishes itself from sibling verify_auth tools by specifying the network.

  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 explicit usage triggers: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also suggests pairing with affiliate_run_diagnostic for a full health check. While it doesn't explicitly exclude alternatives, the triggers and complementary tool guidance are clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_ebay_get_programmeA
  4.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 the return type ('Returns a single Programme') and mentions key fields (commission, status, advertiser URL), but does not mention auth requirements, error behavior, or explicitly confirm read-only semantics. This is adequate for a simple getter but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences: purpose, usage context, and return value with pairing hint. Every sentence adds value, no redundancy, and the key action 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 simple tool with one parameter and no output schema, the description covers purpose, usage, return type, and gives examples of returned fields. It also provides navigation advice (pair with list_programmes). Missing error handling/auth details, but these are not critical for a fetch operation. Overall, it is comprehensive for the tool's simplicity.

  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 schema only provides 'programmeId' as a string with no description. The description adds meaning by calling it the 'network programme id' and explaining that it identifies the programme to fetch. This compensates for the 0% schema coverage, though it doesn't specify format or validation rules.

  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 action ('Fetch a single programme'), the resource ('programme on eBay Partner Network'), and the scope ('by its network programme id'). It distinguishes itself from list_programmes, which is used for discovering ids, and from other networks by explicitly naming eBay Partner Network.

  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?

  Explicitly says to use this when the programme id is already known and you need the full record, and pairs with list_programmes for id discovery. This provides clear when-to-use guidance and names the alternative tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_eduzz_get_programmeA
  4.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry the safety burden. It specifies a read operation ('Fetch'), the return type ('Returns a single Programme'), and the included fields (commission, status, advertiser URL). However, it does not address error cases, auth requirements, or rate limits, leaving some behavioral gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, front-loaded with the action and resource, followed by usage guidance, return type, and pairing hint. No filler or 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?

  For a simple one-parameter get tool with no output schema, the description covers purpose, when to use, parameter meaning, and return shape. It lacks error/edge-case details but is sufficiently complete for the complexity level.

  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?

  Schema coverage is 0%, so the description compensates by clarifying programmeId semantics: it is the network programme id and must already be known. It also instructs how to discover it via list_programmes, adding meaning beyond the bare 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 clearly states 'Fetch a single programme on Eduzz by its network programme id' with a specific verb, resource, and scope. It distinguishes from siblings like list_programmes and get_programme for other networks.

  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?

  Explicitly gives the condition for use: 'when you already know the programme id and need its full record', and names the alternative: 'pair with list_programmes when you need to discover the id first.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_financeads_get_programmeA
  4.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 does state the return type ('Returns a single Programme') and highlights key fields (commission, status, advertiser URL), but it does not explicitly mention auth requirements, error behavior if the id is not found, or confirm it is a non-mutating read operation. The verb 'Fetch' implies safety, but this is not explicit.

  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, front-loaded with the core purpose, and includes usage guidance and return behavior without redundancy. Every phrase 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 simple single-parameter get with no output schema, the description covers purpose, when to use, return type, and how to discover the id via list_programmes. Minor gaps include not specifying not-found behavior or authentication, but these are not critical for this straightforward fetch 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 schema has 0% description coverage, so the description must add meaning. It clarifies that programmeId is the 'network programme id' and that the user should 'already know' it, optionally obtained from list_programmes. This adds sufficient context to the lone parameter, though it could go further by specifying format or validation.

  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 tool fetches a single programme on financeAds by its network programme id, using a specific verb ('Fetch') and resource ('a single programme on financeAds'). It distinguishes itself from sibling network-specific get_programme tools by naming financeAds and the exact lookup key.

  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 explicitly says when to use this tool ('Use this when you already know the programme id and need its full record') and names the alternative for discovering the id ('pair with list_programmes when you need to discover the id first'). This provides clear guidance on selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_flexoffers_get_programmeA
  4.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description discloses the return shape ('Returns a single Programme') and some included fields (commission, status, advertiser URL), which is useful. However, with no annotations, it does not mention authentication requirements, potential errors, rate limits, or side effects, so the behavioral disclosure is only partial.

  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?

  Two sentences, front-loaded with the core operation, no redundant filler. Every clause adds either scope, use-case, return info, or workflow guidance.

  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 single-parameter lookup with no output schema and no annotations, the description covers purpose, parameter origin, return value, and relationship to list_programmes. It could be even more complete by noting auth/error behavior, but it is largely sufficient for this simple 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?

  Schema coverage is 0%, so the description carries the burden. It adds meaning by clarifying that programmeId is the network-specific programme id and explains how to discover it via list_programmes. For a single required parameter, this is solid compensation.

  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 action ('Fetch a single programme'), the resource ('FlexOffers'), and the lookup key ('network programme id'). It also differentiates from sibling tools like affiliate_flexoffers_list_programmes and other networks' get_programme tools.

  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?

  Explicitly says when to use this tool ('when you already know the programme id and need its full record') and points to the alternative ('pair with list_programmes when you need to discover the id first'). This is strong usage guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_flipkart_generate_tracking_linkA
  4.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  There are no annotations, so the description carries the full burden. It discloses the return type ('Returns a TrackingLink') and hints at the need for a valid programmeId. However, it does not mention potential side effects, auth requirements, rate limits, or error behavior. For a generate operation, this is a moderate disclosure but leaves several behavioral aspects unstated.

  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 three sentences, each serving a distinct purpose: stating the main function, providing usage context, and giving return type and a validation tip. It is front-loaded, contains no redundant information, and every sentence 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 tool with only two simple required parameters and no output schema, the description covers the core aspects: what it does, when to use it, what it returns, and how to verify the input. It lacks details on error handling or authentication, but given the simplicity and the existence of sibling tools for verification, it is reasonably complete.

  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?

  Schema description coverage is 0%, so the description must add meaning. It explains that programmeId identifies the joined merchant programme and destinationUrl is the target page/product URL. It also advises confirming the programmeId via list_programmes, which adds semantic value beyond the raw string names in 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 clearly states the specific action: 'Generate a tracking link on Flipkart Affiliate for a given programme and destination URL.' It identifies the exact resource (Flipkart Affiliate tracking link) and distinguishes it from sibling tools for other networks and from Flipkart's list/get/programme tools. The mention of returning a TrackingLink further clarifies the purpose.

  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 explicitly says when to use the tool: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also provides a concrete prerequisite/alternative by advising to 'pair with list_programmes to confirm the programmeId before calling,' giving the agent actionable guidance on how to validate the input.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_growsurf_list_clicksA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It clearly implies a read-only operation via 'List' and states it 'Returns Click records', which is useful. However, it does not disclose details about pagination, authentication requirements, or the precise meaning of 'recent' (e.g., default time window), leaving some behavioral aspects implicit.

  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 written in two sentences, front-loaded with the core purpose, followed by usage context and a pairing suggestion. Every sentence adds value without redundancy or fluff, making it highly scannable for an AI agent.

  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 7 parameters, no annotations, and no output schema, the description is relatively complete: it covers the tool's purpose, when to use it, and the return type. However, it omits details on the structure of Click records, default date ranges, and the required brand parameter, leaving some context-dependent gaps that could hinder correct invocation in edge cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It partially does by mentioning filtering by 'programme and date', which maps to programmeId, from, and to. However, it does not explain the required 'brand' parameter or the pagination parameters (limit, cursor, offset), leaving significant semantic gaps for an agent to infer.

  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 tool's function: 'List recent affiliate clicks on GrowSurf' with a specific verb and resource. It also distinguishes it from sibling tools by naming GrowSurf and the ability to filter by programme and date, making it easy to differentiate from other network-specific list_clicks tools.

  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 explicitly tells when to use this tool: 'Use this for traffic-side debugging' with concrete example questions like 'are my links being clicked at all?' and 'where is traffic going on GrowSurf?'. It also suggests pairing with list_transactions to compare clicks vs conversions, clearly indicating this tool is for clicks and not conversions, and naming a specific alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_hotmart_get_programmeA
  4.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 burden of behavioral disclosure. It does state that the tool returns a single Programme and lists included fields, but it omits authentication expectations, error behavior, and rate limits, leaving clear transparency 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?

  The description is three concise sentences, each adding value: the operation, the usage trigger, and the return/discovery guidance. 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?

  For a simple single-parameter lookup with no output schema, the description covers the core workflow: knowing the id, fetching the full record, and falling back to list_programmes. It also mentions the returned fields, though authentication and error handling are not addressed.

  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 schema provides no description for the programmeId parameter, but the description defines it as 'network programme id' and explains how to obtain it via list_programmes. This adds meaningful context beyond the bare schema definition.

  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 it fetches a single programme on Hotmart by network programme id. It also lists the key fields returned (commission, status, advertiser URL) and distinguishes itself from list_programmes by describing the discovery workflow.

  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?

  Explicitly says 'Use this when you already know the programme id and need its full record' and directs users to pair with list_programmes when the id must first be discovered. This provides clear when-to-use guidance and a named alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_hotmart_list_transactionsA
  4.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 does mention that the tool returns Transaction records including derived ageDays, which is useful return-format context. However, it does not disclose authentication requirements, pagination behavior, or what happens when no filters are provided, leaving gaps for a tool with no annotation-based 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?

  The description is three sentences long, front-loaded with the primary purpose, followed by usage examples and return-info. Every sentence earns its place, and there is no redundancy or fluff. It is compact yet information-dense, ideal for an agent to quickly parse.

  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 tool with 9 parameters, no output schema, and no annotations, the description is reasonably complete. It covers the core functionality, common use cases, and points to a sibling tool for aggregate totals. It does not address pagination or default date-window behavior, which would be useful, but the description still gives the agent enough context to select and invoke the tool correctly in most scenarios.

  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 schema has zero description coverage, so the description must compensate. It adds meaning for several parameters: 'within a window' maps to from/to, 'specific programme' maps to programmeId, and the listed statuses (earned, pending, reversed, paid) map to the status parameter. It also hints at ageDays, which relates to minAgeDays/maxAgeDays. However, it does not explain limit, cursor, or offset, which remain ambiguous despite their self-explanatory names.

  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 ('List') and resource ('affiliate transactions' on Hotmart), and immediately clarifies the scope: within a window or for a specific programme. It also distinguishes itself from sibling tools by listing the relevant statuses (earned, pending, reversed, paid) and explicitly pairing with get_earnings_summary for aggregate totals. This clearly differentiates it from other transaction-listing tools for different networks.

  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 concrete example user queries ('what did I earn last month?', 'what's still pending?', 'show me reversed sales') that signal exactly when to use this tool. It also states that for aggregate totals, one should use get_earnings_summary instead, offering an explicit alternative. This gives the agent strong selection guidance without ambiguity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_impact-advertiser_get_programme_performanceA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It uses 'Fetch' and 'Returns', clearly indicating a read-only operation, and discloses the return type (ProgrammePerformanceRow records). However, it does not explicitly mention side-effect-free behavior, permissions, or pagination, though the read-only intent is unambiguous from the verb.

  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 three sentences with each earning its place: purpose, usage examples, and return type/companion tools. It is front-loaded and contains no redundant information.

  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 data retrieval tool with 8 parameters, no output schema, and no annotations, the description covers the essential aspects: purpose, when to use, return type, and related tools. It lacks explicit parameter-level explanations and pagination details, but the overall context is sufficient for basic usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds context for date parameters ('by date') and publisherId ('pair with list_media_partners to discover publisher ids'), but it does not explain pagination parameters (limit, cursor, offset) or date formats. Thus it only partially compensates for the missing schema descriptions.

  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 specific action ('Fetch per-publisher performance'), the resource ('brand's programme at Impact (advertiser)'), and the metrics (clicks, conversions, gross sale, commission). It distinguishes this tool from siblings by emphasizing 'per-publisher' and the Impact (advertiser) scope, and by contrasting with list_transactions for transaction-level drill-down.

  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 explicitly provides trigger phrases ('how is each publisher performing', 'top-earning partners last month') and suggests companion tools (list_media_partners for publisher ids, list_transactions for transaction-level detail), effectively communicating when to use this tool and offering alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_impact-advertiser_list_contractsA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already declare readOnlyHint=true; the description adds experimental status, single-programme scope, and 'raw payloads preserved,' which goes beyond the annotation. It lacks auth/rate-limit details but is consistent with the read-only hint.

  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?

  Two dense sentences with no filler. Front-loads the action and purpose, then packs parameters and return characteristics into a single well-structured sentence.

  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?

  No output schema, so the description's mention of 'read-only Impact contract records with raw payloads preserved' gives some return context. It covers purpose, params, read-only nature, and use case. Missing pagination details (e.g., opaque cursor, page size) and response envelope structure, but is reasonably complete for a list 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?

  With 0% schema description coverage, the description explicitly enumerates all six parameters: brand and programmeId as required, and status, mediaPartnerId, cursor, and limit as filters. It adds the pagination interpretation of 'page cursor' and clarifies filter roles, though it does not detail status enum semantics or value formats.

  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?

  Description opens with a specific verb ('list') and defines the resource ('Impact contracts' as payment-term relationships with media partners), scoped to one brand programme. This clearly distinguishes it from sibling get_contract (single fetch) and propose_contract (change).

  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?

  Explicitly states when to use: 'to review known partner terms before any separately gated change is proposed.' This gives a clear context and implies read-only review, but it does not name alternative tools for single-fetch or other scenarios.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_impact-advertiser_propose_contractA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations already mark readOnlyHint; description reinforces with 'performs only API reads' and adds return structure (ContractChangePlan with snapshots, warnings, confirmation token). No contradiction.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two dense sentences packed with purpose, usage, inputs, and output. A bit run-on but all content is relevant and 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?

  No output schema, but description explains return value. It gives required inputs and clarifies safety. Missing a bit about how brand/programmeId relate to contract identification, but sufficient for agent to select/invoke.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Input schema has no defined params, so description fully compensates by naming brand, programmeId, and action with enum values apply|remove. This is essential information not present elsewhere.

  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?

  Clearly states it builds a dry-run plan for changing an Impact contract without writing, and explicitly contrasts with apply/remove writes. Distinguishes itself from sibling read tools by emphasizing preview/blast radius.

  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?

  Explicitly says use to preview before any write is enabled, and states required inputs. Does not name alternative tools, but clearly implies the alternative is the actual write operation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_kwanko_get_earnings_summaryA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden of disclosing behavior. It reveals that the tool returns an EarningsSummary including oldestUnpaidAgeDays, which informs the agent about the return structure. It also implies an aggregate operation rather than a raw list by recommending pairing with list_transactions. It doesn't cover pagination behavior or date format, but it does disclose the essential nature of the 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 three sentences, each earning its place: purpose, usage, and return/companion guidance. It is front-loaded with the action and contains no filler or redundant terms.

  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 tool with 8 parameters and no output schema, the description covers purpose, usage, and key return details (EarningsSummary, oldestUnpaidAgeDays). It omits pagination specifics and parameter formats, but the parameter names are mostly self-explanatory, and the description is sufficient for an agent to select and invoke the tool for the intended use case.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It explains that the tool takes a date window (from/to) and provides breakdowns by programme (programmeId) and transaction status (status). The mention of oldestUnpaidAgeDays hints at age-based parameters like minAgeDays/maxAgeDays. However, limit, cursor, and exact formats for from/to are not explained, leaving ambiguity given 8 parameters.

  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 opens with a specific verb ('Summarise earnings on Kwanko') and clearly identifies the resource (earnings) and scope (date window, breakdowns by programme and transaction status). This distinguishes it from sibling tools like list_transactions, and the example ('total earnings in Q1 with status split') reinforces a distinct purpose.

  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 explicitly states when to use the tool: 'Use this when the user wants a single-figure answer plus context'. It also tells the agent to 'pair with list_transactions to drill into the underlying records', providing an alternative for deeper detail. This is clear when/when-not guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_kwanko_get_programmeA
  4.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations exist, so the description carries the full burden. It conveys a read-only fetch via the verb 'Fetch' and names returned fields, but it does not explicitly state safety characteristics, authentication prerequisites, or error/not-found behavior. The behavioral disclosure is adequate but not rich.

  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?

  Two concise sentences, front-loaded with the core action, followed by usage guidance and return details. No filler or redundancy; every sentence 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 simple one-param, no-output-schema tool, the description covers purpose, input semantics, return content, and the discovery workflow via list_programmes. It omits error/not-found handling and explicit auth notes, but those are not critical for a low-complexity fetch.

  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?

  Schema coverage is 0%, but the description compensates by explaining that programmeId is the network programme id and indicates when you'd already have it (or need list_programmes to discover it). This adds meaningful semantics beyond the bare string type, though it doesn't specify format constraints.

  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 it fetches a single programme by its network programme id on Kwanko, with a specific verb and resource. It explicitly distinguishes itself from list_programmes, making its purpose unambiguous among the many sibling get_programme tools.

  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 when-to-use guidance by stating 'Use this when you already know the programme id' and contrasts it with list_programmes for id discovery. This gives direct situational context and an explicit alternative, meeting the highest bar.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_kwanko_list_transactionsA
  4.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations exist, so the description carries full responsibility. It adds the useful detail that records include derived ageDays, but does not mention pagination behavior, authentication requirements, default window, or ordering. These are significant gaps for a read 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?

  Three tightly written sentences: definition, usage examples, and pairing advice. No redundancy; every sentence adds value.

  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 tool with 8 parameters and no output schema, the description covers key use cases, return highlights, and relationship to the summary tool. It does not state default behavior when no filters are given, but overall it is sufficiently complete for an agent to select and invoke it correctly.

  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?

  Schema description coverage is 0%, so the description must compensate. It maps 'window' to from/to, 'specific programme' to programmeId, and statuses to the status parameter. The mention of ageDays hints at minAgeDays/maxAgeDays semantics. However, limit and cursor are not explained.

  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 tool lists affiliate transactions on Kwanko, including specific statuses (pending, reversed, paid) and filtering by window or programme. This differentiates it from sibling tools like list_clicks and get_earnings_summary.

  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?

  Explicitly provides example user queries ('what did I earn last month?', 'what's still pending?') and recommends pairing with get_earnings_summary for aggregate totals, giving clear when-to-use guidance versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_levanta_list_clicksA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries full burden. It discloses the return type ('Returns Click records'), the 'recent' scope, and filtering options. However, it does not explicitly state read-only nature, pagination behavior, or auth requirements. For a non-destructive list operation, this is reasonably transparent but not exhaustive.

  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?

  Three sentences, front-loaded with the main purpose, followed by usage context, return type, and a sibling pairing. Every sentence earns its place with no redundancy or fluff.

  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 moderate complexity (6 params, no annotations, no output schema), the description covers purpose, usage, return type, and a relationship to list_transactions. It lacks explicit parameter formats (e.g., date format) and pagination details, but an agent can likely infer these from the parameter names and the description's mention of filtering. This is close to complete but has minor gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It explains the programme and date filters ('optionally filtered by programme and date'), which maps to programmeId and from/to, but leaves limit, cursor, and offset unexplained. Since pagination parameters are common and self-explanatory, the partial compensation is adequate but not complete.

  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 'List recent affiliate clicks on Levanta, optionally filtered by programme and date' — a specific verb, resource, and scope. It also distinguishes from sibling tools by mentioning Levanta and pairing with list_transactions, making its role unambiguous.

  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 explicitly says 'Use this for traffic-side debugging' with concrete example questions and advises pairing with list_transactions to compare clicks vs conversions. This gives clear when-to-use guidance and a complementary alternative, meeting the bar for strong usage guidelines.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_monetizze_get_programmeA
  4.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 does disclose that the tool returns a single Programme and enumerates some fields (commission, status, advertiser URL), which provides some behavioral context. However, it does not mention whether authentication is required, error behavior if the id is invalid/not found, or any other side-effect details. It is adequate but not comprehensive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the action and resource, and every sentence adds value. It includes purpose, usage condition, return description, and alternative tool guidance with no filler.

  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 tool with one parameter and no output schema, the description covers the essential context: what it does, when to use it, what it returns, and how to get the required id. It omits potential error handling and auth requirements, but these are less critical for a straightforward fetch, so it is reasonably complete.

  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?

  Schema description coverage is 0%, so the description must compensate. It clarifies that programmeId is the 'network programme id' and explains how to obtain it via list_programmes, adding meaningful semantics beyond the bare schema field name. It does not specify format or examples, but the key meaning is clear.

  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 'Fetch a single programme on Monetizze by its network programme id,' which is a specific verb+resource+scope. It distinguishes itself from list_programmes by emphasizing single-record retrieval by id, and the mention of Monetizze differentiates it from other networks' get_programme tools.

  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?

  It explicitly provides usage context: 'Use this when you already know the programme id and need its full record' and contrasts with list_programmes: 'pair with list_programmes when you need to discover the id first.' This is clear when-to-use and alternative guidance, earning a top score.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_mrge_get_earnings_summaryA
  4.4/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 burden of disclosing behavior. It clearly indicates a read-only aggregation operation ('Summarise earnings', 'Returns an EarningsSummary') and adds return details like 'oldestUnpaidAgeDays'. It does not mention authentication prerequisites or rate limits, but the non-mutating nature is strongly implied and the output shape is partially described.

  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 three sentences with no fluff. The first sentence states purpose, the second provides a concrete usage example, and the third describes the return value and links to a related tool. All sentences earn their 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 lack of annotations, no output schema, and a schema with zero parameter descriptions, the description is quite complete. It covers the main purpose, provides usage guidance, and hints at the return shape. It does not explain all 8 parameters (like pagination controls or age filters), but it gives enough context for an agent to select and invoke the tool for typical summary queries.

  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 has 0% description coverage across 8 parameters, so the description must compensate. It explains date window ('from', 'to'), breakdown by 'programme' (programmeId), and 'status' explicitly, and mentions an output field. However, it does not clarify params like 'limit', 'cursor', 'maxAgeDays', or 'minAgeDays', leaving those ambiguous.

  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 tool's function: 'Summarise earnings on mrge across a date window, with breakdowns by programme and by transaction status.' It uses a specific verb ('summarise'), names the resource ('mrge earnings'), and clarifies scope ('date window', 'breakdowns'). This distinguishes it from siblings like list_transactions by emphasizing aggregated results rather than raw records.

  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 explicitly says 'Use this when the user wants a single-figure answer plus context' and gives a concrete example ('total earnings in Q1 with status split'). It also points to a complementary tool: 'pair with list_transactions to drill into the underlying records,' providing clear alternative usage.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_mrge_get_programmeA
  4.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the return type ('Returns a single Programme') and the fields included (commission, status, advertiser URL), which is useful. However, it does not mention authentication requirements, error behavior, or explicitly confirm it's a read-only operation, though that is implied by 'Fetch'.

  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 three sentences, each adding value: what it does, when to use it, and what it returns. It is front-loaded and free of filler.

  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 single-parameter fetch tool, the description is quite complete. It covers input, output, and usage context. Minor gap: it doesn't describe error cases or what happens if the ID is invalid, but that's not critical for a straightforward get 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?

  Schema description coverage is 0%, so the description must compensate. It does by repeatedly referring to 'network programme id' and 'the programme id', clarifying the meaning of the programmeId parameter. The single parameter's purpose is well explained.

  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 action ('Fetch a single programme on mrge by its network programme id') with a clear resource and identifier. It distinguishes itself from sibling tools like list_programmes and other network-specific get_programme tools by explicitly naming the network (mrge).

  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?

  It explicitly states when to use the tool ('when you already know the programme id and need its full record') and when to use an alternative ('pair with list_programmes when you need to discover the id first'). This is clear, actionable guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_netrefer_get_programmeA
  4.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses that the tool returns a single Programme and mentions key fields, but it does not mention authentication requirements, error/not-found behavior, or potential side effects. The 'Fetch' wording implies a read operation, but edge-case behavior remains unspecified.

  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, front-loaded with the core action, and every clause adds value. No filler or redundant phrasing, making it easy to parse quickly.

  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 one-parameter read tool with no output schema or annotations, the description covers the purpose, the return type, key fields, and pairing strategy. It is nearly complete, though it omits potential error handling or authentication context, which are less critical for a fetch 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?

  Schema description coverage is 0%, but the description compensates by explaining that the single parameter is the 'network programme id' and that you should use this tool when you already know the id. This adds meaning beyond the bare schema name 'programmeId', though format specifics are left to 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 clearly states the tool fetches a single programme on NetRefer by its network programme id, distinguishing it from sibling network-specific get_programme tools and list_programmes. It also specifies what the full record contains (commission, status, advertiser URL), making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says to use this when you already know the programme id and need the full record, and pairs it with list_programmes for id discovery. This gives clear when-to-use guidance and names the alternative, which is excellent for tool selection among many similar siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerize-advertiser_list_clicksA
  4.4/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 and does well: it discloses that the tool returns Click records, supports date/programme filtering, and is read-oriented ('List'). It lacks some behavioral details like pagination behavior or date format expectations, but provides meaningful context beyond the tool name for a listing 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?

  Three sentences, all substantive and front-loaded: purpose first, then usage guidance, then return type and pairing suggestion. No fluff or repetition — every sentence 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 7-parameter tool with no annotations and no output schema, the description covers the core aspects: what it does, when to use it, what it returns, and how to combine with another tool. It falls short on pagination details, date format expectations, and auth prerequisites, but overall provides a solid, actionable picture.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate for 7 undocumented parameters. It adds filter semantics ('programme and date' maps to programmeId and from/to), which helps, but leaves brand, limit, cursor, and offset unexplained. The high-level filter hints are useful but not comprehensive for the full parameter set.

  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 ('List') and resource ('recent affiliate clicks on Partnerize (Advertiser)') with explicit scope ('optionally filtered by programme and date'). It clearly distinguishes this tool from the many other list_clicks siblings by platform and advertiser orientation, and names the complementary list_transactions tool for cross-comparison.

  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 gives explicit usage context: 'Use this for traffic-side debugging' with concrete example questions ('are my links being clicked at all?', 'where is traffic going?'). It also names the related list_transactions tool for comparing clicks vs conversions, effectively telling the agent when this tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnero_list_transactionsA
  4.4/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 adds valuable context by stating the return type (Transaction records) and the derived ageDays field. However, it does not mention pagination behavior (cursor/offset/limit) or any potential rate limits or authentication nuances, which are relevant for a list operation with 10 parameters.

  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 three sentences, each with a distinct purpose: definition, usage examples, and return/complement guidance. It is front-loaded and contains no filler, making it highly efficient for an agent to parse.

  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?

  Despite having no output schema and 10 parameters, the description offers a solid overview of the tool's purpose, filtering options, and relationship to get_earnings_summary. It is missing explicit details on pagination and the complete set of filtering rules (e.g., default statuses, brand requirement), but it still provides enough context for common transaction-list use cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It adds meaning to several key parameters: from/to (window), programmeId (specific programme), status (earned/pending/reversed/paid), and min/maxAgeDays (implied by derived ageDays). However, it does not explain pagination parameters (limit, cursor, offset) or the required brand parameter, leaving some schema fields semantically unaddressed.

  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 a specific verb ('List'), a resource ('affiliate transactions on Partnero'), the statuses covered (commissions earned, pending, reversed, or paid), and filtering dimensions (window or programme). It effectively distinguishes itself from sibling tools like get_earnings_summary (aggregate totals) and list_clicks (click data).

  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 gives explicit example user queries that should trigger this tool ('what did I earn last month?', 'what's still pending?', 'show me reversed sales'). It also names get_earnings_summary as a companion for aggregate totals, providing clear guidance on when to use this tool versus a related alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerstack-advertiser_get_programme_performanceA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Without annotations, the description discloses the output type (ProgrammePerformanceRow records) and the per-publisher rollup nature, adding behavioral context beyond the tool name. However, it does not mention pagination behavior or authorization requirements.

  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 three sentences, front-loaded with the main action, then usage examples, then complementary tools. Every sentence adds value with no fluff.

  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?

  Despite lacking an output schema and parameter descriptions, the description provides enough context for selection and invocation, including example queries, companion tools, and output type. Some parameter details remain implicit, but overall it is quite 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 has 0% parameter descriptions, so the description must compensate. It hints at dates ('by date'), publisher IDs (via list_media_partners pairing), and programme/brand context, but leaves limit, cursor, offset, and parameter formats unexplained.

  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 it fetches per-publisher performance with specific metrics (clicks, conversions, gross sale, commission) by date. This distinguishes it from sibling transaction or media partner tools.

  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 gives explicit example user queries ('how is each publisher performing on PartnerStack (advertiser)?', 'show me the top-earning partners last month') and recommends pairing with list_media_partners and list_transactions, clarifying when to use this tool vs alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerstack_get_programmeA
  4.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 returns 'a single Programme' and lists contained fields (commission, status, advertiser URL), which is useful. However, it does not explicitly state that this is a read-only operation with no side effects, nor does it mention error behavior or authentication requirements. The lack of explicit read-only disclosure and error handling keeps this below a 4.

  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 three sentences, each adding value: the action, the use case, and the return value plus progression to the list tool. It is front-loaded with the verb 'Fetch' and contains no filler or redundant information. Perfectly concise for the tool's purpose.

  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 simplicity (one parameter, no output schema, no annotations), the description is fairly complete. It covers the purpose, parameter semantics, return value, and relationship to list_programmes. The only gaps are explicit error handling and authentication prerequisites, which are both minor for this read-only getter pattern. The description sufficiently equips an agent to select and invoke the tool correctly.

  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 only defines 'programmeId' as a required string with 0% description coverage. The description compensates by clarifying that the parameter is 'the network programme id' and explains how to obtain it via list_programmes. This adds meaningful context beyond the raw schema, though it stops short of specifying the expected format or type constraints.

  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 action: 'Fetch a single programme on PartnerStack by its network programme id.' It identifies the specific resource (Programme on PartnerStack), the identifier used (network programme id), and differentiates from sibling tools by naming the network and contrasting with list_programmes. This is a specific verb+resource statement that leaves no ambiguity.

  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 when-to-use guidance: 'Use this when you already know the programme id and need its full record (commission, status, advertiser URL).' It also gives an explicit alternative: 'pair with list_programmes when you need to discover the id first.' This clearly distinguishes from the related list tool and tells the agent exactly when to choose this over alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_pepperjam_generate_tracking_linkA
  4.4/5.0
  Behavior4/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 the return type ('Returns a TrackingLink') and implies the need for a valid programmeId via the list_programmes pairing advice. However, it does not explicitly state whether authentication is required or specify error behavior on invalid inputs, leaving some gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, each adding value: purpose, usage scenario, and return/prerequisite. No wasted words, front-loaded with the core action, and appropriately sized for the tool's complexity.

  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 two-parameter tool with no output schema and no annotations, the description covers the essential aspects: what it does, when to use it, what it returns, and a validation step. It lacks explicit error handling or authentication notes, but the core context is sufficiently complete for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description compensates by identifying the two parameters as 'programme and destination URL.' It clarifies the purpose of programmeId through 'confirm the programmeId,' but lacks details on formats, constraints, or examples. This is adequate for a simple two-parameter tool but not comprehensive.

  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 tool's function: 'Generate a tracking link on Pepperjam for a given programme and destination URL.' It uses a specific verb ('Generate'), a precise resource ('tracking link on Pepperjam'), and identifies the key inputs, which distinguishes it from sibling tools like list_programmes or get_programme.

  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?

  It explicitly states when to use: 'when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also provides a companion step: 'pair with list_programmes to confirm the programmeId before calling,' which acts as a prerequisite and guides the agent to verify input before invocation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_post-affiliate-pro_get_programmeA
  4.4/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. It discloses that the tool fetches a single programme, returns specific fields (commission, status, advertiser URL), and that the programme id is the network's id. It does not mention error handling or authentication, but for a simple read operation this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loads the action, and each sentence adds value: the first states what it does, the second states when to use it and its companion tool. There is no redundancy or fluff.

  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 get tool with no output schema and no annotations, the description covers the key aspects: what it returns, what fields are included, and how it relates to list_programmes. It falls short only on the brand parameter, which is not described. Overall, it is nearly 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 coverage is 0%, so the description must compensate. It clarifies that programmeId is the network programme id, which adds meaning. However, the 'brand' parameter is not explained at all, leaving a significant gap for a tool that requires both parameters.

  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 verb 'Fetch', the specific resource (a single programme on Post Affiliate Pro), and the lookup key (network programme id). It also distinguishes itself from list_programmes by noting it returns a single full record. This is a specific, non-tautological description.

  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 explicitly states when to use the tool: 'Use this when you already know the programme id and need its full record.' It also names the alternative: 'pair with list_programmes when you need to discover the id first.' This provides clear guidance on selection among siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_refersion_get_programmeA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full burden. It clearly explains the fetch behavior, notes it returns a single Programme, and lists the fields returned (commission, status, advertiser URL), going beyond a bare restatement. It implies a read-only operation, but does not explicitly mention safety, permissions, or error conditions, so it is good but not exhaustive.

  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?

  Three concise sentences, each adding value: action, usage context, and relationship with list_programmes. No redundant words, front-loaded with the verb 'Fetch.'

  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 fetch tool with no annotations or output schema, the description covers the action, return fields, and usage guidance, but lacks explanation of the brand parameter and potential error cases. Overall sufficiently complete for typical use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It explains the programmeId parameter as 'network programme id' and clarifies the need to know the ID, but it does not explain the brand parameter, leaving ambiguity. This partial coverage warrants a mid-low score.

  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 'Fetch a single programme on Refersion by its network programme id,' specifying the verb, resource, and identifier. It also distinguishes from sibling list_programmes by noting the pairing for ID discovery.

  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?

  It explicitly says 'Use this when you already know the programme id and need its full record' and advises to pair with list_programmes when discovery is needed, providing clear when-to-use and alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_scaleo_generate_tracking_linkA
  4.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 adds useful context: 'Returns a TrackingLink' and implies a prerequisite (user must have joined the merchant). However, it does not disclose authentication needs, possible errors, or whether generating a link has any side effects. This is adequate but leaves significant gaps in behavioral detail.

  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 three concise sentences, with the action stated first, then the usage context, and finally the return type and prerequisite. Every sentence earns its place with no redundancy or fluff.

  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 tool with no output schema, the description covers the essential context: what it does, when to use it, what it returns, and a prerequisite. It could be more complete with details about URL format or error behavior, but these are not critical for a straightforward link generator. The pairing with list_programmes helps the agent act correctly.

  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?

  With 0% schema description coverage, the description must compensate. It gives meaning to both parameters: 'programme' and 'destination URL,' and explains the destination is 'a specific product or page on a merchant.' It also advises confirming the programmeId via list_programmes, adding practical semantics beyond the bare 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 states exactly what the tool does: 'Generate a tracking link on Scaleo for a given programme and destination URL.' It uses a specific verb and resource, and the mention of Scaleo distinguishes it from the many sibling generate_tracking_link tools for other networks. It also clarifies the user's intent ('share an affiliate link to a specific product or page').

  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 a clear trigger condition: 'Use this when the user wants to share an affiliate link to a specific product or page on a merchant they have joined.' It also names an alternative tool to combine with: 'pair with list_programmes to confirm the programmeId before calling,' which is explicit guidance on how to use it correctly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_shareasale_get_programmeA
  4.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 burden. It discloses the operation type ('Fetch' implies read-only), return shape ('Returns a single Programme'), and content examples (commission, status, advertiser URL). However, it omits potential error behavior, authentication prerequisites, or whether the program might be inactive/nonexistent—common gaps for a simple get-by-id 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?

  Two sentences, no filler. The first sentence states the primary function and key parameter; the second provides use-case and pairing with list_programmes. Every word adds value.

  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 get-by-id tool with one parameter and no output schema, the description covers the action, parameter meaning, return type, and usage hint. It lacks error/edge-case details, but these are less critical here. Overall, it provides a complete operational 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?

  Schema coverage is 0% and the schema only lists programmeId as a string. The description adds meaningful semantics by calling it 'network programme id' and explaining its role in fetching a single programme, which compensates for the bare schema. For a single required parameter, this is sufficient.

  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 opens with a specific verb ('Fetch') and resource ('a single programme on ShareASale'), and clearly specifies the key identifier ('network programme id'). It also lists included fields (commission, status, advertiser URL), making the tool's purpose distinct from sibling list/get tools across other networks.

  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?

  Explicitly states when to use ('when you already know the programme id and need its full record') and points to the alternative for discovery ('pair with list_programmes when you need to discover the id first'). This gives clear decision guidance relative to sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_shopmy_get_earnings_summaryA
  4.4/5.0
  Behavior4/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 the return type (EarningsSummary including oldestUnpaidAgeDays) and mentions breakdowns, adding useful context beyond the schema. However, it doesn't explain pagination behavior, date window inclusivity, or potential side effects (though as a read operation these are minimal). The description adds value but lacks a few behavioral details.

  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 three sentences, front-loaded with the main action and resource, and every sentence adds value. No filler or redundancy, and it includes a useful example and related tool pointer. Efficient and well-structured.

  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 moderate complexity (8 params) and lack of annotations and output schema, the description gives a solid overview of purpose, usage, and return value. It mentions the oldestUnpaidAgeDays field and the pairing with list_transactions, but does not detail all parameter semantics or potential pagination. Slightly incomplete for the full parameter set, but adequate for an agent to select and invoke the tool appropriately.

  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 has 8 parameters with 0% description coverage, so the description must compensate. It does add meaning for date window (from/to), programme (programmeId), and status (status), which are core semantics. However, it does not explain limit, cursor, maxAgeDays, or minAgeDays, leaving several parameters underspecified. Partial compensation only.

  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 tool summarizes earnings on ShopMy with breakdowns by programme and status, using the specific verb 'summarise' and naming the resource. It distinguishes itself from sibling list_transactions tools by focusing on aggregate/summary results rather than individual records.

  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?

  Explicit usage guidance is given: 'Use this when the user wants a single-figure answer plus context' and provides a concrete example. It also suggests pairing with list_transactions for drilling into records, which helps the agent choose between the summary and transaction-level tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tapfiliate_get_programmeA
  4.4/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. It discloses the return type (a single Programme) and key fields (commission, status, advertiser URL), and implies read-only behavior via 'Fetch'. It does not discuss error handling or authentication, but for a simple fetch tool this is adequate and more transparent than typical.

  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 three sentences, front-loaded with the action verb, and contains no redundant words. Every sentence contributes: what it does, when to use it, and how to combine it with list_programmes.

  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 tool with no output schema or annotations, the description covers the purpose, usage context, return type, and key return fields. It also names the related list tool for discovery. However, it omits any mention of the 'brand' parameter and potential error behavior, leaving minor gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It clarifies that programmeId is the 'network programme id' and mentions what the full record contains, but it does not explain the 'brand' parameter at all, leaving ambiguity for one of the two required parameters.

  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 the specific verb 'Fetch' and clearly identifies the resource: a single programme on Tapfiliate by its network programme id. It distinguishes itself from siblings by being Tapfiliate-specific and contrasting with list_programmes.

  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?

  Explicit usage guidance is provided: 'Use this when you already know the programme id and need its full record...' and it names the alternative: 'pair with list_programmes when you need to discover the id first.' This clearly tells the agent when to use this tool vs. the list variant.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_travelpayouts_get_programmeA
  4.4/5.0
  Behavior4/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 clearly indicates a read-only fetch, specifies the return type ('Returns a single Programme'), and lists the content included ('commission, status, advertiser URL'). It does not mention error handling or network-specific requirements, but for a simple fetch operation the behavior is adequately disclosed.

  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 three sentences, each adding value: what it does, when to use it, and what it returns. It is front-loaded with the verb and avoids any redundancy or filler.

  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 single-parameter read tool without an output schema, the description covers the core context: purpose, usage, return type, and key fields. It lacks error/edge case behavior (e.g., not-found handling), but given the tool's simplicity and the pairing note with list_programmes, it is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides only the parameter name and type (programmeId, string) with no description, and schema coverage is 0%. The description adds the semantic context that the id is a 'network programme id', which is useful but does not provide format, example, or additional guidance. This partially compensates for the schema gap but leaves room for improvement.

  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 ('Fetch'), names the exact resource ('a single programme on Travelpayouts'), and identifies the key identifier ('network programme id'). It distinguishes itself from sibling get_programme tools by naming the network and from list_programmes by stating it returns a single record. This fully clarifies the tool's purpose.

  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 explicitly states when to use this tool ('Use this when you already know the programme id') and provides a clear alternative ('pair with list_programmes when you need to discover the id first'). This is direct usage guidance with no ambiguity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_travelpayouts_verify_authA
  4.4/5.0
  Behavior4/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 the return shape ({ok:true, identity?} or {ok:false, reason}) and notes the endpoint is minimal, giving the agent a clear expectation. It falls slightly short by not explicitly stating that the operation is read-only or has no side effects, though the context 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences: purpose, usage timing, and return format. It is front-loaded and every clause adds value, with no filler or 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 parameterless tool with no annotations and no output schema, the description covers purpose, when to use, return values, and its relationship to the diagnostic tool. This is fully sufficient for an agent to select and invoke the tool correctly.

  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 zero parameters and an empty schema. The description correctly implies no inputs are needed. Baseline 4 is appropriate for zero parameters since there is nothing to add beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool verifies Travelpayouts credentials via a minimal authenticated endpoint, naming both the action (verify) and the resource (configured credentials). It does not explicitly contrast with sibling verify_auth tools for other networks, but the network is named, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit guidance: use at session start, after key rotation, or when an auth error occurs. Also recommends pairing with affiliate_run_diagnostic for a full health check, which clarifies how this tool relates to an alternative and when to use it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tune_get_programmeA
  4.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 transparency burden. It discloses the return type ('single Programme') and key fields ('commission, status, advertiser URL'), but does not explicitly state read-only behavior, auth requirements, or error/not-found handling. 'Fetch' implies read, but this is implicit.

  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?

  Two sentences, no waste. The action, use case, return info, and alternative are all packed 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 one-parameter fetch tool with no annotations and no output schema, the description covers purpose, use case, return contents, and alternative. It omits error/not-found behavior and auth prerequisites, but these are less critical given the tool's simplicity.

  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 schema only provides a property name 'programmeId' with no description (0% coverage). The description compensates by explaining this is the 'network programme id' and instructing to use list_programmes when the id is unknown, giving operational context for sourcing the value. It does not specify format constraints, but the field is self-descriptive.

  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 opens with a specific verb ('Fetch'), resource ('a single programme on TUNE'), and access method ('by its network programme id'). It distinguishes itself from sibling list_programmes and other networks' get_programme tools by explicitly naming TUNE.

  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?

  It explicitly states 'Use this when you already know the programme id and need its full record,' and gives a direct alternative: 'pair with list_programmes when you need to discover the id first.' This is explicit when-to-use and alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_value-commerce_get_programmeA
  4.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 adds 'Returns a single Programme' and the fields included (commission, status, advertiser URL), which is useful. However, it does not disclose error behavior (e.g., what happens if the id is invalid), authentication requirements, or potential side effects. The word 'fetch' implies a read operation, but the description could be more explicit.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary action. Every clause adds value: the first sentence gives purpose, the second gives usage guidance and return type. No filler or 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?

  For a simple get-by-id tool with one parameter and no output schema, the description covers the main points: what it does, when to use it, the parameter meaning, and the return type. It lacks error or auth details, but given the tool's simplicity and the presence of a verify_auth sibling tool, this is a minor 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 only declares programmeId as a string with no description (0% coverage). The description compensates by specifying 'by its network programme id' and clarifies the id comes from list_programmes, making the parameter meaning unambiguous. It does not provide format details, but for a simple string id, this is sufficient.

  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 starts with 'Fetch a single programme on ValueCommerce by its network programme id,' which clearly states the action (fetch), the resource (ValueCommerce programme), and the specific scope (single programme by network id). It distinguishes itself from list_programmes by emphasizing 'single' and explicitly pairing with list_programmes for discovery.

  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 gives explicit usage guidance: 'Use this when you already know the programme id and need its full record' and 'pair with list_programmes when you need to discover the id first.' This directly states when to use this tool over the alternative list_programmes, fulfilling this dimension perfectly.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_admitad_get_programmeA
  4.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 the return type ('Returns a single Programme') and the kind of data included, but it does not address authentication requirements, potential errors, or rate limits. The 'Fetch' verb implies a safe read, yet a bit more context would be needed to be fully transparent.

  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 three sentences, all of which add value: what the tool does, when to use it, and what it returns. It is front-loaded with the core action and contains no filler or 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 tool with one parameter and no output schema, the description is complete: it states the action, the parameter's role, the return type, and the fallback discovery path. The lack of annotations is compensated by the explicit single-record scope and the mention of the fields included in the record.

  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?

  Schema description coverage is 0%, so the description must compensate. It clarifies that the parameter is the 'network programme id' and that the user should 'already know the programme id', adding meaning beyond the bare schema name. It stops short of providing a format example, but for a simple single string id this is sufficient.

  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 'Fetch a single programme on Admitad by its network programme id' with a specific verb, resource, and network. It distinguishes itself from siblings by specifying 'single programme' and naming the network, and it lists the returned fields (commission, status, advertiser URL).

  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 explicitly says 'Use this when you already know the programme id and need its full record' and advises pairing with list_programmes when the id is unknown. This gives both the when-to-use scenario and a named alternative, satisfying the top criterion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_admitad_verify_authA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It explains that the tool calls a minimal authenticated endpoint and discloses the return shape ({ok:true, identity?} or {ok:false, reason}), implying a non-mutating check. However, it does not mention potential side effects, auth failure behavior, or whether credentials are required to be pre-configured—though this is implied.

  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 long and front-loads the purpose, then use cases, then return format. Every sentence earns its place with no redundant information.

  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, no-output-schema tool, the description is complete. It covers what the tool does, when to use it, expected return values, and how it relates to a sibling tool (affiliate_run_diagnostic). No significant 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 tool has zero parameters, and the input schema is empty. The description does not need to explain parameter semantics; baseline for 0 parameters is 4. It correctly indicates the tool uses 'configured credentials' rather than taking parameters.

  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 verb ('Verify') and resource ('configured credentials for Admitad') and specifies the method ('calling a minimal authenticated endpoint'). It distinguishes itself from sibling verify_auth tools by naming the network explicitly (Admitad) and from general diagnostic tools by its focused action.

  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?

  Provides explicit use cases: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also suggests pairing with affiliate_run_diagnostic for a full health check, which acts as an alternative. However, it does not explicitly state when NOT to use this tool (e.g., when full diagnostics needed).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adrecord_get_programmeA
  4.5/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 burden. It does disclose that it returns a single Programme and lists included fields, but it does not explicitly state read-only behavior, authentication requirements, or error behavior for an invalid id. It adds some context but leaves 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?

  Two sentences, no fluff, and the main action is front-loaded. Every sentence provides useful information about what, when, and how to use the tool.

  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 single-fetch tool with one parameter and no output schema, this description is complete: it states the purpose, the exact parameter semantics, the return type, and the related tool flow. No critical details are missing.

  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 schema only defines programmeId as a string with no description. The description compensates by clarifying it is the 'network programme id' and advises using list_programmes to discover it first, which adds 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 clearly states the tool fetches a single programme by its network programme id, and specifies the content of the full record (commission, status, advertiser URL). This distinguishes it from list_programmes which discovers ids.

  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 gives explicit when-to-use guidance ('Use this when you already know the programme id and need its full record') and explicitly names the alternative for discovery ('pair with list_programmes when you need to discover the id first').

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_affilae_verify_authA
  4.5/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 behavioral burden. It discloses the return shape ({ok:true, identity?} or {ok:false, reason}) and indicates this is a minimal authenticated endpoint. It does not explicitly state that the operation is non-mutating or safe, but the verify semantics and minimal endpoint strongly imply that. The mention of pairing with run_diagnostic clarifies scope.

  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 three sentences: purpose, usage triggers, and return contract. It is front-loaded with the primary action, and every sentence adds distinct value without redundancy or fluff.

  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 tool with no output schema, the description provides all necessary context: purpose, when to use, what the response looks like, and how it relates to the diagnostic tool. Nothing important is missing.

  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 with zero parameters, and schema description coverage is 100% (vocabulary), so the baseline is 4. The description does not need to explain parameters since there are none, and it focuses instead on behavior and usage.

  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 tool verifies configured Affilae credentials via a minimal authenticated endpoint, with a specific verb ('verify'), resource ('configured credentials for Affilae'), and method. This distinguishes it from sibling verify_auth tools for other networks and from broader diagnostic 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 gives explicit usage contexts: start of a session, after key rotation, or when an auth error occurs. It also mentions pairing with affiliate_run_diagnostic for a full health check. However, it does not explicitly state when NOT to use it or directly compare to other network-specific verify_auth tools, so it falls just short of the full 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin_get_link_builder_quotaA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It clearly discloses what the tool returns (24-hour limit, current usage, raw Awin response) and implies a read-only fetch operation. It does not mention side effects, but none are expected for a quota check.

  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, front-loaded with the action, and includes purpose, usage context, and return value information. No unnecessary words.

  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 tool with no output schema, the description covers all necessary aspects: what it does, when to use it, and what it returns. It is complete enough for an agent to select and invoke correctly.

  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 schema has zero parameters, so no parameter explanations are needed. The description adds context about what the quota numbers mean, which is helpful. Baseline for 0 parameters is 4.

  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 ('Fetch') and a clear resource ('Awin Link Builder quota'), making the tool's purpose immediately obvious. It also distinguishes from sibling tools by focusing on quota retrieval rather than link generation or listing.

  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?

  Explicitly states when to use the tool: 'Use this before generating shortened links or diagnosing link-builder rate issues.' This gives clear context but does not name alternative tools or state when not to use, which would warrant a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_ebay_list_transactionsA
  4.5/5.0
  Behavior4/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 results include derived ageDays and that filtering is by window or programme, which adds behavioral context beyond a generic 'list'. However, it does not mention pagination or authentication requirements, preventing a 5.

  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 three concise sentences: purpose, usage triggers, and return info/pairing. Every sentence earns its place with no redundant content.

  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 9 parameters, no output schema, and no annotations, the description covers the core use cases but omits pagination behavior, default filtering when no parameters are supplied, and detailed parameter formats. These are clear gaps despite the overall good guidance.

  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% coverage, so the description compensates by mapping user intents to filters: 'window' implies from/to, 'specific programme' implies programmeId, and statuses map to status. It also hints at ageDays via the 'derived ageDays' mention. However, it does not explain pagination parameters (limit, cursor, offset) or that status can be an array.

  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 'List affiliate transactions ... on eBay Partner Network' with a specific verb and resource, and covers the statuses (commissions earned, pending, reversed, paid). It distinguishes from sibling list_transactions tools by naming the network and specifying the scope (window or programme).

  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 gives explicit example user queries ('what did I earn last month?', 'what's still pending?') and recommends pairing with get_earnings_summary for aggregates. This provides clear when-to-use guidance and references an alternative tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_everflow-advertiser_get_earnings_summaryA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses that the tool returns an EarningsSummary including oldestUnpaidAgeDays, which is behavioral information beyond the name. It also implies a read-only, summarizing operation. However, it does not mention pagination behavior, authentication requirements, or potential side effects, leaving some gaps for a complex tool with params like cursor and limit.

  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 three sentences, each earning its place. The first sentence states purpose, the second gives usage context with an example, and the third discloses a return field and suggests a complementary tool. It is front-loaded and free of fluff.

  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 no annotations and no output schema, the description has notable gaps. It does not explain pagination (limit/cursor), the meaning of brand, possible status values, or the exact structure of EarningsSummary beyond one field. While the main purpose and usage are clear, the lack of detail for a 9-parameter tool makes it only partially complete.

  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?

  Schema description coverage is 0%, so the description must compensate. It adds meaning for several parameters: 'across a date window' maps to from/to, 'breakdowns by programme' maps to programmeId, and 'by transaction status' maps to status. The mention of oldestUnpaidAgeDays hints at age-related fields like maxAgeDays/minAgeDays. However, it does not explain brand, limit, or cursor, leaving some major parameters undocumented.

  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 tool's function: 'Summarise earnings on Everflow (Advertiser) across a date window, with breakdowns by programme and by transaction status.' This gives a specific verb (summarise), resource (earnings on Everflow), and scope (date window, breakdowns). It also distinguishes from sibling tools by specifying 'Advertiser' and hinting at its summary nature versus list_transactions.

  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 when-to-use guidance: 'Use this when the user wants a single-figure answer plus context — e.g. "total earnings in Q1 with status split".' It also suggests pairing with list_transactions to drill into underlying records, effectively differentiating from the transaction list tool. This meets the bar for clear usage context and alternative identification.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_financeads_verify_authA
  4.5/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 transparency burden. It discloses the return contract ({ok:true, identity?} or {ok:false, reason}) and the nature of the call (minimal authenticated endpoint), which is valuable behavioral context beyond the schema. It does not explicitly state the operation has no side effects, but the read-only intent is strongly implied.

  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?

  Three sentences, each earning its place: the purpose, the usage timing, and the return shape with a pointer to the diagnostic sibling. It is front-loaded with the core purpose and contains zero fluff.

  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 tool with no parameters, no annotations, and no output schema, the description covers everything an agent needs: what it does, when to call it, what it returns, and how it relates to affiliate_run_diagnostic. Documenting the return shape is especially important given the absence of an output schema.

  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 zero parameters and the schema is empty (100% coverage trivially). Per the rubric, 0 params earns a baseline of 4; there is no parameter information for the description to add, and it correctly doesn't invent any.

  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 ('Verify') with a clear resource ('configured credentials for financeAds') and a concrete method ('calling a minimal authenticated endpoint'). It clearly distinguishes this tool from the many sibling _verify_auth tools for other networks by naming financeAds explicitly.

  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 explicit when-to-use scenarios ('at the start of a session, after rotating keys, or when another operation returns an auth error') and points to affiliate_run_diagnostic as an alternative for a full health check. It stops short of explicit when-not-to-use exclusions, so it earns a 4 rather than a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_impact-advertiser_get_programmeA
  4.5/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the burden of behavior disclosure. It clearly indicates a read operation ('Fetch', 'Returns a single Programme') and lists the returned fields (commission, status, advertiser URL). While it doesn't explicitly state 'read-only' or discuss error cases, the semantics of 'fetch' and 'get' adequately convey the non-mutating nature for this simple 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?

  Two sentences, no fluff. The first sentence states the action and identifier; the second provides usage guidance and return type. All information is front-loaded and essential.

  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?

  Despite being simple, the description covers the tool's purpose, when to use it, what it returns, and how to discover the ID if unknown. The low complexity of the tool (2 params, no output schema) means this description is sufficient for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It explains 'programmeId' as 'network programme id' but does not clarify the required 'brand' parameter at all. This leaves a gap for one of the two required parameters.

  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 'Fetch' and names the exact resource ('a single programme on Impact (advertiser)') along with the key identifier ('network programme id'). It clearly distinguishes this tool from sibling list_programmes and other network-specific get_programme tools.

  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?

  Explicitly states when to use: 'when you already know the programme id and need its full record.' It also names the alternative: 'pair with list_programmes when you need to discover the id first.' This provides clear context and exclusion.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_linkconnector_generate_tracking_linkA
  4.5/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 burden. It discloses the return type ('Returns a TrackingLink') and a workflow caveat, but it does not explicitly state whether the operation is side-effect-free or what authentication requirements exist. This is acceptable but leaves some ambiguity about the operation's 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?

  Three sentences, each earning its place: purpose, usage context, and return/workflow note. No filler or repetition. Front-loads the core action and keeps supporting details compact.

  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 tool with two simple parameters, no output schema, and no annotations, the description covers purpose, input semantics, expected return, and a prerequisite step. It fully prepares the agent to invoke the tool correctly and even signals how to avoid a common mistake (calling with an unconfirmed programmeId).

  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?

  With 0% schema coverage, the description must compensate. It maps both parameters to their roles: 'programme' and 'destination URL', and adds semantic guidance for programmeId by recommending confirmation via list_programmes. It gives enough context to understand the purpose of each parameter, though it lacks explicit formats or validation details.

  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 opens with a specific verb ('Generate') and resource ('tracking link on LinkConnector'), then names the two inputs (programme, destination URL). It clearly distinguishes this tool from the many other network-specific generate_tracking_link siblings by explicitly naming LinkConnector.

  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 explicitly states when to use it ('when the user wants to share an affiliate link to a specific product or page on a merchant they have joined') and provides a concrete prerequisite/pairing instruction ('pair with list_programmes to confirm the programmeId before calling'). This gives strong guidance for selection and preparation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_rakuten_get_programmeA
  4.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It implies a read-only operation via 'Fetch' and describes the return contents, but it does not explicitly state read-only behavior, authentication requirements, or error handling (e.g., if the id is invalid). This is adequate but lacks explicit safety or side-effect disclosure.

  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 three sentences with no redundant detail. It is front-loaded with the action and resource, then provides necessary context and guidance, all without waste.

  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?

  Given the tool's simplicity (one parameter, no output schema, no annotations), the description is complete: it states what is returned ('single Programme'), key fields ('commission, status, advertiser URL'), and how to obtain the input id. No critical information is missing for an agent to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides only 'programmeId' as a string with no coverage. The description compensates by clarifying it is the 'network programme id' and by directing users to list_programmes to discover the id. This adds meaningful semantic context beyond the bare 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 specifies the exact action ('Fetch a single programme on Rakuten Advertising'), the key parameter ('by its network programme id'), and the return type ('Returns a single Programme'). It also distinguishes from sibling list_programmes by stating the need to already know the id.

  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?

  Explicitly states when to use ('Use this when you already know the programme id and need its full record') and provides an alternative workflow ('pair with list_programmes when you need to discover the id first'). This gives clear guidance on tool selection relative to its sibling.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_scaleo_get_programmeA
  4.5/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description must carry the burden. It states that it returns a single Programme and hints at read-only via 'Fetch', but does not explicitly mention error behavior, auth requirements, or confirm that no side effects occur. This is adequate but not fully comprehensive.

  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?

  Three efficient sentences with no fluff. The action is front-loaded, usage guidance follows, and the alternative is clearly named. Every sentence earns its place.

  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 single-parameter fetch tool, the description covers purpose, usage, return type, and key fields. No output schema exists, so the description adequately explains the return value. The pairing with list_programmes completes the workflow 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?

  Schema coverage is 0% and there is no param description, but the description compensates by explaining the parameter is the network programme id and when you need it. It adds semantic meaning beyond the bare 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 clearly states the tool fetches a single programme on Scaleo by network programme id, listing specific fields returned (commission, status, advertiser URL). This distinguishes it from sibling list_programmes and other get_programme tools across networks.

  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?

  Explicitly says to use when you already know the programme id and need the full record, and pairs with list_programmes for id discovery. This gives clear when-to-use and alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_yieldkit_get_programmeA
  4.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 full behavioral disclosure burden. It clearly indicates a read operation ('Fetch') and return type ('Returns a single Programme'), and lists the fields returned. However, it does not explicitly confirm no side effects, authentication requirements, or error behavior (e.g., not-found cases), which would improve 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 two sentences long, front-loaded with the core purpose, and every sentence adds value. It avoids redundancy and is perfectly sized for the tool's simplicity.

  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?

  Given the low complexity, minimal schema, and absence of output schema, the description is complete for invocation: it explains what the tool does, when to use it, what the parameter means, what is returned, and how it relates to list_programmes. No critical information is missing for a get-by-id 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 schema contains only 'programmeId' with zero description coverage, but the description adds crucial meaning by identifying it as the 'network programme id'. This clarifies the source and scope of the identifier, going beyond the bare schema. Still, it does not provide format examples or additional constraints, so it does not fully compensate.

  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 tool fetches a single programme on Yieldkit by its network programme id, using the specific verb 'Fetch' and identifying the resource. It also distinguishes from sibling get_programme tools by specifying the network and the single-record scope.

  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 explicitly states when to use this tool ('when you already know the programme id and need its full record') and names the alternative for discovering the id ('pair with list_programmes'). This provides clear usage context and a direct alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_accesstrade_get_programmeA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It discloses that the tool returns a single Programme, lists the notable fields (commission, status, advertiser URL), and implies read-only via 'Fetch'. It does not mention authentication requirements or error behavior, which are minor gaps for a simple getter.

  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?

  Two sentences, no filler. The action is front-loaded, followed by usage condition, return value, and alternative. Every sentence 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 single-parameter getter with no output schema, the description covers purpose, when to use, and return content. Missing auth prerequisites and error states, but it is otherwise complete for the tool's simplicity.

  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?

  Schema coverage is 0%, so the description compensates by identifying the parameter as the 'network programme id' and indicating it can be obtained from list_programmes. This adds meaningful semantics beyond the schema's bare 'programmeId: string', though format constraints are omitted.

  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 'Fetch a single programme on AccessTrade by its network programme id', using a specific verb, resource, and scope. It distinguishes this from sibling network-specific get_programme tools and from list_programmes, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says 'Use this when you already know the programme id' and 'pair with list_programmes when you need to discover the id first', directly naming the alternative and the condition for use.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adcell_get_programmeA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of conveying behavior. 'Fetch' clearly indicates a read-only operation, and 'Returns a single Programme' describes the output. It adds context about the fields returned, but does not mention potential errors, authentication requirements, or rate limits, though these are less critical for a simple fetch-by-id.

  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?

  Two sentences with no filler: the first states the action and target, the second provides usage context and return info. Excellent front-loading and efficient use of words.

  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 tool with one parameter and no output schema, the description covers the key aspects: what it does, when to use it, what it returns, and how to discover the input. Missing details like error handling or auth are not critical for this simple fetch, making it fairly complete.

  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?

  Schema coverage is 0%, so the description must compensate. It clarifies that programmeId is the 'network programme id' and explains the caller should already know it, hinting it comes from list_programmes. This adds meaning beyond the raw schema, though it lacks format specifics or an example.

  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 tool fetches a single Adcell programme by its network programme id, naming the network and resource. It also distinguishes from siblings by specifying the data fields returned (commission, status, advertiser URL) and pairing with list_programmes, avoiding confusion with other networks' get_programme tools.

  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?

  It explicitly states when to use the tool ('when you already know the programme id and need its full record') and provides an alternative ('pair with list_programmes when you need to discover the id first'). This gives clear when-to-use vs. when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_affilae_get_programmeA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided, so description carries the burden. It clarifies this is a read operation ('Fetch') and specifies return contents (commission, status, advertiser URL). Does not mention failure behavior or auth, but for a simple getter this is reasonable 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?

  Three concise sentences, each with a distinct purpose: action, usage scenario, and pairing advice. No wasted words.

  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 no output schema, the description covers the return type and key fields, plus connection to list_programmes. It is complete for a single-parameter fetch tool; minor gap is no error-handling details, but not necessary for a straightforward getter.

  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 parameter programmeId is described as 'network programme id', adding meaning beyond the bare schema. The guidance to pair with list_programmes also indirectly explains how to obtain the id. Lacks format/examples, but with one parameter this is helpful.

  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 'Fetch a single programme on Affilae by its network programme id' – a specific verb, resource, and network. Clearly distinguishes from other get_programme tools via network name and single-record scope.

  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?

  Explicitly says 'Use this when you already know the programme id and need its full record' and contrasts with list_programmes for id discovery. This gives concrete when-to-use guidance and an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_affise_get_programmeA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of behavioral disclosure. It states the operation is a fetch, returns a single Programme, and gives sample fields, conveying a read-only, single-result behavior. It lacks error/edge-case details but for a simple retrieval this is sufficient.

  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?

  Three concise sentences, front-loaded with the action, with each sentence adding a distinct value: what it does, when to use, and what it returns/alternative. No filler or 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?

  For its simplicity, the description is complete: it explains the single input, the return type, example fields, and how to discover the id. Without an output schema, it covers the essential behavioral contract fully, though it does not mention potential failure modes or authentication requirements.

  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?

  Schema coverage is 0%, so the description must compensate. It does by calling the parameter 'network programme id' and explaining it is already known. This adds meaningful context beyond the bare schema property name, though it does not give format or validation details.

  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 action ('Fetch'), the resource ('a single programme on Affise'), and the method ('by its network programme id'). It also lists the fields returned (commission, status, advertiser URL), distinguishing it from generic get_programme siblings and from list_programmes.

  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?

  It explicitly says 'Use this when you already know the programme id' and directs to pair with list_programmes for discovery. This provides clear when-to-use guidance and names the alternative tool, exactly what the dimension asks for.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin-advertiser_report_publisher_decision_resultA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description goes well beyond the readOnlyHint annotation by explicitly stating the tool does nothing else: no network call, no browser action, no state change, and that it records a verified or verify_failed audit line. It also adds a key behavioral rule: never records applied/succeeded, success is only an observed outcome. 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 four sentences with no fluff. The first sentence states purpose, the second gives usage timing with verified semantics, the third discloses behavior constraints, and the fourth lists required params and the 'never records applied' rule. Every sentence earns its place and the most important info 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?

  Given the tool's simplicity and the readOnlyHint annotation, the description covers purpose, usage timing, behavior, and parameter semantics. The only notable gap is the absence of any mention of the tool's return value or how success/failure of recording is communicated, especially since there is no output schema. Still, the lack of a return-value description is minor for a recorder/audit tool that apparently just writes a line.

  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?

  Schema description coverage is 0%, so the description must compensate. It lists all required parameters (brand, programmeId, publisherId, decision, verified) and adds semantics for the non-obvious ones: decision is an enumerate of approve|decline, and verified=true/false maps to expected state presence. However, it does not explain the meaning of brand/programmeId/publisherId or the optional note, though those are reasonably self-explanatory from their names.

  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 tool records the observed outcome of a previously emitted Awin publisher approve/decline handoff, using a specific verb ('Record') and identifying the resource (observed outcome, audit arc). It distinguishes itself from siblings like propose_publisher_decision by explicitly positioning this as the post-handoff verification step, and from other report tools by scoping to publisher decisions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use the tool: after a consumer carries out the handoff and revisits the verify target, with verified=true/false depending on expected state. It explicitly ties to a previously emitted handoff, implying the alternative (propose) tool. However, it does not name the specific sibling tool or list exclusions, so it stops short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_cake_get_programmeA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description must carry the behavioral burden. It clearly communicates a fetch/read operation with no side effects, and discloses that the return value is a single Programme containing commission, status, and advertiser URL. It does not mention error behavior or authentication, but for a simple read-by-id tool this is a minor gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three concise sentences lead with the action and resource, then provide selection guidance, return behavior, and the paired list tool. 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?

  Given one required parameter, no output schema, and no annotations, the description covers the return shape, the fields returned, and the discovery workflow. It is complete enough for the agent to select and invoke the tool, though it could add not-found or error behavior.

  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 schema only defines one required string programmeId with zero description coverage. The description adds meaning by calling it the 'network programme id' and explaining that it can be discovered first via list_programmes, making the parameter's purpose and source clear.

  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: 'Fetch a single programme on CAKE by its network programme id.' It explicitly says the result is a single Programme, distinguishing it from list_programmes and from sibling get_programme tools for other networks.

  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?

  It states exactly when to use the tool: 'Use this when you already know the programme id and need its full record.' It also names the alternative and workflow: 'pair with list_programmes when you need to discover the id first.' This is explicit alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_cake_list_transactionsA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description adds useful behavioral details: it returns Transaction records, includes a derived ageDays field, and supports filtering by window or programme. It doesn't mention pagination or rate limits, but for a read-only list operation the provided context is substantive and helps set expectations for the return payload.

  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, front-loaded with the core action, and each clause adds value (statuses, filtering, user intents, return type, companion tool). No redundancy or filler exists; it is an ideal length for conveying essential information.

  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 tool with 9 optional parameters and no output schema, the description covers purpose, key filtering dimensions, return content, and relationship to a sibling aggregate tool. It omits pagination mechanics (cursor/offset/limit) and default behavior, which are relevant for a list endpoint, but overall it's sufficiently complete for an agent to select and invoke correctly.

  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?

  Schema descriptions are absent (0% coverage), so the description compensates by explaining the window (from/to), programmeId, status categories, and the derived ageDays field which relates to min/maxAgeDays. It does not explain cursor/limit/offset, but these names are relatively self-explanatory and the main functional parameters are semantically covered.

  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 it lists affiliate transactions on CAKE, enumerates status types (commissions earned, pending, reversed, or paid), and mentions filtering by time window or programme. It uses concrete user queries and distinguishes itself from get_earnings_summary, making the tool's purpose unmistakable.

  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?

  It explicitly provides when-to-use examples ('what did I earn last month?', 'what's still pending?') and directs to get_earnings_summary for aggregate totals, implying this tool is for transaction-level details. This is strong usage guidance that helps an agent choose between transaction listing and summary tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_connexity_get_programmeA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It states the return value ('Returns a single Programme') and lists included fields (commission, status, advertiser URL), and the verb 'Fetch' implies a read-only operation. It lacks error handling details, but for a simple getter this is sufficient.

  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?

  Two sentences, front-loaded with the core action, and no wasted words. The structure is clear and scannable.

  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 single-parameter read tool with no output schema, the description adequately covers purpose, usage, and return value. Minor omissions like error cases and authentication expectations are not critical for this simple getter.

  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?

  Schema description coverage is 0%, so the description must compensate. It adds meaning by clarifying the id is the 'network programme id' and explains how to obtain it via list_programmes. This goes beyond the raw schema property name.

  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 action ('Fetch a single programme on Connexity'), the resource (programme), and the key input (network programme id). It also distinguishes from sibling tools by specifying the exact use case and pointing to list_programmes for id discovery.

  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?

  Explicit guidance is provided: 'Use this when you already know the programme id and need its full record' and 'pair with list_programmes when you need to discover the id first.' This clearly differentiates when to use this tool versus the alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_daisycon_get_programmeA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It discloses that the tool returns a full record including 'commission, status, advertiser URL,' which is useful behavioral context. It implies a read operation with 'Fetch,' but doesn't explicitly mention side effects, auth requirements, or error handling. However, for a simple get, the transparency is good.

  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 three sentences, front-loaded with the primary purpose, then usage guidance, then return value and pairing. Every sentence earns its place; no fluff or 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 simplicity (one parameter, no output schema), the description is largely complete: it covers what it does, when to use it, what it returns, and how it relates to list_programmes. It lacks explicit error/edge-case details, but those are less critical for a straightforward fetch. Minor gap: no mention of what happens if the programme id is not found.

  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 schema provides only a 'programmeId' string with no description, so schema coverage is 0%. The description compensates by explaining the parameter is 'its network programme id' and contextualizing it in usage ('when you already know the programme id'). This adds meaning beyond the raw schema, though it doesn't specify the format (e.g., numeric or string).

  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 tool's function: 'Fetch a single programme on Daisycon by its network programme id.' It specifies the resource (programme), the network (Daisycon), and the identifier (network programme id). It also distinguishes from siblings by contrasting with list_programmes and mentioning it returns a single Programme.

  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?

  Explicitly states when to use: 'Use this when you already know the programme id and need its full record.' It also provides an alternative: 'pair with list_programmes when you need to discover the id first.' This is clear guidance on selection relative to sibling tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_effiliation_get_programmeA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the return type ('Returns a single Programme') and the fields included ('commission, status, advertiser URL'). While it doesn't explicitly state 'read-only' or error behavior, the verb 'Fetch' implies a read operation, and the response details add useful transparency beyond the name.

  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?

  Two sentences, front-loaded with the action, no filler. Every clause adds value, including the usage guidance and return details.

  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 low-complexity tool (1 param, no output schema, no annotations), the description is nearly complete. It covers what it fetches, when to use it, and how to find the id if missing. It doesn't cover error cases or authentication, but these are less critical for a simple fetch 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 schema has one parameter (programmeId) with no description (0% coverage). The description adds meaning by clarifying it is the 'network programme id', which distinguishes it from other identifiers. This directly maps to the parameter, providing context the schema lacks.

  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 'Fetch' with a clear resource ('a single programme on Effiliation') and identifies the key identifier ('by its network programme id'). It distinguishes from sibling tools by emphasizing 'single' and referencing list_programmes for discovery.

  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?

  Explicitly states when to use this tool ('when you already know the programme id') and provides a direct alternative ('pair with list_programmes when you need to discover the id first'). This gives clear decision guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_flipkart_get_programmeA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description discloses the return type ('Returns a single Programme') and key fields (commission, status, advertiser URL). It does not mention auth or error behavior, but for a fetch operation this is a minor gap, not a contradiction.

  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?

  Three sentences, front-loaded with the core verb and resource. Every sentence adds value: what it does, when to use it, and its output. 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?

  For a simple 1-parameter fetch tool, the description covers purpose, usage, return content, and relationship to sibling tools. It lacks error-case details or authentication prerequisites, but the simplicity reduces the need. Overall adequate for an agent to invoke correctly.

  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?

  Schema coverage is 0%, so the description is the only source for parameter meaning. It explains that programmeId is the 'network programme id' and clarifies how to obtain it ('discover via list_programmes'). This adds meaningful context beyond the bare schema, though an example or format would push it higher.

  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 tool fetches a single programme on Flipkart Affiliate by network programme id. It distinguishes itself from list_programmes by emphasizing 'single' and 'by its network programme id', making it unambiguous.

  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?

  Explicitly states when to use: 'when you already know the programme id and need its full record.' It also names the alternative: 'pair with list_programmes when you need to discover the id first.' This is clear guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_howl_get_programmeA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It discloses the read scope ('single programme'), the return shape ('Returns a single Programme'), and the record contents. It does not mention authentication or not-found behavior, but for a simple getter this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the core action, and no filler. The reference to list_programmes earns its place as it aids tool selection.

  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 read tool with no output schema, the description covers purpose, usage context, and return contents. It omits error/edge-case behavior, but that is a minor gap for this simple fetch 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 schema only defines programmeId as a bare string, so the description's clarification that this is the 'network programme id' and that the tool is for already-known IDs adds meaningful context. It does not provide format details, but the single parameter is well explained.

  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 ('Fetch') and resource ('a single programme on Howl'), names the identifier ('network programme id'), and lists the returned fields (commission, status, advertiser URL). It clearly distinguishes itself from sibling tools like list_programmes.

  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?

  Explicitly says when to use: 'when you already know the programme id and need its full record.' It also names the alternative path: 'pair with list_programmes when you need to discover the id first.' This is clear selection guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_impact-advertiser_get_contractA
  4.6/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Goes beyond the readOnlyHint annotation by specifying this is an API read (not a browser flow) and enumerating operations it does not perform (propose, apply, remove, execute browser flow). The 'experimental' status is also disclosed, which is useful context for an agent.

  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?

  Three sentences, each serving a distinct purpose: what it does, when to use it, and safety/exclusion info. No filler or 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?

  For a single-record fetch tool, the description covers purpose, usage sequence, and expected response content (status, payout terms, dates, raw payload). No output schema exists, so the description appropriately hints at what the response contains. It lacks error/edge-case details, but these are unlikely to be critical for a simple get.

  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 description names all three parameters but adds little semantic detail beyond the schema field names. It implies the identifiers come from a prior list_contracts call, which is helpful context, but does not define each parameter's format or source. With 0% schema coverage, this is a minimal pass.

  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 ('fetch') with a specific resource ('one read-only Impact contract') and identifies the key identifiers (brand, programmeId, contractId). It clearly distinguishes from list_contracts (single vs multiple) and from mutation tools (read-only vs propose/remove).

  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?

  Explicitly instructs to use 'after list_contracts' when the operator needs full status, payout terms, dates, and raw payload for a known contract. It also lists exclusions (does not propose, apply, remove, or execute a browser flow), giving clear when-not guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_involve-asia_get_programmeA
  4.6/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 explicitly says 'Returns a single Programme' and mentions the included fields, which gives a clear expectation of output. However, it does not mention error handling (e.g., what happens if the id is invalid) or authentication requirements, which would be useful but not critical for a simple fetch 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 two sentences long, front-loaded with the primary action ('Fetch a single programme'), and every sentence adds value. It includes return details and usage guidance without any filler or 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?

  The description is complete enough for a simple one-parameter tool: it states the input, the return type ('single Programme'), and the key fields. However, there is no output schema, and the phrase 'full record' is vague—it lists only three example fields, leaving the exact response shape undefined. It also omits error behavior, but given the low complexity, this is a minor 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 schema provides only the parameter name 'programmeId' with type string and required status, with 0% description coverage. The description compensates by calling it the 'network programme id' and noting that you should already know it, implying it comes from list_programmes. This adds meaning beyond the bare schema, though it does not specify format constraints (e.g., numeric vs alphanumeric).

  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 tool fetches a single programme by its network programme id, listing the fields returned (commission, status, advertiser URL). It uses a specific verb ('Fetch') and resource ('single programme'), and distinguishes itself from sibling tools like list_programmes. The name and description align perfectly.

  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 explicitly states when to use this tool ('when you already know the programme id') and pairs it with list_programmes for the alternative case ('when you need to discover the id first'). This provides clear context for choosing between sibling tools. The guidance is actionable and unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_kwanko-advertiser_get_programme_performanceA
  4.6/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 transparency burden. It discloses the data returned (clicks, conversions, gross sale, commission, by date) and the record type (ProgrammePerformanceRow), but does not detail authorization requirements, pagination behavior, or default date ranges. It is not misleading, but could be richer about output shape and edge cases.

  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 efficient and well-structured: first sentence states purpose and metrics, second sentence provides usage triggers, third sentence mentions return type and complementary tools. No filler or repeated schema information.

  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 has 8 parameters and no output schema or annotations, the description provides essential context: what it does, when to use it, what it returns, and how it relates to sibling tools. It lacks explicit details on pagination, date range defaults, and required vs optional parameters beyond the schema, but is otherwise complete for selection and invocation.

  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?

  Schema description coverage is 0%, so the description must add meaning to parameters. It does so implicitly by mentioning 'by date' (from/to), 'per-publisher' (publisherId), and 'brand's programme' (brand, programmeId), plus suggests list_media_partners for publisher IDs. However, it does not explain pagination parameters (limit, cursor, offset) or date format, which are left to the schema names alone.

  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 tool fetches per-publisher performance for the brand's programme at Kwanko (advertiser), listing specific metrics (clicks, conversions, gross sale, commission) and grouping by date. This distinguishes it from siblings like list_transactions and list_media_partners, which serve different purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly provides example user queries that indicate when to use this tool ('how is each publisher performing', 'show me the top-earning partners last month') and suggests alternatives for related tasks (list_media_partners for publisher IDs, list_transactions for drill-down). This gives clear when-to-use and when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_levanta_get_programmeA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It accurately describes the operation as a fetch, discloses that it returns a single Programme, and lists included fields (commission, status, advertiser URL). It could explicitly note non-mutating behavior, but the read-only nature is implied and the return semantics are well covered.

  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 three sentences long, front-loaded with the main action, and contains no redundant information. Every sentence adds value: what it does, when to use it, and how to discover the id if needed.

  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 simple single-parameter nature and absence of output schema, the description provides sufficient context: it states the return type, key fields, and the relationship to list_programmes. It could mention error cases or full output shape, but the essentials are covered.

  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 schema provides no description for programmeId (0% coverage), but the description clarifies that this is the 'network programme id', adding meaning beyond the bare schema. It also explains the context for when you would already know this id (via list_programmes), which helps correctly populate the parameter.

  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 tool 'Fetch a single programme on Levanta by its network programme id', identifying the specific verb, resource, and scope. It distinguishes from sibling get_programme tools by specifying the network (Levanta) and the identifier type.

  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?

  Provides explicit usage guidance: 'Use this when you already know the programme id and need its full record' and specifically recommends pairing with list_programmes when discovery is needed. This clearly indicates when to use this tool versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_linkconnector_list_transactionsA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses that the tool returns Transaction records including derived ageDays, and indicates the filterable statuses. It does not mention pagination, date formats, or explicit read-only behavior, but as a list operation the core behavior is clear. The absence of side effects is implicit.

  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?

  Three sentences, front-loaded with the core action, followed by usage examples and a return-value/companion-tool note. Every sentence provides useful information without fluff.

  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 9-parameter tool with no output schema or annotations, the description covers purpose, usage, key filters, and the relationship to get_earnings_summary. It is missing pagination guidance and exact value formats (e.g., date format, allowed status strings), but given the low complexity of a list operation, it is reasonably complete.

  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?

  Schema description coverage is 0%, so the description must compensate. It adds meaning for key parameters: 'within a window' for from/to, 'specific programme' for programmeId, the statuses for status, and 'ageDays' for minAgeDays/maxAgeDays. However, it does not explain limit, cursor, or offset, which are pagination-related and remain ambiguous.

  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 ('List') and clearly identifies the resource ('affiliate transactions'), the network ('LinkConnector'), and the scope ('within a window or for a specific programme'). It also lists the statuses (commissions earned, pending, reversed, or paid), which distinguishes it from sibling list_transactions tools for other networks.

  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?

  Explicit usage examples are given: 'what did I earn last month?', 'what's still pending?', or 'show me reversed sales'. It also instructs to pair with get_earnings_summary for aggregate totals, providing a clear alternative for a different use case. This is strong when-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_list_actionsA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The readOnlyHint annotation already signals safety, but the description adds meaningful behavioral detail beyond it: it explicitly states the tool never executes an action, drives a browser, or checks live auth, and that it returns an explicit unsupported-scope result for unknown network/brand. This goes beyond the annotation without contradicting it, though it doesn't discuss pagination or result-size limits.

  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?

  Three dense sentences deliver the core purpose, usage context, safety caveats, return type, and sibling alternatives. The structure front-loads the main function in the first sentence and progressively adds practical details, with no filler or repetition.

  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 description includes the return type (ActionMapEntry[]), lists the key fields returned, covers the unknown-network/brand edge case, and points to related tools. With no output schema, this is fairly complete, though a reader might still want a richer definition of ActionMapEntry and what 'local readiness' means.

  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?

  With 0% schema description coverage, the description compensates by naming all four filter dimensions (network, brand, effect, channel) and clarifying their role as filters. It also ties the effect/channel enums to the action categories and mentions the unsupported-scope result for unknown network/brand. However, it doesn't elaborate on value formats or the meaning of an omitted filter, leaving some ambiguity.

  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 opens with a specific verb and resource: "List the doing-surface actions...the configured adapters declare," and enumerates the output fields (channel, effect, default authority tier, local readiness). This clearly differentiates it from sibling network-specific tools like affiliate_list_networks and affiliate_run_diagnostic by naming exactly what it catalogs and what it does not do.

  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 gives explicit when-to-use guidance: "Use this to see what is possible and what it would cost in approvals before granting a write credential or planning a change." It also provides concrete alternatives, directing users to affiliate_run_diagnostic for live credential/endpoint health and affiliate_list_networks for network discovery, and states what the tool does not do (never executes an action, drives a browser, or checks live auth).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_lomadee_list_transactionsA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full burden. It discloses that results are Transaction records with a derived ageDays field, and implies filtering by date/programme/status. It does not mention pagination, rate limits, or auth requirements, but the provided behavioral context (derived field, record-level output) goes beyond minimal.

  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?

  Two sentences: first states the core action and scope, second gives usage examples, return field, and cross-reference to the summary tool. No filler, front-loaded, every sentence 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?

  Despite 9 parameters, no annotations, and no output schema, the description covers the main purpose, use cases, key filters, and a derived return field. Missing details like pagination defaults or exact status enum values are minor given the description's clarity, but the absence of output schema details prevents a perfect score.

  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?

  Schema coverage is 0%, so the description must compensate. It adds meaning to from/to (window), programmeId (specific programme), status (earned, pending, reversed, paid), and min/maxAgeDays (via derived ageDays). It does not explain limit/cursor/offset pagination semantics, leaving a partial gap.

  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 tool lists affiliate transactions on Lomadee, with specific scope (date window or specific programme) and status types (earned, pending, reversed, paid). It distinguishes itself from sibling tools by naming the platform and transaction type, and from get_earnings_summary by focusing on individual records.

  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?

  Explicit when-to-use cues are given: "what did I earn last month?", "what's still pending?", "show me reversed sales". It also advises pairing with get_earnings_summary for aggregates, providing an alternative/complementary tool. No misleading exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_optimise-media_get_programmeA
  4.6/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. It clearly indicates a read operation via 'Fetch', discloses the return type ('Returns a single Programme'), and enumerates key fields (commission, status, advertiser URL). It does not detail error behavior or auth requirements, but for a simple fetch-by-id tool this is solid behavioral 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?

  Two sentences, front-loaded with the core purpose, and every phrase earns its place. It covers purpose, usage context, return value, and relationship to a sibling tool without any 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?

  For a tool with one required parameter, no annotations, and no output schema, the description covers what it does, when to use it, what it returns, and how it relates to list_programmes. It is complete enough for an agent to select and invoke correctly, though error-handling specifics are absent, so a perfect 5 is not warranted.

  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 schema has one parameter, programmeId, with no description (0% coverage). The description compensates by explaining that this is the 'network programme id' and that it should already be known. This adds meaning beyond the bare schema, though it lacks format or example constraints.

  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 starts with a specific verb+resource+scope: 'Fetch a single programme on Optimise Media by its network programme id.' It clearly distinguishes from the sibling list_programmes tool by focusing on fetching a single record by ID, and explicitly contrasts itself with list_programmes.

  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?

  Provides explicit when-to-use guidance: 'Use this when you already know the programme id and need its full record.' It also tells the agent to pair with list_programmes when discovery is needed, giving a clear alternative and workflow.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerize_get_programmeA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It says 'Fetch' implying a read-only operation and specifies the return is 'a single Programme' with fields like commission, status, and advertiser URL. It doesn't mention auth requirements or error behavior, but for a simple get it's reasonably transparent.

  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?

  Three sentences with no filler. Front-loaded with the primary action, followed by usage guidance and return value. Every sentence 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 description covers what the tool does, when to use it, and what it returns. With no output schema, it gives a preview of fields. It lacks mention of error conditions or id validity, but for a one-parameter read tool it is sufficiently complete.

  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 schema has no parameter descriptions, but the description clarifies that programmeId is a 'network programme id' and suggests using list_programmes to discover it. This adds meaningful context, though it could specify format or source in more detail.

  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 ('Fetch') and resource ('single programme on Partnerize') with the mechanism ('by its network programme id'). It distinguishes from siblings by naming the network and explicitly contrasting with list_programmes.

  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 explicitly states when to use this tool ('when you already know the programme id and need its full record') and names the alternative (list_programmes) for discovering the id first. This is clear and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_profitshare_get_programmeA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries full burden. It conveys a read-only operation via 'Fetch' and discloses the return shape ('Returns a single Programme') and key fields (commission, status, advertiser URL). However, it does not mention error behavior or auth requirements, which would improve transparency further.

  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?

  Three concise sentences with no fluff. The main purpose is front-loaded, usage guidance follows, and the alternative pairing completes it. Every sentence adds value.

  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 (one param, no output schema, no annotations). The description covers what it does, when to use it, what it returns, and how to discover the ID if needed. It could mention not-found/error handling, but it is largely complete for a straightforward fetch-by-id 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?

  Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying 'network programme id', clarifying which identifier is expected. While it doesn't give format examples, for a single simple string parameter this is sufficient context beyond the raw 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 clearly states the tool fetches a single programme on Profitshare by its network programme id, using a specific verb and resource. It also distinguishes from sibling tools by naming the network and contrasting with list_programmes.

  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?

  Explicitly states when to use: 'when you already know the programme id and need its full record'. It also names the alternative: 'pair with list_programmes when you need to discover the id first'. This provides clear when/alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_resolve_brandA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It discloses the return shape ({brand, network, networkBrandId}) and the data source (brands.json), implying a local read operation. It doesn't mention edge cases or error behavior, but for a simple listing tool this is reasonably transparent.

  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 three sentences with no redundancy. It front-loads the core functionality, then gives usage context and return format. Every sentence adds meaningful information, making it optimally concise.

  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 is simple (one optional parameter, no output schema), the description covers purpose, usage timing, return format, and relationship to other tools. It lacks edge-case notes (e.g., empty results or invalid network slug), but is otherwise complete for an agent to select and invoke it correctly.

  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 one `network` parameter with no description, but the description explains it as an optional filter by network slug and provides examples ('Impact', 'Acme'). Since schema description coverage is 0%, this compensation is valuable, though it could be more precise about valid slug values.

  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 tool lists logical brands bound in brands.json, optionally filtered by network slug. This is a specific verb+resource combination that distinguishes it from the many per-network advertiser tools in the sibling list. Concrete examples like 'which brands do I have on Impact?' further clarify the exact intent.

  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?

  Explicitly says to use this tool when the user asks about bound brands, before invoking an advertiser-side tool. It also tells the agent to pair with per-network tools that require the `brand` argument, providing clear when-to-use and integration guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_shopmy_get_programmeA
  4.6/5.0
  Behavior4/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 this is a fetch operation (read-only by implication), returns a single Programme with key fields, and requires a known id. It does not cover error cases or auth prerequisites, but for a simple single-record lookup, the description provides adequate 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?

  Two sentences that are front-loaded with the core action, followed by return details and usage guidance. No wasted words; every sentence 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 simplicity (one required param, no output schema), the description covers what it does, when to use it, what it returns, and how to discover the id. It omits error behavior and authentication requirements, but these are not critical for a straightforward fetch 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 schema has one parameter (programmeId) with 0% coverage, so the description must compensate. It explains that the parameter is the network programme id and references list_programmes for discovery. This adds meaning beyond the bare schema, though it doesn't detail format or validation rules.

  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 tool fetches a single programme on ShopMy by its network programme id, with specific fields (commission, status, advertiser URL) and a return type of a single Programme. It distinguishes itself from list_programmes and from other networks' get_programme tools by specifying the platform.

  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?

  Explicitly says to use when you already know the programme id and need its full record, and pairs with list_programmes for discovery when the id is unknown. This provides clear when-to-use and an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_sovrn-commerce_get_programmeA
  4.6/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the transparency burden. It discloses that the operation is a read-only fetch returning a single Programme object, and clarifies that the id is the network's programme id. It does not cover error behavior, auth prerequisites, or rate limits, but for a simple retrieval tool the core behavior is adequately disclosed.

  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 three sentences, with no filler. The first sentence states the action, the second gives the usage trigger, and the third explains the return type and the discovery alternative. It is front-loaded and every sentence 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 single-parameter fetch, the description is nearly complete: it defines the output shape, parameter semantics, and relationship to list_programmes. Since there is no output schema, the explicit mention of 'returns a single Programme' and the listed fields adds real value. Minor omissions around not-found behavior or auth are not critical at this complexity level.

  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?

  Schema description coverage is 0%, but the description compensates by explaining that programmeId is the network's programme id and that it comes from a prior list_programmes call. It adds semantic origin information beyond the bare string schema. It does not provide format or validation details, but for a single self-named parameter this is sufficient.

  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 opens with a specific verb and resource: 'Fetch a single programme on Sovrn Commerce by its network programme id.' It clearly distinguishes from sibling get_programme tools by scoping to one network and one record, and from list_programmes by emphasizing 'single.' The mention of returned fields (commission, status, advertiser URL) makes the specific purpose concrete.

  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 explicitly states when to use this tool: 'Use this when you already know the programme id and need its full record.' It also names an alternative for discovery: 'pair with list_programmes when you need to discover the id first.' This gives clear, actionable selection guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_2performant_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of behavioral disclosure. It discloses the return shape ({ok:true, identity?} or {ok:false, reason}) and indicates the operation is a minimal network call. It could further mention absence of side effects or credential requirements, but the provided details are sufficient for an auth verification 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 three sentences, each delivering essential value: action, usage timing, return format and pairing with diagnostic. It is front-loaded with the core purpose, and 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.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema, the description is remarkably complete. It covers what the tool does, when to use it, what it returns, and how it relates to the broader diagnostic tool. The sibling context reinforces that this is a network-specific auth check, which the description already makes explicit.

  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 the baseline is 4. The description correctly does not invent parameter details; it explains the tool's purpose and return values, which is all that is needed when no parameters exist.

  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 opens with a specific verb ('Verify') and resource ('configured credentials for 2Performant'), clearly distinguishing it from the many other verify_auth tools by naming the network. It also states the mechanism ('calling a minimal authenticated endpoint'), leaving no ambiguity about what the tool does.

  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 explicitly lists when to use the tool: at start of session, after rotating keys, or after an auth error. It also names affiliate_run_diagnostic as the companion for a full health check, implicitly clarifying that this tool is a lighter, focused check and providing an alternative path.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_accesstrade_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full behavioral disclosure burden. It specifies the exact return shape ({ok:true, identity?} or {ok:false, reason}) and implies a lightweight, read-only operation. It doesn't explicitly confirm no side effects, but the nature of a credential verification makes this reasonable.

  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?

  Three focused sentences deliver purpose, usage timing, and return format without redundancy. The description is front-loaded with the core action and earns every word.

  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, no-output-schema auth checker, the description covers the operation, when to invoke it, and the response structure. It also contextualizes the relationship with the diagnostic tool, making it complete for an agent to select and call correctly.

  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 takes zero parameters, so the baseline is 4. The description adds context about 'configured credentials' but doesn't introduce parameter-level semantics because none exist. It appropriately avoids inventing fields.

  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 tool verifies AccessTrade credentials via a minimal authenticated endpoint. It distinguishes itself from the many sibling verify_auth tools by naming the specific network and from affiliate_run_diagnostic by framing this as a targeted check.

  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?

  Explicit guidance is provided: use at session start, after key rotation, or on auth errors. It also points to affiliate_run_diagnostic as the complementary option for a full health check, giving clear context for when to prefer this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adcell_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description takes on the transparency burden. It discloses that this is a minimal authenticated call, describes the return shape ({ok:true, identity?} or {ok:false, reason}), and implies non-destructive verification. It does not explicitly state read-only or side-effect-free, but the verify semantics cover this well.

  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?

  Three sentences, each with a distinct function: purpose/mechanism, when to use, and expected return plus complementary tool. No fluff or repetition.

  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 no output schema, the description covers the essential context: what it does, when to run it, what it returns, and how it relates to the broader diagnostic tool. Nothing important is missing.

  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 nothing to document. The 100% schema coverage baseline for zero params is 4, and the description correctly omits any parameter discussion.

  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?

  Description states a specific verb ('Verify') and resource ('configured credentials for Adcell'), and distinguishes from sibling verify_auth tools by naming the network. It also clarifies the mechanism ('minimal authenticated endpoint').

  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?

  Explicitly lists when to use: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' Also names the alternative/complement: 'pair with affiliate_run_diagnostic for a full health check,' providing clear usage boundaries.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_addrevenue_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden and does disclose the call to a minimal authenticated endpoint, the return value shape ({ok:true, identity?} or {ok:false, reason}), and failure mode. It does not explicitly state whether the operation is read-only or could have side effects like consuming rate limits, but the 'verify' nature and 'minimal endpoint' phrasing imply a safe, non-mutating check.

  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 three sentences, each serving a distinct purpose: purpose, when to use, and return value/complementary tool. There is no redundancy or filler, making it highly efficient and easy to parse.

  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?

  Given the tool has no parameters, no annotations, and no output schema, the description fully covers what the tool does, when to use it, and what it returns. It even points to a related tool for broader diagnostics, making it complete for an agent to select and invoke confidently.

  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 the description adds no parameter-level detail, but none is needed. Per the scoring rule, 0 parameters gets a baseline of 4. The description correctly focuses on behavior and usage instead of non-existent parameters.

  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 tool's purpose: verifying that configured Addrevenue credentials are valid via a minimal authenticated endpoint. This distinguishes it from the many sibling verify_auth tools by naming the specific network (Addrevenue) and specifying the exact action (verify).

  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?

  Explicit usage scenarios are provided: start of a session, after rotating keys, or when another operation returns an auth error. It also mentions pairing with affiliate_run_diagnostic for a full health check, giving a clear alternative/complement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adrecord_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description takes on the full disclosure burden. It explains the authentication-check behavior, the return shape ({ok:true, identity?} or {ok:false, reason}), and the fact that it calls a minimal endpoint. It implies a non-destructive read-only action but doesn't explicitly state this or mention rate limits; still, it provides solid behavioral context for a simple verification 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 two sentences, front-loaded with the core purpose, followed by usage timing and return values. Every sentence earns its place with no filler or repetition of schema information.

  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 tool with no output schema, the description covers all essential aspects: what it does, when to use it, what it returns, and a related tool for fuller diagnostics. This is complete enough for an agent to select and invoke without ambiguity.

  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 zero parameters, so the schema already fully covers the input surface. The description doesn't need to add parameter details, and the baseline of 4 applies for 0-param tools. It adds no confusion and correctly focuses on behavior.

  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 tool's function: verifying configured Adrecord credentials via a minimal authenticated endpoint. It uses a specific verb ('Verify') and resource ('credentials for Adrecord'), distinguishing it from sibling verify_auth tools for other networks.

  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?

  Explicit usage guidance is provided: use 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also mentions pairing with affiliate_run_diagnostic for a full health check, offering an alternative for broader diagnostics.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adservice_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the disclosure burden. It states the mechanism (calling a minimal authenticated endpoint) and returns structure ({ok:true, identity?} or {ok:false, reason}), giving sufficient transparency. It could explicitly state that it is read-only, but 'verify' and 'minimal endpoint' strongly imply no side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences: the first states purpose and mechanism, the second covers usage timing and return format. Every sentence earns its place with no redundancy or fluff.

  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 tool, this description is complete: it specifies what is verified, when to use it, what is returned, and how it relates to a broader diagnostic. No output schema exists, but the return shape is described. It fully covers the essentials.

  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 schema has zero parameters, so the baseline is 4. The description adds value by explaining the tool's purpose and return format, which goes beyond the empty schema. There are no parameters to document, so this is fully adequate.

  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 tool verifies Adservice credentials via a minimal authenticated endpoint, using a specific verb ('verify') and resource ('credentials for Adservice'). It distinguishes itself from sibling tools like affiliate_adtraction_verify_auth and operational tools like affiliate_adservice_list_programmes.

  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?

  Explicitly prescribes when to use ('at the start of a session, after rotating keys, or when another operation returns an auth error') and even suggests pairing with affiliate_run_diagnostic for a full health check. This provides clear context and differentiates from other verification tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_adtraction_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full burden. It discloses that the tool calls a minimal authenticated endpoint, returns {ok:true, identity?} or {ok:false, reason}, and implies a read-only verification behavior. It does not explicitly state 'read-only' or side-effect-free, but the verify nature and return shape provide sufficient transparency for this simple check.

  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?

  Two sentences, no wasted words. The first sentence front-loads the purpose; the second condenses usage timing, return shape, and pairing with a diagnostic tool. Every clause earns its place.

  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 verification tool with no output schema, the description is complete: it explains what it does, when to use it, what it returns (both success and failure shapes), and how it relates to affiliate_run_diagnostic. No critical gaps remain.

  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 zero parameters, so the baseline is 4. The description adds context about 'configured credentials' but no parameter details are needed. No additional explanation is required given the empty input 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 states a specific verb+resource: 'Verify the configured credentials for Adtraction are valid by calling a minimal authenticated endpoint.' It clearly distinguishes from siblings by naming 'Adtraction' and the verification purpose, separating it from the many other network-specific verify_auth tools.

  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?

  Provides explicit when-to-use guidance: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also mentions an alternative: 'pair with affiliate_run_diagnostic for a full health check', clarifying when a more comprehensive approach is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_affiliate-future_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It discloses the behavior (calling a minimal authenticated endpoint) and the return format ({ok:true, identity?} or {ok:false, reason}). It implies read-only verification but does not explicitly state it has no side effects, which would be a slight improvement.

  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 three concise sentences. The main purpose is front-loaded, followed by usage timing, return values, and a cross-reference. No word is wasted.

  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 zero-parameter verification tool with no output schema, the description is complete: it explains what it does, when to use it, what it returns, and how it relates to a sibling diagnostic tool. No critical information is missing.

  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 zero parameters, so the schema already fully covers parameter semantics. The description adds useful context by mentioning 'configured credentials,' clarifying that credentials are not passed as arguments but are pre-configured.

  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 tool verifies Affiliate Future credentials via a minimal authenticated endpoint, which is a specific verb+resource+scope. It distinguishes itself from other network-specific verify_auth tools by naming the network and the check action.

  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?

  Explicit usage guidance is provided: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also points to affiliate_run_diagnostic for a full health check, offering a clear alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_affise_verify_authA
  4.7/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 burden of behavioral disclosure. It explains the verification mechanism, the return payload shape ({ok:true, identity?} or {ok:false, reason}), and its limited scope via 'minimal authenticated endpoint,' but it doesn't explicitly state that no state changes occur, though 'verify' strongly 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact—two sentences covering purpose, usage timing, return format, and an alternative tool. There is no filler or repetition.

  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?

  Given the zero-parameter schema and lack of output schema, the description provides all necessary context: what it does, when to use it, what it returns, and how it relates to the diagnostic sibling. It is fully self-contained.

  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 zero parameters, so there are no parameter semantics to clarify. The description correctly focuses on behavior and return values.

  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 ('Verify') and identifies the exact resource ('configured credentials for Affise') and method ('calling a minimal authenticated endpoint'). It is clearly distinguished from sibling verify_auth tools by the Affise network designation.

  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?

  It explicitly states when to use: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also points to the alternative affiliate_run_diagnostic for a full health check, making the decision boundary clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_afilio_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations exist, so the description carries full burden. It discloses the mechanism ('minimal authenticated endpoint') and return shape ('{ok:true, identity?} or {ok:false, reason}'), covering success/error behavior. It doesn't mention side effects or rate limits, but for a verify tool this is sufficient.

  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?

  Two sentences: the first states the primary purpose and mechanism, the second covers usage timing and return format. Every word earns its place, no 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 0-param, no-output-schema tool, the description completely covers what it does, when to use it, what it returns, and related tools. It leaves no critical gaps for an agent to invoke it correctly.

  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 zero parameters, so the baseline is 4. The description correctly implies no input is needed beyond configured credentials, matching the empty 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 clearly states 'Verify the configured credentials for Afilio are valid by calling a minimal authenticated endpoint.' It uses a specific verb ('Verify') and resource ('configured credentials for Afilio'), and differentiates from sibling verify_auth tools by naming the network.

  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?

  Provides explicit when-to-use guidance: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also mentions pairing with affiliate_run_diagnostic as an alternative/complementary tool, offering clear context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_amazon-creators_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the operation's nature (a verification call to a minimal endpoint), implies read-only behavior, and specifies the return shape ({ok:true, identity?} or {ok:false, reason}). It does not explicitly state 'no side effects' but the purpose and phrasing make the safety profile clear.

  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?

  Three sentences, each serving a distinct purpose: statement of function, usage timing, and return format with a cross-reference. No wasted words, and the primary action is front-loaded.

  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, no-output-schema tool, the description covers purpose, when to use, return format, and a related tool. It gives the agent enough to select and invoke the tool correctly without needing additional 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 tool has zero parameters, so the baseline for parameter semantics is 4. The description adds context about the implicit 'configured credentials' being tested, which is useful beyond the empty schema. No parameter-specific details are needed.

  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 ('Verify') and resource ('configured credentials for Amazon Creators'), and clarifies it does so via a minimal authenticated endpoint. This clearly distinguishes it from sibling verify_auth tools for other networks and from affiliate_run_diagnostic.

  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?

  Provides explicit usage contexts: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also names a complementary alternative (affiliate_run_diagnostic) for full health checks, giving the agent clear when-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_avantlink_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Despite having no annotations, the description discloses the return shape ({ok:true, identity?} or {ok:false, reason}) and implies a lightweight, read-only verification via 'minimal authenticated endpoint.' It could add more about side effects or rate limits, but the core behavior is well communicated.

  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?

  Three tightly packed sentences—purpose, usage timing, and return format—with no wasted words. The description is front-loaded with the primary action and essential context.

  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 tool with zero parameters and no output schema, this description is fully sufficient: it covers what, when, and what to expect, plus how it relates to a broader diagnostic 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 is empty (no parameters), so there are no parameter semantics to explain. The description adds no parameter details because none are needed; the 0-parameter baseline of 4 is appropriate.

  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 action—'Verify the configured credentials for AvantLink are valid'—and the method ('calling a minimal authenticated endpoint'). It clearly distinguishes this from other verify_auth tools by naming AvantLink and from diagnostic tools by specifying its narrow function.

  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?

  It gives explicit scenarios for use: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also points to an alternative/complementary tool, affiliate_run_diagnostic, for fuller health checks.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin-advertiser_propose_publisher_decisionA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations include readOnlyHint=true, and the description reinforces this by stating 'it performs no network write itself.' It further discloses that the tool is experimental, emits a typed handoff, requires a human to carry it out, and returns an ApiGapResponse with no credentials. This goes well beyond the annotation and provides important 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 three sentences long, front-loaded with the core purpose, then providing the limitation, requirements, and return value. Every sentence adds value with no 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?

  The description covers the tool's purpose, the Awin API limitation, required inputs, the fact that it performs no network writes, and the return type (ApiGapResponse with constraints, verify target, and no credentials). Given the absence of an output schema, this is a complete and self-sufficient description.

  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?

  With 0% schema description coverage, the description compensates by naming the required parameters (brand, programmeId, publisherId, publisherName, decision), specifying the decision enum (approve|decline), and explaining that declineReason is optional for decline. It does not expand on the meaning of each parameter, but the names are self-explanatory and the conditional relationship is clarified.

  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 tool 'prepares a guided browser handoff to approve or decline a pending publisher application,' using a specific verb and resource. It also distinguishes itself from sibling tools by explaining that Awin has no public endpoint and that this emits a handoff rather than executing the decision.

  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 tool's context is clearly established: because Awin exposes no approve/decline endpoint, this is the mechanism to produce a handoff for a human to act on. It lists required parameters and the optional declineReason for decline decisions. It does not explicitly name alternative tools, but the usage scenario is unambiguous.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin_propose_applicationA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Annotations provide readOnlyHint=true, and the description reinforces this by stating 'it performs no network write itself.' It goes well beyond annotations by disclosing the external dependency on AWIN_PUBLISHER_ID with a config error, the return type (ApiGapResponse containing constraints, verify target, and inputs with no credentials), and the consumer's responsibility for surfacing terms. This is rich behavioral disclosure.

  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 six sentences, but every sentence earns its place: purpose, mechanism, required params, config dependency, output shape, and consumer responsibility. It is front-loaded with the core action and structured logically, making it easy for an agent to parse for key decision points.

  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?

  Given the tool's complexity (browser handoff, no public endpoint, config requirement, custom response type) and lack of output schema, the description covers all critical aspects: how it works, what inputs are needed, configuration error behavior, the shape of the ApiGapResponse, and the consumer's obligation for informed acceptance. It is sufficiently complete for an agent to invoke correctly and safely.

  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?

  Schema description coverage is 0%, so the description must compensate. It explicitly lists all parameters, marks required vs optional, and clarifies that 'brand' is 'a display label, not a binding.' However, it provides minimal semantics for advertiserId and programmeName beyond their names, leaving some ambiguity about acceptable formats or meaning. This is a solid improvement over the bare schema but not exhaustive.

  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 tool 'prepare[s] a guided browser handoff to apply to a brand's programme on Awin as a publisher.' This is a specific verb+resource+scope that distinguishes it from listing/getting programmes or generating tracking links. It also explains why this approach is needed due to Awin exposing no public publisher application endpoint.

  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 context that this is an experimental handoff for humans or an authorised consumer skill, and explains that no network write occurs. It implies this is the only way to apply because Awin lacks a public endpoint, but it does not explicitly name alternative tools or state when not to use it. Sibling tools like report_application_result or advertiser-side propose_publisher_decision are not mentioned as exclusions.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_awin_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the transparency burden. It discloses the return shape ({ok:true, identity?} or {ok:false, reason}) and describes the call as minimal, which implies low risk. It stops short of explicitly stating there are no side effects or rate limits, but for a simple auth check this is strong.

  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?

  Three sentences are dense and efficient. The first sentence states the action, the second gives usage triggers, the third describes the return value—no wasted words.

  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 no parameters and no output schema, the description fully covers the tool's behavior, invocation triggers, and expected response format. It is self-contained and complete for an agent to select and invoke correctly.

  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 zero parameters, so the baseline is 4. The description doesn't need to explain parameter semantics, and it correctly focuses on the operation and response.

  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?

  Description clearly states the tool verifies Awin credentials via a minimal authenticated endpoint. The specific verb 'verify' plus resource 'Awin credentials' distinguishes it from the many sibling verify_auth tools for other networks.

  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?

  Explicitly states when to use: at session start, after key rotation, or after auth errors. Also recommends pairing with affiliate_run_diagnostic for a full health check, providing clear contextual guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_belboon_verify_authA
  4.7/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. It discloses the response shape ({ok:true, identity?} or {ok:false, reason}) and implies a read-only check through the word 'verify,' but it does not explicitly state side effects or authorization requirements. The description adds useful behavioral context beyond the minimal schema, but could be more explicit about non-mutating 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 three sentences, each adding distinct value: purpose, usage timing, and return format with pairing advice. It is front-loaded with the primary action and contains no filler or redundant information.

  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, no-output-schema tool, the description is remarkably complete. It explains what the tool does, when to use it, what it returns, and how it relates to the diagnostic tool. There is no missing critical information that would prevent an agent from selecting and invoking this tool effectively.

  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 zero parameters, so the baseline is 4 per the rubric. The description mentions no parameter-related details, but none are needed. It does add context that the tool calls a 'minimal authenticated endpoint,' which indirectly implies no configuration beyond the already-set credentials.

  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 tool's function: 'Verify the configured credentials for Belboon are valid by calling a minimal authenticated endpoint.' It identifies the specific network (Belboon), the action (verify credentials), and the mechanism (minimal authenticated endpoint), effectively distinguishing it from the many other verify_auth sibling tools.

  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?

  Explicit usage scenarios are provided: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also recommends pairing with affiliate_run_diagnostic for a full health check, giving clear guidance on when to use this tool versus a related alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_cj_get_programmeA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It discloses the return type ('Returns a single Programme') and key fields (commission, status, advertiser URL), and 'Fetch' implies a read-only operation. It doesn't mention error cases or auth, but for a simple get, it provides sufficient 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 three sentences, all informative: purpose, usage, and return value/alternative. No filler or repetition. Front-loaded with the core action.

  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 single-fetch tool with one parameter and no output schema, the description covers what it does, when to use it, what it returns, and how to discover the id if needed. It is complete for an agent to select and invoke the 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 schema has 0% description coverage, but the description compensates by explaining that programmeId is the 'network programme id' and that it comes from list_programmes. This gives the parameter meaning beyond just its name and type.

  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 action: 'Fetch a single programme on CJ Affiliate by its network programme id.' It specifies the resource, network, and unique identifier, and it distinguishes from list_programmes by emphasizing 'single.' This is a specific verb+resource+scope.

  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 explicitly says when to use: 'Use this when you already know the programme id and need its full record.' It also names the alternative: 'pair with list_programmes when you need to discover the id first.' This is model use-case guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_cj_verify_authA
  4.7/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 and responds well by disclosing the return shape ('{ok:true, identity?} or {ok:false, reason}') and the nature of the call ('minimal authenticated endpoint'). It implies a read-only verification operation but does not explicitly state 'no side effects,' which could be slightly more transparent.

  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 three sentences, each adding distinct value: what it does, when to use it, and what it returns. It is front-loaded with the core purpose and contains no filler or redundant information.

  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?

  Despite having no output schema, the description includes return format and practical usage contexts. It sufficiently covers the tool's behavior for an AI agent to select and invoke it correctly, including how it fits into a broader health-check workflow.

  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 takes no parameters, so the input schema is empty with 100% coverage. The description correctly avoids inventing parameters and focuses on the configured credentials, which are presumably set elsewhere. Baseline 4 is appropriate for a zero-parameter tool.

  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 ('Verify') and resource ('configured credentials for CJ Affiliate'), clearly distinguishing it from the many sibling verify_auth tools for other networks. It also explains the mechanism ('calling a minimal authenticated endpoint'), leaving no ambiguity about what the tool does.

  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 explicitly provides when-to-use scenarios: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also names an alternative/complementary tool ('pair with affiliate_run_diagnostic for a full health check'), offering clear decision guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_clickbank_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description explains the mechanism ('calling a minimal authenticated endpoint'), the returned structure ('{ok:true, identity?} or {ok:false, reason}'), and the operation is clearly a read-only verification. With no annotations provided, it carries the transparency burden and does so well, though it does not explicitly state 'no side effects' or discuss rate limits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two compact sentences deliver purpose, usage timing, return format, and a pointer to an alternative. No fluff, front-loaded with the core purpose, and every phrase adds value.

  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 verification tool with no output schema, the description fully covers what the tool does, when to use it, what it returns, and how it relates to a broader diagnostic. No important information is missing.

  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 zero parameters, so the description need not explain parameter semantics. The empty schema is fully covered. The description implicitly clarifies that the tool uses pre-configured credentials, which is useful context 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 ('Verify') with a clear resource ('configured credentials for ClickBank') and method ('calling a minimal authenticated endpoint'). It clearly distinguishes from sibling verify_auth tools by network name and states exactly what it checks.

  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?

  Explicitly states when to use: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also names an alternative for more comprehensive health checks: 'pair with affiliate_run_diagnostic for a full health check,' which clarifies when this tool is not sufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_commission-factory_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It discloses the return format ('Returns {ok:true, identity?} or {ok:false, reason}') and implies a non-mutating check via 'verify' and 'minimal authenticated endpoint.' It does not explicitly state there are no side effects, but the semantics strongly suggest a safe read-only 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 three sentences, front-loaded with the purpose, then usage context, then return format. Every sentence adds value with 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?

  For a zero-parameter, no-output-schema tool, the description fully covers purpose, when to use, return behavior, and relationship to a sibling tool. It is self-contained and leaves no important 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?

  There are zero parameters and the schema is empty, so the description has nothing to clarify. The baseline for zero-parameter tools is 4; no further param information is needed.

  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: 'Verify the configured credentials for Commission Factory are valid by calling a minimal authenticated endpoint.' This clearly distinguishes it from sibling verify_auth tools by naming the network, and from other operations by specifying the verification action.

  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 explicitly states when to use the tool: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also distinguishes from affiliate_run_diagnostic by recommending pairing for a full health check, implying this is a focused auth check.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_connexity_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of disclosure. It states the call is minimal and authenticated, and details the exact return shape ({ok:true, identity?} or {ok:false, reason}). While it doesn't explicitly state read-only behavior, the nature of an auth verification tool implies no side effects, and the return contract is transparent.

  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?

  Three concise sentences, each adding value: purpose, usage triggers, and return format. The most critical information is front-loaded, with no filler or repetition.

  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 auth verification tool, the description is complete. It covers what it does, when to use it, what to expect in response, and how it relates to the diagnostic tool. The absence of an output schema is compensated by the explicit return format.

  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 zero parameters, so the baseline is 4. The description correctly focuses on the tool's behavior and return value rather than parameter details, which are irrelevant here.

  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 tool's function: verifying configured Connexity credentials via a minimal authenticated endpoint. It distinctly names the network (Connexity) and the action (verify auth), differentiating it from sibling verify_auth tools for other networks.

  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?

  Explicit guidance is provided on when to use: at session start, after rotating keys, or when an auth error occurs. It also recommends pairing with affiliate_run_diagnostic for a full health check, giving a clear alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_coupang-partners_get_programmeA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Without annotations, the description carries the burden of behavioral disclosure. It states the tool performs a fetch (read operation) and explicitly says it returns a single Programme, adding return-value context. However, it does not mention potential error conditions or data freshness, so a 4 is appropriate.

  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, front-loaded with the core purpose, and every sentence contributes meaning. There is no redundancy or wasted text.

  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 fetch tool without an output schema, the description covers return value, usage context, and relationship to list_programmes. It provides enough information for an agent to select and invoke the tool correctly without further clarification.

  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?

  With 0% schema description coverage, the description compensates by identifying the parameter as 'network programme id', which adds meaning beyond the bare schema type. It also clarifies that the id is the key for retrieving a full record. For a single parameter, this is sufficient but not exhaustive.

  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 tool fetches a single programme on Coupang Partners by its network programme id, which is a specific verb+resource. It also distinguishes itself from sibling tools like list_programmes by specifying the need for a known id and listing the record fields.

  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?

  Explicit guidance is given: 'Use this when you already know the programme id and need its full record.' It also names an alternative (list_programmes) for id discovery, providing clear context for when to use this tool versus alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_coupang-partners_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the full burden. It transparently discloses the return contract ('{ok:true, identity?} or {ok:false, reason}'), indicates it calls a minimal endpoint, and implies no side effects. It stops short of explicitly stating non-destructiveness, but the phrase 'minimal authenticated endpoint' strongly suggests it, and the return format is well-specified.

  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?

  Three sentences each serve a distinct purpose: what it does, when to use it, and what it returns. No filler or redundant information; the structure is front-loaded with the primary purpose and immediately gives actionable usage guidance.

  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 verification tool with no output schema, the description fully covers purpose, usage timing, and return shape. It also makes the relationship to affiliate_run_diagnostic clear, and the sibling context of many network-specific verify_auth tools is handled by the explicit 'Coupang Partners' naming. The description is complete for the tool's complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description appropriately omits parameter details because none exist, and the input schema confirms no parameters. No compensation needed.

  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 a specific verb ('Verify'), the resource ('configured credentials for Coupang Partners'), and the mechanism ('calling a minimal authenticated endpoint'). It distinguishes itself from other network verify_auth tools by naming the network, and from affiliate_run_diagnostic by positioning itself as the auth-specific check.

  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?

  Explicit when-to-use guidance is provided: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also mentions pairing with affiliate_run_diagnostic for a full health check, offering a clear alternative and broader context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_daisycon_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the burden. It discloses the return shape ({ok:true, identity?} or {ok:false, reason}) and describes the call as 'minimal authenticated endpoint,' implying no side effects. It could have explicitly stated read-only/safe behavior, but the nature of a verify operation makes this adequate.

  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?

  Three sentences, front-loaded with the verb and purpose, no filler or repetition. Every clause adds value: what it does, when to use it, what it returns, and how it relates to a complementary tool.

  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, no-output-schema verify tool, the description is complete. It states purpose, usage timing, return format, and relationship to the diagnostic tool. Nothing essential is missing.

  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, so the baseline is 4. The description adds no parameter details (there are none to add), and the schema already reflects an empty parameter set. Nothing further is needed.

  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 ('Verify') and resource ('configured credentials for Daisycon') and clearly differentiates from numerous sibling verify_auth tools by naming the network and the action. It also explains the mechanism ('calling a minimal authenticated endpoint').

  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?

  Explicit when-to-use guidance is provided: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also points to an alternative/complement: 'pair with affiliate_run_diagnostic for a full health check.'

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_ebay_verify_authA
  4.7/5.0
  Behavior4/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 the return shape ({ok:true, identity?} or {ok:false, reason}) and that the call is minimal, which is transparent for a verification tool. It stops short of explicitly stating non-destructiveness or potential side effects, but the semantics imply a safe 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?

  Three sentences, each earning its place: purpose, usage timing, and return value with a note on pairing. Front-loaded and free of wasted words.

  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 verification tool with no output schema, the description is complete: it explains the operation, when to invoke it, what to expect as output, and how it relates to the diagnostic tool. No gaps are evident.

  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 zero parameters and the schema is empty, so the baseline for this dimension is 4. The description appropriately focuses on behavior rather than inputs, and no parameter documentation is needed.

  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 tool's purpose: verifying configured credentials for eBay Partner Network via a minimal authenticated endpoint. It distinguishes from sibling tools by naming the specific network and contrasting with the broader health check (affiliate_run_diagnostic).

  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?

  Explicitly specifies when to use: at session start, after rotating keys, or when another operation returns an auth error. Also names an alternative/complementary tool (affiliate_run_diagnostic) for a full health check, providing clear context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_eduzz_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden of explaining behavior. It discloses the return shape ({ok:true, identity?} or {ok:false, reason}) and mentions calling a minimal authenticated endpoint, implying a lightweight network operation. It doesn't explicitly state side effects or safety (e.g., non-destructive), but for an auth verification tool the return format and purpose are the most critical behavioral traits.

  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, front-loaded with purpose, followed by usage timing and return format. No filler or repetition; every sentence contributes distinct information.

  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 tool with no output schema, the description is remarkably complete: it explains the mechanism, return value, when to use it, and even references a sibling tool for a more comprehensive check. There are no obvious gaps given the tool's simplicity.

  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 zero parameters and an empty schema, so schema coverage is complete. The description adds useful context by noting that it checks 'configured credentials,' implying the tool uses pre-existing configuration rather than taking input. This adds meaning beyond the empty 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 clearly states the tool's purpose: verifying that configured Eduzz credentials are valid via a minimal authenticated endpoint. It uses a specific verb ('verify') and resource ('configured credentials for Eduzz'), and the naming convention distinguishes it from sibling verify_auth tools for other networks.

  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 explicitly provides when to use the tool: at session start, after rotating keys, or when another operation returns an auth error. It also names a complementary tool (affiliate_run_diagnostic) and indicates this tool is for quick auth verification while the diagnostic is for full health checks, offering clear context vs alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_effiliation_verify_authA
  4.7/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 transparency burden. It discloses that the tool calls a 'minimal authenticated endpoint' and specifies the return shape ({ok:true, identity?} or {ok:false, reason}). It implies a non-mutating verification check but does not explicitly state read-only status or describe error/rate-limit 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?

  Three sentences, each earning its place: purpose, usage timing, and return behavior plus relation to run_diagnostic. The core purpose is front-loaded, and there is zero waste.

  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 tool with no annotations and no output schema, the description covers what it does, when to use it, and what it returns. This is sufficient for confident invocation and fully compensates for the absent structured metadata.

  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, giving a baseline of 4. The description usefully notes that the tool acts on 'configured credentials,' indicating that the agent need not supply credentials at runtime and that the environment handles them.

  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 'Verify the configured credentials for Effiliation are valid by calling a minimal authenticated endpoint' — a specific verb+resource+mechanism. The network-specific naming and explicit mention of Effiliation distinguishes it clearly from sibling verify_auth tools for other networks, and the return-value note differentiates it from the broader affiliate_run_diagnostic.

  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 explicitly says 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also points to affiliate_run_diagnostic as the companion for a full health check, providing clear when-to-use context and a named alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_ehub_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries full burden. It explains the tool calls a minimal authenticated endpoint and returns ok/identity or ok/false/reason. It implies read-only behavior through 'verify' language, but does not explicitly mention side effects, rate limits, or permissions; for a verification tool these are less critical.

  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?

  Two sentences convey purpose, usage scenarios, return values, and relationship to the diagnostic tool. Every sentence earns its place with no 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 auth verification tool with no output schema, the description fully covers what it does, when to use it, and what it returns. It also links to the broader diagnostic tool, making it complete for selection and invocation.

  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 zero parameters, so the baseline is 4. The description appropriately does not attempt to describe parameter semantics; the empty schema is self-explanatory.

  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 tool verifies configured eHUB credentials via a minimal authenticated endpoint, using a specific verb and resource. It distinguishes itself from sibling verify_auth tools by explicitly naming eHUB.

  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?

  Provides explicit when-to-use scenarios: start of session, after key rotation, or on auth error. It also suggests pairing with affiliate_run_diagnostic for a full health check, serving as an alternative or complement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_everflow_get_programmeA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full burden. It clearly implies a read-only fetch ('Fetch', 'Returns a single Programme') and adds the data fields included (commission, status, advertiser URL). It does not mention error behavior or authorization, but for a simple get with no side effects, this is strong context beyond the name.

  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?

  Three concise sentences, front-loaded with the action, each adding value. No filler or repetition. The pairing with list_programmes is a compact, high-value addition.

  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?

  The tool is simple (1 param, no output schema), and the description covers what it returns, the input semantics, and how it fits with list_programmes. It is complete for an agent to select and invoke correctly without further information.

  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?

  Schema description coverage is 0%, so the description must compensate. It clarifies that the parameter is the 'network programme id', adding meaning beyond the bare property name 'programmeId'. It does not give format examples, but for a single obvious string parameter, this is adequate compensation.

  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 'Fetch' with a clear resource: 'a single programme on Everflow by its network programme id.' It distinguishes from sibling get_programme tools by naming the network and from list_programmes by explicitly targeting a single record. This is precise and unambiguous.

  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?

  It provides explicit usage context: 'Use this when you already know the programme id and need its full record' and gives a clear alternative flow: 'pair with list_programmes when you need to discover the id first.' This exactly satisfies when-to-use vs. alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_everflow_verify_authA
  4.7/5.0
  Behavior4/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 the call type ('minimal authenticated endpoint'), the return contract ('{ok:true, identity?} or {ok:false, reason}'), and expected use cases. It does not explicitly state that the operation is read-only with no side effects, but the 'minimal authenticated endpoint' wording implies a safe check.

  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 compact and well-structured: one sentence for purpose, one for when to use, one for return format and complementary tool. Every sentence contributes useful information with no 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 zero-parameter verification tool, the description covers the purpose, usage triggers, return value, and pairing with affiliate_run_diagnostic. It is complete enough for an agent to invoke the tool correctly without additional 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 tool has 0 parameters, and the schema is empty, so the baseline is 4. The description adds context by referencing 'configured credentials' but does not need to explain parameter behavior since none exist.

  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 tool 'Verify the configured credentials for Everflow are valid by calling a minimal authenticated endpoint.' It has a specific verb ('verify'), a specific resource ('credentials for Everflow'), and the method. Among many sibling *_verify_auth tools, naming 'Everflow' directly distinguishes it.

  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?

  Explicit usage guidance is provided: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also directs to affiliate_run_diagnostic for a full health check, clarifying when this tool is the right choice versus an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_flexoffers_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the burden. It discloses the return contract ({ok:true, identity?} or {ok:false, reason}) and mentions the endpoint is minimal and authenticated. It could explicitly state that this is a read-only/safe operation, but the 'verify' verb and minimal endpoint imply this. The return shape adds useful behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences pack in purpose, usage scenarios, return format, and tool relationship. Every sentence earns its place, and the most critical information is front-loaded. No filler or 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 tool with no parameters and no output schema, the description is fully self-sufficient. It explains what the tool does, when to use it, what it returns, and how it relates to the diagnostic tool, giving the agent enough context to invoke it correctly.

  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 zero parameters and an empty schema, so there are no parameter semantics to explain. The description correctly omits param details. Baseline of 4 is appropriate for a no-parameter tool.

  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 opens with a specific verb 'Verify', names the resource 'configured credentials for FlexOffers', and specifies the mechanism 'minimal authenticated endpoint'. It clearly distinguishes from sibling verify_auth tools by naming FlexOffers and differentiates from health-check tools by referencing affiliate_run_diagnostic.

  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?

  Provides explicit when-to-use guidance: start of a session, after rotating keys, or when another operation returns an auth error. It also contrasts with affiliate_run_diagnostic by recommending pairing with it for a full health check, making the tool's scope clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_flipkart_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description provides key behavioral details: it performs a lightweight authenticated call and returns a structured success/failure response. It does not disclose potential side effects (though verification is inherently non-mutating) or rate limits, but the core behavior is transparent enough for this simple 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?

  Three sentences, each serving a distinct purpose: verb+resource, usage timing, and return format with an alternative. No filler or redundancy; the most actionable info is front-loaded.

  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 verification tool with no output schema, the description fully covers the purpose, the exact conditions to use it, and the expected response shape. It also situates it relative to the diagnostic sibling. No significant gaps remain.

  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 zero parameters, so there are no semantic details to add. The description clarifies that the credentials being checked are the 'configured credentials', which gives context beyond the empty schema. This matches the baseline 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 uses a specific verb ('Verify') and resource ('configured credentials for Flipkart Affiliate'), and explains the mechanism ('calling a minimal authenticated endpoint'). It clearly distinguishes this from sibling verify_auth tools for other networks and from the broader affiliate_run_diagnostic, which it explicitly contrasts for full health checks.

  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?

  Explicit guidance is given: use at the start of a session, after rotating keys, or when another operation returns an auth error. It also points to affiliate_run_diagnostic as the complement for a full health check, providing an evident when-to-use vs. alternative distinction.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_get_client_strategyA
  4.7/5.0
  Behavior5/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 the return shape, that targets are already parsed, that parseErrors must be reported and excluded from verdicts, and that the context is advisory only and never authorises a write. This is rich behavioral context beyond what a schema would provide.

  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 and front-loaded with purpose and usage. The return structure is dense but every clause adds necessary operational detail (e.g., parseErrors handling, advisory-only nature). No wasted words.

  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?

  Despite no output schema, the description fully documents the return values and their semantics, including nested objects. It also gives usage context and caveats. For a read-only tool with one parameter, this is complete enough to invoke and handle the result correctly.

  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?

  Schema coverage is 0% for the 'brand' parameter, but the description compensates by explaining it as 'the brand slug from brands.json'. This gives the agent the exact source and format for the parameter. It could go further with examples, but for a single parameter this is sufficient.

  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 tool 'Read[s] the advisory strategy and KPI context an operator has recorded for one brand'. The verb 'Read' plus the specific resource (strategy/KPI context per brand) distinguishes it from sibling tools like affiliate_set_client_strategy (write) and affiliate_list_client_strategies (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 explicitly says when to use it: 'Use this before producing a report so a delta can be judged against the client's own plan'. It provides clear context but does not explicitly name alternative tools or state when-not-to-use scenarios, so it falls short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_hotmart_verify_authA
  4.7/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. It discloses that the tool performs a network call to a minimal endpoint and describes the return shape ({ok:true, identity?} or {ok:false, reason}), which is valuable. It doesn't mention potential side effects, latency, or rate limits, but for a verify_auth tool this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences: the first states purpose and mechanism, the second covers usage and return value. Every sentence earns its place with no fluff or repetition, making it highly efficient.

  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 zero-parameter tool with no output schema, the description covers purpose, usage, and return format. It even suggests pairing with affiliate_run_diagnostic for more thorough health checks, making it complete for an agent to decide when and how 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 tool has zero parameters, so schema coverage is 100%. Baseline for 0 params is 4. The description adds no parameter information because none is needed; the schema already indicates an empty object.

  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 tool verifies Hotmart credentials by calling a minimal authenticated endpoint. It names the specific network (Hotmart) and uses a specific verb ('verify'), distinguishing it from other network-specific verify_auth tools like affiliate_adtraction_verify_auth.

  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?

  Provides explicit 'when to use' scenarios: start of a session, after rotating keys, or when another operation returns an auth error. Also names a complementary tool (affiliate_run_diagnostic) for a full health check, giving the agent clear context for choosing this tool vs alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_howl_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of behavioral disclosure. It explains the call type (minimal authenticated endpoint), the return shape ({ok:true, identity?} or {ok:false, reason}), and that it operates on preconfigured credentials. It does not detail side effects or failure modes beyond the reason field, but for a verification tool this is sufficient.

  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?

  Three concise, front-loaded sentences. Each sentence delivers distinct value: purpose, usage timing, return result and relationship to diagnostic. No redundant or filler content.

  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, no-output-schema verification tool, the description is remarkably complete. It covers what, when, response format, and points to affine_run_diagnostic for broader health checks. No critical context is missing.

  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 zero parameters, so the schema is trivially complete. The description adds meaning by clarifying that the credentials are 'configured' in the system, implying no runtime input is needed. This meets the baseline 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 tool's purpose: verifying Howl credentials via a minimal authenticated endpoint. It distinguishes itself from sibling verify_auth tools by naming Howl, and from the broader diagnostic tool by showing a complementary relationship.

  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?

  Explicitly provides usage contexts: at the start of a session, after rotating keys, or when another operation returns an auth error. It also references affiliate_run_diagnostic as the full health check option, giving clear guidance on when to pair with it.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_impact_get_programmeA
  4.7/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 for behavioral disclosure. It effectively communicates the return type ('Returns a single Programme') and key fields (commission, status, advertiser URL), giving the agent a solid understanding of the operation. It could mention error behavior or authentication, but for a simple read tool this is sufficient.

  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 concise sentences with no wasted words. The first sentence states the core purpose, and the second provides usage guidance and return expectations. Excellent structure.

  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 tool with a single parameter and no output schema, the description is remarkably complete. It covers what the tool does, when to use it, what it returns, and how it relates to a sibling tool. No critical information is missing for an agent to select and invoke this tool correctly.

  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 schema has only one parameter (programmeId) with no description, and schema coverage in the description is 0%. However, the description explains the meaning of the parameter ('by its network programme id'), which adds value beyond the bare schema. This compensates for the low 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 clearly states the action (Fetch a single programme), the specific resource (on Impact), and the key input (by its network programme id). It also distinguishes from siblings by referencing Impact and the pairing with list_programmes, making it unambiguous which tool to select.

  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 explicitly says 'Use this when you already know the programme id and need its full record' and advises pairing with list_programmes when discovery is needed first. This provides clear when-to-use and alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_impact_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the return payload ({ok:true, identity?} or {ok:false, reason}) and implies a read-only, non-mutating check via 'verify' and 'minimal authenticated endpoint.' However, it does not explicitly state there are no side effects or describe potential errors beyond the reason field, leaving some gaps for a no-annotation scenario.

  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 three sentences, each serving a distinct purpose: what it does, when to use it, and what it returns. It is front-loaded with the action and contains no redundant wording. Every sentence earns its place, 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.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter verification tool with no output schema, the description covers the essential aspects: purpose, method, usage timing, return value on success and failure, and the relationship to a diagnostic tool. It is complete enough for an agent to select and invoke this tool with confidence, and it explains the edge cases of credential rotation and auth errors.

  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 zero parameters and the schema coverage is 100% (vacuously). The description adds useful context by referencing 'configured credentials,' clarifying that the tool operates on pre-existing configuration rather than inputs. The baseline for 0-param tools is 4, and the description meets it without needing to explain individual parameters.

  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 ('Verify the configured credentials for Impact are valid') and the method ('by calling a minimal authenticated endpoint'). It distinguishes itself from sibling verify_auth tools by naming Impact, and it mentions the return format, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use guidance: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also references the complementary tool affiliate_run_diagnostic for full health checks, giving an implicit alternative and context for when this tool is insufficient.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_indoleads_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the return shape ({ok:true, identity?} or {ok:false, reason}), the minimal endpoint call, and the complementary diagnostic use. It doesn't explicitly say there are no side effects, but the verb 'verify' and minimal-endpoint description imply a safe read-only check.

  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?

  Three sentences, each earning its place: 'what' in the first, 'when' in the second, and 'output/alternative' in the third. No filler, tautology, or 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 parameterless verification tool with no output schema, the description covers all essential aspects: purpose, trigger conditions, return value format, and relationship to the diagnostic tool. The return shape is documented in prose, mitigating the lack of an output schema.

  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 schema has zero parameters and 100% coverage by default. The description adds context by explaining the tool uses pre-configured credentials, which is relevant because there are no parameters to pass. Baseline for 0 params is 4.

  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 action (Verify) on a specific resource (configured credentials for Indoleads) via a minimal authenticated endpoint. Clearly distinguishes from sibling verify_auth tools for other networks and from affiliate_run_diagnostic.

  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?

  Explicitly lists when to use: at session start, after rotating keys, or after an auth error. Also points to affiliate_run_diagnostic as the alternative for a full health check, providing both timing and exclusion guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_involve-asia_verify_authA
  4.7/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, and it delivers useful behavioral details: it calls a minimal authenticated endpoint and returns either {ok:true, identity?} or {ok:false, reason}. This discloses the response shape and effect (verification). It could add explicit side-effect safety (e.g., 'no data is modified'), but for a verify operation the behavior is adequately transparent.

  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, front-loaded with the primary action, followed by usage timing, return format, and a pointer to a related tool. Every sentence adds value; no filler or repetition of schema details. It is concise and well-structured.

  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?

  Given the tool's simplicity (0 params, no output schema), the description is complete: it states what it does, when to use it, what it returns, and how it relates to affiliate_run_diagnostic. It provides enough context for an agent to select and call this tool appropriately without missing key details.

  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 zero parameters in the schema, so the description need not explain parameter semantics. Per the rubric, baseline for 0 params is 4. The description adds no conflicting parameter info and focuses on purpose and return values, which is appropriate.

  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 tool's function: verifying Involve Asia credentials via a minimal authenticated endpoint. It uses a specific verb ('Verify') and resource ('configured credentials for Involve Asia'), and the mention of pairing with affiliate_run_diagnostic distinguishes it from a broader health check. It is immediately clear what this tool does and how it differs from sibling verify_auth tools.

  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 guidance: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also names an alternative/complementary tool (affiliate_run_diagnostic) for a fuller health check, offering clear when-to-use and contextual alternatives. This goes beyond a generic explanation.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_kwanko_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It discloses the call type (minimal authenticated endpoint), the return shape ({ok:true, identity?} or {ok:false, reason}), and implies read-only verification. It does not explicitly mention side effects, but the verification semantics are clear enough for a minimal 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?

  Three sentences, each adding distinct value: purpose, usage triggers, and return format plus companion tool. No redundancy or fluff; front-loaded with the core action.

  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 verification tool, the description fully covers what it does, when to use it, and what to expect as output. It also positions itself within the broader diagnostics workflow, making it contextually complete.

  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 with 100% schema coverage, so there are no parameters for the description to elaborate. Baseline 4 applies since the description adds no parameter-specific information but none is needed.

  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 tool's function: verify that configured Kwanko credentials are valid. It specifies the resource (Kwanko credentials) and the method (minimal authenticated endpoint), and distinguishes it from other network-specific verify_auth tools by naming Kwanko.

  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?

  Explicit usage guidance is given: use at start of session, after rotating keys, or when another operation returns an auth error. It also recommends pairing with affiliate_run_diagnostic for a full health check, clarifying the relationship to an alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_levanta_verify_authA
  4.7/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. It explains the behavior: calls a minimal authenticated endpoint and returns either {ok:true, identity?} or {ok:false, reason}, including the optional identity field and failure reason. It doesn't explicitly state non-mutation, but verification inherently implies no destructive side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, each earning its place: purpose, usage timing, and return format with pairing advice. No redundant or filler content.

  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, no-output-schema tool, the description is complete. It tells the agent what the tool does, when to use it, what it returns, and how it relates to a diagnostic sibling. No additional context is needed for correct invocation.

  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?

  There are zero parameters, so the schema description coverage is 100% vacuous. The baseline for 0 params is 4. The description adds context about using 'configured credentials' but no parameter-specific explanation is needed.

  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 opens with a specific verb and resource: 'Verify the configured credentials for Levanta are valid by calling a minimal authenticated endpoint.' It clearly states what the tool does and naturally distinguishes it from sibling verify_auth tools by naming Levanta and describing the lightweight verification mechanism.

  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 explicitly tells when to use: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also clarifies relationship to the alternative 'affiliate_run_diagnostic' by suggesting pairing for a full health check, giving clear context for selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_linkconnector_get_programmeA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses the return shape ('Returns a single Programme') and specific fields included (commission, status, advertiser URL), which is useful beyond the schema. The verb 'Fetch' implies read-only, but it doesn't explicitly mention error behavior or authentication needs, a minor gap for a simple getter.

  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?

  Two sentences, front-loaded with the action, no repetition of schema details, and every sentence adds value: what it does, when to use it, and how to discover the id.

  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 one-parameter retrieval tool with no output schema, the description is complete: it covers the purpose, the trigger condition, the return contents, and the relation to the sibling list_programmes. No important aspect is missing given the tool's simplicity.

  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?

  Schema coverage is 0% and the description compensates by explaining that programmeId is the 'network programme id' and by showing how to discover it via list_programmes. It adds semantic meaning beyond the bare string type in the schema, though it lacks format examples.

  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 ('Fetch') and resource ('single programme on LinkConnector') and names the key identifier ('network programme id'). It clearly distinguishes itself from the many other get_programme tools by naming the network and from list_programmes by stating it returns a single record.

  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?

  Explicitly states when to use ('when you already know the programme id and need its full record') and points to the alternative workflow ('pair with list_programmes when you need to discover the id first'). This gives the agent direct decision guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_linkconnector_verify_authA
  4.7/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 disclosure. It states the tool calls a minimal authenticated endpoint and explicitly describes the return shape: '{ok:true, identity?} or {ok:false, reason}'. It does not explicitly state that this is a read-only operation, but the nature of verification strongly implies it, and the return format adds meaningful 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 exactly two sentences. The first sentence front-loads the core purpose and mechanism; the second provides usage timing, return format, and a pointer to a related tool. Every sentence adds value with no repetition 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?

  Given that there are no parameters and no output schema, the description is complete: it explains what the tool does, when to use it, what the result looks like, and how it fits into a broader diagnostic workflow. The missing output schema is compensated by the explicit return type in the description.

  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 an empty object with zero parameters, so the baseline is 4. The description does not need to elaborate on parameters because none exist, and it does not introduce any confusing parameter-related terminology.

  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 tool's function: 'Verify the configured credentials for LinkConnector are valid by calling a minimal authenticated endpoint.' It uses a specific verb (verify) and resource (LinkConnector credentials), and differentiates from sibling verify_auth tools by explicitly naming the network and the endpoint type.

  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 gives explicit when-to-use guidance: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also references a complementary tool, 'pair with affiliate_run_diagnostic for a full health check,' which helps the agent decide between alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_list_client_strategiesA
  4.7/5.0
  Behavior5/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 fully describes the return format (array of objects with slug, hasStrategy, hasKpi, registered, orphan) and even explains the orphan flag's meaning. It also discloses data sources (brands.json and client directory on disk), making behavior transparent without speculating about side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and well-structured: one sentence for purpose, one for use cases and return shape. Every clause adds value, with no fluff or redundant content. It front-loads the primary action and follows with essential details.

  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?

  Given the tool has no parameters and no output schema, the description completely covers all necessary context. It explains what is returned, the structure of each item, and the significance of the orphan flag. It also mentions data sources, making this tool self-contained and fully understandable for an 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 tool has zero parameters, so the schema fully covers parameter semantics. Per the rubric, a baseline of 4 is appropriate when there are no parameters. The description adds value by explaining the output structure, which is complementary to parameter understanding but not required.

  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 tool's function: listing which brands have advisory strategy recorded, covering both brands.json and any client directory on disk. It distinguishes itself from sibling tools like affiliate_get_client_strategy (singular) and affiliate_set_client_strategy (write) by being a list operation. The verb 'List' and resource 'brands' are specific and unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides explicit usage contexts: 'Use this to drive a portfolio rollup or to prompt the operator to record strategy for a brand that has none.' It clearly implies when this list tool is appropriate. However, it does not explicitly state when not to use it or name alternative tools, so it falls just short of a 5.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_lomadee_get_programmeA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full transparency burden. It indicates a read-only 'Fetch' operation and informs the agent about the return contents ('commission, status, advertiser URL'), which is useful behavioral context. It doesn't cover error cases or authentication, but for a simple single-record fetch this is reasonable.

  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, front-loaded with the primary purpose followed by situational guidance. Every word adds value, with 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?

  For a one-parameter fetch with no output schema, the description covers purpose, parameter semantics, return type, and return contents ('full record'), and even suggests a companion workflow with list_programmes. It is sufficiently complete for an agent to understand and invoke the tool correctly.

  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?

  Schema description coverage is 0%, but the description compensates by explaining that programmeId is the network programme id and that the agent must already know it. It also connects to list_programmes for discovery, clarifying how the id is obtained.

  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 tool fetches a single Lomadee programme by network programme id, specifying the exact resource and scope. It differentiates from the sibling list_programmes tool by emphasizing it returns a single Programme.

  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?

  It explicitly states when to use the tool ('when you already know the programme id and need its full record') and advises pairing with list_programmes when the id needs to be discovered first. This provides direct, actionable guidance without ambiguity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_lomadee_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full behavioral disclosure burden. It discloses the return format ('Returns {ok:true, identity?} or {ok:false, reason}'), which is useful beyond the schema since no output schema exists. It implies a read-only, minimal network operation. However, it does not explicitly state side effects (though none expected) or handling details beyond the reason field.

  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 three sentences, each serving a distinct purpose: purpose, usage timing, and return format/complement. It is front-loaded with the core action and includes no filler, making it highly efficient for an AI agent to parse.

  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?

  Given the tool's simplicity (no parameters, no output schema), the description is fully complete: it explains what the tool does, when to invoke it, what it returns, and how it relates to a diagnostic tool. An agent has all necessary information to select and call it correctly.

  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 zero parameters, so the schema is complete and there is nothing to document. The description's mention of 'configured credentials' adds context about how the tool operates without parameters. This aligns with the baseline 4 for 0-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 tool's purpose: 'Verify the configured credentials for Lomadee are valid by calling a minimal authenticated endpoint.' It uses a specific verb ('Verify'), identifies the resource ('credentials for Lomadee'), and distinguishes itself from sibling verify_auth tools by explicitly naming Lomadee.

  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?

  Explicit usage guidance is provided: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also names the complementary tool 'affiliate_run_diagnostic' for a full health check, helping the agent choose between them.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_monetizze_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden. It discloses the operation (calls an authenticated endpoint), the return shape ({ok:true, identity?} or {ok:false, reason}), and the optional identity field. It doesn't explicitly state it's non-mutating, but the auth-check nature strongly 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each densely informative: purpose, when to use, return format, and companion tool. No filler or 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 auth verification tool with no output schema, the description is fully sufficient: it explains what it does, when to invoke it, what it returns, and how it relates to a fuller diagnostic. Complete for agent selection and invocation.

  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 zero parameters, so the empty schema already communicates this. The description adds no param-specific meaning, but with 0 params the baseline of 4 is appropriate.

  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 clear, specific action: verify configured Monetizze credentials via a minimal authenticated endpoint. It distinguishes itself from other network-specific verify_auth tools by naming the resource (Monetizze) and the lightweight nature (minimal endpoint).

  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?

  Explicitly gives usage scenarios: at session start, after key rotation, or on auth errors. It also points to affiliate_run_diagnostic as a companion for a full health check, clarifying the relationship to an alternative tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_mrge_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description must carry the full behavioral burden. It discloses the call is to a 'minimal authenticated endpoint,' specifies the return shape ({ok:true, identity?} or {ok:false, reason}), and clarifies the scope by contrasting with run_diagnostic. It doesn't explicitly say it's non-mutating, but the verb 'verify' strongly implies a read-only check.

  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?

  Three sentences, each serving a purpose: purpose/method, usage timing, and return format/related tool. No redundant wording, and the most important information is front-loaded.

  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 verification tool with no output schema, the description covers purpose, method, usage triggers, expected return, and relationship to a related diagnostic tool. This is sufficient for an agent to select and invoke it correctly among many siblings.

  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 schema has zero parameters, so the baseline is 4. The description adds clarity by stating the credentials are 'configured' (pre-set), meaning no user-supplied parameters are needed, which helps the agent understand why the schema is empty.

  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 the specific verb 'Verify,' identifies the resource as 'configured credentials for mrge,' and explains the method ('by calling a minimal authenticated endpoint'). This clearly distinguishes it from sibling verify_auth tools for other networks and from affiliate_run_diagnostic.

  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?

  It explicitly lists trigger conditions: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also directs the agent to 'pair with affiliate_run_diagnostic for a full health check,' providing an alternative and implying when not to use this tool alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_offer18_get_programmeA
  4.7/5.0
  Behavior4/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 the read-only nature through 'Fetch' and states the return behavior (a single Programme). It adds useful context about the contained fields (commission, status, advertiser URL), though it doesn't discuss errors or auth, which are not critical for a simple getter.

  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?

  Two sentences, front-loaded with the action and usage, and no wasted words. Every sentence serves a 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 simple single-fetch tool, the description is complete: it specifies what it fetches, what the returned record includes, and how to discover the id. The pairing with list_programmes addresses the likely predecessor step.

  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?

  Schema coverage is 0%, so description must compensate. It clarifies that programmeId is the network programme id and indicates how to obtain it (via list_programmes), adding meaning beyond the bare parameter name.

  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 tool fetches a single programme on Offer18 by its network programme id, specifying the exact resource and scope. It distinguishes from sibling get_programme tools by naming Offer18 and from list_programmes by emphasizing 'single programme.'

  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?

  Explicitly says to use this when you already know the programme id and need the full record, and recommends pairing with list_programmes when discovery is needed. This provides clear when-to-use and alternative guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_offer18_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden of disclosing behavior. It states the operation is a minimal authentication call, provides the exact return shape ({ok:true, identity?} or {ok:false, reason}), and indicates it relies on configured credentials. This goes beyond a basic description, though it does not detail failure modes or network side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise—two sentences—with no filler. The first sentence states the core purpose and method, the second covers usage timing and output format. Every clause earns its place.

  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 auth verification tool with no output schema, the description is complete: it covers what the tool does, when to use it, what it returns, and how it relates to a larger diagnostic tool. Nothing essential is missing.

  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 zero parameters, and the input schema is empty, so the baseline is 4. The description adds value by clarifying that the tool uses 'configured credentials,' implicitly explaining why no parameters are needed.

  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 ('Verify'), identifies the exact resource ('configured credentials for Offer18'), and explains the mechanism ('calling a minimal authenticated endpoint'). It clearly distinguishes this tool from the many network-specific verify_auth siblings by naming Offer18 and describing its purpose.

  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 explicitly states when to use this tool: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also suggests pairing with affiliate_run_diagnostic for a full health check, providing clear guidance on alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_optimise-media_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses the mechanism ('calling a minimal authenticated endpoint'), the success/failure contract ('Returns {ok:true, identity?} or {ok:false, reason}'), and operational context like credential rotation. It does not explicitly state that the operation has no side effects, but the verification purpose and minimal endpoint strongly imply a read-only check.

  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 three sentences with no wasted words. It front-loads the main purpose, then gives usage timing, then the return shape and relationship to affiliate_run_diagnostic. Every sentence earns its place.

  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 tool with no annotations and no output schema, the description is complete: it explains what the tool does, when to use it, what it returns, and how it fits with a related health-check tool. The agent has enough information to select and invoke it correctly without additional detail.

  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 zero parameters and the schema already fully describes this (100% coverage with an empty properties object). The rule for 0 params is a baseline of 4. The description adds useful context by referring to 'configured credentials', indicating the credentials are pre-set rather than passed in, but no parameter-level explanation is needed.

  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 opens with a specific verb and resource: 'Verify the configured credentials for Optimise Media are valid by calling a minimal authenticated endpoint.' This clearly states what the tool does and, combined with the tool name, distinguishes it from the many other network-specific verify_auth siblings. It also hints at the difference from affiliate_run_diagnostic by positioning this as a narrower check.

  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?

  Explicit guidance is provided: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' This tells the agent when to choose this tool. It also names the complementary tool affiliate_run_diagnostic and contrasts this with a 'full health check', satisfying the when/alternative requirement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerize_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden and delivers: it explains that an authenticated endpoint is called, and describes the return shape ({ok:true, identity?} or {ok:false, reason}). It stops short of explicitly stating side-effect-freeness or rate-limit behavior, but for a verification tool this is sufficient 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?

  Three sentences with a logical flow: purpose first, then usage triggers, then return format. No filler or repetition; every sentence adds value.

  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?

  Given the tool has zero parameters and no output schema, the description is complete for an agent: it states what it verifies, when to use it, what it returns (with optional identity), and how it relates to diagnostics. Nothing critical is missing for safe invocation.

  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 zero parameters, so the 100% schema coverage is vacuous. The baseline for no params is 4, and the description appropriately does not invent parameter docs, though it also doesn't add any clarifying notes about config or environment.

  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 tool verifies Partnerize credentials by calling a minimal authenticated endpoint. This is a specific verb (verify) with a specific resource (Partnerize credentials), and it is immediately distinguishable from the many sibling verify_auth tools for other networks.

  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?

  Explicit guidance is provided: use at start of session, after key rotation, or when another operation returns an auth error. It also points to a complementary tool (affiliate_run_diagnostic) for a full health check, making the usage context very clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_partnerstack_verify_authA
  4.7/5.0
  Behavior4/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 the mechanism ('calling a minimal authenticated endpoint') and the exact return shape ('{ok:true, identity?} or {ok:false, reason}'). It stops short of explicitly stating read-only/no side effects, but 'verify' plus the minimal-endpoint framing strongly 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences, each earning its place: what it does, when to use it, and what it returns. No wasted words, and the most important information is front-loaded in the first sentence.

  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 tool with no output schema and no annotations, the description covers everything essential: purpose, usage timing, return format, and relationship to the full diagnostic tool. Nothing critical is missing.

  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 zero parameters, so the rubric baseline is 4. The description adds mild value by confirming credentials are pre-configured ('configured credentials') rather than passed as arguments, which is useful for an agent deciding what to supply.

  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 opens with a specific verb+resource: 'Verify the configured credentials for PartnerStack are valid.' The PartnerStack prefix distinguishes it from the many sibling verify_auth tools for other networks, and 'minimal authenticated endpoint' distinguishes it from the heavier affiliate_run_diagnostic.

  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 gives explicit timing: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also names a concrete alternative: 'pair with affiliate_run_diagnostic for a full health check,' clarifying when this lighter tool is appropriate.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_pepperjam_get_programmeA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It discloses return content (commission, status, advertiser URL) and that a single Programme is returned. The verb 'Fetch' implies read-only, and the description adds useful context about the return fields, though it doesn't explicitly state side-effect-free behavior or error conditions.

  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?

  Two sentences, front-loaded with the action, no unnecessary words. Every clause contributes: what it does, when to use it, what it returns, and how to discover the id first.

  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 single-fetch tool with one parameter and no output schema, the description is complete. It covers the return value, the required input meaning, and points to the companion list tool for discovery. No significant gaps remain.

  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 schema has one parameter (programmeId, string) with 0% description coverage. The description explains the parameter as 'network programme id', clarifying exactly what identifier is expected. This adds meaning beyond the schema's property name, though it doesn't provide format constraints or examples.

  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 verb (Fetch) and resource (a single programme on Pepperjam by network programme id). It distinguishes itself from sibling tools by specifying 'single programme' and mentioning the id-based lookup, differentiating from list_programmes and other network-specific get_programme tools.

  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?

  Explicitly states when to use this tool ('when you already know the programme id and need its full record') and provides an alternative ('pair with list_programmes when you need to discover the id first'). This gives clear selection guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_pepperjam_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the burden and explains the minimal endpoint call and the exact return shape ({ok:true, identity?} or {ok:false, reason}). It does not explicitly state the operation is side-effect-free, but the nature of an auth verification is implicit; a bit more explicitness about non-destructiveness would push this to 5.

  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, with purpose, usage, return values, and the alternative tool all covered without any unnecessary prose. It is front-loaded with the core purpose first.

  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, no-output-schema tool, the description is complete: it states what it does, when to use it, what it returns, and how it relates to the diagnostic sibling. Nothing essential is missing for this simple verification 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 zero parameters, so the schema is empty and the baseline for parameter semantics is 4. The description adds context about 'configured credentials' but does not need to document any parameters.

  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 identifies the tool as verifying Pepperjam credentials via a minimal authenticated endpoint. It uses a specific verb and resource, and the Pepperjam-specific scope distinguishes it from the many other verify_auth sibling tools.

  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?

  It gives explicit trigger conditions: at session start, after key rotation, or when another operation returns an auth error. It also contrasts with affiliate_run_diagnostic, directing users to the appropriate alternative for full health checks.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_profitshare_verify_authA
  4.7/5.0
  Behavior4/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 the action (calling a minimal authenticated endpoint) and gives the exact return shape: '{ok:true, identity?} or {ok:false, reason}'. It doesn't explicitly state side-effect freedom, but 'verify' and 'minimal authenticated endpoint' imply a non-mutating check.

  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?

  Three sentences, each earning its place: purpose, usage timing, and return/relationship to run_diagnostic. No filler, front-loaded with the core action.

  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 verification tool with no output schema, the description is complete. It covers what it does, when to use it, the return shape, and how it relates to the diagnostic sibling. The agent has enough to select and invoke it correctly.

  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 zero parameters, so the empty schema carries full coverage; per rubric, 0 params baselines at 4. The description adds no parameter details because none exist, but it does describe the output contract, which is useful.

  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 opens with 'Verify the configured credentials for Profitshare are valid by calling a minimal authenticated endpoint', naming a specific verb, resource (Profitshare credentials), and method. It clearly distinguishes from sibling network-specific verify_auth tools by explicitly naming Profitshare.

  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?

  It explicitly states when to use the tool: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also points to affiliate_run_diagnostic for a full health check, contrasting a focused auth verification with a broader diagnostic.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_rakuten_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses that it calls a minimal authenticated endpoint and describes the return shape ({ok:true, identity?} or {ok:false, reason}). This is good transparency, though it doesn't detail potential side effects, rate limits, or the meaning of 'identity' beyond the basic return structure.

  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?

  Three sentences, each earning its place: purpose, when to use, and return shape plus pairing. Front-loaded with the primary verb and resource, no 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?

  Despite having no output schema and no parameters, the description provides the return contract and context of use. It also mentions the sibling tool for comprehensive diagnostics, making it complete for a simple verification 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 zero parameters, so the baseline is 4. The description correctly says nothing about parameters since there are none. It implicitly adds value by focusing on the auth verification purpose rather than any parameter details.

  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 ('Verify') and names the exact resource ('configured credentials for Rakuten Advertising') and method ('calling a minimal authenticated endpoint'). It clearly distinguishes this tool from the many sibling verify_auth tools by explicitly naming Rakuten Advertising.

  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?

  Provides explicit guidance on when to use: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also contrasts with affiliate_run_diagnostic for a full health check, giving a clear alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_run_diagnosticA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the full burden. It discloses the return structure (NetworkCapabilities per network plus a server block with version, update availability, and how to apply) and the diagnostic nature. It doesn't explicitly state side-effect profile, but 'diagnostic' strongly implies a read-only 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?

  Three sentences, front-loaded with the action and scope, then use cases and return-value details. Every sentence adds value, with no redundant content.

  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 tool with one optional parameter, no output schema, and no annotations, the description is self-contained: it explains the return values (NetworkCapabilities per network, server block), use cases, and relationship to verify_auth tools. Nothing critical is missing.

  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 single 'network' parameter has 0% schema description coverage. The description compensates by indicating the tool runs across 'one or all' networks, implying that providing a network selects one and omitting it covers all. It doesn't specify the exact value format, but sibling tool naming conventions provide enough context.

  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 tool runs a capabilities diagnostic across one or all registered affiliate networks, answers 'is everything working?', confirms supported operations, and checks server version. This specific verb+resource scope distinguishes it from per-network sibling tools.

  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?

  Explicitly lists when to use (health check, capability confirmation, server version check) and provides an alternative approach: pair with per-network verify_auth tools for auth failure isolation. This gives clear selection guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_scaleo_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden. It discloses that the call is minimal, describes return values in both success/failure cases, and implicitly indicates a read-only verification. It does not explicitly state no side effects, but the verify semantics and minimal endpoint make that clear.

  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?

  Three sentences, each with a distinct role: purpose, usage timing, and output format. No wasted words.

  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 verification tool, the description covers what it does, when to use it, what it returns, and how it relates to the diagnostic sibling. No 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 zero parameters, so the baseline is 4. The description adds context that credentials are pre-configured, which is useful, but there are no parameters to clarify.

  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 opens with a specific verb ('Verify') and resource ('configured credentials for Scaleo'), and explains the mechanism (minimal authenticated endpoint). It clearly distinguishes from other network verify_auth tools by naming Scaleo and from affiliate_run_diagnostic by scope.

  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?

  Provides explicit usage contexts ('at the start of a session, after rotating keys, or when another operation returns an auth error') and directs to pair with affiliate_run_diagnostic for a full health check, differentiating from the diagnostic tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_set_client_strategyA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden and does exceptionally well: it discloses local-config vs network writes, kpiMarkdown grammar validation, rejection on parse errors (returned as parseErrors), and the explicit safety note that it never authorizes a network action.

  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?

  Three sentences with no fluff, each covering a distinct aspect: purpose, usage workflow, and validation/safety. The third sentence is somewhat dense but still organized and readable.

  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 local write tool with no annotations or output schema, it covers purpose, workflow, safety, and error behavior. The only minor gap is an explicit success return value, but the parseErrors mention provides partial return semantics.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Despite 0% schema coverage, the description adds meaning to all three parameters: brand is a slug from brands.json, kpiMarkdown is validated against a fenced grammar, and strategyMarkdown is the Strategy.md content. This far exceeds the bare string 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 ('Write'), identifies the resource (Strategy.md and/or KPI.md) and target (local config directory), and clearly distinguishes this write tool from sibling read/list tools like affiliate_get_client_strategy.

  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?

  It explicitly states 'Use this only after confirming the content with the operator' and explains the workflow gate (onboarding skill drafts/confirms, this tool persists). This provides clear context but does not name alternative tools 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.

• affiliate_shareasale_verify_authA
  4.7/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 burden of behavioral disclosure. It conveys the mechanism (minimal authenticated endpoint), the return contract ({ok:true, identity?} or {ok:false, reason}), and implies a read-only verification action. It does not detail potential network or permission errors beyond the return shape, but this is sufficient for a verification 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?

  Three tightly written sentences: first states the purpose, second gives usage triggers, third describes the return format and complementary tool. No extraneous content.

  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 tool with no output schema and no annotations, the description covers the essential context: what it does, when to use it, what it returns, and its relationship to a diagnostic tool. It is fully self-contained for an agent to select and invoke it correctly.

  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 are no parameter semantics to clarify. Baseline score of 4 applies as the description adds no unnecessary parameter details.

  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 tool's function: 'Verify the configured credentials for ShareASale are valid by calling a minimal authenticated endpoint.' This specifies a concrete action and resource, distinguishing it from other network-specific verify_auth tools.

  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?

  Explicit guidance is provided: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also suggests pairing with affiliate_run_diagnostic for a full health check, offering an alternative pathway.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_shopmy_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses that it calls a minimal authenticated endpoint and specifies the return format ({ok:true, identity?} or {ok:false, reason}), which gives a clear behavioral contract. It does not explicitly state side effects, but the nature of a verify operation implies no changes, making this sufficient.

  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?

  Three sentences that are front-loaded with the core action, followed by usage timing and return format. Every sentence adds value; no redundant or filler content.

  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?

  This is a simple tool with no parameters and no output schema. The description covers purpose, when to use, return values, and relationship to the diagnostic tool, making it fully complete for an agent to select and invoke it correctly.

  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 zero parameters, so the description has no need to explain parameter meanings. The schema is empty (100% coverage), and the description adds useful context about the operation's purpose and results. Baseline for 0 params is 4.

  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 tool verifies configured ShopMy credentials by calling a minimal authenticated endpoint. It distinguishes from other verify_auth tools by specifying the network (ShopMy) and contrasts with affiliate_run_diagnostic as a full health check.

  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?

  Explicitly states when to use: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' Also tells when to pair with affiliate_run_diagnostic for a full health check, providing clear guidance on tool selection.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_skimlinks_get_programmeA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the transparency burden. It discloses the return type ('Returns a single Programme') and the key fields ('commission, status, advertiser URL'), effectively conveying the read-only behavior. It does not mention error handling or edge cases, but the simple get operation is adequately described.

  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 three sentences, each serving a clear purpose: function, usage, and return/discovery pairing. It is front-loaded with the core action and contains no redundant or filler content.

  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 get tool with no output schema, the description fully covers the return value ('Returns a single Programme') and representative fields, along with the discovery workflow. The tool is simple, and the description provides sufficient context for an agent to invoke it correctly.

  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?

  Schema coverage is 0% with only a bare 'programmeId' string property. The description compensates by clarifying that the id is the 'network programme id' and explains how to obtain it (via list_programmes), giving meaningful context 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 explicitly states 'Fetch a single programme on Skimlinks by its network programme id' with a clear verb, resource, and scope. It distinguishes from sibling list_programmes by specifying it returns a single record and mentions pairing with list_programmes for discovery.

  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 when-to-use guidance: 'Use this when you already know the programme id and need its full record.' It also names the alternative, 'pair with list_programmes when you need to discover the id first,' which clarifies the workflow.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_skimlinks_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full behavioral burden. It discloses the return shape: '{ok:true, identity?} or {ok:false, reason}', and notes the call is to a 'minimal authenticated endpoint.' This is useful but doesn't elaborate on failure modes, side effects, or error behavior beyond the reason field. Slightly more detail would make it perfect.

  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?

  Three sentences, front-loaded with purpose, followed by usage triggers and return format. No fluff or repetition. Every sentence serves a distinct function.

  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 tool with no output schema, the description is fully complete: it explains what it does, when to use it, what it returns, and how it relates to the diagnostic tool. No missing context for an agent to invoke it correctly.

  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 zero parameters and schema coverage is 100% (vacuously). Per the rubric, 0 params yields a baseline of 4. The description adds no parameter-specific semantics because none exist, which is appropriate.

  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 tool's purpose: 'Verify the configured credentials for Skimlinks are valid by calling a minimal authenticated endpoint.' It uses a specific verb (verify) and resource (Skimlinks credentials), and the mention of 'minimal authenticated endpoint' distinguishes it from data-retrieval tools and other network verification tools.

  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?

  Explicitly states when to use: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also names an alternative/complement: 'pair with affiliate_run_diagnostic for a full health check.' This gives clear usage context and distinguishes from other tools.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_sovrn-commerce_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Without annotations, the description discloses the call mechanism ('minimal authenticated endpoint') and the return shape ('{ok:true, identity?} or {ok:false, reason}'). It implies read-only verification, though it does not explicitly state non-destructiveness or permission requirements. This is good context for a zero-parameter 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?

  Two sentences, front-loaded with purpose, and each sentence adds distinct value: first defines the action, second provides usage timing and return format. No 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, simple verification tool, the description fully covers purpose, when to use it, return value, and relationship to a sibling tool. The empty schema and lack of output schema are compensated by the description.

  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 zero parameters, so the schema covers everything vacuously. The description still clarifies that no input is needed and explains what the call does, which is appropriate for a parameterless operation.

  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 ('Verify'), a specific resource ('configured credentials for Sovrn Commerce'), and the method ('calling a minimal authenticated endpoint'). This clearly distinguishes it from other network verify_auth tools by network name.

  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?

  Explicitly states when to use: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also points to affiliate_run_diagnostic for a fuller health check, making the alternative clear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradedoubler_get_programmeA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly indicates a read-only operation ('Fetch') and adds that it returns a single Programme with specific fields, which is useful behavioral context. It does not mention authentication or error cases, but for a simple get tool this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the primary action and followed by usage guidance. Every word earns its place with no redundancy or fluff.

  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 single-parameter get tool with no output schema, the description is complete: it states what it does, when to use it, and what it returns (a single Programme with fields). The context signals (one param, no output schema) align well with this level of detail.

  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?

  With schema description coverage at 0%, the description compensates by clarifying that the parameter is the 'network programme id' and that it should be already known. This adds meaning beyond the bare schema property 'programmeId' (string), helping the agent understand exactly what to provide.

  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 'Fetch a single programme on Tradedoubler by its network programme id' which is a specific verb+resource, and distinguishes it from list_programmes by emphasizing 'single' vs 'list'. It also hints at the content of the full record (commission, status, advertiser URL), making the tool's purpose unmistakable.

  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 guidance: 'Use this when you already know the programme id and need its full record.' It also names the alternative, 'pair with list_programmes when you need to discover the id first,' which is clear and actionable.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradedoubler_list_publisher_sourcesA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden and does well: it discloses the return shape ('array of sources with id, name, url, type, and status') and the semantic meaning of the id field. It does not explicitly state read-only or mention pagination, but the verb 'List' implies a safe read operation, and the description adds useful context beyond the name.

  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 three well-structured sentences, front-loaded with the primary action, and every sentence earns its place by adding detail about use cases and return values. No fluff or repetition.

  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 zero-parameter tool with no output schema, the description fully explains the return value and practical usage. It covers what the tool does, what it returns, and how to use the results in conjunction with other endpoints, making it complete for an 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 tool has 0 parameters with 100% schema coverage, so the baseline is 4. The description adds no parameter info because none are needed, but it does explain how the returned id is used as a parameter elsewhere, which is valuable context.

  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 tool lists 'publisher sources (registered websites/sites) for the Tradedoubler account,' using a specific verb and resource. It differentiates itself from sibling tools like list_programmes by focusing on source/site IDs and their role in tracking links.

  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 explicitly says 'Use this to discover available source/site IDs' and explains how the IDs are used as the 'a=' parameter and as filters in programme/transaction endpoints. It also recommends pairing with list_programmes to scope results, providing clear when-to-use guidance and a companion tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradedoubler_verify_authA
  4.7/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 transparency burden. It discloses that the operation is a verification call, describes the return shape ({ok:true, identity?} or {ok:false, reason}), and implies a read-only, minimal endpoint call. While it doesn't explicitly say 'no side effects' or mention rate limits, it is reasonably transparent for a simple auth verification 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 three sentences with no filler. It front-loads the primary purpose, then gives usage guidelines, and finally the return format and a pointer to a related diagnostic tool. Every sentence contributes meaningful information.

  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 tool with no output schema, the description covers the essential aspects: what it does, when to use it, what it returns, and how it relates to other tools. It is self-contained and enough for an agent to select and invoke it correctly.

  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, and schema coverage is 100%, so the baseline is 4. The description adds a small semantic cue by referring to 'configured credentials,' indicating that no runtime parameters are needed and the tool relies on stored configuration. This adds value beyond the empty 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 and resource: 'Verify the configured credentials for Tradedoubler are valid' via a minimal authenticated endpoint. This clearly states what the tool does and implicitly distinguishes it from sibling data-fetching tools like get_programme or list_transactions, as well as from other networks' verify_auth tools.

  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?

  It explicitly states when to use the tool: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also contrasts with a related tool, advising to 'pair with affiliate_run_diagnostic for a full health check,' which provides clear context on scope and alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tradetracker_verify_authA
  4.7/5.0
  Behavior4/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 the return shape ({ok:true, identity?} or {ok:false, reason}) and characterizes the call as minimal, implying a lightweight read-only operation. However, it stops short of explicitly confirming no side effects or addressing rate limits, leaving a small gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three concise sentences, front-loaded with the primary purpose, followed by usage timing and return format. Every sentence contributes value 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 tool with no annotations and no output schema, the description is complete: it states what it does, when to use it, what it returns, and how it relates to a diagnostic tool. Nothing essential is missing for an agent to invoke it correctly.

  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?

  This tool has 0 parameters, so the baseline is 4. The description adds context about using configured credentials, which is relevant but not parameter-specific. With no params to explain, the schema coverage is effectively complete.

  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 explicitly states the tool verifies TradeTracker credentials via a minimal authenticated endpoint, which is a specific verb+resource+mechanism. It differentiates from other verify_auth tools by naming TradeTracker and from affiliate_run_diagnostic by implying this is a focused auth check.

  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 gives explicit use cases: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also notes pairing with affiliate_run_diagnostic for a full health check, clarifying how it relates to an alternative tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_tune_verify_authA
  4.7/5.0
  Behavior4/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 the return format ({ok:true, identity?} or {ok:false, reason}), which is essential behavioral context, and implies a read-only operation. Could be richer but is adequate for a simple 0-param verification 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?

  Three sentences, each earning its place: purpose, when to use, and return format plus pairing advice. Front-loaded with a specific verb and resource, with no fluff.

  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 low-complexity 0-param tool with no output schema, the description fully covers purpose, usage timing, return shape, and relationship to a sibling diagnostic tool. Nothing essential is missing.

  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 zero parameters and the schema is empty, so there is nothing to document. The description correctly implies no inputs are needed, and the baseline for 0-param tools is 4.

  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 tool verifies TUNE credentials via a minimal authenticated endpoint. It is specific about the verb (verify), resource (TUNE credentials), and distinguishes itself from sibling verify_auth tools by naming TUNE.

  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?

  Explicitly tells the agent when to use it: at session start, after key rotation, or after an auth error. It also recommends pairing with affiliate_run_diagnostic for a full health check, providing a clear alternative/complement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_value-commerce_verify_authA
  4.7/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It explains the call type (minimal authenticated endpoint), the return shape ({ok:true, identity?} or {ok:false, reason}), and implies a read-only, non-destructive operation. It does not explicitly state whether side effects are possible, but for an auth verification tool this is clearly a safe check, so this is a minor gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three compact sentences cover purpose, usage timing, and return format. There is zero fluff, and the most important verb and object are front-loaded. Every sentence contributes actionable information.

  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?

  Despite being a simple tool with no input schema or output schema, the description covers all necessary context: what it does, when to use it, what it returns, and how it relates to a broader diagnostic. No gaps remain for an agent to select or invoke it correctly.

  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 zero parameters and the schema already captures this completely, so the description has little to add. It correctly avoids inventing parameters. Baseline for 0-parameter tools is 4, and no additional parameter guidance is needed.

  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 opens with a specific verb ('Verify') and resource ('configured credentials for ValueCommerce'), making it immediately clear what the tool does. It distinguishes this from sibling verify_auth tools by naming the network (ValueCommerce) and specifying the mechanism (minimal authenticated endpoint).

  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?

  Gives explicit when-to-use scenarios: 'at the start of a session, after rotating keys, or when another operation returns an auth error.' It also points to a broader diagnostic tool ('pair with affiliate_run_diagnostic'), effectively distinguishing this focused auth check from the full health check alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_webgains_verify_authA
  4.7/5.0
  Behavior4/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 the return shape ({ok:true, identity?} or {ok:false, reason}) and indicates a minimal endpoint call. It does not mention potential side effects, rate limits, or detailed error behavior, but for a verification tool this is adequate and generally transparent.

  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?

  Three sentences, each with clear value: purpose, when to use, and return format. No filler or redundancy; the most critical information is front-loaded.

  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?

  This is a simple no-parameter auth verification tool. The description covers purpose, usage triggers, alternative/complementary tools, and the exact return format. It is fully self-sufficient even without annotations or an output schema.

  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 zero parameters, and the schema confirms this with an empty properties object. The description adds no parameter details because none exist. Baseline for 0 params is 4.

  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 ('Verify') and resource ('configured credentials for Webgains') and explains it calls a minimal authenticated endpoint. It distinguishes from sibling verify_auth tools by naming the network and from other tools by focusing on auth validity.

  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 explicitly lists when to use this tool ('at the start of a session, after rotating keys, or when another operation returns an auth error') and suggests pairing with affiliate_run_diagnostic for a full health check, implying when it is not sufficient alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_yieldkit_verify_authA
  4.7/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 burden. It discloses the return shape ({ok:true, identity?} or {ok:false, reason}) and states it calls a minimal endpoint. It does not explicitly state it is read-only or list side effects, but the verification purpose implies a safe, non-mutating operation, providing adequate transparency without contradicting any annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the action and resource, followed by concise usage guidance and return contract. Every sentence earns its place with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no params, no output schema, no annotations), the description is sufficiently complete: it explains purpose, when to invoke, return values, and relationship to the diagnostic tool. There is no missing critical information for an agent to use it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema is complete (100% coverage). Baseline for 0 params is 4, and the description adds no redundant parameter info, so it meets the baseline without detracting.

  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 (verify), resource (Yieldkit credentials), and method (minimal authenticated endpoint). It clearly distinguishes from other verify_auth tools by naming Yieldkit and from affiliate_run_diagnostic by positioning the latter as a complement.

  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?

  Explicitly lists when to use: start of session, after rotating keys, or after an auth error. Also mentions pairing with affiliate_run_diagnostic for a full health check, giving clear context and a named alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_afilio_get_programmeA
  4.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the full burden. It clearly indicates a read-only fetch operation and previews the return content (commission, status, advertiser URL), but does not mention authentication requirements or error behavior for invalid IDs, keeping it from a perfect score.

  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?

  Two concise, front-loaded sentences with no filler. The first sentence states the action and resource, while the second adds usage context and alternative guidance.

  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?

  Given the tool's low complexity (one parameter, no output schema, no annotations), the description adequately covers purpose, usage, alternative, and expected return contents, making it fully complete for an agent to select and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has only a bare string property with no description, but the description compensates by explaining that programmeId is the network programme id and directs the agent to list_programmes to discover it, adding significant semantic meaning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Fetch a single programme on Afilio by its network programme id' with a specific verb and resource, and clearly distinguishes it from sibling tools like list_programmes and other networks' get_programme by naming the Afilio network and single-record scope.

  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?

  It explicitly instructs 'Use this when you already know the programme id' and pairs with list_programmes for id discovery, providing clear when-to-use guidance and a named alternative.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_ehub_get_programmeA
  4.8/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are present, so the description carries the transparency burden. It discloses that this is a 'Fetch' operation (implying read-only), returns a single Programme, and includes specific fields (commission, status, advertiser URL). It does not explicitly mention side-effect-free behavior or error cases, but the read-only intent is clear.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the verb and resource. Every word is informative; 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?

  For a simple single-parameter fetch tool with no output schema, the description is complete. It explains the purpose, the parameter provenance, the return value, and the complementary list tool. No further context is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has no parameter descriptions (0% coverage), but the description fully compensates. It clarifies that programmeId is the network-specific id, and explains how to discover it using list_programmes. This adds meaning beyond the bare property name and schema type.

  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 tool fetches a single programme on eHUB by its network programme id. It explicitly uses a specific verb and resource, and distinguishes this from list_programmes and other network-specific get_programme tools by noting it returns a single record and by the pairing advice.

  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 when-to-use guidance: 'Use this when you already know the programme id and need its full record'. It also names the alternative discovery flow: 'pair with list_programmes when you need to discover the id first'.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_get_brand_rowsA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the data source dependency (local store from affiliate_build_brand_snapshot), the side effect of writing a local CSV when format='file', the entitlement gate, and the entitlement_required fallback result. This goes well beyond a generic 'return data' statement.

  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?

  Three sentences, each additive: returns/formats, usage/prerequisite, entitlement. No filler or repetition of schema details; the most important action 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?

  The tool has no output schema, so the description should clarify return shape. It explains formats and the manifest-for-file tradeoff, but doesn't describe the fields in 'structured rows' or the manifest contents. It also omits error behavior when the snapshot doesn't exist, though the prerequisite is stated. Overall, highly usable but slightly incomplete on result shape.

  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?

  Schema coverage is 0%, so the description is the only source of parameter meaning. It explains the three format enum values, including the file-write behavior, and ties the brand parameter to the brand concept throughout. It does not fully define what constitutes a 'brand' or how to specify it, but the core parameter semantics are covered.

  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 opens with a specific verb ('Return') and a precise resource ('persisted 30-day, transaction-grain rows for a brand'), and enumerates three output formats. It distinguishes itself from siblings by noting it reads the local store written by affiliate_build_brand_snapshot, separating it from network-fetching list_transactions tools.

  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?

  It explicitly states when to use it ('transaction-level drill-down', 'hand a spreadsheet-ready export to the operator') and provides a format preference ('prefer format "file" on large accounts'). It also names the prerequisite (build a snapshot first) and explains the entitlement gate, giving clear selection and invocation guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_list_networksA
  4.8/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description fully carries the transparency burden. It discloses the return structure (NetworkMeta[] with operationClaimStatuses, configured, missingCredentials, setupAction) and the behavioral intent (avoid confusing auth errors, indicates static registry vs live diagnostic). This goes well beyond a minimal description.

  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 about 100 words and densely packed. The first sentence is front-loaded and concise. The second sentence is long but adds necessary return-field detail that would otherwise be missing without an output schema. No filler words, though it could be split for readability.

  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?

  Given zero params, no output schema, and no annotations, the description fully compensates by explaining return fields, when to use, and how it relates to sibling tools. It even covers the 'additively extended' nature of the response, making it complete for agent selection and invocation.

  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 zero parameters, so the baseline is 4. The description doesn't discuss parameters, but none exist, so it doesn't need to. It does mention env-var names in the return context, which adds value without relating to input parameters.

  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 tool lists affiliate networks with adapter version, claim_status, and credential configuration status. This is distinct from sibling tools that list programmes, transactions, or verify auth, and it explicitly positions itself as a registry/discovery tool rather than a diagnostic tool.

  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?

  It explicitly says to use this 'to discover which networks are wired up' and to tell the user which need setup 'before invoking a per-network tool' to avoid auth errors. It also recommends pairing with affiliate_run_diagnostic for live data, providing a clear alternative and when to prefer this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_cake_verify_authA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations exist, so the description fully carries the burden. It discloses that it calls a 'minimal authenticated endpoint,' describes the exact return shape ({ok:true, identity?} or {ok:false, reason}), and implicitly signals it is a lightweight, non-destructive check.

  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 three tightly written sentences with no filler. The first sentence states the core action, the second gives usage timing, and the third covers output and related tool. Every sentence earns its place.

  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?

  Given the tool's simplicity (no parameters, no output schema, no annotations), the description is complete: it explains the purpose, when to invoke, the expected return format, and how it complements a broader diagnostic. No essential information is missing for an AI agent to select and invoke this correctly.

  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 zero parameters and an empty input schema, so there is no parameter-specific semantics to describe. The description does provide context around the tool's purpose and behavior, which is the best possible for a no-parameter tool; the baseline of 4 is appropriate.

  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 ('Verify') and resource ('configured credentials for CAKE'), clearly stating the tool's action and scope. It distinguishes this from sibling verify_auth tools by naming the network (CAKE) and from affiliate_run_diagnostic by noting this is a focused auth check.

  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?

  Explicit guidance is given: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also clarifies the relationship to an alternative (pair with affiliate_run_diagnostic for a full health check), effectively indicating when not to rely on this tool alone.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• affiliate_netrefer_verify_authA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries the full burden. It discloses the call to a 'minimal authenticated endpoint', the return shape '{ok:true, identity?} or {ok:false, reason}', and its role as a lightweight auth check. This gives the agent insight into what to expect and how to interpret results.

  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 three sentences, front-loaded with the main action, and every sentence adds value. It covers purpose, usage, and return details 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?

  Given the simplicity of a zero-parameter tool, the description is fully complete. It explains the return values, when to use it, and how it relates to a broader diagnostic tool, leaving no ambiguity for an 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 tool has zero parameters and an empty schema, so the baseline is 4. The description appropriately avoids discussing parameters since there are none, and it adds value by explaining the return structure and use cases.

  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 tool's purpose: 'Verify the configured credentials for NetRefer are valid by calling a minimal authenticated endpoint.' This identifies the specific network (NetRefer), the action (verify auth), and the mechanism (minimal endpoint), distinguishing it from sibling verify_auth tools for other networks.

  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?

  Explicit usage guidance is provided: 'Use this at the start of a session, after rotating keys, or when another operation returns an auth error.' It also directs users to 'affiliate_run_diagnostic' for a full health check, effectively ruling out this tool for deeper diagnostics.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.