Server Quality Checklist

Tool Scores

• search_archive_itemsC
  2.7/5.0
  Behavior2/5

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

  No annotations are provided, and the description only states it searches items. It does not disclose behavior such as pagination, result ordering, or what happens with empty queries.

  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 concise sentence that is easy to read. However, it is overly terse and could be expanded to include more detail without becoming 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?

  Given no output schema and minimal parameter descriptions, the description does not provide enough context for an agent to understand what the tool returns or how it behaves. Lacks details on pagination, result format, or error 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%. The description hints at media types ('books, audio, video, software') but does not explicitly link to the 'mediatype' parameter or explain 'query' and 'limit'. Some value added, but insufficient.

  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 searches Internet Archive items and lists example media types. However, it does not differentiate from sibling tools like 'get_archived' which might also search items.

  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?

  No guidance on when to use this tool versus alternatives like 'archive_url' or 'list_snapshots'. No context about prerequisites or limitations.

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

• list_snapshotsB
  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 full burden but fails to disclose behavioral traits such as pagination, rate limits, or whether it returns metadata only. It merely states the 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?

  Single sentence, 10 words, no redundancy. Front-loaded with key action and resource. Highly concise.

  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 four parameters, required url, no output schema, and multiple sibling tools, the description lacks completeness. It does not explain return format, pagination (implied by limit), or differentiation from get_archived and search_archive_items.

  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 50% (from and to have descriptions). The description adds 'optionally filtered by date range' but does not clarify url or limit beyond schema. Baseline 3 is appropriate as description adds minimal extra 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 tool lists Wayback snapshots for a URL, with optional date range filtering. It uses specific verbs and resource, and distinguishes from siblings like compare_snapshots or fetch_archived_text.

  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 for listing snapshots with filters but does not provide explicit guidance on when to use this tool versus alternatives like search_archive_items. No exclusions or when-not-to-use advice.

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

• archive_urlA
  3.5/5.0
  Behavior2/5

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

  No annotations provided; the description only mentions return of the snapshot URL. It does not disclose side effects, rate limits, authentication needs, or whether the archiving is synchronous. The statement 'right now' hints at immediacy but lacks specificity.

  Agents need to know what a tool does to the world before calling it. Descriptions 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 efficiently conveys the tool's purpose and result, with no superfluous 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 simplicity (one parameter, no output schema), the description is minimally adequate but lacks information on preconditions (e.g., URL accessibility), idempotency, or 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 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter description, and no additional validation or format hints are 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 ('Submit a URL to be archived right now') and the resource ('Wayback Machine'), with a distinct purpose from siblings that focus on retrieval or comparison.

  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 immediate archiving but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. Usage is inferred from the sibling tools' different purposes.

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

• compare_snapshotsA
  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 full burden. It discloses the return type (line counts and sample changes) but does not mention destructive behavior, authentication needs, rate limits, or size limits implied by the max_chars parameter.

  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 concise sentence that conveys the core purpose and output. It could be slightly improved by adding structure (e.g., listing parameters), but it is not verbose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 output schema is provided, so the description must explain the return value. It does so minimally ('line counts and sample changes'), but lacks detail on the structure of sample changes, error handling, or behavior with invalid inputs. 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 description coverage is only 25% (only date_a has a description). The description adds minimal context ('of the same URL') but does not detail the format of date_a and date_b, nor explain the purpose of max_chars. 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 clearly states the tool compares two Wayback snapshots by extracted text, specifying the output (added/removed line counts and sample changes). It distinguishes itself from sibling tools like list_snapshots and fetch_archived_text.

  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 for comparing two snapshots of the same URL but does not explicitly state when to use this tool versus alternatives (e.g., fetch_archived_text for single snapshot). No exclusions or alternatives are mentioned.

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

• get_archivedA
  3.5/5.0
  Behavior3/5

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

  No annotations provided, so description must carry full burden. It states behavior (closest snapshot, default to most recent) but does not disclose error handling, authorization needs, or side effects. Adequate for a read operation but lacks completeness.

  Agents need to know what a tool does to the world before 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, 14 words, directly states purpose with no filler. 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?

  Tool is simple but lacks output schema. Description does not hint at return format (e.g., snapshot metadata, URL, status). Without annotations, more context about behavior and results 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 50% (date parameter described). Description adds that date defaults to most recent, which is helpful. But url parameter lacks description and tool does not clarify expected format 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?

  Specific verb 'Get' and resource 'Wayback snapshot' clearly state the tool's purpose. The description distinguishes from siblings like 'list_snapshots' and 'fetch_archived_text' by specifying it retrieves the closest snapshot.

  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?

  No explicit guidance on when to use this tool versus alternatives. While sibling names imply other use cases, the description does not provide any when-to-use or when-not-to-use advice.

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

• fetch_archived_textA
  3.8/5.0
  Behavior3/5

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

  Discloses stripping HTML/scripts/nav/Wayback toolbar and context window handling, but does not specify return format or potential rate limits. With no annotations, more detail on behavior (e.g., truncation) 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?

  Two sentences, front-loaded with key information (purpose, cleaning, context window). No redundant 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?

  Covers main aspects: what it does, cleaning, context window. Lacks explicit mention of return format or metadata, but given no output schema and simplicity of the tool, it is mostly 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 low (33%), but the description adds context: cleaning and context window explain the purpose of url and max_chars. However, it does not provide explicit details for each parameter, only overarching 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?

  Describes fetching an archived snapshot and returning clean readable text, which clearly states the action and output. Distinguishes itself from siblings like archive_url (archiving) and compare_snapshots (comparison) by focusing on text extraction.

  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?

  Implies use for obtaining clean text for LLM context, but no explicit when-not-to-use or alternatives. Sibling tools exist (e.g., get_archived might return raw HTML) but no guidance is provided.

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