Server Quality Checklist

Tool Scores

• originality_batch_scanA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided; description merely mentions 'same scan options' and efficiency, but omits critical behavioral details like batch size limits, credit consumption, error handling, and result 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?

  Extremely concise: two sentences that front-load purpose and efficiency benefit. No superfluous 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?

  No output schema; description fails to explain return values, error handling, or how to interpret batch results. Lacks credit cost or rate limit context essential for a batch 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 100% with clear descriptions. The tool description adds minimal extra meaning beyond stating that options apply uniformly across items, which is already implied.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 verb 'process' and resource 'multiple content scans'. It distinguishes from siblings by explicitly noting efficiency for bulk content compared to individual scans.

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

  Usage Guidelines4/5

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

  Description implies usage for bulk scanning with efficiency benefit, but lacks explicit exclusion criteria or comparison with sibling tools like originality_scan for different options per item.

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

• originality_scanA
  3.6/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 for behavioral disclosure. It reveals that enabled checks consume credits and that content must be plain text, but it does not disclose rate limits, whether results are returned synchronously, what happens if credits are insufficient, or how stored results are structured. The storeScan parameter suggests persistence but is not explained.

  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 with two sentences. The first sentence front-loads the comprehensive capabilities, and the second adds key constraints. While efficient, it could benefit from a slightly more structured breakdown of the scan types.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 15 parameters (9 required), no output schema, and no annotations, the description covers the core purpose and credit consumption but lacks details on return format, processing model (sync/async), and how to use stored results. It is sufficient for basic understanding but not fully complete for an agent to predict behavior without additional 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 100%, so the baseline is 3. The description adds minimal value beyond the schema: it notes that plain text is required and that credits are consumed per check. No deeper semantics are provided for 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 tool performs a comprehensive content scan and lists all specific checks (AI detection, plagiarism, fact checking, readability, grammar/spelling, SEO). It distinguishes from siblings like originality_scan_url and originality_batch_scan by focusing on plain text content for a single scan.

  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 mentions the requirement for plain text content and that each enabled check consumes credits, which provides some usage context. However, it does not explicitly guide when to use this tool versus alternatives like originality_scan_url or originality_batch_scan, nor does it specify exclusions or alternatives.

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

• originality_scan_urlA
  3.8/5.0
  Behavior3/5

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

  Without annotations, the description bears full behavioral burden. It discloses that the API fetches content and runs checks, but lacks details on authorization, rate limits, destructiveness, or latency. It adds some value beyond the schema but is 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 two sentences, front-loaded, and no fluff. Every 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?

  Despite 100% schema coverage, the description omits what the tool returns (e.g., scan ID or result object). Since the sibling 'originality_get_scan_results' exists, it implies this tool submits a scan, but no mention of output format. With 15 parameters and no output schema, 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 coverage is 100%, so parameters are well-documented. The description adds no additional meaning beyond the schema; it only mentions the 'URL' parameter implicitly. Baseline 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 clearly states it scans content from a URL, fetching and analyzing it like a regular scan. It effectively distinguishes from siblings like originality_scan (direct text) and batch_scan (batch processing).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 it is 'useful for analyzing published web pages,' implying when to use via URL. It mentions 'same checks as a regular scan,' hinting at alternatives, but does not explicitly state when not to use or compare to other tools.

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

• originality_get_scan_resultsA
  4.1/5.0
  Behavior4/5

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

  Discloses the critical behavioral condition (storeScan required) beyond the schema. With no annotations, this adds transparency. Could mention error handling or auth needs.

  Agents need to know what a tool does to the world before 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. 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.

  Completeness3/5

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

  Covers purpose and condition. Lacks output format or error cases, but given single param and no output schema, it's minimally adequate. Could be more 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 already describes scanId as 'The privateID'. Description adds no further meaning to the parameter itself, just the condition. Baseline 3 due to 100% 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 retrieves stored scan results by scan ID, with a key condition (storeScan=true). It distinguishes from siblings like originality_scan which likely creates scans, and originality_batch_scan.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 only works for scans that had storeScan set to true, guiding when to use. Could further indicate when to use alternatives like originality_scan if not stored.

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

• originality_get_credit_balanceA
  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 must convey behavioral traits. It correctly implies a read-only operation ('Retrieve') and states the result (credit balance). However, it does not specify any rate limits or authentication requirements, but for a simple balance check this is 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 with no extraneous information. The most important information (what it does and when to use it) is 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.

  Completeness3/5

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

  While the tool is simple, the description lacks information about the return value format (e.g., number, object). Since there is no output schema, the description should clarify what the response contains. This is a notable gap.

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

  Parameters4/5

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

  The input schema has zero parameters, so schema description coverage is 100%. Per guidelines, a baseline of 4 is appropriate. The description adds no parameter details, which is fine since there are none.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value 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 ('Retrieve') and the resource ('current account credit balance'). It distinguishes from sibling tools, which are all scanning-related, making this a unique and 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?

  The description explicitly recommends using this tool before running scans to check credit availability. This provides good contextual guidance, though it does not mention any exceptions or alternative use cases.

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