Skip to main content
Glama
alidade-ai

Alidade MCP

Official
by alidade-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Search mentions

search_mentions
Read-only

Retrieve individual posts behind analytics numbers with Alidade content-analysis labels, filter by scope, labels, platforms, dates, and keywords, and paginate results as needed.

Instructions

The individual posts behind the analytics numbers, with Alidade's content-analysis labels attached, newest first by default. Takes the same scope parameters as get_analytics, plus optional label filters (policyIssue, policySubissue, productTheme, csrTheme, campaignTheme, brandPositioning, mentionedEntity) that take arrays of label values matching the labels in get_analytics breakdowns: any value within a filter matches, and all filters must match. Requires the mentions API tier, and every returned post counts against the workspace's monthly post quota — keep pageSize small (default 25) and only paginate when needed. Posts from platform x omit text and engagement metrics per X API terms (Alidade's identifiers and analysis labels are still included); the result lists their X post IDs for lookup with an X API tool.

Input Schema

NameRequiredDescriptionDefault
sortNoSort order by post date (default newest).
cursorNoOpaque pagination cursor from a previous response's `nextCursor`. Use the same query parameters across paged requests.
dateToNoOnly include posts published on or before this date (ISO 8601). A date-only value (`2026-01-31`) includes that whole day, UTC. Overrides the saved search's range end; its range start is kept unless `dateFrom` is also provided.
csrThemeNoOnly include posts labeled with this corporate social responsibility theme (`analysis.csrThemes`, or `/analytics/themes` with taxonomy `csr`). Several values match a post labeled with any of them. Only analyzed posts can match.
dateFromNoOnly include posts published on or after this date (ISO 8601). A date-only value (`2026-01-31`) means the start of that day, UTC. Overrides the saved search's range start; its range end is kept unless `dateTo` is also provided.
keywordsNoComma-separated keywords to filter post content by (e.g. `sustainability,net zero`). Replaces the saved search's keyword filters. Cannot be combined with `booleanQuery`.
pageSizeNoItems per page (max 100, default 25).
entityIdsNoComma-separated entity IDs (max 100) for an ad-hoc scope, treated as a single comparison group. Provide either this or `savedSearchId`.
platformsNoComma-separated platforms to include. Valid values: facebook, instagram, linkedin, x, youtube, tiktok, bluesky. Overrides the saved search's platform filter. Omit to use the saved search's platforms (or all platforms for an ad-hoc scope).
policyIssueNoOnly include posts labeled with this policy issue (the `issue` values from `analysis.policyIssues` and `/analytics/policy-issues`). Several values match a post labeled with any of them. Only analyzed posts can match.
booleanQueryNoBoolean keyword query matching the app's advanced search mode (e.g. `"net zero" AND (solar OR wind)`). Syntax: AND/OR/NOT (upper case), parentheses, quoted phrases with optional proximity ("health care"~3 = up to 3 words between, any phrase length, max 20), NEAR/N (either order) and THEN/N (ordered) between terms or groups, wildcards (elect*, wom?n), fuzzy (medicaid~1, max 2). Always use explicit operators between terms. Mixing AND or NOT with OR at the same depth is an error — parenthesize to make precedence explicit ((a AND b) OR c, (a OR b) NOT c). NEAR/THEN bind tighter than AND/OR — parenthesize a proximity expression that sits next to AND/OR ((a NEAR/5 b) OR c, (a OR b) NEAR/5 c). NOT is not allowed inside NEAR/THEN; exclude outside the proximity expression. Matching is exact-token, case- and accent-insensitive (no stemming) — cover word variants with OR or a wildcard (tariff OR tariffs, tariff*). Korean attaches particles to words, so put a trailing wildcard on each Korean term (검색*). Hindi is written in Devanagari and romanized, so OR both forms ((दोस्त OR dost)); Devanagari and Tamil matching ignores vowel signs, so expect some unrelated matches. Comments are ignored by search: // to the end of the line, <<< >>> inline or across lines. Full syntax: https://docs.alidade-ai.com/search-syntax. Replaces the saved search's keyword filters. Cannot be combined with the keyword parameters.
keywordMatchNoWhether posts must match `any` (default) or `all` of `keywords`.
productThemeNoOnly include posts labeled with this product messaging theme (`analysis.productThemes`, or `/analytics/themes` with taxonomy `product`). Several values match a post labeled with any of them. Only analyzed posts can match.
campaignThemeNoOnly include posts labeled with this political campaign theme (`analysis.campaignThemes`, or `/analytics/themes` with taxonomy `campaign`). Several values match a post labeled with any of them. Only analyzed posts can match.
savedSearchIdNoID of a saved search to scope the request to. Its comparison groups, platform filter, date range, and keyword filters all apply. Only entities your workspace can access are included; a saved search with none returns 422. Provide either this or `entityIds`.
policySubissueNoOnly include posts labeled with this policy sub-issue (the `subissue` values from `analysis.policyIssues`, or `subissues[].name` from `/analytics/policy-issues`). Several values match a post labeled with any of them. Only analyzed posts can match.
excludeKeywordsNoComma-separated keywords that matching posts must not contain (exact word/phrase match). Replaces the saved search's keyword filters. Cannot be combined with `booleanQuery`.
mentionedEntityNoOnly include posts that mention this entity, by Wikidata ID (e.g. `Q312`), as found in `analysis.mentionedEntities` or `analysis.mentionedPolicyEntities`. Several IDs match a post mentioning any of them. Only analyzed posts can match.
brandPositioningNoOnly include posts with a brand-positioning label in this category, either polarity (`analysis.brandPositioning`). Several values match a post labeled with any of them. Only analyzed posts can match.
keywordMatchTypeNo`exact` (default) matches the exact words or phrases only; `stemmed` also matches English word variants (run/running). Applies to `keywords`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly annotation, the description discloses quota consumption per returned post, API-tier requirements, default page size, pagination caution, and a platform-specific caveat that X posts omit text and engagement metrics while retaining identifiers and labels. These are exactly the behavioral details an agent needs before spending quota or interpreting results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but front-loaded with purpose and scope, then quota, filter semantics, and the X caveat. Every sentence carries operational information; however, the long parenthetical label list and nested caveats make it somewhat packed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 20-parameter, read-only search tool with no output schema, the description covers the key unknowns: quota cost, API tier, pagination behavior, filter conjunction semantics, default ordering, and platform-specific field omission with X post IDs provided for lookup. Nothing critical for correct invocation is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so the baseline is 3. The description earns above baseline by explaining how label filters combine: any value within a filter matches, and all filters must match. It also points to get_analytics for analogous scope parameters, but individual parameter formats remain in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific resource and scope: the individual posts behind analytics numbers, with content-analysis labels. It explicitly links and differentiates from get_analytics by describing mentions as the underlying posts, and the default ordering is stated. The only minor gap is that the sibling semantic_search_mentions is not named, but purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear operational guidance: requires the mentions API tier, consumes monthly post quota, keep pageSize small, paginate only when needed, and label filters match any value within a filter and all filters across filters. It does not explicitly compare against semantic_search_mentions, so the agent must infer when to use semantic search instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools