Related MCP server: Grips Intelligence MCP Server
Перед использованием этого сервера убедитесь, что у вас есть:
Node.js (v18 или выше)
Приложение Клода для ПК
Учетная запись Audiense Insights с учетными данными API
Токен X/Twitter API Bearer Token (необязательно, для обогащенных данных влиятельных лиц)
Откройте файл конфигурации для Claude Desktop:
MacOS:
code ~/Library/Application\ Support/Claude/claude_desktop_config.jsonОкна:
code %AppData%\Claude\claude_desktop_config.jsonДобавьте или обновите следующую конфигурацию:
"mcpServers": {
"audiense-insights": {
"command": "npx",
"args": [
"-y",
"mcp-audiense-insights"
],
"env": {
"AUDIENSE_CLIENT_ID": "your_client_id_here",
"AUDIENSE_CLIENT_SECRET": "your_client_secret_here",
"TWITTER_BEARER_TOKEN": "your_token_here"
}
}
}
Сохраните файл и перезапустите Claude Desktop.
get-reportsОписание : Извлекает список отчетов Audiense Insights, принадлежащих аутентифицированному пользователю.
Параметры : Нет
Ответ :
Список отчетов в формате JSON.
get-report-infoОписание : Извлекает подробную информацию о конкретном отчете разведки , включая:
Статус
Тип сегментации
Размер аудитории
Сегменты
Ссылки доступа
Параметры :
report_id(string) : идентификатор отчета разведки.
Ответ :
Полные данные отчета в формате JSON.
Если отчет все еще обрабатывается, возвращается сообщение с указанием статуса ожидания.
get-audience-insightsОписание : Извлекает обобщенные данные для заданной аудитории , включая:
Демографические данные : пол, возраст, страна.
Поведенческие черты : Активные часы, использование платформы.
Психографика : Черты личности, интересы.
Социально-экономические факторы : доход, уровень образования.
Параметры :
audience_insights_id(string) : идентификатор информации об аудитории.
insights(массив строк, необязательно) : список конкретных названий идей для фильтрации.
Ответ :
Аналитика отформатирована в виде структурированного текстового списка.
get-baselinesОписание : Извлекает доступные базовые аудитории , опционально отфильтрованные по стране .
Параметры :
country(строка, необязательно) : код страны ISO для фильтрации.
Ответ :
Список базовых аудиторий в формате JSON.
get-categoriesОписание : Возвращает список доступных категорий близости , которые можно использовать при сравнении влиятельных лиц.
Параметры : Нет
Ответ :
Список категорий в формате JSON.
compare-audience-influencersОписание : Сравнивает влиятельных лиц заданной аудитории с базовой аудиторией . Базовая аудитория определяется следующим образом:
Если одна страна представляет более 50% аудитории, то эта страна используется в качестве базовой линии.
В противном случае используется глобальная базовая линия .
Если выбран определенный сегмент , в качестве базового уровня используется вся аудитория.
Каждое сравнение влиятельных лиц включает в себя:
Аффинити (%) – насколько хорошо влиятельный человек соответствует аудитории.
Базовая близость (%) — близость влиятельного лица к базовой аудитории.
Показатель уникальности — насколько влиятельный человек отличается от базового уровня.
Параметры :
audience_influencers_id(string) : идентификатор влиятельных лиц аудитории.
baseline_audience_influencers_id(строка) : идентификатор влиятельных лиц базовой аудитории.
cursor(число, необязательно) : курсор пагинации.
count(число, необязательно) : количество элементов на странице (по умолчанию: 200).
bio_keyword(строка, необязательно) : Фильтрация влиятельных лиц по ключевому слову биографии .
entity_type(enum: person | brand , необязательно) : Фильтр по типу сущности.
followers_min(число, необязательно) : минимальное количество подписчиков.
followers_max(число, необязательно) : максимальное количество подписчиков.
categories(массив строк, необязательно) : фильтрация влиятельных лиц по категориям .
countries(массив строк, необязательно) : фильтрация влиятельных лиц по кодам стран ISO .
Ответ :
Список влиятельных лиц с оценками сходства, сравнением с исходными данными и оценками уникальности в формате JSON.
get-audience-contentОписание : Извлекает сведения о взаимодействии аудитории с контентом , включая:
Понравившийся контент : самые популярные посты, домены, эмодзи, хэштеги, ссылки, медиа и облако слов.
Общий контент : большая часть общего контента классифицирована схожим образом.
Влиятельный контент : контент из влиятельных аккаунтов.
Каждая категория содержит:
popularPost : Наиболее популярные публикации.
topDomains : Наиболее упоминаемые домены.
topEmojis : Наиболее используемые эмодзи.
topHashtags : наиболее используемые хэштеги.
topLinks : Наиболее распространенные ссылки.
topMedia : общие медиа.
wordcloud : Наиболее часто используемые слова.
Параметры :
audience_content_id(строка) : идентификатор контента аудитории.
Ответ :
Данные о взаимодействии с контентом в формате JSON.
report-summaryОписание : Создает полную сводку отчета Audiense, включая:
Метаданные отчета (название, тип сегментации)
Полный размер аудитории
Подробная информация о сегменте
Основные сведения по каждому сегменту (биография, ключевые слова, демография, интересы)
Наиболее влиятельные лица для каждого сегмента со сравнительными показателями
Параметры :
report_id(string) : идентификатор отчета разведки, который необходимо обобщить.
Ответ :
Полный отчет в формате JSON со структурированными данными по каждому сегменту
Для ожидающих отчетов: сообщение о состоянии, указывающее, что отчет все еще обрабатывается.
Для отчетов без сегментов: сообщение о том, что нет сегментов для анализа.
Этот сервер включает в себя предварительно настроенные подсказки
audiense-demo : помогает анализировать отчеты Audiense в интерактивном режиме.
segment-matching : подсказка для сопоставления и сравнения сегментов аудитории в отчетах Audiense, выявление сходств, уникальных черт и ключевых идей на основе демографических данных, интересов, влиятельных лиц и моделей взаимодействия.
Использование:
Принимает аргумент reportName для поиска наиболее релевантного отчета.
Если указан идентификатор, поиск выполняется по идентификатору отчета.
Вариант использования: структурированное руководство по анализу аудитории.
Проверьте журналы Claude Desktop:
tail -f ~/Library/Logs/Claude/mcp*.logПроверьте правильность настройки переменных среды.
Убедитесь, что абсолютный путь к index.js указан правильно.
Еще раз проверьте учетные данные OAuth.
Убедитесь, что токен обновления все еще действителен.
Убедитесь, что необходимые области API включены.
Чтобы проверить журналы сервера:
tail -n 20 -f ~/Library/Logs/Claude/mcp*.logGet-Content -Path "$env:AppData\Claude\Logs\mcp*.log" -Wait -Tail 20Сохраняйте учетные данные API в безопасности — никогда не публикуйте их в публичных репозиториях.
Используйте переменные среды для управления конфиденциальными данными.
Этот проект лицензирован по лицензии Apache 2.0. Подробнее см. в файле LICENSE.
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
