Server Quality Checklist

Tool Scores

• get_manga_chaptersB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't mention potential side effects, rate limits, authentication needs, or what 'recent' means (e.g., time frame). This leaves gaps in understanding how the tool behaves beyond basic 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 a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part ('List recent English chapter metadata for a manga') contributes directly to understanding the tool, 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 an output schema (which handles return values), low schema coverage, and no annotations, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, parameter usage, and sibling differentiation. For a list tool with three parameters, it should provide more context to be 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 low at 33%, with only 'mangaId' having a description. The tool description adds minimal value by implying 'recent' and 'English' filtering, but doesn't explain how these relate to the parameters (e.g., if 'limit' affects recency or if language is hardcoded). It partially compensates for the coverage gap but doesn't fully clarify parameter meanings 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 action ('List') and resource ('recent English chapter metadata for a manga'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_chapter_access_info' or 'get_manga_details', which might also involve chapter or manga data, so it lacks sibling distinction for 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 Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'get_chapter_access_info' or 'search_manga'. It mentions 'recent' and 'English' as implicit context, but there are no explicit when/when-not instructions or named alternatives, leaving usage unclear in relation to siblings.

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

• search_mangaB
  3.1/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 states it returns 'search metadata only', which implies a read-only operation, but doesn't disclose behavioral traits such as rate limits, authentication needs, pagination, or error handling. This is a significant gap for a search 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 a single, efficient sentence with zero waste. It front-loads the key action and resource, making it easy to parse quickly without unnecessary elaboration.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 (a search function with one parameter) and the presence of an output schema, the description is minimally adequate. However, with no annotations and incomplete behavioral disclosure, it lacks depth for safe and effective use, though the output schema mitigates some gaps by defining return values.

  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 description coverage is 100%, with the single parameter 'query' fully documented in the schema. The description adds minimal value by mentioning 'by title', which aligns with the schema's 'manga title to search for', but doesn't provide additional syntax, format details, or constraints beyond what the schema already covers.

  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 ('Search MangaDex by title') and the resource ('MangaDex search metadata'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get_manga_details' or 'get_manga_chapters', which might also involve manga data retrieval but with different scopes or purposes.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives. It mentions returning 'MangaDex search metadata only', which hints at the output type, but doesn't specify scenarios, prerequisites, or exclusions compared to siblings like 'get_manga_details' for detailed info or 'get_manga_chapters' for chapter lists.

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

• get_chapter_access_infoA
  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 the full burden. It discloses that the tool returns metadata and URLs, and explicitly states a behavioral constraint ('MangaDex does not provide PDF/CBZ download URLs here'), which is useful context. However, it doesn't cover other potential behaviors like error handling, rate limits, authentication needs, or response format details, leaving 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?

  The description is two sentences that are front-loaded with the core purpose and efficiently add a critical exclusion. Every word earns its place, with no redundancy or fluff, making it highly concise and well-structured for quick understanding.

  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 an output schema (which handles return values), 1 parameter with 100% schema coverage, and no annotations, the description provides good contextual completeness. It clearly states the tool's purpose and a key limitation (no PDF/CBZ URLs), which compensates for the lack of annotations. However, it could be more complete by explicitly differentiating from sibling tools or mentioning any authentication requirements.

  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%, with the parameter 'chapterId' fully documented in the schema as a MangaDex UUID. The description doesn't add any parameter-specific information beyond what's in the schema, such as examples or usage notes. Since the schema handles the parameter documentation adequately, the baseline score of 3 is appropriate.

  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 ('Return') and resource ('chapter access metadata'), specifying what information is included (MangaDex reader URL or external host URL) and what is excluded (PDF/CBZ download URLs). It distinguishes from siblings like export_chapter_cbz/pdf by explicitly stating what it doesn't provide, though it doesn't explicitly contrast with get_manga_chapters or get_manga_details.

  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 by stating what the tool returns and what it doesn't (no PDF/CBZ URLs), suggesting it's for accessing reading URLs rather than downloads. However, it doesn't explicitly state when to use this tool versus alternatives like get_manga_chapters or get_manga_external_links, nor does it mention prerequisites or exclusions beyond the format limitation.

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

• get_manga_external_linksA
  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 indicates this is a read operation ('Return'), which is helpful, but doesn't mention potential constraints like rate limits, authentication requirements, or what happens with invalid manga IDs. The description adds value by specifying what types of links are included, but lacks operational details an agent would 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 exceptionally concise and well-structured in a single sentence. Every element earns its place: the core action ('Return only external links'), the target resource ('for a manga'), and the scope clarification ('including MangaDex itself and any mapped sites'). There's zero redundancy or wasted verbiage.

  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 simple nature (single parameter, read-only operation), the presence of an output schema, and 100% schema coverage, the description is reasonably complete. It clearly states what the tool returns and includes helpful scope information. The main gap is lack of behavioral details that would be important for an agent (like error handling), but the output schema reduces the need to describe return values.

  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 schema already fully documents the single mangaId parameter. The description doesn't add any parameter-specific information beyond what's in the schema. This meets the baseline expectation when schema coverage is complete, but provides no additional semantic context about parameter usage or constraints.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Return only external links for a manga' specifies both the action (return) and resource (external links for manga). It distinguishes from siblings like get_manga_details by focusing specifically on external links, though it doesn't explicitly name alternatives. The mention of 'MangaDex itself and any mapped sites' provides helpful scope clarification.

  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 context by specifying 'only external links' and mentioning what's included, suggesting this tool is for retrieving link references rather than full manga data. However, it doesn't explicitly state when to use this versus get_manga_details (which might also contain links) or provide clear exclusion criteria. The guidance is present but not comprehensive.

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

• export_chapter_cbzA
  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 burden. It discloses key behavioral traits: it creates a local file (implied mutation/destructive operation), has a limitation (external chapters cannot be exported), and provides output reporting guidance. However, it doesn't mention authentication requirements, rate limits, error conditions, or what happens if the chapter doesn't 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?

  Two sentences, zero waste. First sentence states purpose and key limitation. Second sentence provides valuable output reporting 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.

  Completeness4/5

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

  Given the tool has an output schema (which handles return values), 100% schema coverage, and no complex nested objects, the description is reasonably complete. It covers the core purpose, key limitation, and output reporting guidance. The main gap is lack of behavioral details like authentication or error handling, but with output schema existing, this is less 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 description coverage is 100%, so the schema already fully documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema descriptions (like explaining UUID format or data-saver vs original quality trade-offs). Baseline 3 is appropriate when schema does the heavy lifting.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value 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 ('Export'), resource ('internal MangaDex chapter'), and output format ('local CBZ file'), distinguishing it from sibling tools like export_chapter_pdf (different format) and get_chapter_access_info (information retrieval rather than file export). It explicitly mentions the limitation to internal chapters only.

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

  Usage Guidelines4/5

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

  The description provides clear context about when to use this tool ('Export an internal MangaDex chapter') and when not to use it ('External-hosted chapters cannot be exported'), but doesn't explicitly mention alternatives like export_chapter_pdf for different formats or when to use information retrieval tools instead. The reporting guidance ('prefer reporting only the saved path') is helpful but not about tool selection.

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

• export_chapter_pdfA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context by specifying that the tool saves a file locally and advising on reporting behavior ('prefer reporting only the saved path unless the user asked for more detail'). However, it lacks details on potential errors (e.g., if chapterId is invalid), file naming conventions, or performance aspects like rate limits, which are important for a file export 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 front-loaded with the core purpose in the first sentence, followed by a limitation and a usage tip. Both sentences earn their place by providing essential information without redundancy. It's appropriately sized for a tool with clear parameters and an output schema, avoiding unnecessary elaboration.

  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 (3 parameters, 100% schema coverage, output schema exists), the description is mostly complete. It covers the purpose, limitations, and reporting advice. However, with no annotations and an output schema (which handles return values), it could benefit from more behavioral details like error handling or file system interactions to fully compensate for the lack of annotations.

  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 schema already documents all parameters thoroughly (chapterId as UUID, quality with enum values, outputDir as optional directory). The description does not add any parameter-specific semantics beyond what's in the schema, such as explaining the implications of 'data-saver' vs 'original' quality or default output locations. Thus, it meets the baseline but doesn't enhance 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 specific action ('Export') and resource ('an internal MangaDex chapter to a local PDF file'), distinguishing it from sibling tools like export_chapter_cbz (which exports to CBZ format) and get_chapter_access_info (which retrieves metadata rather than exporting). It explicitly mentions the limitation that external-hosted chapters cannot be exported, which further clarifies its 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 clear context on when to use this tool by stating it's for exporting internal MangaDex chapters to PDF and that external-hosted chapters cannot be exported. However, it does not explicitly mention when to use alternatives like export_chapter_cbz for CBZ format or get_chapter_access_info for checking export eligibility, leaving some guidance 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.

• get_manga_detailsA
  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 tool's purpose and preference for metadata-only reporting, but lacks details on behavioral traits like rate limits, authentication needs, or response format. The mention of 'Prefer reporting only this metadata' adds some context, but more behavioral information 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.

  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 followed by a usage preference. Every sentence adds value without redundancy, making it 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 tool has one parameter with full schema coverage and an output schema exists, the description is reasonably complete. It covers the purpose and usage preference, but as a read operation with no annotations, it could benefit from more behavioral details like response structure or limitations, though the output schema mitigates this.

  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 description coverage is 100%, so the schema fully documents the mangaId parameter. The description adds no specific parameter semantics beyond what the schema provides, but since there's only one parameter and coverage is high, the baseline is 3. The description's focus on metadata and external links gives slight context, raising it to 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 specific action ('Return'), resource ('MangaDex metadata and mapped external links for a manga'), and distinguishes from siblings by specifying 'Prefer reporting only this metadata, not general background knowledge', which differentiates it from tools like search_manga that might return broader results.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 ('Prefer reporting only this metadata'), implying it's for detailed metadata retrieval rather than general searches. However, it doesn't explicitly name alternatives or state when not to use it, such as distinguishing from get_manga_external_links which might focus only on links.

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