ga4-mcp-server

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action—accounts, properties, streams, reports, custom dimensions/metrics, key events, audiences, secrets, and event sending. No two tools overlap in purpose; even similar operations (archive vs. delete) are clearly differentiated by resource type.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (list_*, create_*, get_*, run_*, archive_*, delete_*, send_*). The use of 'archive' for some resources and 'delete' for others reflects GA4 API conventions rather than inconsistency.
Tool Count4/5
At 19 tools, the set is on the heavier side but still well-scoped for GA4 management, covering configuration, reporting, audience creation, and Measurement Protocol. Each tool serves a distinct purpose, though some trimming could be possible.
Completeness3/5
The surface covers core workflows but has notable gaps: no update/archive for custom metrics, no update for audiences, no delete for key events, and no tools for user properties or property management. These omissions could force workarounds but don't break the primary use cases.
Average 3.5/5 across 19 of 19 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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, the description carries the burden of disclosure, but it only mentions measurement_unit values. It fails to disclose any side effects, permissions, or behavior 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 brief and to the point, with no extraneous words. The enumeration of measurement_unit values is useful and concise.
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 creation tool with six parameters and no output schema, the description is inadequate. It doesn't explain required fields, constraints, or expected outcomes, leaving significant gaps.
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 0%, and the description only clarifies measurement_unit's allowed values. Other parameters like property_id, parameter_name, and display_name remain unexplained, leaving the agent to infer their meaning.
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 'Create a custom metric' with a specific verb and resource. However, it doesn't explicitly differentiate from the sibling create_custom_dimension tool, despite the distinct resource type.
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 create_custom_dimension, nor any prerequisites or context. The description only states the action without usage scenarios.
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, the description must disclose side effects, but it only states the action without mentioning implications like whether this creates a new marking, modifies existing settings, or requires specific permissions. The mutation is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the primary action front-loaded. It is appropriately concise, though the second sentence could arguably be integrated into the schema, but it remains useful in the description.
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 3 parameters, no output schema, and no annotations, so the description should provide more context. It does not explain what makes an event a 'key event', how counting methods differ, or what the response looks like. Minimal guidance for a create operation.
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 0%, so the description must compensate. It adds value for counting_method by listing its possible values, but event_name and property_id are left unexplained. Their names are somewhat self-explanatory, but the description does not fully cover the 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 action ('Mark an event as a key event') and the resource (an event), with a parenthetical explaining 'conversion'. It is specific enough to understand the tool's core function, though it does not explicitly differentiate from siblings like list_key_events or create_event_audience.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description only mentions the counting_method constraint, which is more about parameter usage than 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, the description carries full burden for behavioral disclosure. It only states the listing action without revealing read-only status, authentication needs, pagination, or other relevant behaviors. It adds no context beyond the tool's name.
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, focused sentence with no unnecessary words, earning top marks for conciseness and front-loading.
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?
Although an output schema exists, the description lacks usage guidelines and behavioral transparency. It is a minimal statement that does not fully cover the tool's behavior, especially given the absence of annotations.
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 0%, so the description must compensate for parameter meaning. However, it does not mention property_id at all, leaving the parameter semantics entirely to the schema. The parameter name alone is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('custom metrics defined on a GA4 property'), making the purpose unambiguous. It also distinguishes from sibling tools like list_custom_dimensions by specifying the resource type.
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 guidelines are provided. The description does not mention when to use this tool versus alternatives, 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 does explain that metrics/dimensions use GA4 API names and that dates accept relative forms, which adds some context. However, it does not discuss output format, pagination, error handling, rate limits, or other behavioral traits, making it insufficient for transparent operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core action and then giving concise parameter examples. Every sentence provides value without repetition or fluff, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations, making the description the primary source of context. It covers the most critical parameter semantics (metrics/dimensions, dates) but leaves gaps around property_id, limit, and expected response structure. It is adequate for basic use but not complete for robust 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 0%, so the description must compensate. It adds meaning for metrics (e.g., 'activeUsers', 'conversions') and dimensions (e.g., 'date', 'sessionDefaultChannelGroup'), plus date range formats for start_date/end_date. It does not explain property_id (expected format) or limit (behavior), so coverage is partial across the 6 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 action ('Run a GA4 report') and the resource (GA4), providing a specific verb+resource combination. It does not explicitly distinguish this from the sibling 'run_realtime_report', but the naming and context imply standard reporting, so it is clear but not fully differentiated.
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 explicit guidance on when to use this tool versus alternatives like run_realtime_report. It gives parameter formatting details but does not state the primary use case, exclusions, or prerequisites, leaving the agent without clear selection criteria.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does not mention read-only behavior, pagination, inclusion of archived dimensions, required permissions, or any other behavioral trait. This is minimal for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and contains no unnecessary words. It is appropriately sized for the simple operation it describes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema likely covers return values, so that absence is not a major issue. However, the description lacks important context such as pagination behavior, whether archived dimensions are included, and any permission requirements. For a simple list tool, this is a moderate gap but not severely incomplete.
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 input schema has 0% description coverage, and the description adds little beyond the property_id name. It only indirectly implies the parameter via 'GA4 property,' but does not explain the ID format, where to obtain it, or any other usage detail, leaving the agent with insufficient parameter guidance.
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 action verb ('List') and a specific resource ('custom dimensions') scoped to a GA4 property. This clearly distinguishes it from sibling tools like list_custom_metrics, create_custom_dimension, and archive_custom_dimension.
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 explicit guidance on when to use this tool versus alternatives. There is no mention of list_custom_metrics, create_custom_dimension, or any conditional context, leaving usage to be inferred only from the tool name.
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 does not state that the operation is read-only, whether it requires special permissions, if results are paginated, or what happens if the property_id is invalid. The description only states the basic action, leaving the agent to infer behavior.
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 concise sentence, directly front-loaded with the verb and object. Every word serves a purpose, and there is no redundant or filler content.
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?
This is a simple list operation with a single parameter and output schema available, but the description lacks usage context, behavioral details, and any caveats. It is minimally complete for understanding the tool's purpose, but not adequately complete given the lack of annotations and the presence of a create sibling (create_key_event) that could invite confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes property_id as a required string with no description (0% coverage). The description only mentions 'GA4 property' which is already in the tool description, but does not explain the format of the ID (e.g., numeric vs. 'properties/123'), validation, or its role beyond the obvious. The description adds little meaning beyond the parameter name.
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 the specific verb 'List' with the resource 'key events (conversions)' scoped to a GA4 property. This clearly distinguishes it from sibling tools like create_key_event (create) and other list tools (list_audiences, list_custom_dimensions) by naming the exact resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention that this is the read-only counterpart to create_key_event, nor does it differentiate from run_report for fetching data. The description only states what the tool does, not when to choose it.
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. It only discloses that audience_id accepts two formats, but fails to explain what archiving does (e.g., reversibility, visibility changes, impact on reports) or any permission requirements. This is a significant gap for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and resource. The second sentence adds a valuable clarification without unnecessary detail. No wasted words.
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 mutation tool with no annotations and no output schema, the description leaves important gaps: it does not disclose side effects or reversibility, and property_id is not explained. While the tool is simple and the audience_id nuance is covered, the missing behavioral context and parameter documentation make it incomplete.
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 provides two required string parameters with no descriptions (0% coverage). The description adds meaningful semantics for audience_id by specifying numeric or full resource name formats, but property_id remains completely undefined, leaving a coverage gap for one of the two parameters.
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 ('Archive') and resource ('a GA4 audience'), clearly distinguishing it from sibling tools like 'archive_custom_dimension'. The additional sentence about accepted audience_id formats reinforces the resource scope.
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 intended use is implied by the verb 'archive' and the resource type, but there is no explicit guidance on when to choose this tool over alternatives, nor any exclusionary context (e.g., do not use if deletion is intended). The description lacks mention of effects or prerequisites.
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, the description should disclose side effects, prerequisites, and result behavior. It only explains parameter semantics and validation rules, not what happens on creation (e.g., idempotency, error cases, permissions). This leaves a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the core action. It uses a single sentence plus a few clarifying notes, with no wasted words.
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 no annotations and no output schema, and the description does not explain all required parameters (property_id) or mention what a successful creation returns. Given the complexity of five parameters and a create operation, the description is insufficient for confident use without external knowledge.
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 description explains the meaning of parameter_name, scope, and display_name constraints, which adds value beyond the schema (0% coverage). However, it leaves property_id and the description parameter unexplained, so not all parameters are semantically covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create a custom dimension' with a specific resource, distinguishing it from sibling tools like create_custom_metric. It also provides immediate clarity on key parameters.
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 when to use this tool (when a new custom dimension is needed) but does not explicitly mention alternatives or exclusions, such as contrasting with create_custom_metric or noting that list/archive operations are separate.
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 that secret_id may be a numeric id or full resource name, which is a useful input flexibility detail, but it does not disclose that deletion is permanent, whether special permissions are required, or what happens if the secret does not exist. For a destructive operation, this leaves significant gaps in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant or irrelevant information. It is concise, front-loaded with the core action, and adds the key parameter nuance about secret_id without wasting words. Structure is optimal for a simple tool description.
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 delete tool with three required parameters and no output schema, the description provides the essential action and a useful note about secret_id. However, it omits important context such as the resource hierarchy (property -> stream -> secret), the permanence of deletion, and any potential error scenarios. It is adequate but has clear gaps for an agent to use it safely without additional inference.
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 0%, so the description must compensate for all parameters. It provides meaningful detail only for secret_id (numeric id or full resource name). It leaves property_id and stream_id without any explanation, and does not clarify the hierarchy relationship among the parameters. Since only one of three parameters is partially described, the compensation is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Delete' and the resource 'Measurement Protocol API secret', which exactly matches the tool's function. It also distinguishes from sibling tools like create_measurement_protocol_secret and list_measurement_protocol_secrets by the unique action. The additional note about secret_id accepting a numeric id or full resource name adds clarity without ambiguity.
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 verb 'Delete' implies the use case: to remove an existing Measurement Protocol API secret. However, there is no explicit statement about when to use this tool versus alternatives, no prerequisites, and no guidance on when not to use it. The context is clear from the name, but the description does not provide direct usage guidance beyond the action itself.
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 must disclose behavioral traits. It only says 'List' and gives no details about pagination, limits, ordering, required permissions, or any side effects. This is minimal for a read operation and leaves important behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. There is no filler, and the key information is front-loaded, making it easy to scan.
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 simplicity of the tool (one parameter) and the existence of an output schema, the description is adequate but not complete. It lacks behavioral context like pagination or error handling, and the parameter is not explained. It covers the basic purpose but leaves gaps that could be filled with more detail.
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 0%, so the description must compensate for explaining parameters. The only parameter, property_id, is not described beyond its name. The description offers no additional meaning, such as format, required scope, or how it relates to the GA4 property.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing audiences on a GA4 property. It uses a specific verb ('List') and resource ('audiences'), and the scope ('on a GA4 property') distinguishes it from sibling tools like list_account_summaries or list_data_streams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to see audiences for a given property, but it does not explicitly state when to use it vs alternatives. Since sibling tools target different resources, the usage context is somewhat clear but no exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the burden of behavioral disclosure. 'Get configuration details' indicates a read-only retrieval rather than a mutation, but it does not explicitly state that nothing is modified or describe error behavior, authorization needs, or property_id format. It is adequate but has clear 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, front-loaded sentence that conveys the action, target, and returned fields with no unnecessary words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter, the description is mostly complete: it states the purpose and the returned fields. Given no output schema or annotations, it could add details about property_id format or failure behavior, but the core context is adequately covered.
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 0% and the only required parameter is property_id, yet the description does not mention this parameter or explain its expected format. The description fails to compensate for the low schema coverage, adding no meaning beyond the property name and title.
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+resource pair, 'Get configuration details for one GA4 property,' and names the exact fields returned (name, time zone, currency, industry, create time). This clearly distinguishes it from sibling tools that list accounts/data streams or create/archive entities.
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 list_account_summaries or list_data_streams. It implies use when you need details for a single known property, but it does not mention prerequisites, alternatives, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavioral traits. It does add the key time window ('last ~30 minutes'), but it does not mention expected permissions, response format, or error handling. As a read-only report operation, the safety profile is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with a helpful example. Every word earns its place; there is no redundancy or filler.
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 annotations, and no output schema, the description is notably incomplete. It omits details about response structure, valid metric/dimension formats, and any limitations. The example gives a hint, but an agent would need more guidance to invoke this tool reliably.
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 0%, so the description must compensate. It provides a concrete example with metrics and dimensions, giving some context for their usage, but it leaves limit and property_id unexplained. The example helps but is not enough to fully clarify parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run a GA4 realtime report (last ~30 minutes).' The verb is specific, the resource is a GA4 realtime report, and the time window distinguishes it from sibling tools like run_report. An example further clarifies the expected usage.
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 when to use this tool via the phrase 'last ~30 minutes', but it does not explicitly state how it differs from alternatives like run_report, nor does it provide any when-not-to-use guidance. The context is there, but exclusions are absent.
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, the description must disclose side effects, limits, and permissions, but it only mentions the membership_duration_days max of 540. It doesn't state whether creating a duplicate display name errors, what happens to existing audiences, or any required permissions. This leaves significant behavioral ambiguity for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose and then providing a key parameter detail. There is no redundancy or filler; 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?
The description covers purpose and one parameter limit, but with no output schema and no annotations, it doesn't explain what the tool returns (e.g., audience ID) or preconditions like needing a linked Google Ads account. It is adequate for a simple create tool but leaves room for more contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for membership_duration_days (max 540) and event_name (examples), but property_id, display_name, and description are not explained. With 0% schema coverage, the description only partially compensates, leaving some parameter semantics implicit or relying on the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: creating a GA4 audience of users who triggered a specific event, with examples ('purchase', 'generate_lead'). It distinguishes this from sibling tools like list_audiences or archive_audience by specifying the create action and event-based audience type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case—remarketing lists for Google Ads—and gives concrete event examples. It does not explicitly state when not to use it or name alternative tools, but the purpose is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 adds a security warning ('Treat it as sensitive') and states the return value, which is useful. However, it does not disclose side effects such as whether creating a new secret invalidates existing ones, or whether permissions are required. This is moderate transparency for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary purpose, followed by return value and a security note. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the core purpose and return value, which is important because there is no output schema. However, it omits input parameter semantics, and there are no annotations to provide safety or usage context. For a tool with three required parameters and zero schema description coverage, the description is not fully complete, though it is better than a one-line stub.
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 0%, and the description does not explain any of the three parameters (property_id, stream_id, display_name). It only vaguely references 'a data stream' which maps to stream_id. The description adds minimal value over the raw schema, failing to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the resource ('Measurement Protocol API secret'), and the scope ('on a data stream'). It also distinguishes itself from sibling tools like list_measurement_protocol_secrets and delete_measurement_protocol_secret by explicitly focusing on creation and the returned secret_value.
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 usage context by stating that the returned secret_value is 'needed by send_ga4_event', implying this tool is a prerequisite for sending events. It does not explicitly mention alternatives or when-not-to-use, but the sibling tool names list_measurement_protocol_secrets and delete_measurement_protocol_secret make the management workflow obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context by clarifying that custom_dimension_id can be either a numeric ID or a full resource name. It also explicitly signals deletion via '(delete)'. However, no annotations exist, and the description lacks details on permanence, required permissions, or side effects beyond deletion, leaving a transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the purpose and then provides a precise parameter detail. Every word earns its place with no 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 two-parameter mutation, the description covers the essential action and a nuanced parameter format. However, it does not mention what happens on success (e.g., return value or irreversible deletion), and given no output schema, this absence leaves the agent uncertain about expected results.
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?
With 0% schema coverage, the description compensates by explaining the acceptable formats for custom_dimension_id. This is critical for correct invocation. The other parameter, property_id, is self-explanatory from its name and context, so partial compensation is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Archive (delete) a custom dimension.' This is a specific verb-resource pair that distinguishes it from sibling tools like archive_audience or create_custom_dimension. The parenthetical '(delete)' reinforces the destructive nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for deleting custom dimensions, but it provides no explicit when-to-use guidance or mention of alternatives. Without a stated exclusion or comparison, an agent must infer usage from the name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It states the core operation (listing secrets) but does not mention implicit behaviors like read-only nature, pagination, or sensitivity of secrets. The straightforward name and scope provide some clarity, but the description adds limited context beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that immediately state the purpose and provide essential parameter guidance. There is no fluff or redundancy, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with 2 required parameters and an output schema, but the description omits property_id and provides no explicit guidance on when to use this vs. create/delete variants. The cross-reference to list_data_streams is useful, but the overall description leaves some gaps in 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?
The schema has 0% parameter description coverage, so the description must compensate. It explains stream_id as 'the numeric id from list_data_streams,' which is helpful. However, property_id is left unexplained, though its title 'Property Id' gives some hint. The description partially compensates but misses one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Measurement Protocol API secrets for a data stream, using a specific verb and resource. It distinguishes itself from sibling tools such as create_measurement_protocol_secret and delete_measurement_protocol_secret, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to list secrets for a data stream) and even cross-references list_data_streams for obtaining stream_id. However, it does not explicitly mention exclusions or when to prefer alternatives, though the listing nature is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of conveying behavior. It implies a read-only listing operation and adds a non-obvious detail about the stream id format (last path segment of 'name'), which helps the agent understand the output. It doesn't mention pagination or permissions, but for a simple list tool with an output schema, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The first sentence states the action and resource, the second explains a downstream use case. Every word earns its place, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, output schema present). The description covers the main purpose and the crucial detail about stream id usage. It doesn't explain property_id format or output specifics, but those are partially covered by the parameter name and output schema, so the completeness is high for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not explain the 'property_id' parameter at all. The parameter name is self-explanatory to some degree, but the description adds no formatting, type, or source guidance. Given the low coverage, the description should compensate, and it doesn't.
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') and resource ('data streams (web/app) on a GA4 property'), clearly distinguishing it from sibling tools like list_account_summaries or get_property_details. It also adds a precise note about the stream id being needed for Measurement Protocol secret tools, which further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use this tool—when you need stream IDs for Measurement Protocol secret tools. It doesn't explicitly state when not to use it or name alternatives, but the context is strong enough to guide selection among the listed siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It adds useful behavioral details such as the debug/validation endpoint behavior when validate=True ('checks the payload WITHOUT ingesting it') and clarifies the meaning of measurement_id and client_id. It stops short of discussing authentication requirements or potential failure modes, but the disclosed behaviors are meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core action, and uses compact, precise language. Every sentence adds value, from the main purpose to the parameter clarifications to the validation tip, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description covers the essential operational context: what the tool does, how to identify the stream, how to authenticate, and how to use validation mode. It does not describe the response format or error handling, but for a simple send operation this is a minor gap.
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 0%, so the description must compensate. It explains measurement_id, api_secret, client_id, and validate, but leaves event_name and params largely undocumented. While event_name is self-explanatory, the params object (for additional event parameters) would benefit from explanation, making the compensation partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Send an event into a GA4 property via the Measurement Protocol.' This specifies the verb ('send'), the resource ('event into a GA4 property'), and the method ('Measurement Protocol'), which distinguishes it from sibling tools like run_report or list_data_streams.
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 usage context by explaining the role of each key parameter and recommending validate=True before real sends. However, it does not explicitly mention when not to use this tool or offer alternatives, though the context makes it apparent this is for event ingestion rather than reporting or admin tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the scope ('the service account can see') and the output structure (account name/id, property display name and numeric id), which is more than the tool name alone. However, it does not mention potential limitations like pagination or rate limits for listing all data, which keeps it from a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences each serve a distinct purpose: action, return value, and usage timing. No words are wasted, and the most important information is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema is present, the description fully covers what the tool does, what it returns, and when to call it. It is a complete and self-contained description for this simple discovery tool, leaving no significant gaps in understanding.
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 by the scoring rule the baseline is 4. The description clarifies that it takes no input and simply lists everything visible to the service account, which fully compensates for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List every GA4 account and its properties the service account can see') and distinguishes it from siblings by positioning it as the first-step discovery tool. It also specifies the return content (account name/id, property display name and numeric id), leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'Call this first to discover property ids for the other tools,' providing clear when-to-use guidance and positioning it as the prerequisite for all other GA4 tools. This makes the tool's role in the workflow unmistakable.
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/burhan29ee/ga4-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/burhan29ee/ga4-mcp-server)

Score Badge

Copy to your README.md:

[![ga4-mcp-server MCP server](https://glama.ai/mcp/servers/burhan29ee/ga4-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/burhan29ee/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/burhan29ee/ga4-mcp-server'

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