Server Quality Checklist

Tool Scores

• get_place_infoA
  4/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the burden of disclosing behavior. It implies a read-only metadata lookup by saying 'metadata' and listing returned fields, but it does not explicitly state that no data is modified, nor does it mention authentication, rate limits, or error behavior. This is adequate for a simple read tool but 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 with no filler. The first sentence states the resource and returned fields, and the second gives a practical usage context. Every sentence earns its place 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.

  Completeness4/5

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

  For a simple two-parameter metadata lookup with no output schema, the description adequately names the key returned data fields and the intended use case. It does not explain return formatting or edge cases, but the scope is small enough that the description is nearly 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 100%, so the input schema already explains placeId and universeId well. The tool description adds no parameter-specific meaning beyond the schema's own descriptions; it only names output fields rather than clarifying the input parameters. 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 identifies the tool as retrieving Open Cloud metadata for a specific place within a universe, listing exact fields returned (name, description, server size, server fill behaviour). It distinguishes itself from sibling tools like get_universe_info and get_server_status by scoping to a single place rather than a universe or status endpoint.

  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 a concrete use case: use it when performance metrics broken down by Place point to a specific place ID that needs identification. It does not explicitly mention when not to use it or name alternatives, but the context is clear enough for an agent to select it appropriately.

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

• set_default_universeA
  4/5.0
  Behavior4/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 that the tool writes to a local config file and does not change anything on Roblox, which is a key behavioral trait. However, it does not detail overwrite behavior or return values.

  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 long, front-loads the main purpose, and the second sentence adds a critical caveat. 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?

  The tool is simple (2 params, no output schema) and the description covers purpose, side effects, and the alias feature. It lacks explicit mention of return values or repeated-call behavior, but for a small configuration setter this is nearly sufficient.

  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 that the alias is a short name usable wherever universeId is accepted, but this is already in the schema. The description doesn't add significant new meaning beyond the 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 a specific verb ('Store') and resource ('default universe ID'), explaining the purpose of allowing later calls to omit universeId. It also distinguishes this configuration tool from the analytics/metrics siblings.

  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 you want to set a persistent default for subsequent calls, and the local-config write contrasts with Roblox-side changes. However, it does not explicitly state when to use it versus alternatives or when not to use it.

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

• get_metric_reportA
  4.1/5.0
  Behavior3/5

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

  Since no annotations are provided, the description carries the full burden. It discloses two behavioral traits: metrics with no data return an error field instead of failing the report, and the performance pack only retains 28 days of history. These are useful but not comprehensive; it does not mention auth, rate limits, or other edge cases. This is adequate but not rich.

  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 somewhat long due to the extensive metric lists, but it is well-structured with bullet points for each pack, making it easy to scan. The core purpose and usage guidelines are front-loaded. Every sentence contributes: the purpose, the pack list, the use case, and the retention note. It is appropriately concise for the information it must convey.

  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 complexity (10 parameters) and the presence of a complete schema, the description focuses on the high-level concept of packs, usage guidance, and key behavioral notes. It does not detail every parameter's behavior (e.g., filter semantics) but those are in the schema. The absence of an output schema is acceptable as the tool likely returns straightforward results. The description covers enough for an agent to decide when to use it and what to expect.

  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%, so the baseline is 3. The description adds substantial semantic value for the 'pack' parameter by enumerating all metrics in each pack, which is essential for correct selection. It also adds context about the tool's purpose. Other parameters are adequately described in the schema, so the description meaningfully supplements the pack parameter.

  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 a specific verb and resource: 'Query a themed group of related metrics in one call.' It lists the available packs and even distinguishes its scope from single-number queries by including 'Use this when a question is about an area rather than a single number.' This differentiates it from sibling tools like query_metric or query_metrics.

  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 says when to use ('Use this when a question is about an area rather than a single number') and provides concrete examples. It does not explicitly name alternative tools or state 'when not to use,' but the guidance is clear enough that an agent could infer the appropriate context. It also mentions optional breakdown and comparison features.

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

• get_public_game_statsA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the transparency burden. It discloses that no API key is needed, that it only works for public experiences, and that results include live/lifetime stats. It could add edge-case behavior such as invalid or private universe IDs, but the access model is well communicated.

  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 compact and well-structured: first sentence states what it does, second adds context, final sentence gives use cases. Every sentence earns its place with no 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?

  With no output schema, the description usefully enumerates the returned stats fields (player count, visits, favourites, ratio, genre, server size, last update). It also covers access requirements and use cases. It stops short of error handling, rate limits, or partial-failure behavior, but the tool is simple and the description is largely 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 100%, so the baseline is 3. The description adds the 'up to 50 at once' batch context, but that mostly mirrors the schema's maxItems. It does not explain universe ID formats or how to obtain them, though the parameter is simple enough.

  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 names the resource ('public storefront stats') and the action ('get'), and enumerates specific output fields. It also differentiates from sibling tools by emphasizing batch lookup of up to 50 universes and public accessibility.

  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 gives clear intended use cases: benchmarking competitors or shortlisting your own experiences for deeper analysis. It does not explicitly name alternative tools to avoid, but the context around public, no-key, batch stats makes when-to-use reasonably clear.

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

• analyze_funnelA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description takes on the transparency burden. It discloses the two-stage lookup behavior, the dependency on user-defined step IDs, and the data sparsity issue (steps only appear on days players reached them), which are important behavioral traits.

  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 well-structured with clear paragraphs, but contains some redundancy (e.g., repeating 'discover'). It is appropriately sized for the tool's complexity without being excessively lengthy.

  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?

  The description covers the full workflow, data nuances, and usage tips, giving a complete picture for a complex multi-step tool. It does not specify exact output format, but that is not required given no output schema.

  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 already provides detailed descriptions for all parameters, so the baseline is high. The description enriches understanding of time parameters by explaining why a generous range is needed, which adds meaningful context beyond the 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's function: it resolves funnels end-to-end, discovering funnels and steps, then pulling metrics and highlighting the biggest drop-off. This distinguishes it from lower-level sibling tools like query_metric by offering a composite analysis.

  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 practical usage guidance, such as the need for a generous time range and the ability to omit funnelName for all funnels. However, it does not explicitly contrast with alternative tools when a simpler metric query would suffice.

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

• get_experience_overviewA
  4.3/5.0
  Behavior4/5

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

  No annotations provided, so description supplies the behavioral burden. It discloses query-cost behavior ('roughly two queries per metric... 30-per-minute budget... about a minute') and aggregation nuance ('api-period-total values... distinct users rather than summed daily figures').

  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?

  Three compact paragraphs, front-loaded with a clear one-sentence summary. Sentences on aggregation and query budget are essential context, not filler. Slightly longer than a minimal description but 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?

  Despite complexity (7 params, no output schema, no annotations), the description covers purpose, usage, behavioral traits, and cost implications. It doesn't detail exact return structure, but the KPI list and flag behavior give enough for an agent to know what to expect.

  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?

  Input schema covers all 7 parameters with detailed descriptions, so the baseline is 3. The description adds global context (query budget, defaults) but does not elaborate any parameter beyond what the schema already documents, such as the metrics override list and compare flag.

  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 states 'One-call health check for an experience' with specific verbs (pulls, compares, flags) and resource. It distinguishes from siblings by instructing 'Start here... then drill in with breakdown_metric_by_segments or get_metric_report.'

  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?

  Explicit guidance: 'Start here when asked how a game is doing' and points to alternatives for deeper analysis. It also frames the tool as the initial high-level overview, clearly separating it from drill-down tools.

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

• query_metricsA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided; the description covers the load-bearing behavior: per-query rate limiting, error-without-a-bort, and dropped unsupported operations. It doesn't document return envelopes or all failure modes.

  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 two well-formed paragraphs, front-loaded with purpose and differentiating value, but is otherwise dense and reference-like; the structural weight sits on the schema.

  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?

  The tool has 9 parameters and a 100% populated schema, but lacks an output schema and does not account for success-return or response-shape. The rich text around rate limits, error fields, and overprocesses fills in most of the behavioral context.

  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 fully covers the 9 parameters; the descriptions add defaults (endTime default to today's UTC midnight, exclude; startTime relative; granularity calendar semantics; lastN shorthand; universeId alias) and therefore go beyond lazy names.

  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 opens with 'Query several metrics over the same time range', a specific verb+object. It clearly distinguishes itself from query_metric by supporting multiple metrics, automatic query pacing, and partial failure rather than abort.

  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 states 'prefer this over repeated query_metric calls', explains the 30-query/min API limit, and notes that unsupported filters/breakdowns are silently dropped. Lacks an explicit when-not-to-use, but the guidance is otherwise strong.

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

• compare_periodsA
  4.4/5.0
  Behavior4/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 core behavior (comparing periods, calculating absolute and percent change), explains the implicit baseline behavior (omitting baseline uses the prior window), and describes how series are matched with a breakdown. While it doesn't detail edge cases like overlapping periods or resolution, it provides enough transparency for a read-style analytics 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 two concise paragraphs. The first front-loads the purpose and core usage, including the key interaction between current and baseline. The second adds one clarifying detail about breakdowns. No filler or redundant information, making it exceptionally 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?

  The description effectively covers the tool's purpose, usage patterns, and key parameter semantics. Even though there is no output schema, the description implies the return structure ('absolute and percent change per series', 'which platform or country actually moved') which adequately hints at the output. Minor omissions like pagination or limit behaviors are acceptable for this analytics context, but it could still be slightly more explicit.

  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%, so the baseline is 3. The description adds value beyond the schema by explaining the interplay between current/baseline time parameters, the rule for 'baselineStartTime' omission, and how breakdown series are matched by label. These contextual hints help the agent correctly populate parameters, raising the score 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 tool compares metrics between two time ranges and reports absolute and percent change per series. It identifies a specific use case (measuring effects of updates/events/marketing) and distinguishes itself from sibling metrics tools by emphasizing the comparative analysis aspect.

  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 instructs when to use the tool (to measure changes) and explains how to set the current and baseline periods, including the rule for omitting the baseline to use the immediately preceding equal-length window. It also briefly explains breakdown matching. However, it does not name alternative tools or state explicit when-not-to-use cases, so slightly less than a 5.

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

• describe_metricA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description must disclose behavior itself. It mentions that unsupported inputs cause an opaque 400 and burn query budget—useful behavioral insight. It doesn't explicitly state it's read-only, but that's implied by 'full definition' and the absence of mutation language. It could add details about response shape, but it's adequate.

  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, each earning its place: the first defines the tool's purpose and output details; the second provides actionable usage guidance. No redundancy, clearly structured, and front-loaded with the core definition.

  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 single-parameter, no-output-schema metadata tool, the description covers what the tool does, what it returns, when to use it, and the risk of misuse. It lacks an explicit output schema description, but given the tool's nature, the description is sufficient and thorough.

  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 fully describes the 'metrics' parameter ('Exact, case-sensitive metric names, e.g. ['DailyActiveUsers']'). The description adds context about usage ('one or more metrics') but not new parameter semantics beyond what the schema provides. Since schema coverage is 100%, a baseline score 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?

  The description uses a specific verb ('describe') and clearly states the resource ('one or more metrics') and what it returns: display label, category, granularities, retention days, and valid dimensions. This distinctly differentiates it from siblings like list_metrics (which likely lists names only) and query_metric (which returns data).

  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 instructs to 'Check this before querying an unfamiliar metric' and warns of consequences (opaque 400 error and waste of query budget) for using unsupported granularity/dimension. This gives a clear when-to-use directive and implies when not to use (when you already know the metric details).

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

• get_analytics_operationA
  4.5/5.0
  Behavior4/5

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

  No annotations are available, so the description carries the burden. It discloses that it's an 'escape hatch' for timed-out operations and that normal queries poll themselves, giving good context. It could add details about error handling or idempotence, but the provided context is sufficient for most use cases.

  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 concise sentences with all information front-loaded. Every word adds value, and the distinction from normal flow is crystal clear.

  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 single-parameter tool with no output schema, the description fully covers its purpose, usage context, and relation to the broader API. No significant gaps.

  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 is well-documented in the schema with an example, providing 100% coverage. The description adds context about where the path comes from but doesn't add additional parameter-level semantics beyond that. 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?

  The description clearly states the tool fetches the result of a long-running analytics operation by path, using a specific verb and resource. It distinguishes itself from siblings by framing it as the escape hatch for timed-out queries, which is unique among the listed tools.

  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?

  It explicitly explains when to use this tool: when queries time out and the path is provided in the timeout message. This provides clear usage context and differentiates from the normal polling behavior.

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

• get_universe_infoA
  4.5/5.0
  Behavior4/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 that the tool can return an error if the key is analytics-only, and clarifies which parts require different permissions. It does not describe potential side effects (likely read-only) or rate limits, but given the read-only nature implied, this is adequate.

  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 fairly concise, covering purpose, data points, use cases, and permission requirements in two paragraphs. It front-loads the core purpose and lists key stats, then adds contextual details. Minor redundancy (like repeating the like ratio mention) but overall 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 the tool's moderate complexity (two params, no nested output schema, no annotations), the description is quite complete. It covers what data is returned, permission nuances, and typical use cases like competitor comparison. The absence of an output schema is compensated by listing the data points explicitly, and the error case is disclosed.

  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 already has 100% description coverage for both parameters, so the description doesn't need to reiterate. However, it adds context that universeId can be an alias and optional when a default is set, and includeOpenCloudMetadata controls fetching additional metadata, which aligns with the description's mention of Open Cloud metadata. This slightly exceeds the baseline.

  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 fetches metadata and public storefront stats for an experience, listing specific data points like name, description, creator, dates, player count, visits, and like/dislike ratio. It also explicitly contrasts with the Analytics Query API, distinguishing it from sibling metric tools.

  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?

  Provides explicit guidance: public stats need no API key and work for unowned experiences (useful for competitor comparison), while Open Cloud metadata requires a key with universe read access. It also indicates when to use this tool over others (e.g., complements metric tools for retention analysis) and mentions alternatives like find_universes for ID lookup.

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

• list_dimensionsA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the output (list of dimensions and metrics) and clarifies that actual dimension values are elsewhere, setting accurate expectations. It doesn't mention read-only nature or pagination, but these are minor for a simple lookup 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?

  Two sentences with zero filler. It front-loads the core purpose, adds usage examples, and explicitly redirects to the sibling tool. Every sentence earns its place.

  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 simple list tool with optional parameters and no output schema, the description covers purpose, use cases, parameter implications through context, and points to the related tool for values. It is complete for its complexity.

  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% (both parameters have descriptions), so the baseline is 3. The description adds context on how the tool is used but doesn't supplement the parameter meanings beyond what the schema already provides.

  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 69 dimensions and the metrics supporting each, which is specific and actionable. It explicitly distinguishes itself from list_dimension_values by noting that dimension values come from that sibling tool, preventing confusion.

  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?

  It provides explicit use cases ('what can I slice this by' and 'which metrics can I break down by Country') and explicitly tells users when not to use it ('Dimension *values* come from list_dimension_values'), giving clear when-to-use and 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.

• list_dimension_valuesA
  4.6/5.0
  Behavior4/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 that values only appear for activity periods, mentions the exclusive end default, and notes the metric argument does not compute the metric. However, it does not explicitly state whether this is a read-only operation or discuss rate limits or pagination. Given the absence of annotations, this is reasonably transparent but leaves a small gap about operation safety.

  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 concise, front-loaded with a clear purpose, and uses short paragraphs for separate concerns (pre-filter usage, missing values, metric argument). Every sentence adds value without repeating schema details or annotations, achieving high information density in a compact form.

  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 complexity (10 parameters, no output schema, no annotations), the description covers key behavioral defaults (endTime exclusivity, granularity None for aggregates) and usage guidance. It lacks a brief description of return value shape (e.g., a map of dimension to values), but since there's no output schema, a note on what the response contains might be expected. However, the description focuses on discovery and filtering, and the schema covers parameter semantics well, making this only slightly incomplete.

  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?

  Although schema coverage is 100%, the description adds important context beyond property descriptions: it explains the metric argument's role, the need for granularity to be omitted for limit, and the behavior of endTime. For instance, it clarifies the limit needs granularity omitted, which is not obvious from the schema. The description compensates for the schema's minimal context by tying parameters to usage patterns, even though it doesn't detail every parameter like startTime's relative formats (which the schema already covers).

  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 lists actual dimension values (countries, product IDs, etc.) over a date range, which is a specific verb plus resource. It also distinguishes itself from siblings like list_dimensions (list dimension names vs. values) and from query/breakdown tools by framing it as a pre-filter discovery step.

  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 advises running this before filtering, warns that filters match exact raw values, and recommends widening the date range if expected values are missing. It also clarifies that the metric argument is for namespace selection, not computation, which prevents misuse. Sibling tools like list_dimensions are implicitly contrasted by the 'actual values' phrasing.

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

• query_metricA
  4.6/5.0
  Behavior5/5

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

  Despite having no annotations, the description provides unusually detailed behavior: client-side request validation, per-series summary statistics, trend and outliers, raw data points, no-data buckets, error messaging, default granularity, endTime exclusive semantics, lastDays shorthand, includeDataPoints toggle, and maxDataPoints cap, aggregation hint for rates/averages/percentiles.

  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 well-packed and dense but not bloated. It methodically describes params, returns, defaults, validation and aggregations and stays organized; each sentence pays rent.

  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?

  Has a high degree of richness and the API is complex: no output schema, but the return shape is described per series; multiple edge cases covered; the tool is positioned against siblings; no annotations; but descriptions are complete for the API's surface.

  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% across 12 parameters, so parameters are already well described in the JSON schema. The description adds value beyond schema by documenting default server time, relative time shorthands, excluded endTime, break-down/filter semantics, and the validation-and-clear-error 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?

  Specific verb+resource: 'Query one analytics metric as a time series'; explicitly positioned as 'the core read tool' with 'everything the Analytics Query API exposes is reachable through it', distinguishing it as central versus the sibling metrics tools.

  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?

  Strong context: 'Core read tool' implies primary choice; states validation against metric capabilities avoids opaque errors. Does not explicitly name sibling alternatives or when to avoid, but the core-tool positioning differentiates.

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

• breakdown_metric_by_segmentsA
  4.7/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of disclosing behavior. It clearly states that the tool performs a read operation, returns ranked segments per dimension, flags rate-like metrics at certain thresholds (1.5x/0.67x), and costs one query per dimension. It also discloses that endTime defaults to today's UTC midnight for complete buckets, which is beyond schema info.

  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 well-structured and front-loaded: the first sentence states the core purpose, the second provides a use case, and the last adds cost guidance. No fluff, every sentence serves a purpose.

  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 the tool's complexity (8 parameters, nested filter objects) and lack of output schema, the description provides comprehensive context: it explains the main use case, performance considerations, and how parameters like dimensions and limitPerDimension behave. It also points to sibling tools for discovering dimension values. This is complete enough for an agent to use effectively.

  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?

  Although schema coverage is 100%, the description adds crucial semantic context: it explains that dimensions defaults to all supported dimensions, that limitPerDimension helps cap segments for high-cardinality fields like Country and ProductKey, and that filter values can be discovered via list_dimension_values. This goes beyond basic schema descriptions to explain how parameters interact and when to use them.

  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 specifies the action ('Slice one metric by every dimension it supports'), the resource (metric by dimensions), and the outcome (ranked segments within each dimension). It also differentiates from siblings like query_metric and query_metrics by emphasizing the multi-dimension, per-dimension ranking approach.

  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 states when to use this tool ('This is the fastest way to answer 'who is this bad for?') and contrasts it with alternatives like query_metric/query_metrics by highlighting that it surfaces segment issues without guessing dimensions. It also provides cost guidance ('Costs one query per dimension') and advises restricting dimensions to save resources.

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

• get_server_statusA
  4.7/5.0
  Behavior4/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. The verb 'Check' plus the enumerated read-only configuration fields strongly imply a non-mutating diagnostic operation. It does not explicitly state the output format or whether it makes any external calls, but for a simple status tool the behavioral intent is clear enough.

  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 compact, front-loaded with the core purpose, and every sentence adds value: the first defines scope, the second provides actionable diagnostic usage guidance. 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 the tool has no parameters, no output schema, and a clearly bounded diagnostic purpose, the description is complete. It covers what is checked, when to use it, and why, which is sufficient for an AI agent to select and invoke the tool appropriately.

  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 tool has zero parameters and the schema coverage is 100%, so the baseline is 4. The description appropriately describes the output fields rather than parameters, making clear what the status check will reveal.

  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's purpose with a specific verb ('Check') and resource ('how this MCP server is configured'), then enumerates the exact configuration aspects covered: API key availability/provenance, default universe, saved aliases, and query budget. This clearly distinguishes it from sibling analytics and universe tools.

  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 gives an explicit when-to-use directive: 'Call this first if an analytics tool returns an authentication error', and explains why it is useful ('distinguishes a missing key from a key that lacks the analytics scope'). This is strong, actionable usage guidance.

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

• whoamiA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It clearly states this is a read-only introspection (no side effects implied), and details what is returned (key owner, account, scopes, universes, groups). It also notes the optional groups parameter and the meaning of '*' for universes. It does not explicitly state 'does not modify anything', but the nature of the tool and the details provided are sufficient for an agent to trust it as a safe diagnostic call.

  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 well-structured in three short paragraphs: purpose, usage context, and return details. It is front-loaded with the core action, avoids filler, and every sentence provides useful information (e.g., the wildcard meaning, the group mention). No redundancy or unnecessary verbosity.

  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 a single optional parameter and no output schema, the description is thorough: it covers the problem it solves (anonymity), when to invoke it, what it returns, and the optional behavior. It even provides troubleshooting context (missing scope, disabled key, wrong universe). This is complete for an agent to decide to call it and understand its output.

  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% (only one boolean parameter with a clear description). The description adds value by explaining why the includeGroups parameter is useful ('usually where a studio's real titles live') and its default behavior. This goes beyond the schema's bare description and justifies the parameter's purpose in practice.

  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 states a specific verb ('Identify') and resource ('the owner of the configured API key') and explicitly differentiates from sibling tools by emphasizing that it reveals the caller identity, which is otherwise anonymous. It also lists what it returns (key name, account, scopes, universes), making its purpose unmistakable.

  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 gives explicit when-to-use guidance: 'call this first whenever you need to know whose experiences these are, or when a query fails and you cannot tell whether the cause is a missing scope, a disabled key, or the wrong universe.' It also clarifies that Open Cloud keys are anonymous, which directly informs when this tool is necessary. No alternatives are mentioned, but the context is clear and actionable.

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

• find_universesA
  4.8/5.0
  Behavior5/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 explains that scanning many groups takes multiple requests, how throttling manifests (empty result with errors), and that errors are reported rather than silently omitted. It also discloses that results are cached for 6 hours and that default behavior includes group games, which helps set expectations for network load and freshness.

  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 well-structured with clear paragraphs and front-loaded primary purpose. It uses concise, informative sentences. The only minor room for improvement is that the third paragraph about errors and throttling is somewhat technical but is appropriately placed at the end, and the description is detailed enough to warrant its length for the complexity of the tool.

  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 the complexity (7 parameters, no output schema), the description is remarkably complete. It explains the default behavior, the implications of omitting arguments (who the key belongs to), the impact of includeGroupGames (speed vs coverage), and how to interpret results (errors field indicates throttling). The lack of an output schema is compensated by describing that errors are reported and empty results with errors indicate throttling.

  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 already covers all parameters with descriptions (100% coverage), so the bar is lower. The description adds value by explaining the default behavior when parameters are omitted (e.g., includeGroupGames defaults true, search is optional but ranking is by lifetime visits), and the refresh parameter's purpose (re-fetch after publishing). It does not repeat parameter definitions but contextualizes them.

  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 finds universe IDs for experiences by name or creator. It specifies the primary use case and distinguishes it from sibling tools like get_universe_info and get_place_info, which likely focus on individual universe/place details rather than discovery.

  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?

  Provides explicit guidance on when to use with no arguments (identifies API key owner's account and groups), when to add 'search' (filter by name, with ranking insight), and how to target specific users or groups via username/userId/groupId. It also explains the includeGroupGames parameter for tuning scope, and clarifies that a personal-account-only search might miss studio titles, recommending the default behavior.

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

• list_metricsA
  5/5.0
  Behavior5/5

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

  Without annotations, the description carries full responsibility for transparency. It discloses that the API rejects unrecognized names (case-sensitive), and that the output includes names and labels only unless includeDetails is set. This gives agents a clear picture of behavior and error conditions.

  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 concise, using four sentences that lead with the main purpose, then provide usage context and filter details. There is no redundant or extraneous information, and every sentence adds value.

  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 the tool's simplicity (listing metrics) and the presence of detailed schema parameter descriptions, the tool description is complete. It explains the output behavior (names/labels vs details) and the discovery use case, covering all essential aspects for an agent to use it correctly.

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

  Parameters5/5

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

  The description adds context beyond the schema by explaining how filters work (free-text search, category, dimension, granularity) and mentions case-sensitivity for search. It also clarifies that includeDetails controls output richness, which is not fully explained in the schema descriptions alone.

  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 that the tool lists available metrics from the Roblox Analytics Query API, with specific mention of 168 metrics across 16 categories. It distinguishes itself as a discovery tool for when the exact metric name is unknown, which differentiates it from siblings like query_metric or describe_metric.

  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 instructs to 'Start here when you do not already know the exact metric name', providing clear when-to-use guidance. It also explains filtering capabilities, which helps agents decide between this and other tools that operate on known metrics.

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