Server Quality Checklist

Tool Scores

• list_affiliate_programsA
  3.9/5.0
  Behavior3/5

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

  The description lists the returned fields (name, slug, category, commission rate, network), which is helpful, but it does not disclose pagination behavior, rate limits, or authentication needs. Since no annotations are provided, the description carries full burden but falls short of giving 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 consists of two sentences that efficiently communicate purpose, return values, and usage context without extraneous 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?

  While the description covers the basic return fields and usage context, it lacks details on pagination (despite a cursor parameter), ordering, error handling, and performance characteristics. The absence of an output schema makes this gap more significant, so completeness is only moderate.

  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 three parameters have descriptions in the input schema (100% coverage), so the description adds minimal additional meaning. It does not elaborate on parameter details beyond the schema, so a baseline score of 3 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 the verb 'Browse' and identifies the resource 'available affiliate programs in the AgentFuse catalog', making the action and scope clear. It also hints at its role relative to siblings by stating 'before generating tracked links', distinguishing it from generate_tracked_link and get_affiliate_program.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 advises using this tool 'to discover programs before generating tracked links', providing clear context for when to use it. However, it does not explicitly state when not to use it or mention alternative sibling tools.

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

• record_commissionA
  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 compensate. It discloses idempotency (safe to call multiple times with same network+network_event_id), which is key. However, it does not describe what happens on failure (e.g., invalid tracking_code), whether the endpoint is read-only or not, or any side effects. Some behavioral context 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?

  Three concise sentences: purpose with example, prerequisite, and idempotency note. No unnecessary words, front-loaded with key 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 and no output schema, the description covers the essential usage context but lacks explanation of return values or error handling. It adequately complements the detailed schema but could be more comprehensive (e.g., what the response looks like, permissions 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?

  Since schema description coverage is 100%, baseline is 3. The description adds minimal extra meaning: it emphasizes that tracking_code comes from generate_tracked_link (already in schema) and that network_event_id is used for idempotency (also in schema). No significant new parameter 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 action ('Record an affiliate commission event') and provides a concrete example (purchase or renewal). It distinguishes from sibling tools like record_signup and generate_tracked_link by specifying the trigger (referred user purchase/renewal) and the required tracking_code from generate_tracked_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 (upon purchase or subscription renewal) and notes the prerequisite of having a tracking_code from generate_tracked_link. It also mentions idempotency, suggesting safe retries. However, it does not explicitly state when not to use or provide alternatives.

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

• list_tracked_linksA
  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 burden. It discloses return fields but does not explicitly state read-only nature, authorization needs, or potential side effects. The word 'list' implies read, but not 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?

  Two sentences with no fluff: first defines purpose and output, second gives usage guidance. 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 tool with good schema and no output schema, the description adequately covers purpose, return fields, and usage context. Could mention pagination behavior explicitly but schema covers cursor param.

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

  Parameters3/5

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

  Schema coverage is 100% with detailed parameter descriptions. The description adds no new parameter-level information beyond restating usage context, which does not exceed the baseline for high coverage.

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

  Purpose5/5

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

  The description clearly states it lists tracked affiliate links previously generated by this API key, with specific fields returned. It distinguishes from sibling tools like generate_tracked_link (creation) and list_affiliate_programs (programs).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 tells when to use: 'to look up existing links before generating a new one, or to show a user their active referral links.' It does not explicitly exclude alternatives but provides clear context.

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

• get_statsA
  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 states the tool retrieves stats but does not disclose behavioral traits such as data freshness, caching, or whether it requires specific permissions. The simplicity of a zero-parameter tool partially mitigates this.

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

  Conciseness5/5

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

  The description is a single sentence that is concise and front-loaded with the tool's purpose. 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?

  Given zero parameters and no output schema, the description is fairly complete. It specifies what stats are retrieved and a use case. It could mention if the stats are aggregate over all time or filtered, but not necessary for a simple endpoint.

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

  Parameters4/5

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

  The input schema has no parameters, and schema description coverage is 100%. Baseline for zero parameters is 4, and the description adds no extra parameter info (none 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 it retrieves dashboard summary stats and lists specific metrics (total clicks, signups, commissions, top-performing programs). It distinguishes from sibling tools like generate_tracked_link or record_commission, which focus on individual 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 mentions it is useful for reporting to users or surfacing revenue data, providing clear context. However, it does not explicitly exclude cases where other tools like list_affiliate_programs might be more appropriate.

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

• record_signupA
  4.2/5.0
  Behavior4/5

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

  Discloses idempotency and safety of multiple calls. Without annotations, description provides essential behavioral context about side effects and dependency.

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

  Conciseness5/5

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

  Four sentences, no waste. Purpose first, then condition, prerequisite, and idempotency. 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?

  Covers purpose, trigger, prerequisite, and idempotency. Lacks return value or error handling, but no output schema expected. Adequate for a simple recording 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 100%, so description adds limited value. It reinforces tracking_code's role and network_event_id's idempotency use, but doesn't go beyond 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?

  Clear verb ('Record'), resource ('affiliate signup conversion event'), and condition ('when user signs up'). Distinguishes from siblings like generate_tracked_link (prerequisite) and get_stats.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 call (signup success) and prerequisite (tracking_code). Mentions idempotency but doesn't explicitly exclude alternatives; however, siblings don't overlap.

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

• generate_tracked_linkA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description discloses that the link records clicks, attributes signups/commissions, and returns a short redirect URL and tracking_code. It also mentions optional metadata. This is sufficient for a creation 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. It front-loads the purpose, then provides usage details and behavioral implications. Every sentence is informative and earned.

  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 no output schema, the description explains the return values (short redirect URL and tracking_code) and their importance for sibling tools. All parameters are covered, and the context of the affiliate system is clear.

  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 100%, but the description adds value by explaining that program_slug is human-readable with automatic UUID resolution, and that end_user_id can be any stable unique string. This goes beyond the 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 'Generate a tracked affiliate link for a program and an end user' with a specific verb and resource. It clearly distinguishes from siblings by mentioning the tracking code needed for record_signup and record_commission, and clarifies that it uses human-readable slugs.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 guidance on passing the human-readable slug and saving the tracking_code for later use. It implies usage context as a prerequisite for record_signup and record_commission, but does not explicitly 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.

• get_affiliate_programA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description adequately conveys this is a read-only lookup (no mention of side effects). It explains the output includes commission structure, payout terms, etc. The description is transparent about what the tool does, though it could mention if there are any rate limits or authentication requirements, but for a simple read operation 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 concise sentences with front-loaded key 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.

  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 parameter and no output schema, the description fully explains the purpose, parameter, return contents, and links to related tools. Nothing is missing.

  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 100% coverage and the description adds meaningful context: it gives example slugs ('webflow', 'elevenlabs') and tells the user to use list_affiliate_programs to find more slugs. This goes beyond the schema 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 it retrieves full details for a single affiliate program by slug. It lists specific return fields (UUID, commission, payout terms, etc.) and distinguishes from sibling tools like list_affiliate_programs (listing all) and generate_tracked_link (which requires the UUID from 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 explicitly notes that the slug parameter can be discovered using list_affiliate_programs, and that the returned UUID is needed for generate_tracked_link. While it doesn't state explicit when-not-to-use scenarios, the context is clear and provides helpful direction.

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