Server Quality Checklist

Tool Scores

• profileA
  3.6/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 behavioral disclosure burden. It mentions that some platforms require login and which have exact counts, but does not disclose rate limits, error handling, or side effects. The read-only nature is implied by 'Get...metrics'.

  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, front-loaded with the main purpose and fields, then platform-specific details. Every sentence adds value; no redundancy or filler.

  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 simple tool with one parameter and no output schema, the description is reasonably complete, covering returned fields and platform nuances. It omits potential error conditions (e.g., invalid URLs) but is adequate for typical use.

  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 single parameter 'url' is fully described in the schema with examples. The tool description does not add additional semantics beyond what the schema provides, but the schema itself is adequate. Score at baseline given 100% coverage.

  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 retrieves account-level metrics for a profile URL and lists the returned fields. It does not explicitly differentiate from siblings like 'profile_batch' or 'metrics', but the purpose is specific and unambiguous.

  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 provides platform-specific usage notes (e.g., Threads/LinkedIn need login) but does not explicitly say when to use this tool over alternatives like 'profile_batch' or 'metrics'. Usage context is implied rather than explicit.

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

• metrics_batchA
  4/5.0
  Behavior4/5

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

  Discloses max 50 items, mixed types allowed, order preservation, and response format including error handling. Lacks details on rate limits or authentication, but core behavior is well covered.

  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 purpose, efficient and 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?

  Explains return structure despite no output schema, but could detail metrics object fields. Covers error responses. Parameter is well explained, though sibling contrasts are missing.

  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?

  Description adds max 50 constraint and mixed types beyond schema description ('Public post URLs'). However, schema description contradicts tool description by only mentioning posts. This inconsistency reduces clarity.

  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 'Get metrics for many posts and/or profiles in one call', distinguishing it from singular sibling tools like 'metrics' and 'profile_batch'. Specifies batch capability and return structure.

  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 batch operations with 'in one call' and 'max 50', but does not explicitly contrast with singular 'metrics' tool or specify when not to use it. No direct alternative guidance.

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

• profile_batchA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided. The description discloses return structure ({ count, results }), order preservation, and error handling (profile object or { url, error }). However, it omits details on idempotency, rate limits, or side effects, which are needed for a batch 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 two sentences, front-loaded with the primary action and key constraints. Every word adds value without 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?

  Given no output schema, the description explains the return format and error behavior. With one well-documented parameter and low complexity, the description covers all necessary information for correct usage.

  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 covers the single parameter 'urls' with 100% description, specifying type, max items, and mixed platforms. The description reiterates this without adding new semantic meaning. Baseline 3 applies.

  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 account-level metrics for multiple profile URLs in one call, specifying it is like the 'profile' tool but supports up to 50 URLs. It lists compatible platforms (YouTube, TikTok, etc.), making the purpose unambiguous.

  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 contrasts with the sibling 'profile' tool by highlighting batch capability and mixed platforms. It provides a use case (comparing follower counts across creators), but does not explicitly mention when not to use this tool or how it differs from 'metrics_batch'.

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

• metricsA
  4.3/5.0
  Behavior4/5

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

  No annotations provided, so description covers behavioral traits: explains normalization of fields (shares, quotes, bookmarks), mentions it's free, and implies read-only access. Lacks details on rate limits or error handling.

  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?

  Single paragraph packed with information, no filler. Could benefit from bullet points for platforms or output fields, but remains clear and efficient.

  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 one parameter and no output schema, the description fully explains inputs, outputs, and supported platforms. Completeness is high, though including expected response format or error cases would elevate further.

  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?

  Only one parameter 'url', schema describes it as 'The public post URL (short links OK).' Description adds meaning: resolves short links automatically and lists compatible platforms, exceeding the schema's 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 'Get a public social post's metrics' with a specific verb and resource, and lists supported platforms and output fields, distinguishing it from sibling tools like metrics_batch and profile.

  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 clear usage context: provide a post URL, short links resolve automatically, lists supported platforms. Implicitly distinguishes from batch tool, but lacks explicit 'when not to use' guidance.

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

• historyA
  4.7/5.0
  Behavior4/5

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

  No annotations provided, so the description carries full burden. It discloses return format (series with fields for posts and profiles), ordering, and behavior for unfetched URLs (empty series). It does not mention authentication or side effects, but it's a read-only 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?

  Three succinct sentences: first states purpose and return, second explains 'since' parameter, third explains empty series case. Each sentence adds value, and the most important information is front-loaded.

  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 tool with 2 parameters and no output schema, the description explains the return format, the 'since' parameter usage, and the empty series behavior. This is sufficient for an agent to use the tool correctly without additional documentation.

  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 100%, but the description adds meaning beyond: explains the 'since' parameter for delta polling, and hints at return fields. The URL parameter is described as public post or profile URL. This provides useful context for correct usage.

  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 gets the recorded metrics history of a post or profile, the growth curve, and specifies the return format (series of snapshots) and ordering (oldest first). It distinguishes from siblings by focusing on history vs. current metrics.

  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?

  The description explicitly tells when to use this tool: to get history, and when to use alternatives: call metrics or profile if the series is empty. It also explains the 'since' parameter to poll delta, avoiding fetching the whole series.

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