Server Quality Checklist

Tool Scores

• gsc_search_analyticsD
  1.3/5.0
  Behavior1/5

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

  With no annotations provided, the description must disclose behavior, but it says nothing about return format, pagination, rate limits, authentication, or the meaning of 'raw'. The agent has no idea what to expect from the call, making this a severe 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.

  Conciseness2/5

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

  The description is a single sentence, which is concise, but it is under-specified rather than efficiently informative. There is no front-loading of critical details, and the sentence lacks the substance needed for an agent to act correctly.

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

  Completeness1/5

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

  For a tool with 7 parameters, no output schema, and no annotations, this description is completely inadequate. It doesn't explain the response structure, the meaning of 'raw', or any constraints, leaving the agent unable to understand the tool's full behavior or results.

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

  Parameters1/5

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

  The schema description coverage is only 43%, so the description should compensate for undocumented parameters like 'type', 'rowLimit', and 'startRow'. It adds no parameter-level meaning beyond the schema, failing to clarify the purpose or format of these fields.

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

  Purpose2/5

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

  The description states a specific verb ('Run') and resource ('Search Console Search Analytics query'), but the word 'raw' is vague and doesn't distinguish this tool from siblings like gsc_top_queries or gsc_top_pages, which also run GSC queries. The agent cannot tell what makes this 'raw' or how it differs from the pre-built tools.

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

  Usage Guidelines1/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. The description gives no context about scenarios where a raw query is appropriate, nor does it mention any exclusions or sibling comparisons, leaving the agent without direction.

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

• ga4_landing_pagesD
  1.5/5.0
  Behavior1/5

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

  No annotations are provided, so the description must fully disclose behavior, but it does not. There is no mention of what data is returned, whether it is read-only, any rate limits, or side effects. The description offers zero behavioral transparency.

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

  Conciseness2/5

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

  The description is extremely short but this is under-specification, not conciseness. It provides a terse noun phrase that lacks actionable structure. There is no front-loading of critical information—only a vague label.

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

  Completeness1/5

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

  With 4 parameters, no output schema, and no annotations, this tool demands a much richer description to explain its purpose, output format, and any limitations. The current description is wholly inadequate for an agent to call this tool reliably, especially given the large sibling set with overlapping capabilities.

  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 description adds no information about parameters beyond what the schema already provides. While schema coverage is 75%, the description does not clarify semantics for the 'property' parameter or the date formats. It fails to compensate for any gaps, and the minimal mention of 'engagement metrics' does not relate to any parameter.

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

  Purpose2/5

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

  The description 'GA4 landing pages with engagement metrics' is essentially a restatement of the tool name, providing no verb or specific action (e.g., 'retrieve', 'list', 'analyze'). It is vague about what engagement metrics are returned and how this tool differs from siblings like ga4_top_pages or ga4_run_report.

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

  Usage Guidelines1/5

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

  There is no guidance on when to use this tool versus any of the 19 siblings. No context about use cases, prerequisites, or exclusions is provided. An agent cannot determine if this is the right tool for a given task without external knowledge.

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

• ga4_realtimeD
  1.8/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the tool is a 'realtime active users report', implying a read-only operation but not explicitly stating so. It does not mention required permissions, rate limits, or any side effects. For a data-reporting tool, the lack of even a 'read-only' declaration or any behavioral caveats is a notable gap.

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

  Conciseness2/5

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

  The description is a single under-specified sentence that provides minimal useful content. While it is not verbose, it is not appropriately sized because it omits essential information (like what the report contains or how parameters work). It functions more as a label than an instructive description, so it falls into under-specification rather than genuine conciseness.

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

  Completeness1/5

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

  Given the tool has 4 parameters, no output schema, and no annotations, the description is grossly insufficient. It doesn't explain the return format, the meaning of the default metrics/dimensions, the realtime window, or any limitations. An agent cannot safely invoke this tool without additional external knowledge.

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

  Parameters1/5

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

  Schema description coverage is only 25% (only the 'property' parameter has a description). The description adds no information about any parameters—it does not explain what 'limit', 'metrics', or 'dimensions' are for, nor does it compensate for the schema's lack of per-parameter descriptions. With low coverage and zero enrichment from the description, the agent is left to guess parameter semantics.

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

  Purpose3/5

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

  The description 'GA4 realtime active users report' states a specific resource (GA4 realtime) and implies the tool fetches a report of active users. It distinguishes itself from siblings by the 'realtime' modifier, but lacks an explicit verb (e.g., 'get', 'retrieve') and doesn't clarify whether it returns raw data or an aggregated summary. It's more a title than a functional description, so it's not a tautology but falls short of fully clarifying the intended action.

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

  Usage Guidelines1/5

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

  There is absolutely no guidance on when to use this tool versus its siblings such as ga4_run_report or ga4_top_pages. The description does not mention any use case, prerequisites, or conditions that would select this realtime report over the standard report. Without any context, the agent has no way to know if this is for live dashboards, event tracking, or something else.

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

• ga4_run_reportC
  2.4/5.0
  Behavior2/5

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

  Annotations are absent, so the description carries full responsibility for disclosing behavior. It only says 'Run a raw GA4 Data API report,' which gives no information about pagination, rate limits, authentication requirements, or what the response contains. Despite being unambiguously a read operation, the lack of any behavioral details is a significant gap for a low-level tool.

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

  Conciseness4/5

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

  The description is a single sentence with no filler words, which is efficient. However, it lacks any logical structure or breakdown; it is just a flat statement. Conciseness is good, but the structure could be improved by front-loading key usage constraints.

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

  Completeness1/5

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

  This is a low-level tool with 7 parameters, no output schema, and no annotations. The description is grossly inadequate—it does not explain what a 'raw GA4 Data API report' returns, how the parameters relate, or any expected behavior. An agent would have to rely on external knowledge or trial-and-error to use this tool correctly.

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

  Parameters2/5

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

  Schema description coverage is only 43% (3 of 7 parameters documented: endDate, startDate, property). The description adds no information about the parameters, especially the required dimensions and metrics, and does not compensate for the undocumented parameters. An agent would not know what values to provide for dimensions/metrics or how the limit/offset behave.

  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 states a specific action ('Run...') and a resource ('GA4 Data API report'), which clearly distinguishes it from the specialized sibling tools like ga4_top_pages or ga4_events. However, the word 'raw' is vague and doesn't specify what kind of data is returned, though the intent is reasonably clear.

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

  Usage Guidelines1/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 any of the 18 siblings. There is no mention of when it should be preferred over specialized reports, nor any exclusions or conditions. The agent is left to infer that this is a generic fallback, which is not stated.

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

• find_high_impression_low_ctr_pagesC
  2.5/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of disclosing behavior. It only says 'Find', implying a read-only query, but doesn't state that it returns a list of pages, respect pagination limits, or interact with GSC's sampling/rate limits. No side effects or constraints are mentioned, leaving the agent without a clear picture of what happens when the tool is invoked.

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

  Conciseness2/5

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

  The description is a single sentence, which is concise, but it is under-specified for a tool with 6 parameters, no annotations, and no output schema. It lacks the necessary context to be immediately actionable. While it has no fluff, its brevity does not serve the agent's need for guidance.

  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?

  For a tool with no annotations, no output schema, and incomplete parameter documentation, the description is far too thin. It does not explain return format, default thresholds, or how results are ordered, nor does it distinguish this from overlapping siblings. The agent cannot confidently invoke this tool correctly without additional probing.

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

  Parameters2/5

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

  Schema coverage is only 50%, covering date and siteUrl, but not maxCtr, minImpressions, or rowLimit. The description says 'high impressions and low CTR' which vaguely maps to minImpressions and maxCtr, but doesn't explicitly tie these parameters to their roles or explain defaults. The tool name hints, but the description adds little semantic value beyond the schema.

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

  Purpose4/5

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

  The description clearly states a specific action ('Find') on a specific resource ('GSC pages') with clear criteria ('high impressions and low CTR'). It is distinct from siblings like gsc_top_pages, which list pages generally, and find_pages_with_clicks_but_low_engagement, which targets a different metric. However, it doesn't explicitly name alternatives, so it doesn't fully differentiate from all siblings.

  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 gives no guidance on when to use this tool versus alternatives like seo_opportunity_report or gsc_search_analytics. It doesn't mention prerequisites, typical scenarios, or when a different tool would be more appropriate. The agent is left to infer usage from the tool name and schema.

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

• ga4_eventsC
  2.5/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 fully disclose behavior. It does not mention whether the operation is read-only, what the output format is, whether pagination or limits apply, or any side effects. The description says nothing beyond the basic purpose, leaving the agent blind to critical behavioral details.

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

  Conciseness3/5

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

  The description is very short at seven words, which is concise, but it under-specifies the tool's purpose. It is front-loaded with the core idea but does not earn its place by adding enough value. It is not verbose, but it is too terse to be helpful.

  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 has 4 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the return value, any filtering semantics beyond event name, or the intended usage. An agent would struggle to call this correctly without external 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 75%, with startDate and endDate having format descriptions and property having an example. The description adds no parameter meaning itself. Since coverage is moderate and the remaining parameter (limit) is self-explanatory, the schema carries the burden adequately.

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

  Purpose3/5

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

  The description 'GA4 events by event name' indicates the tool returns events, but it is vague about whether it lists event names, counts, or detailed event data. It does not specify a clear verb like 'get' or 'list', and does not distinguish it from sibling tools like ga4_run_report or ga4_top_pages.

  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?

  There is no guidance on when to use this tool versus alternatives. The description offers no context about typical use cases, prerequisites, or exclusions. An agent would not know why to pick this over ga4_run_report or gsc_search_analytics.

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

• gsc_query_page_matrixC
  2.6/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavior, but it only states a purpose. It does not mention return format (e.g., rows containing query, page, impressions, clicks), whether results are aggregated, how rowLimit works, or any permissions/rate-limit concerns. The word 'matrix' suggests a cross-tabulation, but that's not explicit. The agent is left blind to what happens at runtime.

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

  Conciseness4/5

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

  The description is a single, tightly worded sentence with no filler. It front-loads the core resource and purpose. However, it is so short that it forfeits the opportunity to add necessary context, so it earns a 4 only for economy, not informativeness.

  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?

  This is a moderately complex tool (matrix output, 4 parameters) with no output schema and no annotation support. The description fails to specify the output shape, pagination, or differentiation from similar tools. An agent cannot confidently call this tool based on the given definition alone; it would likely need to probe with a test call.

  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 75% (rowLimit lacks a description). The tool description adds no parameter semantics beyond what the schema already provides. The schema itself supplies basic hints (date format, GSC property, default rowLimit). Since coverage is high, the baseline of 3 applies; the description neither enhances nor detracts from parameter understanding.

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

  Purpose3/5

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

  The description identifies a specific resource (GSC query/page matrix) and a purpose (finding page-level keyword opportunities), but it leaves the exact nature of the matrix vague. It does not say what rows or columns the matrix contains, how it aggregates data, or what distinguishes it from gsc_search_analytics, gsc_top_queries, or gsc_top_pages. It's more than a tautology but lacks concrete detail to separate it from siblings.

  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 usage guidance is provided. There is no indication of when to prefer this tool over the several very similar GSC analytics siblings, no prerequisites (e.g., siteUrl being required despite not being marked required), and no note about result size or filtering. An agent must infer its use from the tool name and one-line description, which is insufficient.

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

• gsc_top_queriesC
  2.6/5.0
  Behavior2/5

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

  With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the output metrics, omitting crucial details like aggregation behavior (daily vs. total), row limits, or how the siteUrl parameter affects results. No mention of response structure or error behaviors.

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

  Conciseness3/5

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

  The single sentence is concise and free of filler, but it's under-specified rather than efficiently informative. It lacks a structure that front-loads key decision points (like defaults or required parameters), making it concise but not useful.

  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 lack of an output schema and the presence of many sibling tools, this description is incomplete. It doesn't specify what fields are returned (e.g., CTR, position), how rowLimit interacts with pagination, or how dates are applied. An agent would need to guess or manually inspect the schema to use it correctly.

  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 description adds no parameter information beyond what the schema already provides. Schema coverage is 75% (missing rowLimit description), and the description doesn't compensate by explaining that rowLimit controls the number of queries or that siteUrl can be a domain property. It simply restates the tool's purpose without parameter context.

  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 identifies the resource (GSC queries) and the key metrics (clicks/impressions), which is specific enough to understand the tool's basic function. However, it doesn't distinguish itself from sibling tools like gsc_search_analytics or gsc_top_pages, and the 'clicks/impressions' phrasing is ambiguous about whether both are returned or one is chosen.

  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. There is no mention of conditions, exclusions, or comparisons to sibling tools like gsc_search_analytics or gsc_top_pages, leaving an agent unable to choose correctly.

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

• compare_gsc_ga4_pagesC
  2.9/5.0
  Behavior2/5

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

  Annotations are entirely absent, so the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, what the response structure looks like, how unmatched pages are handled, or any pagination/limits. The single-line description gives no behavioral transparency beyond the intent to combine data.

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

  Conciseness4/5

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

  The description is a single sentence with no redundancy. It is concise and front-loaded with the primary action and data sources. However, it could be slightly more informative without losing conciseness, but as written it is efficient.

  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?

  This is a complex tool that joins data from two different APIs, yet the description leaves critical context unexplained. There is no output schema, so the description should describe the return shape and semantics. It also lacks guidance on how the join is performed and what the result represents. For an agent to call this correctly and interpret results, more detail is needed.

  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 80%, so the parameter meanings are largely provided by the input schema. The tool description adds nothing beyond that—it does not clarify how parameters relate to the join or what any of them mean in the context of this specific tool. Since coverage is high, the baseline of 3 applies without additional value.

  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 states the specific action 'Join' and identifies the two data sources: GSC page performance and GA4 landing-page engagement. It is clear that this tool merges data from two distinct platforms. However, it does not specify the join key or the output format, and it does not explicitly differentiate itself from other composite tools like find_high_impression_low_ctr_pages, so it misses some 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?

  No usage guidance is provided. The description does not state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. Without this, an agent cannot determine if this is the right tool for a given task beyond the obvious 'comparing GSC and GA4 data' context.

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

• content_refresh_candidatesC
  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 the full burden of disclosing behavior. It states the tool ranks pages but does not reveal whether it is read-only, whether authentication to both GSC and GA4 is required, how the data is combined, or any limitations such as rate limits or data freshness. This is a significant gap for a tool that likely performs multi-source analysis.

  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, succinct sentence that clearly states the tool's core function without any filler. It is front-loaded with the action and purpose, making it easy to parse. No unnecessary words or redundant details.

  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?

  For a tool that combines GSC and GA4 data to rank pages for refresh, the description is overly minimal. It does not explain what 'opportunity' means, which engagement metrics are used, how the ranking is computed, or what the output format is. There is no output schema, so the description alone must clarify expected results, but it does not. The tool's complexity demands more detail than 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 80%, with startDate, endDate, siteUrl, and property having descriptions in the schema, and rowLimit lacking description. The tool description adds no parameter-specific information beyond the schema. Since the schema does most of the documentation, the baseline of 3 is appropriate; the description does not compensate for the undocumented rowLimit parameter.

  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 (rank), the resource (pages), and the criteria (GSC opportunity and GA4 engagement), making the purpose distinct from pure GSC or GA4 reporting tools. It implicitly differentiates from siblings like gsc_top_pages or ga4_top_pages by combining both data sources, but does not explicitly name alternatives, so it stops short of a 5.

  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 its many siblings (e.g., seo_opportunity_report, find_pages_with_clicks_but_low_engagement). It does not state prerequisites, such as whether both siteUrl and property are required, or when a user should choose this over a more specific report. The context is entirely implied by the name and brief description.

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

• find_pages_with_clicks_but_low_engagementC
  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 must carry the full burden of behavioral disclosure. It only states the action ('find') without mentioning whether it is read-only, how it combines GSC and GA4 data, what the output format is, or any side effects or limitations. This is a minimal behavior description that leaves much to inference.

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

  Conciseness4/5

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

  The description is a single sentence with no extraneous words, making it highly concise. It front-loads the core purpose. However, it lacks any structural elements like examples or bullet points, and given the tool's complexity, it might be too terse. Still, for conciseness alone it earns a 4.

  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 7 parameters, no output schema, and no annotations, the description is far from complete. It does not explain what 'weak GA4 engagement' means operationally, how data from GSC and GA4 is merged, or what the returned data looks like. The description leaves critical information missing for an agent to correctly invoke and interpret results.

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

  Parameters3/5

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

  The schema description coverage is 57%, with four parameters (startDate, endDate, siteUrl, property) having descriptions. The tool description adds no additional meaning about parameters like rowLimit, minClicks, or maxEngagementRate, but those are partially self-explanatory given the tool's purpose. Since schema coverage is moderately high and the description adds nothing, baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the action ('Find') and the target resource ('pages with GSC clicks but weak GA4 engagement'). This is specific enough to distinguish it from many siblings, though it does not explicitly name an alternative tool or contrast with them. A 4 reflects clear purpose without explicit 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?

  There is no guidance on when to use this tool versus alternatives like compare_gsc_ga4_pages or content_refresh_candidates. The description gives no context about appropriate use cases, prerequisites, or exclusions, so agents have to infer usage patterns from the name alone.

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

• ga4_top_pagesC
  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 does not mention default ordering, limit behavior, whether filtering is supported, pagination, or any caveats about the metrics reported. The description adds little beyond what the name already implies.

  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?

  A single front-loaded sentence with no filler. It is efficient, though it sacrifices useful detail for brevity.

  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?

  For a tool with 4 parameters, no output schema, and no annotations, the description should explain what 'top' means, how results are ordered, and what the returned shape looks like. It does none of this, leaving an agent to guess at the tool's semantics and output format.

  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 75%, with startDate, endDate, and property already documented in the schema. The description itself adds no parameter-level meaning, and 'limit' remains undocumented in both places, though its default of 100 is specified in the schema. Baseline 3 is appropriate since the schema carries most of the weight.

  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 names a specific verb and resource ('Top GA4 pages') and lists the measured metrics (views, users, sessions), which makes the basic purpose clear. However, it does not differentiate this tool from siblings like ga4_landing_pages, gsc_top_pages, or ga4_run_report, and it is ambiguous what ordering 'top' implies.

  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?

  There is no guidance on when to use this tool versus alternatives such as ga4_landing_pages, ga4_run_report, or gsc_top_pages. Given the sibling set is large and overlapping, an agent cannot tell from the description which tool fits a given reporting task.

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

• gsc_top_pagesC
  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. It only says 'top ... by clicks/impressions', which implies a sorted list but doesn't disclose how 'top' is determined (e.g., sort order, aggregation, date range handling, or whether both metrics are returned). The behavior is underspecified for a tool that likely returns multiple rows.

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

  Conciseness4/5

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

  The description is a single, efficient sentence with no fluff. It's concise, but the brevity sacrifices essential context. The key info (resource and metric) is present, but there's no structure or front-loading of critical usage constraints.

  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?

  The tool has 4 parameters, no output schema, and no annotations, yet the description only says 'Top GSC pages by clicks/impressions.' It lacks critical details: what does the output look like? How is 'top' defined? Are there any sorting or filtering options? How does it differ from similar tools? This is insufficient for an agent to call it correctly without guessing.

  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 75% (3 of 4 parameters have descriptions). The description adds no parameter-specific guidance beyond what the schema provides. The mention of 'clicks/impressions' indirectly relates to the output but not to how parameters affect results. Baseline 3 applies because the schema handles most parameter semantics.

  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 states a clear verb-noun pair ('Top GSC pages') and the metric (clicks/impressions), making it distinct from sibling tools like gsc_top_queries which focus on queries. However, it doesn't explicitly differentiate from gsc_query_page_matrix or compare_gsc_ga4_pages, which also deal with pages, so it's clear but not perfectly unique.

  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?

  There is no guidance on when to use this tool versus alternatives. With 19 siblings, an agent has no indication of why this tool is preferred over gsc_top_queries, gsc_query_page_matrix, or find_high_impression_low_ctr_pages. No exclusions or prerequisites are mentioned.

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

• seo_opportunity_reportC
  2.9/5.0
  Behavior2/5

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

  With no annotations, the description must disclose behavior, but it only restates the purpose. It does not explain how the two candidate lists are combined (union, intersection, ranking), what data sources are required (GSC and GA4), whether it is read-only, or the output format. This is a significant gap for a report tool.

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

  Conciseness4/5

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

  The description is a single concise sentence with no fluff. It front-loads the core value proposition ('compact SEO opportunity report') and then specifies the data sources included. It is efficient, though it could benefit from a bit more detail without becoming verbose.

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

  Completeness2/5

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

  Given the tool's complexity (5 parameters, two implied data sources, no output schema, no annotations), the description is too sparse. It does not clarify output structure, rowLimit behavior, or whether both siteUrl and property are required. An agent could not safely call this tool correctly based on this description alone.

  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 80%, so the schema already documents most parameters. The tool description adds no extra meaning about how parameters interact (e.g., that both siteUrl and property are needed for combined data). Since coverage is high, the baseline of 3 is appropriate, but it does not elevate beyond that.

  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 produces a 'compact SEO opportunity report' that combines two candidate types (high-impression/low-CTR and low-engagement), distinguishing it from sibling tools that focus on individual types. However, the verb is implied rather than explicit (e.g., 'generates', 'returns'), so it stops short of a fully specific action statement.

  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 calling the individual sibling tools (e.g., find_high_impression_low_ctr_pages or find_pages_with_clicks_but_low_engagement). The description does not mention trade-offs, prerequisites, or alternative workflows, leaving the agent to infer context.

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

• ga4_traffic_sourcesB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It states that it retrieves traffic sources grouped by channel and source/medium, but does not mention whether it is read-only, whether any side effects occur, or how the data is returned (e.g., pagination, limiting). This is a minimal read-like tool, but the description offers no explicit safety or mutation 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 a single sentence with zero filler, front-loading the exact purpose. Every word earns its place, and it is immediately scannable.

  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 simple report tool, the description is adequate but not complete. It does not describe the output format or metrics, and with no output schema, an agent cannot predict the result structure. Given the number of GA4 sibling tools, a bit more context on what differentiates this output (e.g., 'returns sessions and users by channel') would improve completeness.

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

  Parameters3/5

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

  The schema already describes three of four parameters (75% coverage), including date format and property format; the description adds nothing about parameters. The only undocumented parameter, limit, is not explained in the description either. Since the schema does the heavy lifting, the description remains at baseline without enhancing understanding.

  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 'GA4 traffic sources by default channel group and source/medium' names a specific resource (GA4 traffic sources) and specifies the grouping dimensions, clearly distinguishing it from sibling tools like ga4_top_pages or ga4_landing_pages. It could be slightly more explicit about what metrics are returned, but the core purpose is unambiguous.

  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?

  There is no guidance on when to use this tool versus alternatives such as ga4_run_report or ga4_landing_pages. The description states only what the tool does, not the context in which it should be selected, nor any exclusions or prerequisites. An agent must infer usage from the name alone.

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

• project_mappingsB
  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 full responsibility for behavioral disclosure. It only says 'List ... from PROJECTS_CONFIG', implying a read-only operation, but does not mention response format, potential errors, or whether it requires any configuration. It gives minimal transparency beyond the basic action.

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

  Conciseness4/5

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

  The description is a single, clear sentence with no wasted words. It is appropriately concise for a parameter-less tool, though it could be slightly more descriptive without becoming verbose. It's on the minimal side but not under-specified.

  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 simple list tool with no parameters and no output schema, the description is adequate but not fully complete. It does not explain what the output looks like, what 'mappings' entails, or any edge cases. Given the tool's simplicity, this is a minimum viable description that could benefit from a note about the return structure.

  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 (schema is an empty object), and schema description coverage is 100%. Per the rubric, a baseline score of 4 is appropriate since there are no parameters to document. The description adds nothing here, but none is needed.

  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 object (local domain/client mappings) with a specific source (PROJECTS_CONFIG). It is unambiguous about what the tool does, though it does not explicitly differentiate from sibling tools like project_lookup, so it doesn't earn a 5.

  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?

  There is no guidance on when to use this tool versus alternatives. No context about typical use cases, prerequisites, or why one would choose this over siblings. The agent must infer usage purely from the tool name and description.

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

• project_lookupB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description must fully disclose behavior. It implies a read-only lookup ('Find') but does not specify whether the operation is safe, what happens on no match, or any permissions required. It also does not describe the return format or potential side effects.

  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 sentence that is front-loaded with the action and resource. Every word adds value, and there is no redundant or repeated information.

  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 lookup with no output schema, the description adequately tells an agent what input to provide and the general purpose. However, it omits details like the shape of the returned mapping, multiple-match behavior, or error handling. Given the simplicity of the tool, this is nearly complete but not exhaustive.

  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 only defines nameOrDomain as a string with 0% coverage. The description clarifies that the parameter can be a project name, client, or domain, adding meaning beyond the bare schema. This compensates for the missing schema description, though it stops short of giving concrete examples or format constraints.

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

  Purpose4/5

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

  The description uses a specific verb ('Find') and a specific resource ('local project mapping'), and lists search criteria (project name, client, or domain). This makes the tool's purpose clear and distinguishes it from the broad GSC/GA4 analytics siblings, though it does not explicitly differentiate from the similarly-named 'project_mappings' sibling.

  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. Given the sibling 'project_mappings' exists, an agent cannot tell which tool to prefer without additional context. No exclusions or conditions are stated.

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

• gsc_url_inspectionA
  3.5/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the behavioral burden. It identifies the operation as an inspection, which implies a read-only action, but it does not disclose any additional behavioral aspects such as permission requirements, rate limits, or response characteristics. The description is not misleading but lacks explicit transparency about side effects or constraints.

  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 directly states the core action and scope. It is efficiently concise with no wasted words, earning its place in the limited space.

  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?

  The description is incomplete for an effective tool definition. It lacks any explanation of the return value (e.g., what index statuses are possible), does not clarify the meaning of siteUrl and languageCode, and provides no contextual guidance on prerequisites like GSC property access. With no output schema and sparse annotations, this leaves agents without critical information to use the tool correctly.

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

  Parameters2/5

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

  Schema description coverage is only 33% (only siteUrl has a description). The tool description adds minimal value: it implies inspectionUrl is the target URL, but does not clarify the role of siteUrl or languageCode. Given the low schema coverage, the description should compensate more substantially, but it does not.

  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 ('Inspect'), a specific resource ('Google index status'), and the scope ('for a URL under a GSC property'). It is distinct from sibling tools that focus on analytics or reporting, 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 for checking index status but provides no explicit guidance on when to choose this over alternatives (e.g., which other tools to use for similar URL checks). Sibling tools like gsc_search_analytics or gsc_top_pages are not referenced, leaving the selection criteria unstated.

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

• gsc_list_sitesA
  3.8/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that results are scoped to the current credentials, but it does not mention whether permissions are included, what the return format looks like, or any caveats about property types.

  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 front-loads the verb and resource, states the scope, and contains no filler. Every word 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?

  For a zero-parameter, no-output-schema list tool, the description covers the essential function. However, it could strengthen completeness by noting that the returned site identifiers can be used as inputs for other GSC tools, which would help the agent understand downstream usage.

  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% vacuously. The description cannot add parameter meaning beyond what already exists, so the zero-param baseline of 4 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 'List' with a clear resource 'Google Search Console sites' and adds scope with 'visible to the current credentials.' This distinguishes it from the sibling analytics and reporting tools, which operate on data rather than site enumeration.

  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 gives no explicit when-to-use instruction or mention of alternatives. The sibling context implies this tool is likely the discovery step before running GSC analytics tools, but that relationship is left entirely implicit.

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

• ga4_list_propertiesA
  3.9/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 that results are limited to what 'the credentials' can see, implying authentication scoping, but it does not specify the return format beyond 'summaries,' whether pagination applies, or whether it returns both accounts and properties in a single call. Behavior is only partially 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?

  A single, clear sentence with no filler. The essential scope (accounts and property summaries) is front-loaded and the credential constraint is included. Every word earns its place.

  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?

  Without an output schema, the description should clarify what the agent can expect. It says 'summaries' but not whether each item includes a property ID, account hierarchy, or how to map them to sibling tool parameters. For a discovery tool that feeds into other GA4 tools, this missing linkage is a notable gap.

  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 is fully covered. A baseline of 4 applies because there are no parameters to explain. The description adds no parameter-specific 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 states a clear action (list) and resource (GA4 accounts and property summaries). It distinguishes itself from sibling report tools like ga4_run_report, ga4_top_pages, and gsc_* tools, which operate on specific properties rather than enumerate them.

  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 purpose implies usage for discovery before report tools, but the description does not explicitly state when to use it versus siblings. It lacks guidance like 'use this to get property IDs before calling ga4_run_report' or exclusions such as 'use gsc_list_sites for Search Console.' Useful context is left to inference.

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