Skip to main content
Glama
alidade-ai

Alidade MCP

Official
by alidade-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Create a saved search

create_saved_search

Creates a workspace saved search with curated entity comparison groups, keyword or boolean filters, and date/platform scoping for reuse across other tools.

Instructions

Create a workspace saved search with manually curated comparison groups of entities (get entity IDs from find_entities). It appears in the app for all workspace members and can be used as savedSearchId in the other tools. Keyword filters accept either keywords/excludeKeywords or a booleanQuery — not both. Dynamic (rule-based) groups can only be created in the app.

Input Schema

NameRequiredDescriptionDefault
nameYesSaved search name.
groupsYesComparison groups (max 8). Analytics responses are keyed by group.
keywordsNoKeywords to filter post content by. Cannot be combined with `booleanQuery`.
dateRangeNoDate range filter. Omit or null = all time.
platformsNoPlatforms to include. Omit or empty = all platforms.
visibilityNoWorkspace visibility: `team_edit` (default — any workspace member can edit) or `team_view` (view-only for members; also not editable via the API afterwards).team_edit
descriptionNoOptional description.
booleanQueryNoBoolean keyword query matching the app's advanced search mode. 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. Cannot be combined with the keyword parameters.
keywordMatchNoWhether posts must match any (default) or all of `keywords`.
excludeKeywordsNoKeywords that matching posts must not contain (exact word/phrase match). Cannot be combined with `booleanQuery`.
keywordMatchTypeNoExact (default) matches the literal word or phrase; stemmed also matches English word variants (win/wins/winning).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare write/non-idempotent/non-destructive. The description adds real context beyond them: the search becomes visible to all workspace members and can be referenced as savedSearchId by other tools, plus the constraint that dynamic groups are app-only. It omits duplicate-name behavior and the irreversibility of team_view (which the schema carries, not the description).

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?

Four short sentences with the resource and scope front-loaded, followed by constraints. Minimal waste, though the mutual-exclusion sentence duplicates schema text and could be trimmed.

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

Completeness4/5

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

For an 11-parameter creation tool with no output schema, the description covers the highest-value unknowns: cross-tool reuse, workspace visibility, ID sourcing, and the app-only dynamic-group limitation. Remaining gaps (name collisions, failure modes) are modest.

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 description coverage is 100%, so all 11 parameters are already documented in detail, including the booleanQuery syntax and the mutual exclusions. The description only restates the 'not both' rule, so baseline 3 applies; no new syntax or format guidance is added.

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

Purpose4/5

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

States a specific verb+resource ('Create a workspace saved search') and immediately qualifies what the groups contain ('manually curated comparison groups of entities'). It distinguishes itself from siblings by pointing at find_entities for ID sourcing and by scope (workspace-wide, reusable as savedSearchId), though it never explicitly contrasts with update_saved_search.

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?

Gives actionable preconditions: get entity IDs from find_entities, keyword filters accept one of two modes, and dynamic/rule-based groups must be built in the app instead. It does not state when to choose this over update_saved_search or what to do if a similarly named search already exists.

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