GA4 MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific GA4 analysis functions, such as comparing periods, analyzing funnels, getting device breakdowns, or running reports. No tools appear to overlap in functionality, making it easy for an agent to select the correct one based on the task.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern, primarily using 'get_' or 'run_' prefixes (e.g., get_daily_trend, run_report). Minor variations like 'compare_periods' and 'list_accounts' still adhere to a clear naming convention, ensuring predictability and readability throughout the set.
Tool Count4/5
With 20 tools, the count is slightly high but reasonable for a comprehensive GA4 analytics server, covering diverse aspects like traffic, user behavior, and reporting. It avoids being overwhelming by maintaining clear scopes, though it borders on the upper limit for typical server purposes.
Completeness5/5
The tool set provides complete coverage for GA4 analytics, including data retrieval (e.g., get_traffic_summary), detailed analyses (e.g., get_conversion_funnel), property management (e.g., list_accounts), and flexible reporting (e.g., run_report). No obvious gaps exist, supporting full agent workflows from overview to deep dives.
Average 3/5 across 20 of 20 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it states the tool performs comparisons, it doesn't describe what the comparison output looks like, whether it requires specific permissions, what happens with invalid date ranges, or any rate limits. For a tool with 6 parameters including nested objects, this is insufficient 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 extremely concise - just two sentences in Japanese that efficiently convey the core functionality. Every word earns its place, with no redundant information. The structure is front-loaded with the main purpose followed by specific examples.
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 (6 parameters including nested objects), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the comparison output looks like, how results are formatted, what metrics are available beyond the defaults, or any error conditions. For a comparison tool with multiple parameter configurations, more context 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?
The schema description coverage is 100%, so all parameters are documented in the schema. The description mentions comparison types (week-over-week, month-over-month, year-over-year) which aligns with the comparisonType enum values, but adds little beyond what's already in the comprehensive schema descriptions. Baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose as 'compare two periods' and provides specific examples of comparison types (week-over-week, month-over-month, year-over-year analysis). However, it doesn't explicitly differentiate this comparison tool from other analytics tools in the sibling list, which includes various reporting tools like get_daily_trend and 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 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 the many other analytics tools available (like get_daily_trend, run_report, get_traffic_summary). It mentions what types of comparisons are possible but gives no context about appropriate use cases or when to choose this over alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions analysis and checking rates, which implies a read-only operation, but doesn't specify data sources, permissions, rate limits, or output format. For a tool with 3 parameters and no annotations, this leaves significant behavioral gaps.
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 concise with two sentences that directly state the tool's function. It's front-loaded with the main purpose and avoids unnecessary details. However, it could be slightly more structured by explicitly mentioning it's for GA4 data or linking to sibling tools.
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 no annotations, no output schema, and 3 parameters with full schema coverage, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral traits, usage context, and output format. For an analytics tool with potential complexity, more completeness is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters (propertyId, period, steps). The description adds no additional parameter semantics beyond what's in the schema, such as explaining how steps relate to funnel analysis. Baseline score of 3 is appropriate when schema does the heavy lifting.
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's purpose: 'analyzes conversion funnels' and 'checks step pass-through rates and dropout rates.' It specifies the verb (analyze/check) and resource (conversion funnels), but doesn't differentiate from sibling tools like 'get_user_journey' which might have overlapping analytics functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites, context, or comparisons to sibling tools like 'get_user_journey' or 'run_report' that might offer similar functionality. Usage is implied through the description but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While it indicates this is a data retrieval operation ('取得します'), it doesn't disclose important behavioral traits like whether this requires authentication, has rate limits, returns paginated results, or what format the data comes in. For a data retrieval tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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 appropriately concise with two sentences. The first sentence states the core purpose, and the second provides use case context. There's no wasted verbiage or unnecessary repetition. While it could be slightly more specific, every sentence earns its place by adding value.
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 data retrieval tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'trend data' specifically includes, how results are structured, whether there are limitations on date ranges or metrics, or how this differs from similar sibling tools. The description provides basic purpose but lacks the contextual richness needed for confident tool 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?
Schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description adds no parameter-specific information beyond what's in the schema. It mentions '日別のトレンドデータ' (daily trend data) which aligns with the date parameters, but provides no additional semantic context about parameter usage, relationships, or constraints. Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose: '日別のトレンドデータを取得します' (retrieves daily trend data). It specifies the resource (trend data) and timeframe (daily), and mentions potential use cases (graph creation, trend analysis). However, it doesn't explicitly differentiate from sibling tools like 'get_hourly_traffic' or 'get_traffic_summary' which might also retrieve trend-related data.
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. It mentions general use cases ('グラフ作成やトレンド分析に使用できます' - can be used for graph creation and trend analysis), but doesn't specify scenarios where this tool is preferred over siblings like 'compare_periods' for trend analysis or 'run_report' for custom data retrieval. There's no explicit when/when-not guidance or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While it indicates this is a read operation ('取得します' - get), it doesn't mention authentication requirements, rate limits, pagination, data freshness, or what specific metrics beyond the examples are included. For a metrics retrieval tool with no annotation coverage, this leaves significant behavioral gaps.
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 Japanese sentence that clearly states the tool's purpose. It's appropriately concise without being under-specified, though it could potentially be more structured with separate sentences for purpose and scope.
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 this is a metrics retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what format the metrics are returned in, what specific metrics beyond the examples are available, whether there are limitations on data availability, or how the metrics are calculated. For a tool that presumably returns complex engagement data, more context 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 100%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. It mentions 'engagement metrics' generally but doesn't explain how parameters affect which metrics are returned or their calculation. Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose: 'エンゲージメント関連の詳細指標（エンゲージメント率、平均エンゲージメント時間など）を取得します' translates to 'Get detailed engagement-related metrics (engagement rate, average engagement time, etc.)'. It specifies the verb ('取得します' - get) and resource (engagement metrics), but doesn't explicitly differentiate from sibling tools like 'get_traffic_summary' or 'get_user_journey' which might also involve engagement data.
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. With multiple sibling tools like 'get_traffic_summary', 'get_user_journey', and 'run_report' that might overlap with engagement metrics, there's no indication of when this specific engagement metrics tool is appropriate versus those other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description only states what the tool retrieves but doesn't mention any behavioral traits: no information about permissions needed, rate limits, whether this is a read-only operation, what format the results come in, or any side effects. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded with the core functionality. Every word earns its place in conveying the essential 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 complexity of analytics tools and the lack of both annotations and output schema, the description is insufficiently complete. It doesn't explain what the analysis results contain, their format, or any important behavioral context. For a tool that retrieves analytical data with multiple parameters and no output schema, users need more information about what to expect from the tool's operation.
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 schema already documents all three parameters (propertyId, period, limit) with descriptions and enum values. The description doesn't add any additional meaning about parameters beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
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's purpose: '離脱ページ（ユーザーが最後に見たページ）の分析結果を取得します' (Get analysis results for exit pages, the last pages users viewed). It specifies the verb '取得します' (get/retrieve) and resource '離脱ページの分析結果' (exit page analysis results). However, it doesn't explicitly differentiate from sibling tools like 'get_landing_pages' or 'get_top_pages', which reduces it from a perfect score.
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 are multiple sibling tools for analytics data (e.g., get_landing_pages, get_top_pages, get_engagement_metrics), but the description doesn't indicate when exit page analysis is specifically needed or when other tools might be more appropriate. No usage context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. While 'get' implies a read operation, the description doesn't address authentication requirements, rate limits, pagination behavior (despite having a 'limit' parameter), error conditions, or what format the analysis results take. For a tool with 4 parameters and no output schema, this is insufficient.
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 that gets straight to the point. It's appropriately sized for a tool with clear parameters documented in the schema. There's no wasted language or unnecessary elaboration.
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 annotations, and no output schema, the description is inadequate. It doesn't explain what 'access analysis results' actually contain, how they're structured, or what metrics are included. For an analytical tool in a crowded namespace of 17 sibling tools, more context about the specific type of analysis and its output 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 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema - it mentions 'region (country or city/ward/town/village)' which aligns with the 'level' parameter's enum values, but doesn't provide additional context about parameter interactions or usage patterns.
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's purpose: 'get access analysis results by region (country or city/ward/town/village)'. It specifies the verb ('get') and resource ('access analysis results'), and indicates the regional breakdown dimension. However, it doesn't explicitly differentiate from sibling tools like 'get_traffic_sources' or 'get_device_breakdown' that also provide analytical breakdowns.
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. With 17 sibling tools including various analytical breakdowns (device, traffic sources, etc.), there's no indication of when geographical analysis is preferred over other dimensions or how this tool relates to broader reporting tools like 'run_report'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions 'get analysis results' but doesn't specify what the analysis includes (e.g., metrics like bounce rate, sessions), whether it's read-only, if there are rate limits, or authentication needs. For a tool with no annotations, this is a significant gap, warranting a score of 2.
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 in Japanese that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly. However, it could be slightly more structured by including key details, but it's concise enough for a score of 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (retrieving analytics data), no annotations, and no output schema, the description is incomplete. It doesn't explain the return values or behavioral aspects like data format or limitations. While it states the purpose, it lacks depth for a tool in this context, resulting in a score of 3.
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, with clear documentation for each parameter (propertyId, period, limit). The description adds no additional meaning beyond the schema, such as explaining how 'landing pages' relate to the parameters. Given the high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.
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's purpose: 'get analysis results for landing pages (pages users first accessed).' It specifies the verb 'get' and resource 'landing pages analysis results,' making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_top_pages' or 'get_exit_pages,' which might also retrieve page-related data, so it doesn't reach a score of 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 alternatives. It doesn't mention sibling tools or contexts where this tool is preferred, such as for analyzing initial user interactions compared to other page-related tools. Without any usage instructions, it falls to a score of 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions what the tool does but doesn't describe key behavioral traits such as whether it requires authentication, has rate limits, returns paginated results, or what format the output takes. For an analytics tool with no annotation coverage, this leaves significant gaps in understanding how it operates.
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 in Japanese that clearly states the tool's purpose and available metrics. It's appropriately sized and front-loaded with the main function, though it could be slightly more structured by separating purpose from capabilities for better readability.
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 complexity of user behavior analysis, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs, rate limits, or output format, and it lacks usage guidelines. For a tool with two parameters and analytical output, more context is needed to ensure proper agent 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?
Schema description coverage is 100%, so the schema already documents both parameters (propertyId and period) with descriptions and enum values for period. The description adds no additional meaning beyond what the schema provides, such as explaining how these parameters affect the analysis or providing usage examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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 performs 'comparative analysis of new vs returning users' and specifies what metrics can be checked (session counts and dwell time). This provides a specific verb ('compare analysis') and resource ('new vs returning users'), though it doesn't explicitly differentiate from sibling tools like 'get_engagement_metrics' or 'get_user_journey' that might overlap in user behavior analysis.
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. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools such as 'get_engagement_metrics' or 'get_user_journey', which might offer similar or complementary user behavior insights. Usage is implied only by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While '取得します' implies a read operation, it doesn't specify whether this requires authentication, has rate limits, returns structured data, or handles errors. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence in Japanese that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential 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?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what format the returned details will have, what specific fields are included beyond the examples given, or how to interpret the results. The context signals show this is a simple single-parameter tool, but the description should do more to compensate for missing structured documentation.
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 has 100% description coverage with a clear parameter description for 'propertyId'. The description adds no additional parameter information beyond what the schema provides, but doesn't need to compensate for gaps. Baseline 3 is appropriate when schema documentation is complete.
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 ('取得します' - retrieve/get) and resource ('GA4プロパティの詳細情報' - GA4 property details), specifying what information is retrieved (name, timezone, currency, etc.). It distinguishes from siblings by focusing on property metadata rather than reports or analytics data, though it doesn't explicitly name alternatives.
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 like 'get_metadata' (which might overlap) or other property-related tools. There's no mention of prerequisites, appropriate contexts, or exclusions for this specific property details retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions the tool retrieves rankings and lists metrics, but doesn't describe behavioral traits such as whether it's a read-only operation, potential rate limits, authentication requirements, or what the output format looks like. For a data retrieval tool with zero annotation coverage, this is a significant gap in transparency.
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 appropriately concise with two sentences that directly state the tool's purpose and capabilities. There's no unnecessary information or repetition. However, it could be slightly more front-loaded by immediately clarifying the ranking aspect, though the current structure is still 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?
Given the complexity of a ranking tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the ranking methodology (e.g., sorted by page views?), output format, or behavioral constraints. While it mentions metrics, it lacks details needed for the agent to fully understand how to use and interpret results from this 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?
The schema description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain how 'pathFilter' interacts with ranking or what 'limit' prioritizes). This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't compensate with additional semantic 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 states the tool's purpose: '人気ページのランキングを取得します' (get ranking of popular pages). It specifies the verb ('取得します' - get/retrieve) and resource ('人気ページのランキング' - ranking of popular pages), making the purpose understandable. However, it doesn't explicitly distinguish this tool from similar siblings like 'get_landing_pages' or 'get_exit_pages', which might also retrieve page-related data.
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. It mentions what metrics can be checked ('PV数、滞在時間、直帰率など' - page views, dwell time, bounce rate, etc.), but doesn't specify use cases, prerequisites, or comparisons to sibling tools like 'get_landing_pages' or 'get_traffic_summary'. This leaves the agent with insufficient context for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It states this is a retrieval operation ('取得します') but doesn't describe what format the analysis results take, whether there are rate limits, authentication requirements, pagination behavior, or what happens when parameters are omitted. For a data retrieval tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
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, efficient Japanese sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for what it communicates and front-loads the core functionality. Every word earns its place in conveying the essential 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 complexity of an analytics tool with 3 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the analysis results look like, what metrics are included, how data is formatted, or any behavioral constraints. The agent would need to guess about the output structure and operational characteristics when invoking this 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?
The schema description coverage is 100%, so the schema already fully documents all three parameters with descriptions and enum values. The description doesn't add any parameter-specific information beyond what's in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.
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's purpose: '取得します' (get/retrieve) traffic source analysis results, specifying the resource as '流入元（チャネル、ソース、メディアなど）' (traffic sources like channel, source, medium). It distinguishes itself from siblings by focusing specifically on traffic source analysis rather than other analytics dimensions like devices, geography, or pages. However, it doesn't explicitly contrast with the most similar sibling 'get_traffic_summary'.
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. It doesn't mention when this tool is appropriate, what prerequisites might exist, or how it differs from similar tools like 'get_traffic_summary' or 'run_report'. The agent must infer usage context solely 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.
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 mentions the tool executes reports and retrieves data like active user counts, but doesn't disclose important behavioral traits such as authentication requirements, rate limits, data freshness, or whether this is a read-only operation.
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 in Japanese that conveys the core purpose. It's appropriately sized and front-loaded with the main action, though it could be slightly more structured for clarity.
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 complexity of a real-time reporting tool with no annotations and no output schema, the description is insufficient. It doesn't explain what data is returned, the format of results, error conditions, or performance characteristics that would help an agent use it correctly.
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 schema already documents all three parameters thoroughly. The description doesn't add any additional semantic context about the parameters beyond what's in the schema descriptions, maintaining the baseline score.
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's purpose: 'execute real-time reports' and 'get current active user count etc.' It specifies the verb (execute/get) and resource (real-time reports), though it doesn't explicitly distinguish it from sibling tools like 'run_report' or 'get_daily_trend'.
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. It doesn't mention when real-time reporting is appropriate compared to historical reports, nor does it reference any sibling tools for different use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions flexibility but doesn't address important behavioral aspects: authentication requirements, rate limits, whether this is a read-only operation, expected response format, error handling, or performance characteristics. The description is insufficient for a tool with 8 parameters and complex nested objects.
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 appropriately concise with two sentences that directly state the tool's purpose and key capability. There's no wasted language, though it could be slightly more informative given the tool's complexity. The structure is front-loaded with the core purpose stated first.
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 complex tool with 8 parameters (including nested objects), no annotations, and no output schema, the description is inadequate. It doesn't explain what kind of data structure is returned, how results are formatted, pagination behavior, or error conditions. The description should provide more context about the tool's behavior and output given the absence of structured metadata.
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 schema already documents all parameters thoroughly. The description adds minimal value beyond the schema, only mentioning that arbitrary dimensions and metrics can be specified. It doesn't provide additional context about parameter interactions, best practices, or common use patterns that would help an agent use the tool effectively.
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's purpose: 'GA4の汎用レポートを実行します' (runs GA4 general reports) with the ability to specify arbitrary dimensions and metrics for flexible data retrieval. It's specific about the resource (GA4 reports) and action (execute/run), though it doesn't explicitly differentiate from sibling tools like 'run_realtime_report' or other specialized GA4 tools.
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. With many sibling tools available (compare_periods, get_daily_trend, run_realtime_report, etc.), there's no indication of when this flexible report tool is preferable to more specialized ones, nor any mention of prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states what data is returned (device breakdown with OS/browser info) but doesn't describe the return format, pagination, rate limits, authentication needs, or whether this is a read-only operation. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 appropriately sized and front-loaded. The first sentence clearly states the core purpose, and the second sentence adds valuable supplementary information about included data (OS and browser details). There's no wasted language 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 simple 2-parameter read tool with no output schema, the description provides basic purpose but lacks important context. It doesn't explain the return format, data structure, or what 'アクセス内訳' (access breakdown) specifically entails. While it mentions OS and browser information are included, it doesn't describe how this data is organized or presented.
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 schema already documents both parameters (propertyId and period with enum values). The description doesn't add any parameter-specific information beyond what's in the schema. It doesn't explain how these parameters affect the device breakdown results or provide additional context about parameter usage.
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's purpose: 'デバイス別（PC/モバイル/タブレット）のアクセス内訳を取得します' (Get access breakdown by device - PC/mobile/tablet). It specifies the verb ('取得します' - get/retrieve) and resource ('アクセス内訳' - access breakdown) with device categories. However, it doesn't explicitly differentiate from sibling tools like 'get_geo_breakdown' or 'get_traffic_sources' beyond mentioning it includes OS and browser information.
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. It doesn't mention when this tool is appropriate (e.g., for device-specific analysis) or when other tools like 'get_traffic_summary' or 'get_engagement_metrics' might be better suited. There's no context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions the tool's purpose and potential use case but doesn't describe what the tool actually returns (e.g., hourly traffic counts, percentages), whether it requires specific permissions, rate limits, or any side effects. For a read operation with zero annotation coverage, this leaves significant gaps in understanding the tool's behavior.
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 concise (two sentences) and front-loaded with the core purpose. Both sentences add value: the first states what the tool does, and the second suggests a use case. There's no wasted text, though it could be slightly more structured for clarity.
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 no annotations, no output schema, and the description lacks behavioral details, it's incomplete for effective use. The agent won't know what format the hourly traffic data returns (e.g., JSON structure, metrics included) or any operational constraints. For a data analysis tool with 2 parameters, this leaves too much unspecified.
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 both parameters (propertyId and period) well-documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema (e.g., it doesn't explain format of propertyId or clarify period enum values). Baseline 3 is appropriate when the schema handles parameter documentation effectively.
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's purpose: 'analyzes hourly access patterns' (時間帯別のアクセス状況を分析します) and mentions it can be used for 'optimizing posting or campaign timing' (投稿やキャンペーンのタイミング最適化に活用できます). It specifies the resource (access patterns) and verb (analyzes), but doesn't explicitly differentiate from sibling tools like get_daily_trend or get_traffic_summary beyond the hourly focus.
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 context ('for optimizing posting or campaign timing'), suggesting when this analysis might be useful. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like get_daily_trend or get_traffic_sources, nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions the prerequisite (GA4 site search configuration) but doesn't describe what the analysis entails (e.g., metrics returned, format, whether it's read-only or has side effects). For a tool with no annotations, this leaves significant gaps in understanding its behavior and safety profile.
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 concise with two sentences that directly address purpose and a key usage condition. It's front-loaded with the main function and avoids unnecessary details. However, it could be slightly more structured by explicitly separating purpose from prerequisites for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with three parameters and analytical functionality. It lacks details on what the analysis returns (e.g., metrics like search volume or trends), behavioral traits (e.g., read-only status, rate limits), and how it differs from siblings. This leaves the agent with insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (propertyId, period, limit) with descriptions. The description doesn't add any parameter-specific details beyond what's in the schema, such as explaining how 'propertyId' relates to GA4 or what 'limit' affects in the analysis. Baseline 3 is appropriate when the schema handles parameter documentation.
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's purpose: 'サイト内検索キーワードを分析します' (analyzes site search keywords). It specifies the resource (site search keywords) and verb (analyzes), making the function clear. However, it doesn't explicitly differentiate from sibling tools like 'get_top_pages' or 'get_traffic_sources' that might also involve keyword analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context: 'GA4でサイト内検索が設定されている場合のみ有効です' (only valid when site search is configured in GA4). This implies a prerequisite condition but doesn't explicitly state when to use this tool versus alternatives like 'get_top_pages' for general page analysis or 'run_report' for custom reports. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 describes a read operation ('取得します' - get) which implies it's non-destructive, but doesn't mention any behavioral traits like authentication needs, rate limits, response format, or whether it's a safe operation. For a tool with zero annotation coverage, this is a significant gap in transparency, as it lacks details on how the tool behaves beyond its basic purpose.
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 appropriately sized with two sentences that are front-loaded: the first states the core purpose, and the second adds usage context. There's no wasted text, and both sentences earn their place by providing essential information. However, it could be slightly more structured to explicitly separate purpose from guidelines, but it remains efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with 1 optional parameter), no annotations, no output schema, and high schema coverage, the description is somewhat complete but has gaps. It explains what the tool does and hints at usage, but lacks behavioral details like response format or error handling. For a tool with no output schema, the description doesn't compensate by describing return values, making it minimally adequate but not fully comprehensive.
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 1 parameter with 100% description coverage, providing details on 'propertyId' as a GA4 property ID that defaults to an environment variable. The description doesn't add any parameter-specific information beyond what the schema already documents. According to the rules, with high schema coverage (>80%), the baseline score is 3 even without param info in the description, which applies here as the description doesn't compensate with additional 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 clearly states the tool's purpose: '利用可能なディメンションとメトリクスの一覧を取得します' (Get a list of available dimensions and metrics). It specifies the verb '取得します' (get) and resource 'ディメンションとメトリクスの一覧' (list of dimensions and metrics), but doesn't explicitly differentiate from sibling tools like 'get_property_details' or 'list_accounts' that might also retrieve metadata. The second sentence adds context about usage with 'run_report' but doesn't fully distinguish it from other metadata-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance: 'run_reportで使える項目を確認できます' (You can check items usable in run_report). This suggests the tool is for preparing to use 'run_report', but it doesn't explicitly state when to use this tool versus alternatives like 'get_property_details' or when not to use it. No explicit alternatives or exclusions are mentioned, leaving some ambiguity about its specific context among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 describes the action ('取得します' - get) and output metrics, but doesn't mention critical behaviors like whether this is a read-only operation, requires authentication, has rate limits, or returns aggregated vs. raw data. For a data retrieval tool with zero annotation coverage, this is a significant gap in transparency.
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 concise with two sentences: one stating the purpose and one providing usage context. It's front-loaded with the core functionality. However, the second sentence ('ダッシュボード的な使い方に最適です') could be more specific, and there's some redundancy in mentioning '指定期間' (specified period) when the schema already covers it.
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 no annotations and no output schema, the description is moderately complete. It covers the purpose and hints at usage, but lacks details on behavioral traits (e.g., read-only status, error handling) and output format. For a 2-parameter tool with 100% schema coverage, it's adequate but has clear gaps in transparency and output expectations.
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 both parameters ('propertyId' and 'period') well-documented in the schema. The description doesn't add any parameter-specific details beyond implying a '指定期間' (specified period) context. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description provides no extra semantic value for parameters.
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's purpose: '指定期間のトラフィック概要（PV数、ユーザー数、セッション数、直帰率など）を取得します' (Get traffic summary for a specified period including page views, users, sessions, bounce rate, etc.). It specifies the verb '取得します' (get) and resource 'トラフィック概要' (traffic summary) with concrete metrics. However, it doesn't explicitly differentiate from siblings like 'get_daily_trend' or 'get_hourly_traffic' beyond mentioning 'ダッシュボード的な使い方に最適です' (ideal for dashboard use).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage context: 'ダッシュボード的な使い方に最適です' (ideal for dashboard use), suggesting it's for high-level overviews. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_daily_trend' for time-series data or 'run_report' for custom reports. No exclusions or clear alternatives are mentioned, leaving the agent to infer from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions analysis of pages before/after a target page but lacks details on output format (e.g., list of pages with counts), pagination (though limit parameter exists), rate limits, authentication needs, or data freshness. For a tool with 5 parameters and no annotations, this is a significant gap in 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core purpose, and the second adds context. Both sentences earn their place by clarifying utility. However, it could be slightly more structured (e.g., explicitly mentioning parameters or output), but it avoids redundancy and waste.
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 5 parameters, 100% schema coverage, no annotations, and no output schema, the description is minimally adequate. It covers the purpose and usage context but lacks details on behavioral traits (e.g., what the analysis returns, error handling) and doesn't compensate for the missing output schema. For a tool with moderate complexity, this leaves gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly (e.g., propertyId as GA4 property ID, period with enum values, pagePath with example). The description adds no additional parameter semantics beyond what the schema provides, such as explaining interactions between parameters (e.g., how direction affects results). Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose: '特定ページの前後に閲覧されるページを分析します' (analyzes pages viewed before/after a specific page). It specifies the verb (analyzes) and resource (pages viewed around a target page), distinguishing it from siblings like get_top_pages or get_landing_pages. However, it doesn't explicitly differentiate from all siblings (e.g., get_exit_pages might overlap in analyzing page navigation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context: 'ユーザーの回遊パターンの把握に便利です' (useful for understanding user navigation patterns). This suggests when to use it—for analyzing user flow patterns. However, it doesn't explicitly state when not to use it or name alternatives (e.g., compare_periods for temporal comparisons or get_conversion_funnel for conversion analysis), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 describes a read operation ('取得します' - get/retrieve), which implies it's non-destructive, but doesn't mention any behavioral traits like permissions needed, rate limits, pagination, or what the output looks like. For a tool with zero annotation coverage, this is a significant gap, though it at least implies a safe 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 appropriately sized and front-loaded: it states the core purpose in the first sentence and adds usage context in the second. Every sentence earns its place by providing essential information without waste, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It explains the purpose and usage context adequately, but without annotations or output schema, it lacks details on behavioral aspects like response format or limitations. This makes it minimally viable but not fully comprehensive.
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 0 parameters, and the schema description coverage is 100% (since there are no parameters to describe). In such cases, the baseline is 4, as there's no need for the description to compensate for parameter documentation. The description doesn't add parameter info, which is fine here.
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's purpose: 'GA4のアカウントとプロパティの一覧を取得します' (Get a list of GA4 accounts and properties). It specifies the verb ('取得します' - get/retrieve) and the resources (accounts and properties). However, it doesn't explicitly differentiate from siblings like 'get_property_details' or 'get_metadata', which might also retrieve property-related information, so it doesn't reach a perfect 5.
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 for when to use this tool: 'どのプロパティIDを使うべきか確認する際に便利です' (Useful when checking which property ID to use). This gives a practical scenario, but it doesn't explicitly state when not to use it or name alternatives among the sibling tools, 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ga4-mcp-server MCP server](https://glama.ai/mcp/servers/Shin-sibainu/ga4-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/Shin-sibainu/ga4-mcp-server)

Score Badge

Copy to your README.md:

[![ga4-mcp-server MCP server](https://glama.ai/mcp/servers/Shin-sibainu/ga4-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/Shin-sibainu/ga4-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Shin-sibainu/ga4-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server