Este servidor, basado en el Protocolo de Contexto de Modelo (MCP) , permite que Claude o cualquier otro cliente compatible con MCP interactúe con su cuenta de Audiense Insights . Extrae información de marketing y análisis de audiencia de los informes de Audiense, incluyendo análisis demográficos, culturales, de influencers y de interacción con el contenido .
Antes de utilizar este servidor, asegúrese de tener:
Node.js (v18 o superior)
Aplicación de escritorio Claude
Cuenta de Audiense Insights con credenciales de API
Token portador de API de X/Twitter (opcional, para datos enriquecidos de influencers)
Related MCP server: Grips Intelligence MCP Server
Para instalar Audiense Insights Server para Claude Desktop automáticamente a través de Smithery :
npx -y @smithery/cli@latest install @AudienseCo/mcp-audiense-insights --client claudeAbra el archivo de configuración de Claude Desktop:
Sistema operativo Mac:
code ~/Library/Application\ Support/Claude/claude_desktop_config.jsonVentanas:
code %AppData%\Claude\claude_desktop_config.jsonAgregue o actualice la siguiente configuración:
"mcpServers": {
"audiense-insights": {
"command": "/opt/homebrew/bin/node",
"args": [
"/ABSOLUTE/PATH/TO/YOUR/build/index.js"
],
"env": {
"AUDIENSE_CLIENT_ID": "your_client_id_here",
"AUDIENSE_CLIENT_SECRET": "your_client_secret_here",
"TWITTER_BEARER_TOKEN": "your_token_here"
}
}
}
Guarde el archivo y reinicie Claude Desktop.
get-reportsDescripción : Recupera la lista de informes de estadísticas de Audiense propiedad del usuario autenticado.
Parámetros : Ninguno
Respuesta :
Listado de informes en formato JSON.
get-report-infoDescripción : Obtiene información detallada sobre un informe de inteligencia específico , que incluye:
Estado
Tipo de segmentación
Tamaño de la audiencia
Segmentos
Enlaces de acceso
Parámetros :
report_id(cadena) : El ID del informe de inteligencia.
Respuesta :
Detalles completos del informe en formato JSON.
Si el informe aún se está procesando, devuelve un mensaje indicando el estado pendiente.
get-audience-insightsDescripción : Recupera información agregada para una audiencia determinada, que incluye:
Demografía : género, edad, país.
Rasgos de comportamiento : Horas activas, uso de la plataforma.
Psicografía : Rasgos de personalidad, intereses.
Factores socioeconómicos : ingresos, nivel educativo.
Parámetros :
audience_insights_id(cadena) : el ID de las estadísticas de audiencia.
insights(matriz de cadenas, opcional) : lista de nombres de insights específicos para filtrar.
Respuesta :
Perspectivas formateadas como una lista de texto estructurada.
get-baselinesDescripción : Recupera las audiencias base disponibles, opcionalmente filtradas por país .
Parámetros :
country(cadena, opcional) : código de país ISO por el que filtrar.
Respuesta :
Lista de audiencias de referencia en formato JSON.
get-categoriesDescripción : Recupera la lista de categorías de afinidad disponibles que se pueden utilizar en comparaciones de personas influyentes.
Parámetros : Ninguno
Respuesta :
Lista de categorías en formato JSON.
compare-audience-influencersDescripción : Compara a los influencers de una audiencia dada con una audiencia de referencia . Esta audiencia se determina de la siguiente manera:
Si un solo país representa más del 50% de la audiencia, ese país se utiliza como base.
De lo contrario, se utiliza la línea base global .
Si se selecciona un segmento específico , se utiliza la audiencia completa como base.
Cada comparación de influencers incluye:
Afinidad (%) : qué tan bien se alinea el influencer con la audiencia.
Afinidad de referencia (%) : la afinidad del influenciador dentro de la audiencia de referencia.
Puntuación de singularidad : qué tan distinto es el influenciador en comparación con la línea base.
Parámetros :
audience_influencers_id(cadena) : ID de los influenciadores de la audiencia.
baseline_audience_influencers_id(cadena) : ID de los influenciadores de la audiencia de referencia.
cursor(número, opcional) : Cursor de paginación.
count(número, opcional) : Número de elementos por página (predeterminado: 200).
bio_keyword(cadena, opcional) : filtrar influencers por palabra clave biográfica .
entity_type(enum: person | brand , opcional) : Filtrar por tipo de entidad.
followers_min(número, opcional) : Número mínimo de seguidores.
followers_max(número, opcional) : Número máximo de seguidores.
categories(matriz de cadenas, opcional) : filtra influencers por categorías .
countries(matriz de cadenas, opcional) : filtra personas influyentes por códigos ISO de país .
Respuesta :
Lista de personas influyentes con puntuaciones de afinidad, comparación de referencia y puntuaciones de singularidad en formato JSON.
get-audience-contentDescripción : Recupera detalles de interacción con el contenido de la audiencia , incluidos:
Contenido gustado : publicaciones, dominios, emojis, hashtags, enlaces, medios y una nube de palabras más populares.
Contenido compartido : la mayoría del contenido compartido está categorizado de manera similar.
Contenido influyente : contenido de cuentas influyentes.
Cada categoría contiene:
popularPost : Publicaciones más comprometidas.
topDomains : Dominios más mencionados.
topEmojis : Emojis más utilizados.
topHashtags : Los hashtags más utilizados.
topLinks : Enlaces más compartidos.
topMedia : Medios compartidos.
wordcloud : Palabras más utilizadas.
Parámetros :
audience_content_id(cadena) : El ID del contenido de la audiencia.
Respuesta :
Datos de participación en el contenido en formato JSON.
report-summaryDescripción : Genera un resumen completo de un informe de Audiense, que incluye:
Metadatos del informe (título, tipo de segmentación)
Tamaño completo de la audiencia
Información detallada del segmento
Principales perspectivas para cada segmento (palabras clave biográficas, datos demográficos, intereses)
Principales influencers de cada segmento con métricas de comparación
Parámetros :
report_id(cadena) : El ID del informe de inteligencia a resumir.
Respuesta :
Resumen completo del informe en formato JSON con datos estructurados para cada segmento
Para informes pendientes: Mensaje de estado que indica que el informe aún se está procesando
Para informes sin segmentos: Mensaje que indica que no hay segmentos para analizar
Este servidor incluye indicaciones preconfiguradas
audiense-demo : ayuda a analizar los informes de Audiense de forma interactiva.
segment-matching : una solicitud para hacer coincidir y comparar segmentos de audiencia en los informes de Audiense, identificando similitudes, rasgos únicos y conocimientos clave basados en datos demográficos, intereses, personas influyentes y patrones de participación.
Uso:
Acepta un argumento reportName para encontrar el informe más relevante.
Si se proporciona una identificación, se busca por ID de informe.
Caso de uso: Orientación estructurada para el análisis de audiencia.
Consulte los registros de Claude Desktop:
tail -f ~/Library/Logs/Claude/mcp*.logVerifique que las variables de entorno estén configuradas correctamente.
Asegúrese de que la ruta absoluta a index.js sea correcta.
Verifique nuevamente las credenciales de OAuth.
Asegúrese de que el token de actualización siga siendo válido.
Verifique que los ámbitos de API requeridos estén habilitados.
Para comprobar los registros del servidor:
tail -n 20 -f ~/Library/Logs/Claude/mcp*.logGet-Content -Path "$env:AppData\Claude\Logs\mcp*.log" -Wait -Tail 20Mantenga seguras las credenciales de API: nunca las exponga en repositorios públicos.
Utilice variables de entorno para gestionar datos confidenciales.
Este proyecto está licenciado bajo la licencia Apache 2.0. Consulte el archivo de licencia para más detalles.
Compares the influencers of an audience with a baseline audience. The baseline is determined as follows: If the selection was the full audience and a single country represents more than 50% of the audience, that country is used as the baseline. Otherwise, the Global baseline is applied. If the selection was a specific segment, the full audience is used as the baseline. Each influencer comparison includes: - Affinity (%) - The level of alignment between the influencer and the audience. Baseline Affinity (%) - The influencer’s affinity within the baseline audience. Uniqueness Score - A measure of how distinct the influencer is within the selected audience compared to the baseline.
| Name | Required | Description | Default |
|---|---|---|---|
| audience_influencers_id | Yes | The ID of the audience influencers. | |
| baseline_audience_influencers_id | Yes | The ID of the baseline audience influencers. | |
| cursor | No | Cursor for pagination. | |
| count | No | Number of items per page (default: 200). | |
| bio_keyword | No | Keyword to filter influencers by their biography. | |
| entity_type | No | Filter by entity type (person or brand). | |
| followers_min | No | Minimum number of followers. | |
| followers_max | No | Maximum number of followers. | |
| categories | No | Filter influencers by categories. | |
| countries | No | Filter influencers by country ISO codes. |
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 some context by detailing the baseline determination logic and the comparison metrics (Affinity, Uniqueness Score), which helps understand the tool's behavior. However, it doesn't cover critical aspects like whether this is a read-only operation, potential rate limits, error conditions, or pagination behavior (implied by cursor/count parameters), making it incomplete for a tool with 10 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose and then detailing baseline logic and comparison metrics in a structured manner. Each sentence adds value, such as explaining baseline determination and output fields, with no redundant information. However, it could be slightly more concise by integrating the baseline rules more tightly with the main function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (10 parameters, no annotations, no output schema), the description is partially complete. It covers the purpose, baseline logic, and output metrics, which are essential. However, it lacks details on return values (e.g., format of comparison results), error handling, and how parameters like 'bio_keyword' or 'followers_min' affect the comparison, leaving gaps that could hinder an AI agent's ability to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 10 parameters thoroughly. The description adds minimal value beyond the schema by implying the use of 'audience_influencers_id' and 'baseline_audience_influencers_id' for comparison, but doesn't provide additional syntax, format details, or explain how parameters like 'cursor' or 'categories' integrate with the comparison logic. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: comparing influencers between an audience and a baseline audience. It specifies the verb 'compares' and the resources 'influencers of an audience' and 'baseline audience', making the function explicit. However, it doesn't differentiate from sibling tools like 'get-audience-insights' or 'report-summary', which might also involve audience analysis, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage by explaining how the baseline is determined (e.g., full audience vs. specific segment, country vs. Global baseline), which gives context for when to apply this tool. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get-audience-insights' or 'report-summary', and doesn't mention prerequisites or exclusions, leaving gaps in usage clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves audience content engagement details for a given audience.
This tool provides a detailed breakdown of the content an audience interacts with, including:
Liked Content: Popular posts, top domains, top emojis, top hashtags, top links, top media, and a word cloud.
Shared Content: Content that the audience shares, categorized similarly to liked content.
Influential Content: Content from influential accounts that impact the audience, with similar categorization.
Each category contains:
popularPost: List of the most engaged posts.
topDomains: Most mentioned domains.
topEmojis: Most used emojis.
topHashtags: Most used hashtags.
topLinks: Most shared links.
topMedia: Media types shared and samples.
wordcloud: Frequently used words.
| Name | Required | Description | Default |
|---|---|---|---|
| audience_content_id | Yes | The ID of the audience content to retrieve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes what data is returned (content breakdowns) but doesn't mention critical behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or data freshness. The description focuses on output structure rather than operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear bullet points and categorization. It's appropriately sized for the complexity of the tool, though the detailed breakdown of return categories could be considered slightly verbose. The information is front-loaded with the core purpose stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description provides good detail about what data is returned but lacks operational context. It adequately describes the output structure but doesn't cover behavioral aspects or usage guidance. Given the single parameter with full schema coverage, the description is moderately complete but has significant gaps in behavioral transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter clearly documented. The description doesn't add any parameter-specific information beyond what's in the schema, but with complete schema coverage, the baseline score of 3 is appropriate. No additional semantic context is provided about the 'audience_content_id' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as retrieving audience content engagement details with a breakdown of liked, shared, and influential content. It specifies the resource (audience content) and verb (retrieves), but doesn't explicitly differentiate from sibling tools like 'get-audience-insights' or 'get-reports' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get-audience-insights' or 'get-reports'. It doesn't mention prerequisites, exclusions, or specific scenarios where this tool is preferred over sibling tools, leaving the agent without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves aggregated insights for a given audience ID, providing statistical distributions across various attributes. Available insights include demographics (e.g., gender, age, country), behavioral traits (e.g., active hours, platform usage), psychographics (e.g., personality traits, interests), and socioeconomic factors (e.g., income, education status).
| Name | Required | Description | Default |
|---|---|---|---|
| audience_insights_id | Yes | The ID of the audience insights. | |
| insights | No | Optional list of insight names to filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what insights are retrieved but lacks critical behavioral details such as whether this is a read-only operation, potential rate limits, authentication requirements, or the format of the aggregated data. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core action ('Retrieves aggregated insights') and then listing insight categories. Both sentences earn their place by clarifying scope, but it could be slightly more concise by integrating the list more tightly or omitting minor redundancies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (retrieving aggregated insights with multiple categories), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, response format, error handling, or how insights are aggregated. For a tool with rich potential outputs and no structured support, more context is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 ('audience_insights_id' and 'insights'). The description adds value by explaining the types of insights available (e.g., demographics, behavioral traits), which helps contextualize the 'insights' parameter, but it doesn't provide additional syntax or format details beyond what the schema offers. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Retrieves') and resource ('aggregated insights for a given audience ID'), and it distinguishes the type of insights provided (demographics, behavioral traits, psychographics, socioeconomic factors). However, it doesn't explicitly differentiate from sibling tools like 'get-audience-content' or 'get-reports', which might also retrieve audience-related data, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get-audience-content' or 'get-reports', nor does it specify prerequisites, exclusions, or contextual cues for selection. Usage is implied through the description of insights but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves available baselines, optionally filtered by country.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO country code to filter by. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a retrieval operation, implying read-only behavior, but doesn't clarify whether this requires authentication, has rate limits, returns paginated results, or what format the baselines come in. For a tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just one sentence with zero wasted words. It's front-loaded with the core purpose and includes the key optional feature. Every word earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is insufficiently complete. While concise, it doesn't explain what 'baselines' are in this context, what data they contain, how results are structured, or whether there are limitations on retrieval. For a retrieval tool with no structured output documentation, more context about the return value would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions optional filtering by country, which aligns with the single parameter in the schema. With 100% schema description coverage (the country parameter has a clear description), the description adds minimal value beyond what's already documented in the structured schema. This meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Retrieves') and resource ('available baselines'), making the purpose understandable. It distinguishes this as a retrieval operation rather than creation or modification. However, it doesn't explicitly differentiate from sibling tools like 'get-reports' or 'get-categories', which appear to be similar retrieval operations in the same domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by mentioning optional filtering by country, but offers no explicit when-to-use advice. There's no indication of when to choose this tool over sibling tools like 'get-reports' or 'get-categories', nor any mention of prerequisites, dependencies, or typical use cases. The agent must 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.
Retrieves the list of available affinity categories that can be used as the categories parameter in the compare-audience-influencers tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 indicates this is a retrieval operation, implying it's likely read-only and non-destructive, but doesn't explicitly state permissions, rate limits, or error behavior. The description adds some context about how the output is used, but lacks detailed behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the tool's purpose and usage without any wasted words. It's front-loaded with the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless retrieval tool with no annotations or output schema, the description is reasonably complete. It explains what the tool does and how its output is used, though it could benefit from mentioning the return format or any limitations. The lack of output schema means the description doesn't need to cover return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter information, but it does provide context about the output's purpose, which is valuable. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Retrieves') and resource ('list of available affinity categories'), and explicitly distinguishes this tool from its sibling 'compare-audience-influencers' by explaining how the output is used. This goes beyond a basic definition to show the tool's role in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: to get categories that 'can be used as the categories parameter in the compare-audience-influencers tool.' This provides clear guidance on its purpose relative to the sibling tool, though it doesn't mention other potential alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves detailed information about a specific intelligence report, including its status, segmentation type, audience size, segments, and access links.
| Name | Required | Description | Default |
|---|---|---|---|
| report_id | Yes | The ID of the intelligence report. |
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 states 'Retrieves' (implying a read operation) but doesn't disclose behavioral traits such as authentication needs, rate limits, error conditions, or what happens if the report_id is invalid. For a tool with no annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and lists key attributes without waste. Every word contributes to understanding the tool's function, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with one parameter), no annotations, and no output schema, the description is adequate but incomplete. It covers the purpose and attributes but lacks behavioral details and output information, which are needed for full contextual understanding in the absence of structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'report_id' fully documented in the schema. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieves' and the resource 'detailed information about a specific intelligence report', with specific attributes listed (status, segmentation type, audience size, segments, access links). It distinguishes from siblings like 'get-reports' (likely listing reports) and 'report-summary' (likely providing summaries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get-reports' or 'report-summary' is provided. The description implies usage for a specific report but doesn't specify prerequisites or exclusions, leaving the agent to infer context from tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves the list of Audiense insights reports owned by the authenticated user.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'authenticated user' (implying auth needs) but doesn't disclose other behavioral traits like whether it's read-only (implied by 'Retrieves'), rate limits, pagination, sorting, or what happens if no reports exist. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It could be slightly more structured by adding usage context, but it avoids redundancy and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and no output schema, the description is minimally adequate but lacks completeness. It doesn't explain return values (e.g., format, fields) or behavioral details like pagination. For a list-retrieval tool with no annotations, more context on output and constraints would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds no parameter information, which is appropriate here. Baseline is 4 for 0 parameters, as no additional semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieves') and resource ('list of Audiense insights reports'), specifying ownership scope ('owned by the authenticated user'). It distinguishes from some siblings like 'get-report-info' (detailed info vs. list) but doesn't explicitly differentiate from 'get-audience-insights' or 'report-summary', which might have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like 'get-report-info' (for detailed report data) or 'get-audience-insights' (possibly for broader insights). The description implies it's for listing reports, but lacks explicit when/when-not instructions or prerequisite context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a comprehensive summary of an Audiense report, including segment details, top insights, and influencers.
| Name | Required | Description | Default |
|---|---|---|---|
| report_id | Yes | The ID of the intelligence report to summarize. |
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 states the tool generates a summary but lacks details on output format (e.g., structured data vs. text), performance characteristics (e.g., processing time), error handling, or any side effects. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Generates a comprehensive summary') and lists key components without unnecessary details. Every word earns its place, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (generating a comprehensive summary), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the summary output looks like (e.g., text, JSON structure), how comprehensive it is, or any limitations. For a tool with no structured output documentation, more detail is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'report_id' fully documented in the schema as 'The ID of the intelligence report to summarize.' The description adds no additional parameter semantics beyond what the schema provides, such as format examples or validation rules. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generates a comprehensive summary of an Audiense report' with specific components mentioned ('segment details, top insights, and influencers'). It distinguishes from some siblings like 'get-report-info' by emphasizing summary generation rather than basic information retrieval, though it doesn't explicitly differentiate from all siblings like 'get-audience-insights'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid report_id), comparison with siblings like 'get-report-info' for basic metadata or 'get-audience-insights' for specific insights, or any exclusions. Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose with no overlap: compare-audience-influencers focuses on influencer comparisons, get-audience-content on content engagement, get-audience-insights on aggregated statistics, get-baselines on baseline data, get-categories on affinity categories, get-report-info on report metadata, get-reports on report listings, and report-summary on report summarization. The descriptions reinforce these distinct roles, making tool selection unambiguous.
All tool names follow a consistent kebab-case pattern with a verb-noun structure (e.g., get-audience-insights, compare-audience-influencers). The verbs are appropriate and predictable (get, compare, report), and there are no deviations in naming style or convention across the set.
With 8 tools, this server is well-scoped for an audience insights domain. The count is neither too sparse nor bloated, covering core operations like retrieving insights, content, reports, and comparisons without redundancy. Each tool serves a specific, necessary function in the workflow.
The tool set provides comprehensive coverage for analyzing audience insights, including retrieval of reports, insights, content, and comparisons. Minor gaps exist, such as the lack of tools for creating or updating reports or audiences, which might limit full lifecycle management. However, the available tools support most common analysis tasks effectively.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only access to InfluSense influencer discovery, ratings, watchlists, and reports via MCP.
Manage 230M+ influencers, track campaigns, and access real-time CIMS analytics via AI agents
Query your Minter.io social media analytics: Instagram, TikTok, X, Facebook, LinkedIn, Threads.
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AudienseCo/mcp-audiense-insights'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
