Related MCP server: Mailchimp Universal MCP Server
Stellen Sie vor der Verwendung dieses Servers sicher, dass Sie über Folgendes verfügen:
Node.js (v18 oder höher)
Claude Desktop App
Audiense Insights-Konto mit API-Anmeldeinformationen
X/Twitter API Bearer Token (optional, für angereicherte Influencer-Daten)
Öffnen Sie die Konfigurationsdatei für Claude Desktop:
MacOS:
code ~/Library/Application\ Support/Claude/claude_desktop_config.jsonWindows:
code %AppData%\Claude\claude_desktop_config.jsonFügen Sie die folgende Konfiguration hinzu oder aktualisieren Sie sie:
"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"
}
}
}
Speichern Sie die Datei und starten Sie Claude Desktop neu.
get-reportsBeschreibung : Ruft die Liste der Audiense Insights-Berichte ab, die dem authentifizierten Benutzer gehören.
Parameter : Keine
Antwort :
Liste der Berichte im JSON-Format.
get-report-infoBeschreibung : Ruft ausführliche Informationen zu einem bestimmten Geheimdienstbericht ab, darunter:
Status
Segmentierungstyp
Publikumsgröße
Segmente
Zugriffslinks
Parameter :
report_id(Zeichenfolge) : Die ID des Geheimdienstberichts.
Antwort :
Vollständige Berichtsdetails im JSON-Format.
Wenn der Bericht noch verarbeitet wird, wird eine Meldung zurückgegeben, die den ausstehenden Status angibt.
get-audience-insightsBeschreibung : Ruft aggregierte Erkenntnisse für eine bestimmte Zielgruppe ab, darunter:
Demografie : Geschlecht, Alter, Land.
Verhaltensmerkmale : Aktive Stunden, Plattformnutzung.
Psychografik : Persönlichkeitsmerkmale, Interessen.
Sozioökonomische Faktoren : Einkommen, Bildungsstatus.
Parameter :
audience_insights_id(Zeichenfolge) : Die ID der Zielgruppen-Insights.
insights(Zeichenfolgen-Array, optional) : Liste mit bestimmten zu filternden Insight-Namen.
Antwort :
Erkenntnisse als strukturierte Textliste formatiert.
get-baselinesBeschreibung : Ruft verfügbare Basiszielgruppen ab, optional gefiltert nach Land .
Parameter :
country(Zeichenfolge, optional) : ISO-Ländercode, nach dem gefiltert werden soll.
Antwort :
Liste der Basiszielgruppen im JSON-Format.
get-categoriesBeschreibung : Ruft die Liste der verfügbaren Affinitätskategorien ab, die in Influencer-Vergleichen verwendet werden können.
Parameter : Keine
Antwort :
Liste der Kategorien im JSON-Format.
compare-audience-influencersBeschreibung : Vergleicht Influencer einer bestimmten Zielgruppe mit einer Basiszielgruppe . Die Basiszielgruppe wird wie folgt ermittelt:
Wenn ein einzelnes Land mehr als 50 % des Publikums repräsentiert, wird dieses Land als Basis verwendet.
Andernfalls wird die globale Basislinie verwendet.
Wenn ein bestimmtes Segment ausgewählt wird, wird die gesamte Zielgruppe als Basis verwendet.
Jeder Influencer-Vergleich beinhaltet:
Affinität (%) – Wie gut der Influencer zum Publikum passt.
Basisaffinität (%) – Die Affinität des Influencers innerhalb des Basispublikums.
Einzigartigkeitswert – Wie deutlich sich der Influencer vom Ausgangswert abhebt.
Parameter :
audience_influencers_id(Zeichenfolge) : ID der Zielgruppen-Influencer.
baseline_audience_influencers_id(Zeichenfolge) : ID der Influencer des Baseline-Publikums.
cursor(Zahl, optional) : Seitencursor.
count(Zahl, optional) : Anzahl der Elemente pro Seite (Standard: 200).
bio_keyword(Zeichenfolge, optional) : Filtern Sie Influencer nach Bio-Schlüsselwort .
entity_type(Aufzählung: person | brand , optional) : Filtern nach Entitätstyp.
followers_min(Zahl, optional) : Mindestanzahl an Followern.
followers_max(Zahl, optional) : Maximale Anzahl an Followern.
categories(Zeichenfolgen-Array, optional) : Filtern Sie Influencer nach Kategorien .
countries(Zeichenfolgen-Array, optional) : Filtern Sie Influencer nach ISO-Ländercodes .
Antwort :
Liste der Influencer mit Affinitätsbewertungen, Basisvergleich und Eindeutigkeitsbewertungen im JSON-Format.
get-audience-contentBeschreibung : Ruft Details zur Inhaltsinteraktion des Publikums ab, darunter:
Beliebte Inhalte : Beliebteste Beiträge, Domänen, Emojis, Hashtags, Links, Medien und eine Wortwolke.
Freigegebener Inhalt : Die meisten freigegebenen Inhalte sind ähnlich kategorisiert.
Einflussreicher Inhalt : Inhalt von einflussreichen Konten.
Jede Kategorie enthält:
popularPost : Beiträge mit den meisten Interaktionen.
topDomains : Am häufigsten erwähnte Domänen.
topEmojis : Am häufigsten verwendete Emojis.
topHashtags : Am häufigsten verwendete Hashtags.
topLinks : Am häufigsten geteilte Links.
topMedia : Gemeinsam genutzte Medien.
wordcloud : Am häufigsten verwendete Wörter.
Parameter :
audience_content_id(Zeichenfolge) : Die ID des Zielgruppeninhalts.
Antwort :
Daten zur Inhaltsinteraktion im JSON-Format.
report-summaryBeschreibung : Generiert eine umfassende Zusammenfassung eines Audiense-Berichts, einschließlich:
Berichtsmetadaten (Titel, Segmentierungstyp)
Gesamte Zuschauerzahl
Detaillierte Segmentinformationen
Top-Erkenntnisse für jedes Segment (Bio-Schlüsselwörter, demografische Merkmale, Interessen)
Top-Influencer für jedes Segment mit Vergleichsmetriken
Parameter :
report_id(Zeichenfolge) : Die ID des zusammenzufassenden Geheimdienstberichts.
Antwort :
Vollständige Berichtszusammenfassung im JSON-Format mit strukturierten Daten für jedes Segment
Für ausstehende Berichte: Statusmeldung, die angibt, dass der Bericht noch verarbeitet wird
Für Berichte ohne Segmente: Meldung, dass keine Segmente zur Analyse vorhanden sind
Dieser Server enthält vorkonfigurierte Eingabeaufforderungen
audiense-demo : Hilft bei der interaktiven Analyse von Audiense-Berichten.
segment-matching : Eine Aufforderung zum Abgleichen und Vergleichen von Zielgruppensegmenten in Audiense-Berichten, um Ähnlichkeiten, einzigartige Merkmale und wichtige Erkenntnisse basierend auf demografischen Merkmalen, Interessen, Influencern und Engagement-Mustern zu identifizieren.
Verwendung:
Akzeptiert ein ReportName-Argument, um den relevantesten Bericht zu finden.
Wenn eine ID angegeben ist, wird stattdessen nach der Berichts-ID gesucht.
Anwendungsfall: Strukturierte Anleitung zur Zielgruppenanalyse.
Überprüfen Sie die Protokolle von Claude Desktop:
tail -f ~/Library/Logs/Claude/mcp*.logÜberprüfen Sie, ob die Umgebungsvariablen richtig eingestellt sind.
Stellen Sie sicher, dass der absolute Pfad zu index.js korrekt ist.
Überprüfen Sie die OAuth-Anmeldeinformationen doppelt.
Stellen Sie sicher, dass das Aktualisierungstoken noch gültig ist.
Überprüfen Sie, ob die erforderlichen API-Bereiche aktiviert sind.
So überprüfen Sie die Serverprotokolle:
tail -n 20 -f ~/Library/Logs/Claude/mcp*.logGet-Content -Path "$env:AppData\Claude\Logs\mcp*.log" -Wait -Tail 20Bewahren Sie API-Anmeldeinformationen sicher auf – geben Sie sie niemals in öffentlichen Repositories preis.
Verwenden Sie Umgebungsvariablen, um vertrauliche Daten zu verwalten.
Dieses Projekt ist unter der Apache 2.0-Lizenz lizenziert. Weitere Informationen finden Sie in der Lizenzdatei.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get-categories1 field changedInput schema / additionalPropertiesRemoved value: -falseget-reports1 field changedInput schema / additionalPropertiesRemoved value: -falsecompare-audience-influencersget-audience-contentget-audience-insightsget-baselinesget-categoriesget-report-infoget-reportsreport-summaryScored across 8 tools
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.
Minds is a synthetic market research platform. This MCP server lets ChatGPT, Claude, and Cursor build Audiences from a brief, run durable Studies and Question Blocks, compare segments, and export results. OAuth 2.1 or Minds API key.
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
Ask live marketing data anything to get verified answers, client-ready reports, and next steps.
