Server Quality Checklist

Tool Scores

• gsc_search_analyticsC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It states the returned metrics (clicks, impressions, CTR, position), but does not mention that this is a read-only operation, potential rate limits, pagination behavior, or how filter parameters interact (e.g., all three filter fields must be used together). This is a significant gap for a data-querying 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 long, with the primary action and resource in the first sentence and output metrics in the second. It is concise, front-loaded, and contains no redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

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

  Given the tool's complexity (9 parameters, flexible dimensions, filter operators) and the absence of an output schema, the description is insufficiently complete. It does not explain how to construct valid filter combinations, the meaning of the returned metrics beyond their names, or how row limits apply. The description would be incomplete for an agent trying to use the tool correctly without additional context.

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

  Parameters3/5

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

  Schema description coverage is 100% with descriptions for all nine parameters, so the schema does the heavy lifting. The description adds minimal value by mentioning 'flexible dimensions and filters' but does not elaborate on parameter relationships or usage patterns, such as the need to specify filterDimension, filterOperator, and filterExpression together.

  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 queries Google Search Console search analytics data, with a specific verb ('Query') and resource. It mentions flexibility in dimensions and filters, and lists returned metrics. However, it does not explicitly differentiate from sibling tools like gsc_top_queries or gsc_top_pages, which are more specialized.

  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 is given on when to use this tool vs alternatives. Sibling tools like gsc_top_queries and gsc_top_pages exist, but the description does not mention them or state that this tool is for custom flexible queries. Usage context is only implied by 'flexible dimensions and filters.'

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

• meta_list_ad_accountsC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It claims to 'List all' accounts, but the schema shows a `limit` parameter with a default of 25 and a description 'Max accounts to return', meaning it does not necessarily return all accounts. This contradiction is not addressed in the description, and pagination behavior is not mentioned. This is a significant transparency gap.

  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, with the primary action and resource front-loaded. Every word contributes meaningful information about purpose and output. There is no filler or redundancy.

  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 low complexity (one optional parameter, no output schema), the description covers the basic purpose and return fields. However, it fails to explain how the `limit` parameter works in relation to the claim of listing 'all' accounts, and it does not mention pagination or how to retrieve more than the default 25. This leaves an important gap for successful usage.

  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?

  The schema provides 100% coverage for the `limit` parameter with a clear description, so the baseline is 3. However, the description's phrasing 'List all' directly conflicts with the limit semantics, and it adds no explanation about how the limit affects the result set. This creates confusion rather than adding value, so a lower score is warranted.

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

  Purpose4/5

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

  The description clearly states the action ('List') and the resource ('Meta/Facebook ad accounts') with a specific scope ('accessible with the current access token'). It also enumerates the returned fields, making the purpose unambiguous. However, it does not explicitly distinguish this tool from siblings like meta_account_overview, so it misses the top score for sibling differentiation.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives such as meta_account_overview or other listing tools. There is no mention of prerequisites, use cases, or exclusions. The agent is left to infer the appropriate context from the tool name alone.

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

• gads_campaign_performanceB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and metrics, omitting details about return structure, pagination, default sorting, freshness, or authentication. The description adds minimal context beyond the basic 'get' intent.

  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 directly communicates the tool's function and the key metrics. Every word earns its place, and there is no redundant or irrelevant information.

  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?

  The tool has no output schema and no annotations, so the description should clarify the return shape and usage context. It names the metrics but does not explicitly state that results are per campaign or grouped, nor does it mention the impact of filters. This is adequate for a simple read tool but leaves gaps for a new user.

  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 100% of parameters with descriptions, so the baseline is 3. The tool description adds value by listing the metrics returned, but it does not elaborate on how parameters like orderBy or dateRange affect results. It neither compensates for nor detracts from the schema.

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

  Purpose4/5

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

  The description clearly states the tool retrieves performance metrics for Google Ads campaigns and enumerates specific metrics (impressions, clicks, cost, conversions, CTR, CPC, conversion rate). While it doesn't explicitly contrast with sibling tools like keyword or ad group performance, the noun 'campaigns' is specific enough to distinguish the resource.

  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 is provided on when to use this tool versus the many sibling tools (e.g., gads_keyword_performance, gads_ad_group_performance). It lacks context about data ranges, prerequisite setup, or scenarios where campaign-level metrics are appropriate.

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

• gads_keyword_performanceB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get' which implies a read operation, but does not explicitly state it is read-only, nor does it mention default date ranges, limiting, sorting, or how filters affect results. No padding is added beyond the implicit safety of a read.

  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, front-loaded with the primary action, and lists metrics efficiently. Every word contributes to conveying the tool's purpose with no fluff or redundancy.

  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?

  For a tool with no output schema, the description gives a general idea of the returned fields but omits important context such as how parameters affect results, what the default behavior is, or how to interpret the data. It is adequate for a simple list tool but has clear 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?

  Schema description coverage is 100%, with every parameter having a description. The tool description does not add any parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate; the schema already handles the semantic burden.

  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 performance metrics for Google Ads keywords and enumerates specific metrics (search term, match type, clicks, impressions, cost, conversions, quality score). This specific verb+resource combination distinguishes it from sibling tools like campaign or ad group performance.

  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 is provided on when to use this tool versus alternatives such as gads_campaign_performance or gads_ad_group_performance. It does not mention any prerequisites, ideal use cases, or exclusions.

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

• gsc_top_pagesA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description carries full responsibility for behavioral disclosure. It states the sort order and output fields but does not reveal scope defaults (e.g., siteUrl optional behavior, limit application), data latency, or any prerequisites. This leaves significant behavioral ambiguity for a tool that aggregates search data.

  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 sentences, front-loaded with the primary action and followed by output details. No wasted words.

  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?

  The tool has 5 parameters and no output schema, but the description lists the returned metrics, which is helpful. However, it omits any mention of how optional parameters like siteUrl and queryFilter affect the result, and does not explain the date range scope beyond the schema. The description is adequate but could be more complete for a tool with no annotations.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already describes all parameters. The description adds no additional parameter-specific semantics beyond the schema, but it does mention the output fields, which are not parameters. Baseline 3 applies because the schema handles parameter documentation.

  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 top pages from Google Search results sorted by clicks, distinguishing it from query-focused siblings like gsc_top_queries. It also lists the key return metrics, 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 Guidelines3/5

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

  The description implies usage when page-level performance data is needed, but it does not explicitly contrast with sibling tools (e.g., gsc_top_queries) or provide when-not-to-use conditions. The guidance is implied by the resource type 'pages' rather than stated.

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

• ga4_realtime_reportA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It does disclose a key behavioral trait: the time window of 'last 30 minutes' and the real-time nature. However, it omits details like authentication requirements, return format, or rate limits, leaving some behavioral aspects undisclosed.

  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, front-loaded sentence that conveys the core purpose without any waste. Every word adds value, and the structure is optimal for quick comprehension.

  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?

  With no output schema, the description should explain what the returned report looks like. It only says 'showing current active users and activity,' which is too vague to know the response structure (e.g., rows, metrics, formatting). The tool has four parameters but no return value details, making the description incomplete for an agent to fully anticipate the output.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds minimal context beyond the schema, mentioning 'current active users' and 'activity' that loosely map to the metrics parameter, but it does not provide additional clarity on parameter usage or relationships.

  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: 'Get a realtime GA4 report showing current active users and activity from the last 30 minutes.' It specifies the resource (GA4 realtime report) and scope (last 30 minutes), distinguishing it from sibling tools like ga4_run_report which likely handles historical data.

  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 the use case for real-time monitoring but does not explicitly compare with alternatives or state when not to use it. There is no mention of 'use ga4_run_report for historical data' or similar exclusions, leaving usage guidance 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.

• ga4_user_metricsA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the burden of disclosing behavior. It indicates a read-only operation via the verb 'Get' and lists the metrics returned, which is a positive signal. However, it does not mention potential limitations like data sampling, response shape, or whether the comparison adds separate fields, which would enhance transparency for a tool without an output schema.

  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, well-structured sentence that front-loads the purpose and lists the exact metrics. It is concise, scannable, and contains no filler or redundant details, earning a top score.

  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 that there is no output schema, the description partially compensates by enumerating the returned metrics. However, it does not explain the response format (e.g., single row vs. table), how the previous-period comparison is represented, or any prerequisites like the property ID. While the tool is relatively simple, the missing output structure and comparison details leave some gaps for an agent.

  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 input schema already covers all four parameters with descriptions (100% coverage), so the description does not need to add parameter-level detail. It does provide context by explaining that 'compare with the previous period' relates to the comparePreviousPeriod flag, but this adds no new syntactic or semantic info beyond the schema. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states that the tool retrieves a summary of key user metrics, listing the specific metrics (total users, new users, sessions, etc.). This distinct resource and action set it apart from sibling tools like ga4_top_pages or ga4_traffic_sources, and it is immediately evident what the tool accomplishes.

  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 its use for obtaining a high-level user metrics summary, but it does not explicitly state when to choose this over alternatives such as ga4_run_report for custom reports. There is no exclusionary guidance or mention of conditions where this tool is inappropriate, leaving the usage context implicit.

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

• gsc_inspect_urlA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It discloses the categories of information returned but does not mention read-only behavior, permissions, rate limits, or side effects. The verb 'Inspect' suggests a safe read operation, but it is not explicitly stated, leaving a transparency gap.

  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 main purpose and followed by a useful use-case. Every word earns its place, with no redundancy or clutter.

  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?

  The description covers purpose and a use case, and the schema handles parameter details. However, with no output schema or annotations, the description does not explain the structure or interpretation of the inspection results. It is adequate but could offer more context on what 'issues' means or how to act on findings.

  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 input schema already provides detailed descriptions for both parameters (url and siteUrl), including an example and a pointer to gsc_list_sites. The tool description adds no additional parameter information, so with 100% schema coverage, the 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 inspects a URL and lists what it returns: indexing status, crawl info, mobile usability, and any issues. The verb 'Inspect' and resource 'URL' are specific, and it distinguishes itself from sibling analytics tools like gsc_search_analytics which handle aggregate data.

  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 a concrete use case: 'Useful for debugging why a page isn't appearing in search.' This implies when to use the tool, providing clear context. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.

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

• meta_ad_insightsA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses the output fields, which is useful, but does not mention authentication needs, rate limits, or explicitly state that it is a read-only operation. The word 'Get' implicitly indicates a safe read, and listing the return fields adds some transparency, but it stops short of richer behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose and followed by a concise list of output fields. There is no fluff or redundancy, and every clause adds value.

  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?

  With no output schema, the description does list the returned fields, which is good. However, it lacks context on scope (e.g., whether all ads in the account are returned for the date range), pagination behavior, or how it differs from adset/campaign insights. Given the straightforward nature of a read tool and schema coverage, it is minimally complete but not rich in guidance.

  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 parameters are already well-documented in the schema. The description adds no additional meaning about parameters like limit, adsetId, or campaignId, nor does it explain how filters interact. Baseline 3 is appropriate because the schema handles parameter semantics.

  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 performance insights for individual ads,' which is a specific verb (Get) and resource (individual ads). It lists the exact metrics returned (name, ad set, campaign, spend, impressions, clicks, conversions), distinguishing it from sibling tools like meta_campaign_insights and meta_adset_insights by explicitly targeting the ad level.

  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 ad-level insights through 'individual ads,' but does not explicitly state when to use this tool over alternatives. It lacks direct comparisons to meta_campaign_insights or meta_adset_insights, though the phrase 'individual ads' gives clear context that this is for granular ad data.

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

• ga4_run_reportA
  3.8/5.0
  Behavior3/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 provides useful context on GA4 API naming conventions and relative date syntax, but does not mention potential quirks like result limits (though the schema has a default), data freshness, or that an invalid property ID will error. It is a read-only operation, but that is not stated.

  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 the primary action, and no wasted words. Every sentence provides value: the first defines the tool, the second gives naming/date conventions.

  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 core aspects (dimensions, metrics, date range) and key conventions. The schema fully documents all 9 parameters, including filters and propertyId. An output schema is absent, so no return-value explanation is expected. Missing a note about the sibling ga4_list_accounts for property discovery, but the schema's propertyId description already covers that.

  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 reinforces parameter semantics by naming example metrics/dimensions and date formats, but adds no extra meaning beyond what is already in the schema property descriptions. The examples are helpful for a user unfamiliar with GA4 API 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?

  The description clearly states the tool's purpose: running a custom GA4 report with dimensions, metrics, and date range. It uses a specific verb ('Run') and resource ('GA4 report'), and the word 'custom' differentiates it from specialized GA4 siblings like ga4_top_pages or ga4_realtime_report.

  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 custom reporting needs but does not explicitly state when to use this tool versus the specialized GA4 siblings. It offers no exclusions or alternatives, leaving the agent to infer that this is the general-purpose fallback. This is adequate but not explicit.

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

• gsc_top_queriesA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full behavioral disclosure burden. It discloses the output fields and sorting order (by clicks), which is helpful. However, it omits details about the default limit (e.g., 25), pagination behavior, or data freshness. These are gaps that could affect user expectations.

  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 action and resource, and the second sentence adds output details. There is no redundant or fluff content, making it appropriately concise.

  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 list tool, the description covers the core purpose, output fields, and sorting. It does not explicitly mention default limit behavior or the role of the optional siteUrl parameter, but these are partially available in the schema. The absence of an output schema makes the field list important, which is provided. Overall, it 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 coverage is 100%, so every parameter already has a description. The tool description adds no additional parameter-level context, which is acceptable given the high schema coverage. Baseline of 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 action ('Get the top search queries'), the resource (search queries driving traffic to your site), and the sorting criteria (by clicks). It also lists the returned fields, making the tool's purpose unmistakable and distinct from siblings like gsc_top_pages or gsc_search_analytics.

  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 the use case—when you need top queries—but does not explicitly mention when to use it instead of alternatives like gsc_search_analytics or gsc_top_pages. There are no exclusions or alternative references, so the guidance is only implicit.

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

• meta_account_overviewA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses the output metrics and optional breakdown dimension, and the verb 'Get' implies a read operation. However, it does not detail return structure, pagination, or any constraints like rate limits or data freshness, leaving some behavioral aspects unspecified.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, front-loaded with the core purpose, and includes no redundant information. It is concise while covering the essential functions and optional breakdown.

  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 lack of an output schema and annotations, the description lists key metrics and parameters, providing a clear picture of what the tool does. It falls short of fully distinguishing sibling tools and detailing output structure, but for a straightforward overview tool it is reasonably complete.

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

  Parameters3/5

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

  The input schema has 100% description coverage, so the baseline is 3. The description adds little beyond the schema—it restates the optional breakdown and date range but does not provide extra context on parameter formats or relationships beyond what the schema already specifies.

  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 a high-level performance overview for a Meta ad account with specific metrics (spend, impressions, clicks, CTR, CPC, CPM, conversions). The account-level scope distinguishes it from sibling tools like meta_campaign_insights or meta_adset_insights.

  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 account-level overviews and provides date range and breakdown context, but it does not explicitly mention when to use this tool over alternatives (e.g., campaign/adset/ad insights) or state exclusions. The usage guidance is implicit rather than explicit.

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

• meta_adset_insightsA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It conveys a read-only operation via 'Get' and discloses the type of metrics returned. It does not discuss behaviors such as pagination, data freshness, access requirements, or handling of missing data, but for a simple read tool this is acceptable, and there is no contradiction.

  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, front-loaded sentence that concisely states the action and expected output metrics. Every word earns its place, with no redundant or filler content.

  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 tool with five parameters and no output schema, the description adequately explains the core purpose and the metrics returned. It addresses the key ambiguity of campaign-level vs. account-level scope, though it omits details about output structure or edge cases. Overall, it is sufficiently complete for a straightforward insights tool.

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

  Parameters3/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds context about campaign or account scoping but does not meaningfully extend the parameter definitions already provided in the schema, such as 'Filter to a specific campaign ID'.

  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 ('Get') and the resource ('performance insights for ad sets'). It distinguishes from sibling tools like meta_campaign_insights and meta_ad_insights by focusing specifically on ad-set-level data, listing key metrics (spend, impressions, clicks, conversions) and the scope ('within a campaign or account').

  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 ad-set-level performance data is needed, and the phrase 'within a campaign or account' provides context. However, it does not explicitly mention alternatives (e.g., campaign vs. ad insights) or when not to use this tool, so guidance is implicit rather than explicit.

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

• meta_campaign_insightsA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses the output metrics (spend, impressions, etc.) and implies a read-only operation. However, it does not disclose behavior around limit/pagination (default 25) or how 'all campaigns' reconciles with the limit parameter, nor any date/timezone handling.

  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-loaded with the core purpose, and each word adds value. It lists the key metrics without unnecessary detail or repetition.

  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?

  As a simple read tool with a complete schema, the description adequately covers the core behavior. However, the phrase 'all campaigns' could mislead users into expecting all campaigns when the default limit is 25, and there is no clarification about pagination or that limit must be increased for truly all campaigns.

  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 parameters are fully documented in the schema. The description adds context about the metrics but does not add additional meaning or syntax details for the parameters, aligning with the baseline for high 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 action ('Get') and the resource ('performance insights for all campaigns in a Meta ad account'), and lists the specific metrics returned. It distinguishes itself from sibling tools like meta_adset_insights and meta_ad_insights by explicitly focusing on the campaign level.

  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 campaign-level insights but does not explicitly compare with adset or ad-level tools. There is no direct statement of when to use this tool versus alternatives, though the resource clarity helps infer it.

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

• ga4_traffic_sourcesA
  4/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 burden. It discloses the returned metrics (sessions, users, engagement) but does not address potential behavioral aspects like result limits, pagination, or authentication needs. The read-only nature is implied but not explicitly stated.

  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, front-loaded sentence with no filler. It efficiently communicates the action, resource, and output metrics.

  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 no output schema, the description covers the returned metrics but omits details about default limits or response format. However, for a straightforward data retrieval tool, it provides sufficient context to understand the tool's basic purpose and output.

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

  Parameters3/5

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

  Schema coverage is 100%, so the schema already documents all parameters. The description adds the context of 'date range' aligning with startDate/endDate and the purpose of the parameters, but it doesn't provide additional syntax or constraints beyond what the schema already offers.

  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: 'Get traffic source breakdown' with specific metrics (sessions, users, engagement) and grouping by source/medium. It distinctly identifies the resource and distinguishes it from sibling tools like ga4_top_pages or ga4_user_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 implies usage context: use when you need traffic source breakdown for a date range. It doesn't explicitly mention alternatives or exclusions, but the specific scope makes the intended use clear enough.

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

• gads_ad_group_performanceA
  4/5.0
  Behavior3/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 metrics returned and grouping behavior, which is useful. However, it does not mention data range handling, zero-spend inclusion, or response format, leaving moderate gaps for a read 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?

  A single, front-loaded sentence that states the action, resource, and key outputs with no filler. Every word contributes to understanding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

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

  For a simple read-only tool with fully documented parameters and an explicit list of returned metrics, the description is reasonably complete. It could mention that it returns a list or how limit applies, but the schema covers those details, and the output is predictable.

  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 fully describes all four parameters (100% coverage), so the description adds little beyond what is already present. Baseline 3 is appropriate; the mention of 'within campaigns' subtly aligns with the campaignName parameter but does not add new semantics.

  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 ('Get performance metrics'), the resource ('Google Ads ad groups'), and the specific metrics returned. It also mentions grouping, which distinguishes it from sibling tools like gads_campaign_performance and gads_keyword_performance.

  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 implies the tool is for ad-group-level performance analysis, which provides clear context for when to use it compared to campaign or keyword tools. It does not explicitly name alternatives or exclusions, but the context is unambiguous.

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

• gads_queryA
  4/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the burden of behavioral disclosure. It only says 'execute a raw query' and gives an example. It fails to disclose whether this is read-only, any rate limits, response format, or potential errors. The example implies a SELECT query but does not guarantee the tool is non-mutating or explain its behavior beyond execution.

  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 plus a representative example. It is front-loaded with the action and purpose, contains no filler, and every sentence earns its place. The example is succinct and illustrative.

  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 single-parameter tool with no output schema, the description covers the essential purpose and when to use it. It does not describe the output format or error handling, which would be valuable, but the example and clear scope make it reasonably complete for its simplicity.

  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 describes the param simply as 'A valid GAQL query string'. The tool description adds a full example query, demonstrating the expected syntax and structure, which provides meaningful enrichment beyond the schema's minimal definition.

  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 with a specific verb ('Execute') and resource ('raw Google Ads Query Language (GAQL) query'). It distinguishes itself from sibling tools by noting it is for 'custom queries not covered by other tools' and provides a concrete example.

  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 states when to use it ('Use for custom queries not covered by other tools'). It does not name specific alternatives but clearly implies that other tools cover predefined queries. This is clear contextual guidance, though it lacks explicit 'when not to use' phrasing.

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

• gsc_list_sitemapsA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the full burden. It states what the tool does and the fields returned, but does not explicitly mention read-only behavior, authentication requirements, or any side effects. The verb 'List' implies safety, but additional context 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?

  A single, efficient sentence that is front-loaded with the action and resource, with no redundant 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?

  For a simple one-parameter tool with no output schema, the description provides key return values (status, last download date, URL counts) which helps the agent understand what to expect. Minor gap: schema marks siteUrl as not required, and the description doesn't clarify whether it must be provided.

  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% and the parameter description in the schema ('Use gsc_list_sites to find available sites') is helpful. The tool description itself adds no extra parameter meaning, so 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 uses a specific verb-object pairing ('List all sitemaps') and specifies the resource (sitemaps submitted for the site). It clearly distinguishes from sibling tools like gsc_list_sites (lists sites) and gsc_search_analytics (search data).

  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 implies usage context (needs a siteUrl) and the parameter schema explicitly directs users to gsc_list_sites to find available sites, providing a cross-reference. However, it does not explicitly state when not to use this tool or name alternatives besides that hint.

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

• gads_account_summaryA
  4.1/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 clearly indicates a read-only retrieval ('Get') and specifies the output scope (aggregate account metrics + top campaigns), which is sufficient behavioral context for a low-risk reporting tool. It does not mention authentication or rate limits, but that is less critical for this simple read 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 a single sentence that immediately states the tool's purpose, then lists the key metrics and the distinctive top-5-campaigns output. It is front-loaded, free of filler, and every phrase contributes useful information.

  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 one optional parameter, no output schema, and no complex nested structures, this description is complete. It fully informs the agent of what the tool returns and at what level of detail, without needing to explain the parameter since the schema already covers it.

  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 input schema provides 100% coverage for the single optional parameter 'dateRange' with an enum, default value, and a description. The tool description does not add additional semantics beyond the schema, so the baseline score of 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 uses a specific verb ('Get') and resource ('Google Ads account'), and clearly enumerates the metrics returned (spend, clicks, impressions, conversions, key averages) plus a distinctive 'top 5 campaigns' detail. This differentiates it from sibling tools like gads_campaign_performance and gads_keyword_performance, which focus on lower-level breakdowns.

  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 phrase 'high-level summary' implies a broad overview use case, and the 'top 5 campaigns' detail suggests it is meant for quick insights rather than deep dives. However, there is no explicit when-to-use guidance or mention of alternatives such as gads_campaign_performance or gads_keyword_performance, leaving usage context only implied.

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

• ga4_list_accountsA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the transparency burden. It implies a read-only operation and mentions authentication, but does not disclose details like response format, pagination, or potential large result sets. This is adequate for a simple list tool 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, with the action first and use case second. Every word adds value with 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 zero-parameter list tool, the description covers the main purpose and gives practical usage guidance. It does not describe the return structure, but given the simplicity and lack of output schema, this is a minor gap. The description is complete enough for an agent to select and invoke it.

  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, so schema coverage is trivially 100%. Per the rubric, the baseline for 0 params is 4. The description adds no parameter-specific information, which is fine since there are none to document.

  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: 'List all GA4 properties accessible to the authenticated Google account.' This is a specific verb-resource combination and naturally distinguishes it from sibling report tools like ga4_run_report or ga4_realtime_report.

  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?

  It explicitly says to use this for discovering Property IDs for use with other ga4_* tools, providing a clear when-to-use context. It does not explicitly mention alternatives or exclusions, but the instruction is sufficient for this simple list tool.

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

• ga4_top_pagesA
  4.2/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the transparency burden. It discloses the return fields and the sorting principle (top pages by views), implying a read-only operation. It could mention prerequisites like propertyId, but the schema covers that.

  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, front-loaded sentence. It starts with the core purpose and then lists the expected output fields. There is no redundant information 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 retrieval tool, the description is adequate. It clearly explains what the tool does and what it returns, while the schema covers parameter details. It could be more complete with an example, but it is sufficient for selection and invocation.

  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 documents all four parameters with descriptions and defaults, achieving 100% coverage. The description adds no additional parameter semantics beyond what the schema contains, so the 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 action (Get), the resource (top pages), the ordering metric (by views), and the date range constraint. This distinguishes it from sibling tools like ga4_traffic_sources and ga4_user_metrics, which focus on different dimensions.

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

  Usage Guidelines4/5

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

  The description provides clear context: use this tool when you need top pages for a specified date range. However, it does not explicitly mention alternatives or when not to use it, though its purpose is self-explanatory.

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

• setup_guideA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the behavioral disclosure burden. It discloses that the tool is informational: it shows configuration status and provides setup guides. However, it does not explicitly state that it performs no mutations or other side effects, leaving a slight gap. The behavior described is consistent and plausible for a setup guide, but not exhaustively detailed.

  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-loaded with the primary action, and every word adds value. It avoids filler or repetition, making it optimally concise and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

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

  For a simple, parameterless tool, the description is complete enough: it states what the user gets, what information is shown, and what happens for missing configurations. There is no output schema, but the description covers the return semantics adequately. It could be more explicit about the format or level of detail, but that is not critical for this simplicity.

  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, so the schema provides no constraints. Per the baseline for 0 parameters, the description need not compensate. It still mentions the key information returned (configuration status and setup guides), which gives context without needing parameter explanations.

  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 and resource: 'Get step-by-step instructions for configuring the Marketing Analytics MCP server.' It clearly distinguishes from sibling tools, all of which are data retrieval operations, by focusing on setup and configuration. This makes its purpose immediately clear 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 Guidelines4/5

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

  The description implies usage by stating what the tool does: it shows configured APIs and provides guides for missing ones. While it does not explicitly say 'use this when you need setup help,' the context and unique role among data-query siblings make the appropriate usage clear. No explicit exclusions or alternatives are mentioned, but none are needed.

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

• gsc_list_sitesA
  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 burden of behavior disclosure. It mentions that results are scoped to the 'authenticated Google account,' which is a key behavioral trait. It does not elaborate on return format or edge cases, but for a simple list tool this is acceptable.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with the action ('List all...'), and every word earns its place. No redundancy or padding.

  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 zero-parameter list tool with no output schema and no annotations, the description fully covers the tool's purpose, scope, and usage context. It even clarifies the relationship to other gsc_* tools, making it a complete entry point.

  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 schema coverage is 100% (empty schema). Per guidelines, a baseline of 4 applies since there are no params to document. The description adds no parameter details, but none are needed.

  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: 'List all Search Console sites/properties accessible to the authenticated Google account.' This is a specific verb+resource+scope, and it distinguishes itself from sibling gsc_* tools that operate on specific sites.

  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 second sentence, 'Use this to discover Site URLs for use with other gsc_* tools,' provides explicit context for when to use this tool (as a discovery step before other tools). It does not list alternatives or exclusions, but there are no obvious competing tools for listing sites.

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