이 서버는 MCP(Model Context Protocol) 기반이며, Claude 또는 기타 MCP 호환 클라이언트가 Audiense Insights 계정과 상호 작용할 수 있도록 지원합니다. Audiense 보고서에서 인구 통계, 문화, 인플루언서 및 콘텐츠 참여 분석을 포함한 마케팅 인사이트와 잠재고객 분석을 추출합니다.
이 서버를 사용하기 전에 다음 사항을 확인하세요.
Node.js (v18 이상)
클로드 데스크톱 앱
API 자격 증명이 있는 Audiense Insights 계정
X/Twitter API 전달자 토큰 (선택 사항, 강화된 인플루언서 데이터용)
Related MCP server: Grips Intelligence MCP Server
Smithery를 통해 Claude Desktop용 Audiense Insights Server를 자동으로 설치하려면 다음을 수행합니다.
지엑스피1
Claude Desktop의 구성 파일을 엽니다.
맥OS:
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(문자열) : 청중 인사이트의 ID입니다.
insights(문자열 배열, 선택 사항) : 필터링할 특정 인사이트 이름 목록입니다.
응답 :
구조화된 텍스트 목록으로 구성된 통찰력입니다.
get-baselines설명 : 국가 별로 필터링하여 사용 가능한 기준 대상 고객을 검색합니다.
매개변수 :
country(문자열, 선택 사항) : 필터링할 ISO 국가 코드입니다.
응답 :
JSON 형식의 기준 대상자 목록입니다.
get-categories설명 : 인플루언서 비교에 사용할 수 있는 친화도 카테고리 목록을 검색합니다.
매개변수 : 없음
응답 :
JSON 형식의 카테고리 목록입니다.
compare-audience-influencers설명 : 특정 타겟층의 인플루 언서와 기준 타겟층을 비교합니다. 기준층은 다음과 같이 결정됩니다.
단일 국가가 전체 시청자의 50% 이상을 차지하는 경우, 해당 국가를 기준으로 사용합니다.
그렇지 않은 경우에는 글로벌 기준선이 사용됩니다.
특정 세그먼트를 선택하면 전체 대상이 기준으로 사용됩니다.
각 인플루언서 비교에는 다음이 포함됩니다.
친화도(%) – 인플루언서가 대중과 얼마나 잘 어울리는지.
기준 친화도(%) – 기준 청중 내에서 인플루언서의 친화도입니다.
고유성 점수 – 영향력 있는 사람이 기준선과 비교했을 때 얼마나 독특한가를 나타냅니다.
매개변수 :
audience_influencers_id(문자열) : 청중 인플루언서의 ID입니다.
baseline_audience_influencers_id(문자열) : 기준 청중 인플루언서의 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(문자열) : 청중 콘텐츠의 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 20API 자격 증명을 안전하게 보관하세요. 공개 저장소에 절대 노출하지 마세요.
민감한 데이터를 관리하려면 환경 변수를 사용하세요.
이 프로젝트는 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
