该服务器基于模型上下文协议 (MCP) ，允许Claude或任何其他兼容 MCP 的客户端与您的Audiense Insights帐户进行交互。它从 Audiense 报告中提取营销洞察和受众分析，涵盖人口统计、文化、影响者和内容参与度分析。
在使用此服务器之前，请确保您已：
Node.js （v18 或更高版本）
克劳德桌面应用程序
具有 API 凭据的Audiense Insights 帐户
X/Twitter API Bearer Token （可选，用于丰富影响者数据）
Related MCP server: Grips Intelligence MCP Server
要通过Smithery自动为 Claude Desktop 安装 Audiense Insights Server：
npx -y @smithery/cli@latest install @AudienseCo/mcp-audiense-insights --client claude打开Claude Desktop的配置文件：
MacOS：
code ~/Library/Application\ Support/Claude/claude_desktop_config.json视窗：
code %AppData%\Claude\claude_desktop_config.json添加或更新以下配置：
"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"
}
}
}
保存文件并重新启动 Claude Desktop。
get-reports描述：检索经过身份验证的用户拥有的Audiense 洞察报告列表。
参数：无
回复：
JSON 格式的报告列表。
get-report-info描述：获取有关特定情报报告的详细信息，包括：
地位
分割类型
观众规模
段
访问链接
参数：
report_id(字符串) ：情报报告的ID。
回复：
JSON 格式的完整报告详细信息。
如果报告仍在处理中，则返回一条指示待处理状态的消息。
get-audience-insights描述：检索给定受众的汇总见解，包括：
人口统计：性别、年龄、国家。
行为特征：活跃时间、平台使用情况。
心理特征：性格特征、兴趣。
社会经济因素：收入、教育状况。
参数：
audience_insights_id(string) ：受众洞察的 ID。
insights（字符串数组，可选） ：要过滤的特定洞察名称列表。
回复：
格式化为结构化文本列表的见解。
get-baselines描述：检索可用的基准受众，可选择按国家/地区进行过滤。
参数：
country（字符串，可选） ：用于过滤的 ISO 国家代码。
回复：
JSON 格式的基线受众列表。
get-categories描述：检索可用于影响者比较的亲和力类别列表。
参数：无
回复：
JSON 格式的类别列表。
compare-audience-influencers描述：将给定受众群体的影响者与基线受众群体进行比较。基线确定方法如下：
如果某个国家/地区的观众人数超过 50%，则以该国/地区为基准。
否则，使用全局基线。
如果选择了特定的部分，则将整个受众群体作为基线。
每个影响者比较包括：
亲和力（%） ——影响者与受众的契合程度。
基线亲和力 (%) – 影响者在基线受众中的亲和力。
独特性得分——影响者与基线相比的独特程度。
参数：
audience_influencers_id(string) ：受众影响者的 ID。
baseline_audience_influencers_id(字符串) ：基线受众影响者的 ID。
cursor（数字，可选） ：分页光标。
count（数字，可选） ：每页的项目数（默认值：200）。
bio_keyword（字符串，可选） ：通过bio 关键字过滤影响者。
entity_type（枚举： person | brand ，可选） ：按实体类型过滤。
followers_min（数字，可选） ：关注者的最小数量。
followers_max(数字，可选) ：关注者的最大数量。
categories（字符串数组，可选） ：按类别过滤影响者。
countries（字符串数组，可选） ：按国家 ISO 代码过滤影响者。
回复：
具有亲和力分数、基线比较和独特性分数的影响者列表（JSON 格式）。
get-audience-content描述：检索受众内容参与详情，包括：
喜欢的内容：最受欢迎的帖子、域名、表情符号、主题标签、链接、媒体和词云。
共享内容：大多数共享内容按类似方式分类。
有影响力的内容：来自有影响力的账户的内容。
每个类别包含：
popularPost ：参与度最高的帖子。
topDomains ：提及次数最多的域名。
topEmojis ：最常用的表情符号。
topHashtags ：最常用的主题标签。
topLinks ：最多人分享的链接。
topMedia ：共享媒体。
wordcloud ：最常用的单词。
参数：
audience_content_id(string) ：受众内容的 ID。
回复：
JSON 格式的内容参与度数据。
report-summary描述：生成 Audiense 报告的综合摘要，包括：
报告元数据（标题、分段类型）
全部观众人数
详细分部信息
每个细分市场的热门见解（个人简介关键词、人口统计、兴趣）
各细分市场最具影响力人物及比较指标
参数：
report_id(字符串) ：要汇总的情报报告的 ID。
回复：
完整的报告摘要采用 JSON 格式，包含每个部分的结构化数据
对于待处理报告：状态消息表明报告仍在处理中
对于没有细分的报告：指示没有可供分析的细分的消息
该服务器包含预配置的提示
audiense-demo ：帮助以交互方式分析 Audiense 报告。
segment-matching ：提示匹配和比较 Audiense 报告中的受众细分，根据人口统计、兴趣、影响者和参与模式识别相似性、独特特征和关键见解。
用法：
接受 reportName 参数来查找最相关的报告。
如果提供了 ID，则它会按报告 ID 进行搜索。
用例：受众分析的结构化指导。
检查 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 许可证。更多详情请参阅许可证文件。
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
