Skip to main content
Glama
alidade-ai

Alidade MCP

Official
by alidade-ai

Semantic search mentions

semantic_search_mentions
Read-only

Find posts by meaning: embeds a natural-language query and returns the most semantically similar posts first. Scope by saved search, entities, platforms, and dates for vector-based discovery.

Instructions

Find posts by meaning: embeds a natural-language query and returns the most similar posts (pure vector similarity, no keyword matching), most relevant first. Results carry the post text, metrics, and entity but not the content-analysis labels — use search_mentions for chronological listings, keyword filters, or labels. Scope with savedSearchId or entityIds like the other tools — a saved search's groups, platforms, and date range apply, but its keyword filters do not (fold important terms into query). Requires the mentions API tier, and every returned post counts against the workspace's monthly post quota — keep limit small (default 15). Posts from platform x omit text and engagement metrics per X API terms; the result lists their X post IDs for lookup with an X API tool.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of posts to return (max 100, default 15).
queryYesWhat to look for, in natural language (e.g. `criticism of the new pricing model`). Matching is by meaning, not keywords, so a descriptive phrase or sentence works better than a bare term.
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.
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.
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).
savedSearchIdNoID of a saved search to scope the search to. Its comparison groups, platform filter, and date range apply; its keyword filters do not (fold important terms into `query`). A saved search with no entities your workspace can access returns 422. Provide either this or `entityIds`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses critical operational traits: results are sorted most-relevant-first, returned posts omit content-analysis labels, the mentions API tier is required, every returned post counts against the monthly quota, and X platform posts omit text and metrics but include X post IDs. These details materially affect how an agent should invoke the tool.

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

Conciseness5/5

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

Despite covering many caveats, the description is front-loaded with purpose, then alternatives, scoping, quota, and platform caveats in a logical order. Every sentence carries actionable information with no filler.

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?

With no output schema, the description explains what results contain (post text, metrics, entity), ordering, and what is omitted for X posts. Combined with annotations, it gives an agent everything needed to call the tool correctly, including quota and API-tier prerequisites.

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

Parameters3/5

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

Schema coverage is 100%, and the schema already documents limit defaults, query semantics, date overrides, platform values, and savedSearchId keyword behavior. The description reinforces a few of these (keep limit small due quota, fold keywords into query) but adds little parameter-level meaning beyond the schema itself, so baseline 3 applies.

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 names a specific verb and resource ('Find posts by meaning'), explains the mechanism (pure vector similarity, no keyword matching), and explicitly distinguishes itself from the sibling search_mentions. An agent can tell immediately what this tool does and how it differs from keyword-based alternatives.

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

Usage Guidelines5/5

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

It explicitly routes the agent: use search_mentions for chronological listings, keyword filters, or labels. It also explains how to scope with savedSearchId or entityIds and warns that saved-search keyword filters do not apply, instructing the agent to fold important terms into query instead. Usage conditions and alternatives are fully covered.

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