How do I use mcp-activeview?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-activeview what were the impressions for example.com yesterday?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-activeview

Official

by Zest-Global

Overview Schema Related Servers Score Discussions

Python

Local

MCP ActiveView (read-only)

Servidor MCP que expone la ActiveView External API (https://external-api.activeview.app) a Claude. Es un wrapper de solo lectura: el helper de red solo hace GET, así que ninguna tool puede crear, modificar ni borrar datos.

Hecho con FastMCP (Python), transporte stdio (local).

Qué expone (12 tools, todas de lectura)

Price rules

get_price_rules — reglas de precio de un sitio.

Reportes por dominio

get_report_by_domain — métricas (revenue, impressions, eCPM, match rate…).
get_kvp_report_by_domain — métricas agrupadas por una key de GAM.
get_session_kvp_report_by_domain — KVP de sesiones (Snowflake).
get_custom_gam_report_by_domain — reporte GAM con dimensiones/métricas a elección.

Reportes por network (varios dominios con el filtro domains)

get_report_by_network
get_kvp_report_by_network
get_custom_gam_report_by_network

Redirects (A/B testing)

list_redirect_domains — dominios de redirect con sus paths.
get_redirect_path — detalle de un path.
get_redirect_path_mappings — split de tráfico (url + %).
get_redirect_path_mapping_logs — historial de cambios del split.

💰 Micros: los campos de revenue de GAM (*_revenue) vienen en micros (1.000.000 = 1 unidad de moneda). Divídelos entre 1.000.000. Las tools ya se lo recuerdan a Claude en su descripción.

Related MCP server: TikTok Ads MCP

Requisitos

Python ≥ 3.10 (recomendado 3.12). El Python 3.9 que trae macOS por defecto no sirve.
git para clonar.
Una API key de ActiveView, en formato token:secret (el bearer completo, con los dos puntos).
Opcional pero recomendado: uv (instala con brew install uv). Si no quieres uv, abajo tienes la variante con python -m venv + pip.

Instalación paso a paso (Claude Code)

1. Clonar el repo

git clone https://github.com/TU-USUARIO/mcp-activeview.git
cd mcp-activeview

2. Crear el entorno virtual e instalar dependencias

Con uv (recomendado):

uv venv --python 3.12 .venv
uv pip install --python .venv -r requirements.txt

O con venv + pip estándar (sin uv):

python3.12 -m venv .venv        # o python3 si tu 3 ya es ≥3.10
./.venv/bin/pip install -r requirements.txt

3. Conseguir tu API key

La sacas de tu panel de ActiveView. Es un único valor con la forma token:secret: dos partes separadas por dos puntos (:). Lo copias entero, incluidos los dos puntos. Por ejemplo:

# Ejemplo (valores inventados). Pega tu clave real entera:
ACTIVEVIEW_API_KEY=ab12cd34ef56...:9f8e7d6c...

En esta guía verás el placeholder tu_token:tu_secret; sustitúyelo por tu clave real.

Cada persona usa su propia key. La key nunca va dentro del repo.

4. Registrar el servidor en Claude Code

Desde la carpeta del repo (para que $(pwd) resuelva las rutas absolutas solo):

claude mcp add activeview \
  --scope user \
  --env ACTIVEVIEW_API_KEY=tu_token:tu_secret \
  --env ACTIVEVIEW_NETWORK_CODE=YOUR_NETWORK_CODE \
  -- "$(pwd)/.venv/bin/python" "$(pwd)/server.py"

--scope user lo deja disponible en todos tus proyectos. Usa --scope local (por defecto) si solo lo quieres en el proyecto actual.
ACTIVEVIEW_NETWORK_CODE es opcional: si lo pones, podrás pedir reportes sin repetir el network code en cada consulta (ver sección abajo). Quítalo si no quieres un valor por defecto.

5. Verificar

claude mcp list

Debe mostrar activeview: … ✔ Connected. Luego, dentro de Claude Code, pídele algo como:

"Dame las impresiones de ayer en tu-dominio.com"

Si responde con datos, está funcionando.

Network code por defecto (opcional)

Puedes fijar un network_code por defecto con ACTIVEVIEW_NETWORK_CODE. Si lo haces, las tools se pueden llamar sin pasar network_code cada vez; un valor explícito en la llamada siempre tiene prioridad sobre el por defecto.

Funciona tanto por --env (paso 4) como en un fichero .env local:

cp .env.example .env
# edita .env:
#   ACTIVEVIEW_API_KEY=tu_token:tu_secret
#   ACTIVEVIEW_NETWORK_CODE=YOUR_NETWORK_CODE    # opcional, el de tu propiedad principal

⚠️ Un único network code por defecto solo cubre los dominios de esa red. Para dominios de otra red, pasa su network_code en la consulta.

¿--env o .env? Lo más limpio es --env en claude mcp add (la key vive en la config de Claude, no en el proyecto). El .env es cómodo para pruebas locales y está ignorado por git (no se sube nunca). Si una variable ya viene del cliente MCP, esa gana sobre la del .env.

Alternativa: Claude Desktop

En claude_desktop_config.json:

{
  "mcpServers": {
    "activeview": {
      "command": "/ruta/absoluta/a/mcp-activeview/.venv/bin/python",
      "args": ["/ruta/absoluta/a/mcp-activeview/server.py"],
      "env": {
        "ACTIVEVIEW_API_KEY": "tu_token:tu_secret",
        "ACTIVEVIEW_NETWORK_CODE": "YOUR_NETWORK_CODE"
      }
    }
  }
}

Usar el python del .venv directamente es lo más robusto. Reinicia el cliente tras añadirlo.

Probarlo en local (sin Claude)

# Inspector visual de FastMCP (UI web para invocar las tools a mano):
ACTIVEVIEW_API_KEY=tu_token:tu_secret ./.venv/bin/fastmcp dev server.py

# O lanzarlo en stdio tal cual lo lanzará Claude:
ACTIVEVIEW_API_KEY=tu_token:tu_secret ./.venv/bin/python server.py

Seguridad

Este servidor está pensado para ser seguro por diseño:

Solo lectura, garantizado por construcción. El único helper de red (_get) usa exclusivamente httpx.get. No existe ningún post/put/patch/delete en el código, así que ninguna tool puede crear, modificar ni borrar datos. Todas las tools se anuncian con readOnlyHint: True.
Host fijo. Todas las peticiones van a https://external-api.activeview.app; el servidor no acepta URLs ni hosts arbitrarios.
Validación de entradas. network_code debe ser numérico y domain solo admite [A-Za-z0-9.-]. Esto bloquea intentos de inyección de path (../, ?, #, @, /) en la URL de la petición.
La API key nunca se versiona. .env está en .gitignore; el repo solo trae .env.example con placeholders. La key se pasa por variable de entorno y no se registra en logs.
Sin ejecución de código ni acceso a disco. El servidor solo hace peticiones HTTP GET de lectura; no escribe ficheros, no ejecuta shell, no toca tu sistema.

Buenas prácticas al instalarlo:

Trata tu ACTIVEVIEW_API_KEY como una contraseña. Si la pasaste por línea de comandos, recuerda que puede quedar en el historial del shell; preferible .env o un gestor de secretos.
Si crees que tu key se ha filtrado, rótala en ActiveView; la del repo nunca debería aparecer en un commit.
Revisa requirements.txt antes de instalar (dependencias: fastmcp, httpx, python-dotenv).

Troubleshooting

Síntoma	Causa probable / solución
`claude mcp list` muestra `✘ Failed to connect`	Ruta del `python`/`server.py` mal, o venv sin dependencias. Reejecuta el paso 2 y usa rutas absolutas.
Aviso "fastmcp not installed" en VSCode	Selecciona el intérprete `.venv/bin/python` (Command Palette → "Python: Select Interpreter").
Las tools devuelven `401`	API key inválida o revocada. Comprueba `ACTIVEVIEW_API_KEY` (formato `token:secret`).
`Invalid network_code` / `Invalid domain`	El valor llevaba caracteres no permitidos. `network_code` es numérico; `domain` solo letras/dígitos/puntos/guiones.
`No network_code given…`	No pasaste `network_code` y no hay `ACTIVEVIEW_NETWORK_CODE` configurado.
`python3.12: command not found`	Instala Python 3.12 (`brew install python@3.12`) o usa otro ≥3.10.

Nota sobre los reportes "Custom GAM"

La colección Postman traía las dos variantes con el orden de segmentos distinto (gam/custom vs custom/gam). Confirmado contra la API real, el orden correcto en ambas es gam/custom:

por dominio → /report/gam/custom/{network}/{domain}
por network → /report/gam/custom/{network}

Available Tools

12 tools

get_custom_gam_report_by_domainA

Read-only

Custom GAM report for a domain with caller-chosen dimensions and metrics.

Availability of dimension/metric combinations matches GAM itself; combos that GAM cannot report will also fail here. Revenue fields are in micros.

ParametersJSON Schema

Name	Required	Description
`key`	No	Filter results by this key
`domain`	Yes	Site domain, e.g. 'example.com'
`metrics`	No	Comma-separated GAM metrics, e.g. 'AD_EXCHANGE_LINE_ITEM_LEVEL_REVENUE,AD_EXCHANGE_LINE_ITEM_LEVEL_IMPRESSIONS'. Same names as the GAM API: https://developers.google.com/ad-manager/api/reference/v202308/ReportService.Column
`end_date`	No	Report end date, 'YYYY-MM-DD' (optional)
`order_id`	No	Filter results by order id
`site_name`	No	Filter results by site name
`dimensions`	No	Comma-separated GAM dimensions, e.g. 'DATE,SITE_NAME'. Same names as the GAM API: https://developers.google.com/ad-manager/api/reference/v202308/ReportService.Dimension
`start_date`	Yes	Report start date, 'YYYY-MM-DD'
`network_code`	No	GAM network code for the domain. Optional — if omitted, the server falls back to the ACTIVEVIEW_NETWORK_CODE environment variable.

TDQS

A4/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true, so the tool is read-only. The description adds valuable behavioral context: that dimension/metric combos must match GAM capabilities (or fail) and that revenue fields are in micros.

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

Conciseness5/5

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

Two concise sentences with no wasted words. First sentence states purpose, second adds critical constraints. Perfectly front-loaded.

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?

Despite no output schema, the description does not explain return format, result limits, or how filter parameters (key, order_id, site_name) interact. Lacks details necessary for full tool usage 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?

Schema coverage is 100% with parameter descriptions. The description adds holistic context about dimensions and metrics being caller-chosen and constraints from GAM, plus revenue micros, which supplements the schema.

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

Purpose5/5

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

The description clearly states the tool generates a custom GAM report for a specific domain with caller-chosen dimensions and metrics. It also distinguishes from sibling 'get_custom_gam_report_by_network' by focusing on domain 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 description implies usage for domain-specific custom reports but does not explicitly provide when-to-use or when-not-to-use guidance, nor mentions alternatives like 'get_report_by_domain'.

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

get_custom_gam_report_by_networkA

Read-only

Custom GAM report across a network with caller-chosen dimensions and metrics.

Same constraints as get_custom_gam_report_by_domain. Revenue fields in micros.

ParametersJSON Schema

Name	Required	Description
`key`	No	Filter results by this key
`domains`	No	Comma-separated domains, e.g. 'a.com,b.com' (optional)
`metrics`	No	Comma-separated GAM metrics, e.g. 'AD_EXCHANGE_LINE_ITEM_LEVEL_REVENUE,AD_EXCHANGE_LINE_ITEM_LEVEL_IMPRESSIONS'. Same names as the GAM API: https://developers.google.com/ad-manager/api/reference/v202308/ReportService.Column
`end_date`	No	Report end date, 'YYYY-MM-DD' (optional)
`order_id`	No	Filter results by order id
`site_name`	No	Filter results by site name
`dimensions`	No	Comma-separated GAM dimensions, e.g. 'DATE,SITE_NAME'. Same names as the GAM API: https://developers.google.com/ad-manager/api/reference/v202308/ReportService.Dimension
`start_date`	Yes	Report start date, 'YYYY-MM-DD'
`network_code`	No	GAM network code for the domain. Optional — if omitted, the server falls back to the ACTIVEVIEW_NETWORK_CODE environment variable.

TDQS

A4.2/5.0

Behavior4/5

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

The annotation readOnlyHint is present. The description adds that the report is customizable (caller-chosen dimensions/metrics) and that revenue fields are in micros, referencing sibling constraints. This provides useful behavioral context beyond the annotation.

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: the first states the main purpose, the second adds a critical constraint (same as domain tool) and a key detail (revenue in micros). No superfluous text, well 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?

Given 9 parameters, no output schema, and a readOnlyHint annotation, the description adequately covers the tool's purpose and key constraints. It could be improved by mentioning the output format or common dimension/metric examples, but it is sufficiently complete for an agent to understand the 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?

All 9 parameters have descriptions in the schema (100% coverage). The description only hints at the purpose of dimensions and metrics parameters ('caller-chosen') and does not add new semantic meaning beyond what is already in the schema.

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

Purpose5/5

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

The description clearly states the tool generates a custom GAM report at the network level, with user-selectable dimensions and metrics. It differentiates itself from the sibling tool get_custom_gam_report_by_domain by explicitly referencing it and noting identical constraints.

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

Usage Guidelines4/5

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

It references the sibling tool get_custom_gam_report_by_domain and notes shared constraints, implying when to use this network-level variant. It also mentions that revenue fields are in micros. However, it does not explicitly state when not to use this tool or list alternatives for other scenarios.

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

get_kvp_report_by_domainB

Read-only

Key-value-pair (KVP) metrics for a domain, grouped by a GAM key.

Returns rows keyed by key/value with GAM ad-exchange metrics. Note: ad_exchange_line_item_level_revenue is in micros (divide by 1,000,000).

ParametersJSON Schema

Name	Required	Description	Default
`key`	No	Key to group by, e.g. 'utm_campaign' or 'utm_source'	utm_campaign
`domain`	Yes	Site domain, e.g. 'example.com'
`end_date`	No	Report end date, 'YYYY-MM-DD' (optional)
`timezone`	No	Timezone for the data. One of: '' (default), 'gam' (Google Ad Manager), 'pacific', 'gmt_3', 'cet', 'eastern'.
`start_date`	Yes	Report start date, 'YYYY-MM-DD'
`network_code`	No	GAM network code for the domain. Optional — if omitted, the server falls back to the ACTIVEVIEW_NETWORK_CODE environment variable.

TDQS

B3.3/5.0

Behavior3/5

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

The description discloses that ad_exchange_line_item_level_revenue is in micros (divide by 1,000,000), which is a behavioral trait beyond the readOnlyHint annotation. However, it omits other behavioral aspects like pagination, data freshness, or potential performance implications.

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 with two front-loaded sentences. Every sentence adds value: the first states the core purpose, the second provides a critical behavioral detail. No redundancy or fluff.

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 complexity of 6 parameters (2 required) and no output schema, the description is adequate but incomplete. It explains the grouping and revenue unit, but lacks details about return structure, error handling, or how to differentiate from sibling tools.

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?

With 100% schema description coverage, the parameters are already well-documented structurally. The description adds minimal extra meaning (e.g., revenue unit conversion) but does not significantly enhance understanding beyond the schema.

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

Purpose4/5

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

The description clearly states that the tool returns KVP metrics for a domain grouped by a GAM key, specifying rows keyed by key/value with GAM ad-exchange metrics. However, it does not differentiate this tool from siblings like get_kvp_report_by_network or get_session_kvp_report_by_domain.

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 does not provide guidance on when to use this tool versus alternatives. It lacks information on prerequisites, limitations, or scenarios where this tool is preferable, leaving the agent without context for selection.

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

get_kvp_report_by_networkB

Read-only

KVP metrics across a network, grouped by a GAM key. Revenue in micros.

ParametersJSON Schema

Name	Required	Description	Default
`key`	No	Key to group by, e.g. 'utm_campaign'	utm_campaign
`domains`	No	Comma-separated domains, e.g. 'a.com,b.com' (optional)
`end_date`	No	Report end date, 'YYYY-MM-DD' (optional)
`start_date`	Yes	Report start date, 'YYYY-MM-DD'
`network_code`	No	GAM network code for the domain. Optional — if omitted, the server falls back to the ACTIVEVIEW_NETWORK_CODE environment variable.

TDQS

B3.1/5.0

Behavior3/5

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

The readOnlyHint annotation assures safe read operations, lowering the bar. The description adds the detail that revenue is in micros, but lacks information about output format, pagination, limits, or error handling. Minimal additional 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 a single, front-loaded sentence. It is efficient and gets to the point, though it could include slightly more detail without significant bloat.

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

Completeness2/5

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

With no output schema, the description should provide richer context about return values. It only mentions revenue in micros, omitting other metrics, grouping details, and behavioral aspects. Incomplete for a 5-parameter report 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?

All 5 parameters have descriptions in the input schema (100% coverage), so the baseline is 3. The description does not elaborate on any parameters beyond the schema, adding no extra value.

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

Purpose4/5

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

The description clearly states the tool retrieves KVP metrics across a network, grouped by a GAM key, with revenue in micros. It distinguishes from sibling tools like get_kvp_report_by_domain and get_report_by_network, though KVP abbreviation is not expanded.

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 does not mention prerequisites, conditions, or exclusions, leaving the agent to infer usage from the tool name alone.

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

get_price_rulesA

Read-only

Get all price (pricing) rules configured for a site.

Returns an array of rule objects with fields such as ad_unit, country, device, ecpm, impressions, match_rate, desired_match_rate, revenue, rule, state and utm_source.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Site domain, e.g. 'example.com'
`network_code`	No	GAM network code for the domain. Optional — if omitted, the server falls back to the ACTIVEVIEW_NETWORK_CODE environment variable.

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, so safety is clear. The description adds return field details but omits other behavioral traits (e.g., pagination, authorization requirements, error cases). With annotations, the bar is lower; still, some additional context would improve.

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

Conciseness5/5

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

Two sentences, front-loaded with the primary action, followed by a concise list of return fields. No redundant or extraneous text.

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 read-only list tool with good annotations, the description covers the main action and return fields. Minor gap: no mention that network_code is optional despite schema indicating default. Still, fairly complete for the complexity level.

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. The description repeats the domain as 'Site domain' but adds no new semantic value beyond what the schema provides. Baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states it retrieves all pricing rules for a site using a specific verb ("Get") and resource ("price rules"). It also lists returned fields, distinguishing it from sibling tools that generate reports rather than retrieve configured rules.

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?

No explicit guidance on when to use this tool versus alternatives like report tools. The purpose is implied but lack of when-to-use or when-not-to-use instructions limits agent decision-making.

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

get_redirect_pathA

Read-only

Get details of a specific redirect path, including its current mappings.

ParametersJSON Schema

Name	Required	Description	Default
`redirect_path_id`	Yes	ID of the redirect path

TDQS

A4/5.0

Behavior4/5

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

Annotations already provide readOnlyHint: true, so the description is free to add other context. It adds 'including its current mappings' which gives insight into what is returned, enhancing transparency beyond annotations. No contradictory behaviors.

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 one sentence (12 words), front-loaded with the action, and contains no extraneous information. Every word adds value.

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

Completeness4/5

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

Given the tool's simplicity (one parameter, read-only, no output schema), the description adequately conveys what the tool does. It could optionally mention that it returns details like mapping but it's sufficient for an agent to understand its purpose.

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

Parameters3/5

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

Schema coverage is 100% with the parameter redirect_path_id described as 'ID of the redirect path'. The description adds no additional meaning beyond that, so baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states 'Get details of a specific redirect path, including its current mappings.' The verb 'Get' and resource 'redirect path' are explicit, and it distinguishes from sibling tools like 'get_redirect_path_mappings' which likely returns only mappings.

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

Usage Guidelines3/5

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

The description implies usage when you need details of a specific redirect path, but it does not provide explicit guidance on when to use this tool versus alternatives like 'list_redirect_domains' or 'get_redirect_path_mapping_logs'. No exclusions or alternative tool mentions.

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

get_redirect_path_mapping_logsB

Read-only

Get the change logs (CREATE/UPDATE/DELETE) for a redirect path's mappings.

ParametersJSON Schema

Name	Required	Description	Default
`redirect_path_id`	Yes	ID of the redirect path

TDQS

B3.3/5.0

Behavior2/5

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

The description adds minimal behavioral context beyond the readOnlyHint annotation. It does not disclose what the logs contain, how they are ordered, or any other behavioral traits. The annotation already indicates it's read-only, so the description adds little value.

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

Conciseness5/5

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

The description is a single sentence that conveys the essential information without any filler. It is concise and 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?

While the description covers the basic purpose, it lacks details about the return format, pagination, or filtering. Given that there is no output schema, the description should provide more context about what the logs contain (e.g., timestamps, user info) to be fully complete.

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

Parameters3/5

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

The schema has 100% coverage with a clear description for the single parameter. The tool description does not add additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

Purpose5/5

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

The description clearly states it retrieves change logs for a redirect path's mappings, specifying the types of changes (CREATE/UPDATE/DELETE). It distinguishes from sibling tools like get_redirect_path_mappings (which presumably returns current state) by focusing on historical logs.

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

Usage Guidelines2/5

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

No explicit guidance is given on when to use this tool versus alternatives such as get_redirect_path_mappings. The context only implies that this is for history, but no when-to-use or when-not-to-use information is provided.

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

get_redirect_path_mappingsA

Read-only

Get the traffic-split mappings (url + percentage) for a redirect path.

ParametersJSON Schema

Name	Required	Description	Default
`redirect_path_id`	Yes	ID of the redirect path

TDQS

A4/5.0

Behavior3/5

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

Annotations declare readOnlyHint: true, and description's 'Get' confirms read-only. No additional behavioral context (e.g., response size, permissions). Description adds minimal value beyond annotations.

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?

Single sentence, 11 words, zero fluff. Every word earns its place.

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

Completeness4/5

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

Adequate for a simple getter tool with one parameter and readOnlyHint annotation. Specifies output format (url + percentage). Could mention pagination or result limits, but not critical.

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

Parameters4/5

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

Schema description coverage is 100%. Description adds meaning by stating the output contains 'url + percentage', which helps agent understand parameter's purpose beyond the schema.

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

Purpose5/5

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

Description uses explicit verb 'get' and resource 'traffic-split mappings' with details 'url + percentage'. Clearly distinguishes from siblings like get_redirect_path and get_redirect_path_mapping_logs.

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?

No explicit when-to-use or alternatives provided. Usage is implied by name and context, but lacks guidance for choosing among sibling tools.

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

get_report_by_domainA

Read-only

Metrics report for a single domain (same metrics used by the pricing service).

Returns per-request_uri rows with ad_unit, country, device, ecpm, impressions, eligible_ad_requests, match_rate, responses_served, revenue and utm_source.

ParametersJSON Schema

Name	Required	Description
`domain`	Yes	Site domain, e.g. 'example.com'
`end_date`	No	Report end date, 'YYYY-MM-DD' (optional)
`start_date`	Yes	Report start date, 'YYYY-MM-DD'
`network_code`	No	GAM network code for the domain. Optional — if omitted, the server falls back to the ACTIVEVIEW_NETWORK_CODE environment variable.

TDQS

A3.7/5.0

Behavior3/5

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

The description adds context that the metrics are the same as used by the pricing service, but the read-only nature is already covered by annotations. No contradictions, but minimal added value beyond annotations.

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 very concise, using two sentences to convey the purpose and the returned fields. It is front-loaded and efficient.

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?

Despite lacking an output schema, the description explicitly lists the fields returned, providing complete understanding of the report structure. It also mentions the metric source (pricing service), which adds useful context.

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

Parameters3/5

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

Schema coverage is 100% with all parameters described. The description adds general context about the report metrics but does not elaborate on individual parameter usage or constraints. Baseline of 3 is appropriate.

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

Purpose5/5

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

The description clearly states it provides a metrics report for a single domain and lists the specific metrics returned, distinguishing it from sibling tools that focus on networks or custom reports.

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 get_report_by_network or get_custom_gam_report_by_domain. It does not specify prerequisites or when to avoid it.

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

get_report_by_networkA

Read-only

Metrics report across a whole network, optionally filtered to some domains.

Same row shape as get_report_by_domain.

ParametersJSON Schema

Name	Required	Description
`domains`	No	Comma-separated domains, e.g. 'a.com,b.com' (optional)
`end_date`	No	Report end date, 'YYYY-MM-DD' (optional)
`start_date`	Yes	Report start date, 'YYYY-MM-DD'
`network_code`	No	GAM network code for the domain. Optional — if omitted, the server falls back to the ACTIVEVIEW_NETWORK_CODE environment variable.

TDQS

A4.2/5.0

Behavior4/5

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

Annotations indicate readOnlyHint=true, consistent with a report tool. Description adds that it produces metrics and the output shape matches get_report_by_domain, providing behavioral context beyond the annotation.

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

Conciseness5/5

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

The description is two sentences, front-loaded with the main purpose, and contains no extraneous information.

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

Completeness4/5

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

The description explains the report scope and references the sibling's output shape, which compensates for the lack of an output schema. It is sufficient for a simple read 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 coverage is 100%, so parameters are already well-documented. The description does not add substantial meaning beyond what the schema provides, warranting the baseline score.

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 provides a metrics report across a whole network with optional domain filtering. It also explicitly mentions the row shape matches get_report_by_domain, distinguishing it from the domain-level sibling.

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

Usage Guidelines4/5

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

The description implies the tool is for network-wide metrics with optional domain filtering, and references get_report_by_domain for shape, giving context. However, it lacks explicit when-to-use or when-not-to-use guidance compared to siblings.

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

get_session_kvp_report_by_domainB

Read-only

Session-based KVP report for a domain (sessions data from Snowflake).

Returns rows with COUNTRY_CODE, COUNTRY_NAME, KEY, VALUE, RECORDED_DATE and TOTAL, filtered by the given key.

ParametersJSON Schema

Name	Required	Description	Default
`key`	No	Key to group by, e.g. 'utm_campaign' or 'utm_source'	utm_campaign
`domain`	Yes	Site domain, e.g. 'example.com'
`end_date`	No	Report end date, 'YYYY-MM-DD' (optional)
`timezone`	No	Timezone for the data. One of: '' (default), 'gam' (Google Ad Manager), 'pacific', 'gmt_3', 'cet', 'eastern'.
`start_date`	Yes	Report start date, 'YYYY-MM-DD'
`network_code`	No	GAM network code for the domain. Optional — if omitted, the server falls back to the ACTIVEVIEW_NETWORK_CODE environment variable.

TDQS

B3.2/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=true, so the description does not need to restate safety. It adds context by specifying the data source (Snowflake) and the returned columns, but does not disclose performance characteristics, rate limits, or the behavior when optional parameters are omitted.

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. The first sentence states the core function, and the second lists key output columns. It is front-loaded and efficient, though it could be slightly more structured for readability.

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

Completeness4/5

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

Given that there is no output schema, the description compensates by listing the returned columns. It covers the main purpose and data source. However, it does not explain optional filtering beyond 'key', or how timezone and network_code affect results. Still, it is fairly complete for a read-only report tool.

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

Parameters3/5

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

Schema coverage is 100%, so the parameters are already described in the schema. The description adds minimal extra meaning beyond stating that results are filtered by the given key, which aligns with the key parameter. No additional clarification on format or usage of optional parameters like timezone or network_code.

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 that it provides a session-based KVP report for a domain, using Snowflake data, and lists the output columns. However, it does not explicitly distinguish itself from sibling tools like get_kvp_report_by_domain, which likely serves a similar purpose but without the 'session' qualifier.

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 its siblings (e.g., get_kvp_report_by_domain). There is no mention of prerequisites, data freshness, or scenarios where this tool is preferred.

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

list_redirect_domainsA

Read-only

List redirect domains created in the web interface, each with its paths.

Returns {"redirectDomains": [{id, name, createdAt, redirectPaths:[{id, path}]}]}. Returns an empty list if none exist.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior5/5

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

Annotations provide readOnlyHint, and the description adds detailed return format including an empty list case, which goes beyond basic annotation info.

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

Conciseness5/5

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

Two sentences that front-load the purpose and immediately provide return format. No wasted words.

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

Completeness5/5

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

For a parameterless tool with no output schema, the description fully specifies what it does and what it returns. No gaps.

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?

No parameters exist; schema coverage is 100%. With zero parameters, the description has nothing to add, and baseline score of 4 is appropriate.

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

Purpose5/5

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

The description clearly states it lists redirect domains with their associated paths. It distinguishes from sibling tools, which are focused on reports or specific redirect paths.

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 indicates the tool lists redirect domains from the web interface. It doesn't explicitly exclude alternatives, but sibling tools have different purposes, making usage clear.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool targets a distinct reporting or redirect management operation. Custom GAM reports, KVP reports, session reports, price rules, and redirect paths are all clearly separated, with no overlapping purposes.

Naming Consistency4/5

Most tools follow a 'get_<noun>_by_<scope>' pattern (e.g., get_custom_gam_report_by_domain) or 'list_<noun>' (e.g., list_redirect_domains). The pattern is consistent snake_case, though get_price_rules deviates slightly by not including a scope.

Tool Count5/5

With 12 tools covering multiple areas (reports, redirects, pricing rules), the count is well-scoped for a read-only dashboard server. Each tool has a distinct purpose and none seem extraneous.

Completeness4/5

The tool surface covers the main read operations for GAM reports, redirect paths, and pricing rules. Missing write operations (create/update/delete) are likely intentional given the 'view' nature, but could be considered a minor gap for full lifecycle management.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

LemonadoOAuth
io.github.lemonadolabs
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Marketing Research & Data Databases
3
AIStatusDashboard
io.github.aistatusdashboard
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Monitoring Observability
2
paid-ads AOAuth
io.github.connected-paths
Hosted MCP server for Google Ads and LinkedIn Ads analysis.
Marketing Social Media
2
The Quiet Protocol Growth Offense MCP A
com.thequietprotocol.www
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Databases Research & Data Finance
292

Related MCP Servers

flin-google-ads-mcp
Marketing Search
flin-agency
A
license
B
quality
C
maintenance
Read-only MCP server for Google Ads, enabling querying campaigns, ad groups, ads, insights, and keywords without create/update/delete operations.
Updated a month ago (2026-08-04 08:31 UTC)
9
MIT
TikTok Ads MCP
Marketing Social Media
Buer2333
A
license
B
quality
B
maintenance
A read-only MCP server that provides comprehensive access to the TikTok Business API for retrieving advertising data, including campaigns, ad groups, ads, and performance reports.
Updated 8 days ago (2026-08-27 07:47 UTC)
24
MIT
flin-meta-ads-mcp
Marketing Social Media
flin-agency
A
license
B
quality
B
maintenance
Read-only MCP server for Meta Ads that lists and reads ad accounts, campaigns, ad sets, ads, ad images, creatives, and fetches insights at various levels.
Updated a month ago (2026-08-04 12:54 UTC)
14
MIT
yandex-metrika-mcp
Marketing Research & Data
nikolaymokh-dev
A
license
Not graded
quality
C
maintenance
Read-only MCP server for Yandex Metrika analytics, enabling report retrieval via MCP clients like Claude Code or Cursor without modifying any data.
Updated 2 months ago (2026-07-07 06:10 UTC)
70
MIT

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/Zest-Global/mcp-activeview'

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