AirOps

Create or update a usage rule for a Brand Kit. Omit `id` to create a new usage rule; provide `id` to update an existing one. On update, only provided fields are changed. `applies_to` is set on creation and cannot be changed. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a competitor for a Brand Kit. Omit `id` to create a new competitor; provide `id` to update an existing one. On update, only provided fields are changed. Competitors must be associated with at least one product line from the same brand kit. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a visual example for a Brand Kit's Data Visualization section. Omit `id` to create a new visual example; provide `id` to update an existing one. On update, only provided fields are changed. Visual examples must be grouped under a Visual Use Case — pass `visual_use_case_id` on create. Use `manage_brand_kit_visual_use_case` first if no use case exists yet. To attach an image, either: - Use `signed_id` with the token from create_brand_kit_direct_upload after direct upload (preferred). - Use `file_url` with a publicly accessible URL to an image. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a Visual Use Case for a Brand Kit. A Visual Use Case is a named grouping of visual examples that share a common set of instructions for when and how to apply them (e.g., "Hero sections", "Social posts", "Email headers"). Omit `id` to create a new visual use case; provide `id` to update an existing one. On update, only provided fields are changed. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a writing rule for a Brand Kit. Omit `id` to create a new rule; provide `id` to update an existing one. Scoping: A rule can optionally be scoped to exactly one dimension — a single content type, audience, OR region. Provide at most one of `content_type_id`, `audience_id`, or `region_id` on create. They are mutually exclusive. A rule with no scoping is global (applies everywhere). Scoping is immutable: it is set on create only. On update, only `text` can be changed. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Delete one or more writing rules from a Brand Kit. This edits the Brand Kit draft version only; it does not change the active (live) version. A failure deleting one rule does not block or roll back the others: the response reports which rules were deleted and which could not be. IMPORTANT: Always show the user exactly which writing rules will be deleted and ask for confirmation before calling this tool.

Create or update an audience for a Brand Kit draft. Omit `id` to create a new audience; provide `id` to update an existing one. On update, only provided fields are changed. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Create or update a region for a Brand Kit. Omit `id` to create a new region; provide `id` to update an existing one. On update, only provided fields are changed. This tool edits the Brand Kit draft version only; it does not change the active (live) version. IMPORTANT: Always show the user exactly which fields will be created or changed and ask for confirmation before calling this tool.

Record a recap entry summarizing the changes you made to a Brand Kit. Call this once, near the end of a session that mutated the Brand Kit — not for every edit. Put the evidence behind the changes in `body_markdown`: verbatim quotes, source URLs, and pages. Example: create_brand_kit_recap_entry( brand_kit_id: 123, title: "Refreshed tone & voice and added 2 regions", body_markdown: "Made the tone more concise per the latest brand guidelines (https://acme.com/brand). Added US East and US West to support the Q3 launch." )

List all Brand Kits the user has access to. Returns `brand_management_enabled` and `aeo_enabled` flags for each brand kit. Use `get_brand_kit` for brand management details, or `get_insights_settings` for AEO configuration. Optionally filter by workspace_name, workspace_id, brand_management_enabled, or aeo_enabled. IMPORTANT: If multiple brand kits are returned and the user has not specified which one to use, present the list and ask them to confirm. Do NOT arbitrarily pick one.

Fetch a Brand Kit's brand identity (writing_tone, writing_persona) and associated entities (product lines, audiences, content types, regions, writing rules, custom variables, visual/design assets). Call AFTER `list_brand_kits` confirms `brand_management_enabled: true`. # Decision flow 1. Specific entity by ID → `includes=["<type>"]`, `filters=[{field: "<type>.id", operator: "EQ", value: <id>}]`. 2. Entity by name (product_lines, content_types, audiences, regions, custom_variables, visual_examples) → `filters=[{field: "<type>.name", operator: "CONTAINS", value: "<fragment>"}]`. 3. Find text content ("rule about tone", "any mention of Red List") → filter by the text field: `filters=[{field: "writing_rules.text", operator: "CONTAINS", value: "tone"}]`. 4. Structural discovery → small `includes` with `fields=["<type>.id","<type>.name"]` only. # Scale (typical kit vs outliers) Most kits are small — these rarely need filtering: - audiences, regions, usage_rules, palettes, content_samples: usually 0-2, rarely >10 - content_types, product_lines: usually 1-3 These have tails you must handle: - writing_rules: usually 3, outliers exceed 200. Never include in full without a filter — filter by text (CONTAINS) or by id. - competitors: usually 10, outliers exceed 250. Include via product_lines.competitors only when needed, and consider a name filter. - custom_variables: outliers exceed 150. Filter by name (CONTAINS) for known variables (e.g. "Red List"), or by value (CONTAINS) for content. - Scoped writing_rules via audience/region/content_type nesting: outliers exceed 200. Filter the parent by id or name first. # Writing rules — global vs scoped Writing rules are EITHER global OR scoped to a single audience/content_type/region (never both). For content targeting a specific audience/region/content_type, fetch BOTH: 1. Top-level `writing_rules` include → global rules. 2. Nested writing_rules on the scoping parent → scoped rules. Merge client-side. # Anti-patterns - `includes=["writing_rules","custom_variables","product_lines.competitors", "content_types.writing_rules"]` without filters → blows context on outlier kits. - Calling without `fields` on a large kit → returns full text (template_outline, rule text, ICP) for every row. - Forgetting filters on `writing_rules`, `custom_variables`, or `competitors` — those are the three biggest tails. # Versioning `version: "draft"` reads pending edits; defaults to `"active"`. Use active for on-brand output unless the user explicitly asks for draft.

Initiate a direct file upload for use with Brand Kit visual tools. This returns an upload URL (pointing directly to the storage service), upload headers, and a signed_id. The workflow is: 1. Call this tool with the Brand Kit ID and file metadata (filename, content_type, byte_size, checksum). The checksum must be the Base64-encoded MD5 digest of the file contents. 2. Upload the file to the returned `upload_url` using an HTTP PUT with **all** the provided `upload_headers`. No additional authentication is needed — the URL is a time-limited presigned URL. Example: curl -X PUT -H "Content-Type: <type>" -H "Content-MD5: <checksum>" --upload-file <path> "<upload_url>" 3. Pass the returned `signed_id` to a manage tool (e.g. manage_brand_kit_logo_variant, manage_brand_kit_visual_example, or manage_brand_kit_font). IMPORTANT: Always confirm with the user before initiating an upload.

Get AEO insights configuration for a Brand Kit, this includes the relevant information to use any AEO and analytics tools. Returns competitors, personas, prompt count, and other relevant information. Use `list_brand_kits` first to find Brand Kits with `aeo_enabled: true`.

Publish a Brand Kit's current draft so changes become active. This promotes the current draft to active and creates a fresh draft from it. IMPORTANT: Always confirm with the user before publishing.

Step 2 of the two-step file ingestion flow for a Knowledge Base. Consumes a `signed_id` returned by `knowledge_base_create_direct_upload` (step 1) plus the file's metadata, and registers the document with the Knowledge Base. Returns immediately with the new `document_id` in `pending` status — poll `knowledge_base_get_status` to monitor indexing. Workflow: 1. Call `knowledge_base_create_direct_upload` with the file metadata to get back a `signed_id` and a presigned `upload_url`. 2. PUT the file bytes to the `upload_url` with the provided headers. 3. Call this tool with the `signed_id`, the desired `name` (used as the document's display name), the `document_type` MIME (must match the supported types), and an optional `metadata` hash. The `metadata` hash, if provided, is a single-level key/value object. It **replaces** any existing metadata on the document (no merge) and is filterable at search time via `search_knowledge_base`.

Bulk-ingest one or more web pages into a Knowledge Base. Each URL becomes a separate document that fetches and indexes asynchronously. The call returns immediately with the new document IDs in `pending` state — poll `knowledge_base_get_status` to check progress. URLs must be absolute and include the `http://` or `https://` scheme (e.g. `https://example.com/page`). No documents are created if any URL fails validation. The `metadata` hash, if provided, is applied identically to every document in the batch (single-level keys only); it replaces (not merges) any existing metadata and is filterable at search time.

Initiate a direct file upload for a Knowledge Base. Returns a presigned S3 upload URL, the required upload headers, and a `signed_id` you'll use with `knowledge_base_add_file` to register the document. This is the first call in the two-step file ingestion flow — large files (PDFs, DOCX, MD, HTML, etc.) don't fit through the MCP transport, so the file bytes go directly from your client to S3. Workflow: 1. Call this tool with the file metadata (filename, content_type, byte_size, checksum). The checksum must be the Base64-encoded MD5 digest of the file contents. 2. PUT the raw file bytes to the returned `upload_url` with **all** the provided `upload_headers`. No additional authentication is needed — the URL is a time-limited presigned URL. 3. Pass the returned `signed_id` to `knowledge_base_add_file` to register the document. Only after step 3 is the file searchable. Example: > knowledge_base_create_direct_upload(knowledge_base_id: 1, filename: "report.pdf", content_type: "application/pdf", byte_size: 1234567, checksum: "...") # → { signed_id: "abc...", upload_url: "https://s3...", upload_headers: { ... } } > knowledge_base_add_file(knowledge_base_id: 1, signed_id: "abc...", name: "Q4 Report", document_type: "application/pdf") # → { document_ids: [42], status: "pending" } Maximum file size is 256 MB.

Permanently delete a single document from a Knowledge Base. This action cannot be undone. IMPORTANT: Always warn the user that deletion is permanent and ask for explicit confirmation before calling this tool.

Read the full reconstructed text content of a Knowledge Base document end-to-end — the loader-extracted text from every chunk concatenated in `position` order. Use when chunked search results aren't enough: summarizing a whole document, answering questions across an entire report, or reading back a doc before delete-and-recreate. For finding specific passages, prefer `search_knowledge_base`. Returns up to `max_chars` characters starting at `offset` (defaults to 0 and 200000). When the document is larger than the slice, the response includes `next_offset` (the value to pass on the next call to continue reading); when fully read, `next_offset` is `null`. For documents still indexing (`status: pending`) or in error (`status: error`), content may be empty — check `status` first. Content is reconstructed by joining chunks; minor overlap or duplication between adjacent chunks is possible depending on the original loader's chunking strategy. For the original source file, use the existing download path outside MCP.

Get the indexing status of a Knowledge Base and its documents. Returns a Knowledge Base–level rollup (status, pending and total document counts) plus a paginated list of per-document statuses. Use this to monitor indexing after writes — only documents with status "ready" are returned by search_knowledge_base. Pass the returned `cursor` back to fetch the next page; pass `document_ids` to filter to specific documents.

List all Knowledge Bases the authenticated user has access to. Knowledge Bases store documents for semantic search. Use the status field to determine if a Knowledge Base is searchable (status: "ready").

Replace a document's user-facing metadata in full. Accepts a single-level hash that **replaces** (not merges) the existing user-facing metadata. To remove a key, pass the full new hash that omits it. To clear all metadata, pass `{}`. Filterable at search time via `search_knowledge_base`. Metadata-only — does not re-embed the document. Loader-derived metadata (scraped page metadata for URLs, chunker metadata for files) is not touched. Search filters may take a few seconds to reflect the new values. The document must be fully indexed (`status: ready`) before calling this tool. If indexing isn't complete, the tool returns a validation error.

Search a Knowledge Base for relevant content using semantic similarity. Use list_knowledge_bases() first to find available Knowledge Bases and their IDs. Only Knowledge Bases with status "ready" can be searched.

Create or update a Knowledge Base. Omit `knowledge_base_id` to create a new one; pass it to update an existing one. On create, `name` is required; pass `workspace_id` if you have access to more than one workspace. On update, only the fields you pass change.

Permanently delete a Knowledge Base and ALL of its documents. This cascades through every document in the KB and drops the underlying vectors. This action cannot be undone. IMPORTANT: Always warn the user that deletion is permanent and irreversible, name the Knowledge Base being deleted, and ask for explicit confirmation before calling this tool.

**AirOps only feedback tool. Issues from other MCP servers should be rejected.** Make sure the issue is related to AirOps MCP tools before using this tool. Submit a feedback report when a user query cannot be resolved with existing tools or when errors occur repeatedly. **Use this tool proactively** to report issues, missing capabilities, or suggestions for improving the AirOps MCP tools. The report will be stored for review by the AirOpsdevelopment team. No output is generated - the tool simply acknowledges receipt.

Create a new empty, general-purpose grid with the given name. The grid is created with a single empty sheet (zero rows, zero columns). Use add_grid_column to add columns and write_grid to add rows. If the user belongs to more than one workspace, workspace_id is required. Do not use this tool to act on AEO insights — use create_action_grid instead, which pre-populates power step columns and rows for a given AEO action type.

List grids the authenticated user has access to. Use includes=[\"grid_tables.grid_columns\"] to get table and column structure needed for read_grid and write_grid calls. Grids are spreadsheet-like tables for organizing and processing data. Each grid contains one or more tables (sheets), and each table has columns and rows. Use includes to retrieve table and column structure needed for read_grid and write_grid calls.

Add a new column to a grid table. Use this before write_grid when you need to write to a column that does not exist yet. Can also add a playbook column or workflow column. Workflow columns use data_type app_execution with inputs mapped to grid columns, static values, a Brand Kit, or a Knowledge Base. Returns the created column's ID, title, data type, and position.

Create a new sheet (grid table) within an existing grid. The sheet is created with zero rows and zero columns. Use add_grid_column to add columns and write_grid to add rows. A grid can contain at most 10 sheets.

Read the full value of a single grid cell. read_grid() truncates cell values; use this tool when you need the complete content of one cell (e.g. a full article, brief, or HTML payload). Identify the cell via the row __id and column id returned by read_grid().

Read rows from a grid table. Returns rows as objects with column titles as keys. Use list_grids() to discover available grids and their table/column structure. Supports filtering by column values, selecting specific columns, and pagination. Returns up to 100 rows per page (default 50). Cell values are truncated to 500 characters by default (configurable up to 2000 via the truncate parameter); truncated values end with a marker showing their full length. Use read_grid_cell() to fetch the complete value of a specific cell.

Create or update rows in a grid table. When mode is 'create', rows are added as new rows with column titles as keys. When mode is 'update', each row must include a '__id' key with the row ID to update. To update a single cell, pass a single-element array with the row ID and the column to change. Maximum 1000 rows per operation.

List all workspaces the authenticated user has access to. Workspaces are the top-level container for all resources in the AirOps platform. A user can have multiple workspaces, and each workspace can have multiple resources like Brand Kits, Pages, Prompts, etc.

List web pages with daily metrics (AEO citations, GSC clicks/impressions, GA4 traffic, and configured GA4 key events) for a brand kit. Supports filtering by metrics and text fields, sorting, and pagination.Web page metrics are the daily metrics of citations, clicks, impressions, traffic, and configured GA4 key events for a specific web page.

Get prompts citing a specific web page. Returns AI prompts that cite the page along with citation metrics (citation_rate, mention_rate) and trends. Use includes: ["topic"] to get topic details for each prompt.Prompts are the questions that can be asked about a brand or web page. They are the search queries that are used to get AI answers with citations and mentions.

List campaigns the authenticated user has access to. Use get_campaign to retrieve action grid IDs and custom instructions for a campaign. Campaigns are Plays that coordinate strategy playbooks, action grids, and related opportunities for improving AEO performance.

Get a campaign by ID, including action grid IDs needed to inspect or update its grid. Campaigns are Plays that coordinate strategy playbooks, action grids, and related opportunities for improving AEO performance.

Accept pending opportunities for a campaign and add their resources to the campaign action grid. Before calling this tool, summarize the opportunities or opportunity items that will be accepted and get explicit user confirmation.

Create a pending opportunity for a campaign. Before calling this tool, summarize the proposed opportunity name, description, and target resources for the user, then get explicit confirmation. In Quill or other OAuth MCP clients, provide play_id from list_campaigns or get_campaign. In playbook sessions, play_id is optional and is derived from the current session.

Reject pending opportunities for a campaign. Before calling this tool, summarize the opportunities or opportunity items that will be rejected and get explicit user confirmation.

List opportunities for a campaign, including their matching opportunity items. Use this before accepting or rejecting opportunities so you can reference the opportunity and opportunity item IDs.

Get AEO metrics for a specific web page. Page details include citation share, citation rate, unique cited questions count, and Google Search Console metrics (clicks, impressions, position, CTR) with trends.

Get AI answers for a specific prompt/question. Prompt answers are the AI answers for a specific question/prompt asked to multiple AI providers and the answers are aggregated. The answers include whether the brand was mentioned and cited in the answer. To get full answer text, citations, and mentions, use the get_answer tool with the answer ID.

List AI answers for a brand kit with filters for date range, providers, countries, prompt_id, and brand_mentioned. Individual AI answers with their cited URLs and brand/competitor mentions.

Get a specific AI answer by ID with full text content. Get a single AI answer with full details. Use this to retrieve the complete answer text (not truncated), citations, and mentions. Use includes parameter to get citations, mentions, and persona details.

Create a new AEO topic on a Brand Kit. Topics are categories used to group AEO prompts. Behavior: - `name` must be unique within the Brand Kit. - `color` is optional. If omitted, a color is auto-assigned from the platform palette. Valid colors: light_grey, grey, green, teal, blue, purple, lilac, pink, red, coral, orange. - This tool does NOT create or assign prompts. Use `create_aeo_prompt` with the returned topic ID to add prompts to the topic. IMPORTANT: Always show the user the topic you plan to create (name and color) and get explicit confirmation before calling. You can verify the topic was created by calling `list_topics` filtered by name.

Update an existing AEO topic's name and/or color on a Brand Kit. Behavior: - At least one of `name` or `color` must be provided. - If `name` is provided, it must remain unique within the Brand Kit. - Valid colors: light_grey, grey, green, teal, blue, purple, lilac, pink, red, coral, orange. - Existing prompt assignments are preserved. This tool cannot move a topic to another Brand Kit. IMPORTANT: Always show the user the topic (current name) and the change you plan to apply, and get explicit confirmation before calling. You can verify the change by calling `list_topics`.

Delete an AEO topic from a Brand Kit. Behavior: - This is a HARD delete. The topic is removed from the Brand Kit entirely. - Deletion is blocked when the topic has associated prompts. Use `list_aeo_prompts` filtered by `topic_id` to inspect prompts before deleting. - Candidate questions and question recommendations for the topic are deleted by model associations when the topic is deleted. IMPORTANT: This action is destructive and cannot be undone via this tool. Always show the user the topic name and associated prompt count, then get explicit confirmation before calling.

List topics for a specific Brand Kit. Topics are the categories of questions that can be asked about a Brand Kit. They are used to group questions together and to create a taxonomy of questions.

Create a new AEO persona on a Brand Kit. Personas represent the characters used to simulate AI-search queries when measuring AI visibility, citations, and mentions. Behavior: - `title` must be unique within the Brand Kit (max 200 chars) and `description` is required (max 5000 chars). - Optional `add_to_all_prompts` (default `false`): when `true`, the new persona is also assigned to every existing live prompt in the Brand Kit. This may incur additional answer credits/month; if the workspace's estimated answers limit would be exceeded, the call is rejected with a `validation_error` containing `estimated_answers` and `max_answers` in `details`. Defaults to `false` so the agent does not silently incur credits. Writing guidance: avoid including specific brand names in the persona's title or description — the LLM may then mention the brand in its answer, which the analyzer will count as a mention and skew the data. IMPORTANT: Always show the user the persona you plan to create (title, description, and whether `add_to_all_prompts` is on) and get explicit confirmation before calling. You can verify the persona was created by calling `list_personas` sorted by `created_at` descending.

List personas for a specific Brand Kit. Personas are the characters that can be used to ask questions about a brand. They are used to get AI answers with citations and mentions.

Apply a single tag operation (add or remove) to a batch of AEO prompts in one Brand Kit, atomically. Operations: - `add` — adds the supplied tag_ids to each prompt's existing tags. Duplicates are silently deduped. - `remove` — removes the supplied tag_ids from each prompt. Tags not currently on a prompt are silently no-oped. Specifying tags: - Pass `tag_ids` (use `list_tags` to discover them). - Tags must already exist on the Brand Kit. This tool does NOT create new tags. Atomicity: - The call is fully atomic. If ANY supplied `prompt_id` is missing/discarded/ cross-brand-kit, or ANY `tag_id` is unknown on the Brand Kit, the call is refused with a `validation_error` listing every problem, and no taggings are changed. - On success, all listed prompts receive the operation in a single DB transaction. Limits: - Up to 100 `prompt_ids` per call. IMPORTANT: Always show the user the prompts and tags you plan to operate on, and get explicit confirmation before calling.

Add a region (ISO alpha-2 country code) to a Brand Kit's configured AEO regions. Why this tool exists: AEO prompts and prompt-assignments can only reference regions that are configured on the Brand Kit. When `create_aeo_prompt` or `update_aeo_prompt_assignments` returns a `validation_error` mentioning that the country code is "not configured on this brand kit", call this tool to add the missing region first, then retry. Behavior: - Re-adding an already-configured region is a no-op (idempotent) and returns success. - The country code must be a valid ISO 3166-1 alpha-2 code supported by the platform (e.g. US, GB, DE, FR, JP, BR, IN, ...). - Optional `add_to_all_prompts` (default `false`): when `true`, the new region is also assigned to every existing live prompt in the Brand Kit. This may incur additional answer credits/month; if the workspace's estimated answers limit would be exceeded, the call is rejected with a `validation_error` containing `estimated_answers` and `max_answers` in `details`. Defaults to `false` so the agent does not silently incur credits. IMPORTANT: Always show the user the region you plan to add (and whether `add_to_all_prompts` is on) and get explicit confirmation before calling. Adding a region cannot be undone via this tool.

Create a new AEO prompt for a Brand Kit. Prompts are questions that can be asked about a brand to AI search engines, used to track AI visibility and citations. After creation, background jobs automatically analyze the prompt on search engines, extract keywords, and compute volume metrics. You can optionally assign countries, personas, and platforms to the prompt at creation time. The workspace's estimated answers limit is enforced — if the assignments would push the workspace over its quota, creation is rejected. IMPORTANT: Always show the user exactly which fields you plan to use (text, topic_id, and any assignments) and ask for their confirmation before calling this tool. User confirmation is mandatory. You can verify the prompt was created by calling `list_aeo_prompts` sorted by `created_at` descending. A topic_id is required. If the user hasn't specified a topic, use the `list_topics` tool first to discover available topics and either suggest one or ask the user to choose.

List AEO prompts for a specific Brand Kit. Questions are the AI prompts that can be asked about a brand. They are used to get AI answers with citations and mentions.

List page content updates for a workspace. Track content updates.

Get a specific page content update by ID. Its change_detection object carries the detection status and categories, plus a nested changes array (the before/after diff) on this single-update fetch. Track content updates.

Track a page content update (publish/refresh) to correlate future analytics with content changes. Call this tool after a page is published or refreshed through a CMS (e.g. WordPress, Webflow, Contentful) or any MCP server that modifies page content. This lets AirOps correlate page performance metrics — AI visibility, citations, mentions — with specific content updates over time. The URL must match a domain configured in one of the workspace's Brand Kits. If no matching Brand Kit domain is found, the content update cannot be created. If the URL matches multiple Brand Kits (for example regional variants sharing a domain), a content update is created for each, routed by the most specific brand_url path (e.g. "https://example.com/es/post" maps to the Brand Kit whose brand_url is "https://example.com/es/"). IMPORTANT: Always show the user exactly which fields you plan to use (url, type, source) and ask for their confirmation before calling this tool. User confirmation is mandatory.

List domains cited in AI answers for a Brand Kit. Cited domains aggregated by domain with citation metrics. Shows which domains are being cited in AI answers for a Brand Kit.

Get prompts citing a specific URL. The 'id' parameter is the URL to look up.

List citations (URLs) with metrics for a Brand Kit. Citations (URLs) with detailed metrics including influence score. Shows individual URLs being cited in AI answers with page-level context.

Create a grid pre-wired with power steps to take action on AEO insights. This is the ONLY supported way to run power steps from MCP: each action_type maps to a specific set of power step columns (e.g. content optimization, citation outreach, question answering) that are auto-configured on the grid and ready to execute against the rows you provide. Use this whenever the user wants to act on AEO data — citations, questions, page opportunities, etc. — for a specific brand kit; pass the AEO records as `rows` and the matching `action_type`. Do NOT use create_grid + add_grid_column to assemble a power step grid by hand; that path will not produce a working power step setup. Use create_grid only for empty, general-purpose grids unrelated to AEO.

Get individual AI answers with sentiment details for a specific theme. Returns answer text, sentiment (positive/neutral/negative), confidence score, and provider. Use this to understand WHY a theme has a particular sentiment score. Today's data is still being processed — always use yesterday (2026-07-03) or earlier as end_date.

Create a new AEO tag on a Brand Kit. Tags are user-defined labels that can be applied to prompts via `bulk_update_aeo_prompt_tags`. Behavior: - `name` must be unique within the Brand Kit (case-insensitive). The model enforces this via a unique index on (brand_kit_id, lower(name)). - `color` is optional. If omitted, a color is auto-assigned from the platform palette. Valid colors: light_grey, grey, green, teal, blue, purple, lilac, pink, red, coral, orange. - This tool does NOT apply the new tag to any prompts. Use `bulk_update_aeo_prompt_tags` with `operation: 'add'` to assign it afterward. IMPORTANT: Always show the user the tag you plan to create (name and color) and get explicit confirmation before calling. You can verify the tag was created by calling `list_tags` filtered by name.

Update an existing AEO tag's name and/or color on a Brand Kit. Behavior: - At least one of `name` or `color` must be provided. - If `name` is provided, it must remain unique within the Brand Kit (case-insensitive). - Valid colors: light_grey, grey, green, teal, blue, purple, lilac, pink, red, coral, orange. - Existing taggings on prompts are preserved — only the tag's own attributes change. IMPORTANT: Always show the user the tag (current name) and the change you plan to apply, and get explicit confirmation before calling. You can verify the change by calling `list_tags`.

Delete an AEO tag from a Brand Kit. Behavior: - This is a HARD delete. The tag is removed from the Brand Kit entirely. - All taggings on prompts that referenced this tag are also deleted (cascade via `Aeo::Tag has_many :taggings, dependent: :destroy`). Every prompt that had this tag will lose it. - The response includes `tagged_prompts_count`: the number of prompts that lost the tag. Use this to communicate the blast radius back to the user. IMPORTANT: This action is destructive and cannot be undone via this tool. Always show the user the tag name AND `tagged_prompts_count` (look it up first via `list_tags` + `list_aeo_prompts` if needed) and get explicit confirmation before calling.

List tags for a specific Brand Kit. Tags are user-defined labels applied to prompts within a Brand Kit. They are typically used to filter analytics by arbitrary groupings (e.g. priority, campaign, theme) that go beyond topics.

Update the country, persona, and platform assignments of one or more existing AEO prompts on a Brand Kit. Writes to the brand kit's draft session ONLY — changes do NOT take effect until you call `commit_aeo_prompt_assignments`. Semantics: - For each entry in `prompts`, the arrays you pass REPLACE that prompt's current draft assignments for the given dimension (full-sync per prompt). - Omitting a dimension array CLEARS that dimension on the prompt (e.g. omitting `persona_ids` removes all persona assignments from that prompt's draft). - At most 100 prompts can be updated per call. Workflow: 1. Call `update_aeo_prompt_assignments` to stage your changes in the draft. 2. Inspect `limit_exceeded` in the response. If true, the workspace would exceed its estimated-answers quota on commit. Adjust by calling `update_aeo_prompt_assignments` again, or call `discard_aeo_prompt_assignments` to abandon. 3. When ready, call `commit_aeo_prompt_assignments` to apply the draft to live. Always confirm with the user before committing. IMPORTANT — shared draft with the UI: - There is one draft per brand kit, shared between MCP and the human-facing UI. - If the user has unsaved UI edits, your edits accumulate in the same draft. A subsequent commit will publish both sets of edits together; a discard will destroy both. Surface this to the user before committing or discarding. To discover prompt IDs and current assignments, use `list_aeo_prompts`. To inspect current draft state without modifying it, use `get_aeo_prompt_assignments_status`.

Commit the current prompt-assignment draft for a Brand Kit to live. Replaces all live country, persona, and platform assignments for the brand kit's prompts with the draft data. The workspace's estimated answers limit is enforced. If committing would push the workspace over its quota, the call is rejected with an `AnswersLimitExceeded` validation error containing `estimated_answers` and `max_answers` in `details`. Recover by calling `update_aeo_prompt_assignments` to adjust, or `discard_aeo_prompt_assignments` to abandon. IMPORTANT: - This action affects live data and is not undoable except by manually editing assignments again. Always get explicit user confirmation before calling. - If the human user has unsaved UI edits in the same draft, those will also be committed. Surface this to the user before proceeding. - After a successful commit, a fresh empty draft is automatically re-mirrored from the new live data. You may immediately stage further edits with `update_aeo_prompt_assignments`. - This tool does NOT return the new live estimated-answers/month. If you or the user need the post-commit estimates, call `get_aeo_prompt_assignments_status`. Do NOT reuse the pre-commit `draft_estimated_answers` from `update_aeo_prompt_assignments` and do NOT compute the estimate yourself — repetition-times, persona/country/platform interactions, and concurrent edits can all shift the result.

Discard the current prompt-assignment draft for a Brand Kit. Throws away ALL uncommitted edits — both your own and any unsaved edits the human user made in the UI — and re-mirrors a fresh empty draft from live. Live assignments are never touched. IMPORTANT: - This action is destructive and unrecoverable. Pending UI edits the user has not committed will be lost. - Always get explicit user confirmation before calling. - Calling discard when no draft exists is a no-op; a fresh empty draft is still created so further `update_aeo_prompt_assignments` calls work without setup.

Inspect the current prompt-assignment draft state for a Brand Kit without modifying anything. Read-only. This is the authoritative source for workspace estimated-answers numbers (live and draft). Call it whenever you need them — never compute or guess them yourself. In particular: - At the start of a session, to detect a pre-existing draft from unsaved UI edits. - Immediately after `commit_aeo_prompt_assignments`, to read the new live `estimated_answers` — the commit tool does not return them. - Before staging more changes via `update_aeo_prompt_assignments`, to compare against `max_answers`. Returns: - `has_draft`: whether a draft session exists for this brand kit. - `has_changes`: whether the draft has uncommitted edits relative to live (null if no draft). - `draft_id`: the draft's ID (null if no draft). - `live_estimated_answers`: current workspace estimated answers/month based on live assignments. - `draft_estimated_answers`: what the workspace estimated answers/month would be if the draft were committed now (null if no draft). - `max_answers`: the workspace's effective answers limit. - `limit_exceeded`: whether committing the draft now would exceed the limit (false if no draft).

Query analytics data and display it as an interactive chart. Returns data with a UI reference for visualization. Today's data is still being processed — always use yesterday (2026-07-03) or earlier as end_date. CONSTRAINTS: (1) Only metrics from the same scale group can be plotted together: percentage metrics (mention_rate, share_of_voice, citation_rate, citation_share, sentiment_score, first_mention_rate), count metrics (citation_count, answer_count), or position metrics (average_position). (2) Area and bar charts support only single metrics with single dimensions. (3) Line charts support up to 2 dimensions (date + optional grouping), but when using 2 dimensions only a single metric is allowed.

Query analytics data for a Brand Kit with flexible metrics, dimensions, and filters. Today's data is still being processed — always use yesterday (2026-07-03) or earlier as end_date . "Use this to set appropriate date ranges when users ask about recent metrics without specifying dates. IMPORTANT: USE chart_image_url WHEN YOU NEED TO EMBED A CHART IN NOTION/GOOGLE DOCS, ETC."

List saved analytics reports for a specific Brand Kit. Reports are saved analytics views for a Brand Kit. They contain modules that display different analytics metrics.

Get a specific report by ID with its module configurations. Reports are saved analytics views for a Brand Kit. They contain modules that display different analytics metrics.