Server Quality Checklist

Tool Scores

• get_task_statusA
  3.8/5.0
  Behavior3/5

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

  Annotations provide readOnlyHint and openWorldHint. The description adds return details but does not address the open world hint (e.g., potential external side effects). Disclosures are 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?

  Single sentence with no wasted words, front-loaded with the primary action and resource. Every part 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 single parameter, no output schema, and thorough annotations, the description sufficiently covers purpose and return values. Lacks mention of potential limitations like max tasks or pagination, but not critical.

  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 clear parameter description ('Task IDs from create_task'). The tool description adds context about 'one or more' but does not significantly enhance 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?

  The description clearly states the tool retrieves status and progress of Upvote.club tasks, specifying exact information returned (actions completed, progress percentage, meaningful comment submissions). This distinctly separates it from sibling tools like create_task or delete_task.

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

  Usage Guidelines3/5

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

  The description implies usage when task status is needed, but lacks explicit guidance on when not to use it or alternatives. No mention of prerequisites or conflict with other tools.

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

• delete_taskA
  4.2/5.0
  Behavior4/5

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

  Adds significant behavioral context beyond annotations: refunds unused points, restores a daily task slot, and prohibits deletion of completed tasks. Annotations already signal destructiveness and idempotency, but description fleshes out specifics.

  Agents need to know what a tool does to the world before 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: first states action, second adds side effects, third adds constraints and user guidance. 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?

  Covers core behavior, side effects, constraints, and usage instruction. Lacks mention of error cases or return values, but acceptable given no output schema and simple 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?

  Only one parameter (task_id) with 100% schema coverage; description does not add further meaning beyond the schema's description. Baseline 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?

  Clearly states it deletes an Upvote.club task, refunds points, and restores slots. Distinguishes from siblings like create_task and get_task_status by specifying the action and side effects.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 instruction to confirm with the user first, and states that completed tasks cannot be deleted. Does not mention alternatives or when not to use, but context is clear.

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

• create_taskA
  4.3/5.0
  Behavior4/5

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

  Annotations declare it's not read-only, not idempotent, not destructive. The description adds behavioral context: 'SPENDS points (price × actions_required, plan discount) and 1 daily slot' and 'Auto-detects platform from URL,' which goes beyond annotations to explain 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 four sentences, front-loading the purpose. It includes necessary details (costs, references, constraints) without superfluous text. Could be slightly tighter, but efficient overall.

  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 parameters, no output schema, and annotations, the description covers core purpose, costs, auto-detection, and minimums. It references get_api_reference for examples and errors, partially compensating for missing return info. Leaves little 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?

  Schema coverage is 78%, so baseline is 3. The description adds value by explaining auto-detection of social_network_code when omitted and specific minimum points for GitHub/Product Hunt and meaningful COMMENT, which are not in 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 starts with 'Create a promotion task on Upvote.club,' clearly stating the verb and resource. It distinguishes from siblings like delete_task and get_api_reference by focusing on creation and referencing costs (points, daily slot) and auto-detection.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 implicitly guides usage by noting it spends points and a daily slot, and suggests calling get_api_reference for examples. It does not explicitly state when not to use it, but the context of constraints provides adequate guidance.

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

• get_api_referenceA
  4.7/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 value by specifying that the tool provides request examples, pricing rules, and error catalogs, giving insight into the content. It does not contradict annotations and 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?

  Description is concise (two sentences) and front-loaded with the tool's purpose. Every clause adds value: listing contents, giving usage hint. 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?

  Given no parameters, no output schema, and annotations indicating a safe read-only tool, the description fully covers what an agent needs: purpose, contents, and when to call. It is complete and actionable.

  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?

  Tool has zero parameters with 100% schema coverage, so the description does not need to add parameter-level semantics. The baseline of 4 applies as no additional explanation is 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?

  Description clearly states it is the 'Full Upvote.club Public API reference' and enumerates its contents (inputs/outputs, examples, pricing, errors). It distinguishes itself from sibling tools like create_task and list_platforms by being a reference rather than an 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?

  Explicitly says 'Call before create_task if unsure about fields or pricing,' providing clear guidance on when to use this tool versus alternatives. This directly tells the agent to invoke it as a prerequisite for create_task.

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

• list_platformsA
  4.7/5.0
  Behavior4/5

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

  Annotations already mark as readOnlyHint=true. Description adds context about what data is returned (actions, price, example URLs), which is useful beyond the annotation. No mention of rate limits or auth, but not needed for a simple 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?

  Two sentences, no fluff. First sentence defines purpose and output, second gives usage advice. Perfectly front-loaded and 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?

  Given no input params, no output schema, and simple purpose, description fully explains what the tool returns (platforms, actions, minimum price, example URLs). No gaps 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?

  No parameters in schema, so no param description needed. Baseline 4 per guidelines for 0-param tool. Description adds no redundant parameter info.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 verb and resource: 'List all social platforms supported by Upvote.club' with details of returned data (actions, price, URLs). Clearly distinguishes from sibling tools which are task management operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'Call this first if you are unsure which platform or action applies', providing clear when-to-use guidance and implying it's a discovery tool.

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